什么？实时数仓竟然这么简单？

俺作为公司实时数仓第一个实践者 记录自己定义一些规范与实时数仓理解

流式数仓概况

建设目的

清晰数据结构：让每个数据层都有自己的作用和职责，在使用和维护的时候能够更方便和理解
复杂问题简化：将一个复杂的任务拆解成多个步骤来分步骤完成，每个层只解决特定的问题
统一数据口径：通过数据分层，提供统一的数据出口，统一输出口径
减少重复开发：规范数据分层，可以数据复用，开发通用的中间层，可以极大地减少重复计算的工作

设计理念

实时流处理链路 (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 永久表存储）