目录#
架构#
参考架构#
参考架构-快手 基于Kafka+Hive-Lambda架构 [6]#
参考架构-vivo 基于Hudi-批流一体架构 [4]#
参考架构-腾讯 基于Hudi-批流一体架构 [3]#
美团 基于Doris [1]#
痛点 [5]#
传统 T+1 任务#
- 海量的TB级 T+ 1 任务延迟导致下游数据产出时间不稳定。
- 任务遇到故障重试恢复代价昂贵
- 数据架构在处理去重和 exactly-once语义能力方面比较吃力
- 架构复杂，涉及多个系统协调，靠调度系统来构建任务依赖关系
Lambda 架构痛点#
- 同时维护实时平台和离线平台两套引擎，运维成本高
- 实时离线两个平台需要维护两套框架不同但业务逻辑相同代码，开发成本高
- 数据有两条不同链路，容易造成数据的不一致性
- 数据更新成本大，需要重跑链路
Kappa 架构痛点#
- 对消息队列存储要求高，消息队列的回溯能力不及离线存储
- 消息队列本身对数据存储有时效性，且当前无法使用 OLAP 引擎直接分析消息队列中的数据
- 全链路依赖消息队列的实时计算可能因为数据的时序性导致结果不正确
Tradeoff 总结 [5]#
总的来说，数据湖 替换 Kafka 的优势主要包括：
- 实现存储层的流批统一
- 中间层支持 OLAP 分析
- 完美支持高效回溯
- 存储成本降低
当然，也存在一定的缺陷，如：
- 数据延迟从实时变成近实时
- 对接其他数据系统需要额外开发工作
实时数仓-分层 [1]#
数据源 ODS#
明细层 DMD#
- 目的是给下游提供直接可用的数据
- 要对基础层进行统一的加工，比如清洗、过滤、扩维等
- 按照主题进行管理
汇总层 DMS#
- 所有的指标都统一在汇总层加工
- 汇总指标池
按照统一的规范管理建设，形成可复用的汇总结果
实时数仓-构建流程 [1]#
搭框架
数据建设的层次化定规范
每一层加工到什么程度，每一层用什么样的方式时效性
设计的时候，层次不能太多
数仓建模#
事实表 [2]#
- 事务事实表
- 周期快照事实表
- 累积快照事实表
维度表 DIM [2]#
类型
- 星型模型
维表只和事实表关联，维表之间没有关联，查询性能好，但冗余度高
一般而言，我们都使用星型模型。 - 雪花模型
雪花模型是星型模式中的维度表进行规范化处理，进一步分解到附加表（维表）中冗余度小，但是查询性能差。
将一个维表拆成核心表和拓展表
- 星型模型
存储
- HBase
- Redis
- MySQL
维度关联 [6]#
在 DWD 层的实战中，DWD 表需要进行维度扩展是非常常见的需求。在我们的实战中，维表扩展会基于维表的具体情况选择不同的关联方式。
- 在大多数情况下维表变化比较稳定，我们会选择借助第三方 KV 存储，使用 UDF 直接访问 KV 存储来实现维表扩展。但在选择第三方 KV 存储时，当维表内容特别大时选择 kiwi、当 QPS 较高时选择 Kcatch。
- 当维表变化频繁且对时效性要求较高时，选择 interval join。借助 interval 时间范围的特性来达到合理控制状态大小的目的。
- 当维表关联逻辑比较复杂，为了任务的稳定性和扩展性，我们会通过自定义维表进行关联，手动维护状态管理的过程，实现 DWD 维表的扩展。
实时数仓的 DWS 层只有在数据量特别大且聚合后的数据量有明显减少的场景下才会构建。如果 DWD 层的 QPS 比较小，一般会直接省去 DWS 层的建设。这样的做法不仅可以保证数据的及时性，同时也缩短了指标产出的链路，进而保证了任务的稳定性。
ADS 层 - 以窗口为核心的解决方案 [6]#
| 场景 | 窗口 |
|---|---|
| 在针对当日累计的场景，即要求每分钟实时产出从当天 0 点开始到当前统计时间分钟截止的总指标值的需求， | cumulate window。 |
| 针对活动累计场景，即活动一般会持续 n 天，则需求要求每分钟实时产出从活动开始到当前统计时刻为止的总指标值。 | infinity_cumulate window。 |
| 在针对分布类的指标需求时，即需求指标会随着时间的推移出现波动。同一粒度下我们需先拿到最新的数据状态，再进行下一步汇总的统计。 | unbounded+infinity_cumulate window。 |
| 在针对单直播间累计的场景下， | dynamic_cumulate。 |
ZHYT#
