作为公司实时数仓的第一个实践者，我记录了自己对一些规范和实时数仓理解的定义。
流式数仓概述#
建设目的#
清晰的数据结构：使每个数据层都有自己的作用和职责，以便在使用和维护时更加方便和理解。
简化复杂问题：将复杂的任务拆分为多个步骤来逐步完成，每个层只解决特定的问题。
统一的数据口径：通过数据分层，提供统一的数据出口和输出口径。
减少重复开发：规范数据分层，可以复用数据，开发通用的中间层，极大地减少重复计算的工作量。
设计理念#
实时流处理链路（Flink + Kafka）对数据进行分层，包括 ODS、DWD、DWS，并实时写入在线服务层，提供实时 OLAP 服务。
- 与离线数仓相比，实时数仓的数据源存储不同，基于 Kafka 设计数仓，明细数据或汇总数据都存储在 Kafka 中，维度信息考虑从 HIVE T+1 读取。
- 相比于离线数仓，实时数仓没有复杂的业务逻辑，更加注重数据的流转效率，数仓的层次更少。
- 各层之间的数据流转和计算通过 Flink 来完成。
适用场景#
运营层面：例如实时业务变化、实时按主题的统计分析，以及当日分时业务趋势分析等。
生产层面：例如实时系统是否可靠，系统是否稳定，实时监控系统的健康状况等。
C 端用户：例如搜索推荐排序，需要实时行为、特点等特征变量的生成，给用户推荐更合理的内容。
风控侧：实时风险识别、反欺诈、异常交易等，都是大量应用实时数据的场景。
针对 OLAP 的架构设计#
数仓设计示例#
分层#
| 层级 | 名称 | 存储方式 | 层级描述 |
|---|---|---|---|
| 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 名称区分大小写
问题#
- Lambda 架构导致口径不统一等问题（考虑使用 Flink 14 + 批流通一 API）
- ADS 持久化不完善，加入 Druid、ES 等用于 OLAP
- 复用性与数仓链路每层可查询的需求（Hive Catalog 永久表存储）