架构师必备：后端程序员需要了解的数仓知识-编程阁

后端程序员平时除了接触业务代码、中间件、存储等，也难免会跟数仓有交集。下面结合笔者的经验和思考，从后端程序员的视角看数仓、做个总结，后续再跟数仓/BI argue的时候就不虚了😃

分成两部分介绍：离线数仓、实时数仓。

离线数仓

离线数仓是最典型的数仓应用场景。后端服务产生了业务数据、监控埋点、日志等，如果要做统计分析，就要先离线采集到数仓，再通过SQL做聚合查询。离线数仓的重点，在于统计分析历史存量数据，做合理的业务域划分、数据分层、数据分区。

数据采集

需要采集的数据包括：业务数据、监控埋点、日志等。

业务数据：一般存储在DB、或HBase，可一次性把存量数据导入hive表，后续定时扫描一段时间范围内的增量数据导入hive表
监控埋点：后端服务发出埋点消息，采集程序消费消息、解析、最终导入到hive表
日志：可通过filebeat采集日志，采集程序解析后、导入到hive表

数据分层

逻辑层面的水平数据分层：

ODS (Operational Data Store)：原始数据，一般不做任何加工
DWD (Data Warehouse Detail)：数仓明细数据，在ODS的基础上做一些简单加工，如数据清洗，解析json格式字段、打平后存储
DWS (Data WareHouse Summary)：数仓汇总数据，在DWD的基础上按维度做聚合宽表，方便业务方使用
ADS (Application Data Service)：直接可用的报表应用数据

离线数仓的数据分层，类似于后端代码结构的分层设计，比如分为接口层interface、逻辑层service、数据访问层repository。数据分层可以隔离每层之间的依赖，每层的变更只限于本层。比如mysql拆库迁移只需要更换ods表，但无需改dwd表，这样数据使用方不用感知数据源变更。数据分层可以在DW层聚合数据，提高数据使用方的效率、降低开发成本。

后端程序员接触最多的是ods和dwd表：

ods表涉及到数据采集，并且是归档删在线数据的前提
dwd表可以用来排查历史数据，因为json格式字段已打平，所以方便做筛选查询

数据分区

按时间维度做垂直分区，一般是日级或小时级分区，取决于调度频率：

天级增量表：包含某一天有变更的数据记录
天级全量表：包含某一天完整的数据记录，相当于快照
小时级增量表：包含某一小时有变更的数据记录

因为数据量较大，所以不是所有的离线表都会永久保留。比如ods天级增量表可能仅保留最近n天、或最近n个分区，而dwd天级全量表会merge增量数据，可查到历史上的所有数据记录。

离线数仓使用场景

离线统计：
- 通过hive sql做复杂的关联查询、聚合查询，底层会转成MapReduce任务，查询HDFS里的hive表
- 比如把多张事实表、维度表join起来，做某个维度的数量加总、金额加总。事实表是业务活动的事件记录，可以做聚合查询统计。维度表是元数据，按维度做聚合分析（max、count，group by维度）。事实表一般包含多个维度表的外键。

后端刷历史存量数据：需要先在离线统计符合条件的数据，再导出id消息，作为后端刷数据的输入依据

后端归档删除在线数据

后端在线数据不断膨胀，当业务层面不再访问时，需要做归档删除。一定要确保业务数据先被离线采集到、再删除在线数据，否则就可能丢数据、找不回来了。比如新增一个archive_status字段代表归档状态（而非有业务含义的deleted字段），初始值是0，被软删后改成1，那么如果hive表里记录的归档状态是1，则代表该记录已被离线采集到，可放心地删除对应在线记录。

实时数仓

有了离线数仓，为什么还需要实时数仓呢？

主要还是为了时效性，离线数仓最快是小时级，如果需要秒级延迟，就需要上实时数仓了
实时数仓跑出来的结果，可以被后端服务查询，用于在线业务

实时数仓的重点，在于低延迟计算、exactly-once处理，与后端应用结合可以实现很多功能。

实时数仓构建流程

使用flink把数据采集、数据计算、数据导出的流程串起来。这里引用一张某云厂商的实践教程图，里面的数仓存储可替代为其它。参考：实时数仓搭建

实时入仓：mysql binlog、或业务事件，触发实时数据流，通过flink实时入仓
数据计算：通过flink关联join多个ods表，得到dwd表，再实时计算得到按维度聚合的dws表
数据导出、对外提供接口查询：计算结果可导出到实时数仓，如Doris、Hologres等，也可以导出到mysql、hbase、或redis，并封装成RPC接口。这样后端服务可以查询实时数仓接口，对外提供高qps查询