实时数仓 2.0 版本
随着数据量的暴涨，HBASE中的埋点数据源经常查询超时，同时各业务消费实时数据的需求也开始增多，如果继续沿用实时数仓 1.0 架构，需要付出大量的额外成本。于是，在实时数仓 1.0 的基础上，我们建立起了实时数仓 2.0，梳理出了新的架构设计并开始着手建立实时数仓体系，新的架构如下图所示。
缓冲层 ODS
实时数仓 1.0 我们只对用户行为日志数据做 ETL 处理，在 2.0 版本中我们加入了对业务库的变更日志 Binlog 的处理，Binlog 日志在缓冲层为库级别或者 Mysql 实例级别，即：一个库或者实例的变更日志存放在同一个 Kafka Topic 中(zb)。同时随着公司业务的发展不断有新 App 产生，在原始层不仅采集APP日志，像小程序以及内部孵化的项目的埋点数据也需要采集，不同 App 的埋点数据仍然使用同一套 Schema。
明细层 DWD
明细层是我们的 ETL 层，这一层数据是由原始层经过 Flink Streaming ETL 后得到。其中对 Binlog 日志的处理主要是完成库或者实例日志到表日志的拆分，对用户行为的日志主要是做一些通用 ETL 处理，由于我们使用的是同一套数据结构，对不同 App 数据处理的逻辑代码可以完全复用，这大大降低了我们的开发成本。
明细汇总层 DWS
明细汇总层是由明细层通过 ETL 得到，主要以宽表形式存在。业务明细汇总是由业务事实明细表和维度表 Join 得到，用户行为日志明细汇总是由用户行为日志日志按业务线拆分和用户行为日志维度 Join 得到。用户行为日志按业务拆分后可以满足各业务实时消费的需求，我们在用户行为日志拆分这一块做到了自动化，下图演示了用户行为日志数据进行自动化切分的过程。
Streaming lib是用户行为日志分发模块，它消费上游 ETL 后的全量数据并定期读取埋点元数据信息，通过将用户行为日志数据与元信息数据进行「Join」完成按业务进行用户行为日志拆分的逻辑，同时也会对切分后的用户行为日志按业务做 ETL 处理。 只要埋点元信息中新增一个埋点，那么这个埋点对应的数据就会自动切分到该业务的 Kafka 中，最终业务 Kafka 中的数据是独属于当前业务的且已经被通用 ETL 和业务 ETL 处理过，这大大降低了各个业务使用数据的成本。
数据集市层:汇总层之指标汇总
数据集市层是由明细层DWD或者明细汇总层DWS通过聚合计算得到，这一层产出了绝大部分的实时数仓指标，这也是与实时数仓 1.0 最大的区别。某互联网公司是一个广告的平台是一个流量中心，对业务指标的汇总我们可以从广告内容角度和用户角度进行汇总，从内容角度我们可以实时统计内容（内容可以是广告文案，广告素材，广告形式，广告受众人群，广告投放省份）的展示数、点击数、ECPM、ARPU等指标，从用户角度我可以实时统计用户的点击数、转化数、曝光数、填充数等指标。对流量指标的汇总我们分为各业务指标汇总和全局指标汇总。对各业务指标汇总，我们可以实时统计视频广告，文章广告，硬广等广告业务的曝光数、点击数、CTR 等，对全局指标汇总我们主要以实时会话为主，实时统计一个会话内的 广告页面PV数、广告页面曝光数、广告页面点击数、广告内容浏览深度、会话时长等指标。
福利大放送
为了更好地帮助大家学习，
限时放送1v1模拟面试and职业规划分析诊断大礼包！
不管你是想在职提升，还是跳槽学习，
亦或者转行学习and毕业求职
这份礼包都是你不可错过的必备神器！
果汁建立了数据知识分享社群，
群内每天都有干货和免费小课资料分享。
数量有限、先到先得
根据下方方式
领取大礼包
