随着数据量的不断增大，传统的离线数仓在时效性上已经满足不了我们的需求了，实时数仓架构应运而生。今天我们来总结一下目前市面上常见的一些实时数仓的架构，了解他们的优缺点以及如何在不同的场景中选用正确的架构。
① 数仓分层
数仓分层。我们一般将数仓分为以下几个层次：• ODS层
ODS是数据接入层，也叫贴源层。所有接入的数据首先会进入ODS层。一般来说ODS层的数据的来源比较丰富。从数据粒度上看ODS层是粒度最细的数据层。• DIM层
DIM是维度层。这种数据一般变化不大，数据量也不会太大，可以结合事实表进行关联形成宽表。• DWD层
DWD是明细数据层。是经过ODS层清洗，转后的干净的数据。DWD层数据粒度通常和ODS的粒度相同，不同的是该层的数据质量更高，字段更全面等。• DWS层
DWS是主题数据层。面向主题来组织数据的，通常是星形或雪花结构的数据。从数据粒度来说，这层的数据是轻度汇总级的数据，已经不存在明细数据了。• ADS层
ADS是数据应用层。它是完全为了满足具体的分析需求而构建的数据，也是星形或雪花结构的数据。从数据粒度来说是高度汇总的数据，其汇总的目标主要是按照应用需求进行的。
• 数仓分层有时候并不一定按照严格的 ods -> dwd -> dws -> ads 顺序来进行建设。可以根据具体情况随意组合。 • 数仓分层的总体思路是用空间换时间，利用大量的预聚合操作来提升用户体验。
② 几种常见的实时数仓方案
方案1. Kappa 架构
• Kappa架构将 App 日志、系统日志、binlog日志 等实时地发送到Kafka • 然后通过 Flink，按照不同的业务构建不同的流式计算任务，对数据进行分析和处理 • 接着将计算结果输出 MySQL、ES、HBase、KUDU 等数据库中 • 最终将计算结果通过 BI 报表进行展现
优点
缺点
• 每来一个需求或者需求变更时，都需要定制化开发，开发成本和时间成本都比较高 • 对于 flink 集群的要求比较高
方案2. 数仓分层 + flink
• 首先将数据接入 ODS 贴源数据层 • 再使用 Flink 对 ODS 层数据进行 ETL、转换等操作，形成 DWD 数据明细层，并将结果发送到 Kafka • 接着使用 Flink 形成 DWS 轻度汇总层 • 最后在 DWS 层上进一步对数据进行汇总形成 ADS 层供业务人员使用
优点
缺点
方案3. 数仓分层 + flink + 数据湖
优点
• 实现了流批一体，基于同一个 Flink SQL 既可以进行流计算，也可以进行批计算 • 将流计算和批计算的存储进行了统一，这样数据的血缘关系的和数据质量体系的建立也变得简单了 • 数据的各层（ODS、DWD、DWS、ADS）数据，都支持OLAP的实时查询 • 流式的 Upsert(Delete) 功能。流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的，而离线数仓做更新的话需要全量数据覆盖，而数据湖刚好能解决这个问题
方案4. 基于全场景MPP数据库
• 实时数据直接写入 kafka • 离线数据可以转为流数据写入 kafka，也可以通过 broker load 等方式导入 doris • 使用 doris 的 stream load 将 kafka 数据实时导入 doris 数据库 • 基于 doris 表可以建立物化视图、rollup 等提高查询效率 • 基于 doris 表可以直接对外提供统计数据
③ 选型及建议
1. 对于业务简单，且以流式数据为主的大数据架构可以采用方案1 2. 如果以流式计算为主，对数据分层要求比较严格，建议使用方案2 3. 如果想支持更大规模的和复杂的应用场景，人手比较充裕的情况下，建议采用方案3，这也是目前相对比较完善的一个实时数仓架构了 4. 如果想使用起来简单，业务也比较简单，对于分层的要求也不高，可以无脑使用方案4
④ 写在最后
原文作者：毛毛小妖的笔记；如有侵权，请联系管理员删除。
上一篇：
零代码数据同步平台开源啦！！！
下一篇：
如何正确使用Git版本管理工具
请登录后发表评论
登录
全部评论
