俺作为公司实时数仓第一个实践者 记录自己定义一些规范与实时数仓理解
流式数仓概况#
建设目的#
清晰数据结构：让每个数据层都有自己的作用和职责，在使用和维护的时候能够更方便和理解
复杂问题简化：将一个复杂的任务拆解成多个步骤来分步骤完成，每个层只解决特定的问题
统一数据口径：通过数据分层，提供统一的数据出口，统一输出口径
减少重复开发：规范数据分层，可以数据复用，开发通用的中间层，可以极大地减少重复计算的工作
设计理念#
实时流处理链路 (Flink + Kafka) 对数据进行分层 ODS，DWD，DWS，并实时写入在线服务层，提供在线服务 (实时 OLAP)
- 与离线数仓相比，实时数仓的数据源存储不同，基于 kafka 设计数仓，明细数据或者汇总数据都会存在 Kafka 里面，维度信息考虑从 HIVE T+1 读取
- 相比于离线数仓，没有复杂的业务逻辑，更加追求数据的流转效率，数仓的层次更少
- 各层之间的数据流转和计算通过 flink 来完
适合场景#
运营层面：比如实时业务变化，实时按主题的统计分析，以及当日分时业务趋势分析等。
生产层面：比如实时系统是否可靠，系统是否稳定，实时监控系统的健康状况等。
C 端用户：比如搜索推荐排序，需要实时行为、特点等特征变量的生产，给用户推荐更加合理的内容。
风控侧：实时风险识别、反欺诈、异常交易等，都是大量应用实时数据的场景。
针对 OLAP 的架构设计#
数仓设计示例#
分层#
| 层级 | 名称 | Stroage | 层级描述 |
|---|---|---|---|
| ODS | 贴源层 | cdc 后写入 Kafka/flink-cdc-table | 采集的非结构化数据 |
| DWD | 明细层 | kafka | 过滤、连接、打宽 （filter union join） |
| DWS | 汇总层 | kafka | 业务聚合 （agg win ,join 维度） |
| ADS | 应用层 | ||
| DIM | 维表层 | upsert-kafka | hive 维表，明细关联 |
ods ：
业务库 binlog：一般来自各类关系型数据库 binlog。
系统日志：日志一般是以文件的形式保存，使用 Flink、Kafka 来实时接入
消息队列：来自 Kafka 的数据等
dw：
flink 处理模型 ，按照主题划分
ads：
一般就直接对接 OLAP 分析，或者业务层数据调用接口了。
这是最顶层，一般都是结果类型数据，可以直接拿去使用或者展示的数据了，也是对数据抽离分析程度最高的一层数据。
dim 来源：
明细数据维度，来源 hive。
案例#
食品安全业务为例
设计#
ods ：realtime_ods_采集来源。库名。表名
dwd ：realtime_dwd. 表名
dim ：realtime_dim. 维度表名
dws ：realtime_dws. 按需打宽业务名
ads ：realtime_ads. 指标名
topic 示例：
注意：topic 名字区分大小写
Issues#
- lamda 架构，导致口径不统一等问题 （考虑 flink 14 + 批流通一 api）
- ADS 持久化不完善，加入 Druid、ES 等做 OLAP
- 复用性与数仓链路每层可查的诉求（hive catalog 永久表存储）