数仓架构（离线和实时）--企业版

数仓架构图–企业版

1. 背景

1. 数仓，这是一个并不新颖的词语。在PC时代，就有传统数仓，当时数据一般存放在数据库中，一般是Oracle或者Mysql集群中。因为那时候数据量还不是非常大，所以使用数据库集群就可以进行数据的存储和查询分析，集合前端web页面就能做数据交互式的查询和展示。
2. 进入互联网时代之后，由于移动设备和移动通信技术快速发展，来自移动端的数据几何倍数增加，传统数仓技术已经无法支撑这么海量的数据存储和查询分析。现代化数仓应运而生。
   PS：

• 移动互联网时代，因为都是敏捷开发，为了更好研究客户喜好，改进用户功能和体验，不管是web页面还是app应用，都会将PC时代就有的用户行为埋点功能加上，采集这些用户行为数据日志信息之后，进行存储，分析，提炼有效信息。
• 行为数据埋点，就是当用户打开软件开始到离开软件，中间的动作和行为做记录，如点击一个按钮，收藏，关闭，滑动等等。触发一个业务行为如浏览某个页面，分享等等，甚至app进入后台，关闭app等都会被记录下来。
• 除了行为日志数据之外，还有来自越来越复杂业务端的埋点数据，业务数据等也都需要进行分析处理，用来提炼有效信息。
  大数定理，当数据样本足够大，就一定可以将提炼的信息尽可能接近于事实。今日头条的推荐算法，美国提出的高频交易都是突破了传统观念的技术方向，以数据说话，就是从数据中提炼理论，而不是先设想出一个理论再去验证使用。只要样本足够完整足够大，数据不会说谎。

2. 架构

2.1. 移动端和业务后台做埋点统计和上传

1. 移动端的埋点，一般分为即时埋点和延后埋点，顾名思义，即时埋点就是触发一个动作，就将用户行为埋点数据上传到日志服务器（一般称之为行为日志埋点服务器，日志埋点服务器，日志服务器等不同叫法）。延后埋点就是，考虑到移动端网络信号不稳定原因，一般会将埋点数据一条一条存放到移动端的文件中，等满足触发条件时，再批量上传到日志服务器。
   注意，移动端由于设备性能差异性较大，网络情况复杂，一般不会设置很复杂的日志上传机制，并且允许有一部分数据丢失来应对移动端各种复杂情况。
2. 业务后台埋点，当业务后台触发一些行为时，也会将这些数据上传到日志服务器中。这主要是考虑到进行用户行为流程分析时，一些指标不好在移动端进行采集如订单状态、支付状态、贷款授信状态等的及时变化。

2.2 flume日志采集

1. 因为日志服务器一般是以集群形式存在，日志文件存放在集群各个节点服务器上。这时候一般采用分布式日志采集框架进行采集，flume只是目前比较主流的框架，还可以根据业务需求选择其他日志框架；如果有极致要求，甚至需要自行开发日志采集框架。
2. flume采集架构简单说明

• 在日志采集时，一般使用tailDir Source，这个可以监控多个文件夹，还可以实现断点续传（会记录偏移量）
• 选择channel时,一般是三种选择，file channel、memory channel、kafka channel。

file channel，使用文件做缓存，速度相对最慢，但胜在稳定，断电也不怕数据丢失。
memory channel，速度最快，但断电数据就会丢失
kafka channel，适合需要将数据最后导入kafka集群的场景。

• 选择sink时，可以根据需求，如jdbc sink，hdfs sink等

3. flume是有事务功能，体现在2个阶段，source到channel，channel到sink，事务的本质就是进行一个批量操作并且记录这个批量操作的执行状态。flume的事务在三种事务实现理念中选择的是at least once（另外2种是at most once， exactly once）。特别情况下，数据会有重复。
4. flume有拦截器，选择器，监控器。

• 拦截器就是在数据进入source之后，可以对每条数据做过滤，拦截，打标记。
• 选择器就是可以根据每条数据的特征如拦截器打上的标记对数据做有选择分发分流。
• 监控器，顾名思义，可以对flume做状态监控

flume的最小采集单位是agent，一个agent中由3个模块组成，source，channel，sink。
可以将一个agent看做是一个水泵，source就是进水口，channel就是水泵缓冲空间，sink就是出水口。channel是用来平衡进水口和出水口之间的速度差异的。
agent之间可以按照需求进行级联，组成网络。

注意，如果使用hdfs sink，则注意设置rollSize、rollInterval、rol