引言
数据仓库想必每个行业从业者都在以各式各样的方式进行实践和应用，在久远一点叫做离线数仓，后来由被称为数据中台等演化名称，再往后，又衍生到现代化实时数据栈这样的概念中，但说到底，终究还是为了解决数据的接、存、管、算、查这五个要义的，无论是多么具有附加价值的其他能力，也都是围绕这五个基本核心功能延展的。
那今天我们主要来念叨念叨，在我从业这些年沉淀下来的关于数据仓库方向的一些个人观点和看法，尤其这两年主要在参与 Apache Doris 和 SelectDB 实时数据仓库的解决方案架构设计、技术支持和生态研发的过程中，在司内和业内诸多大佬的言传身教下，个人感觉还是收获满满的，那咱们就 OPEN 起来，来跟大家唠唠我个人眼中的实时数仓。
注：本篇只讨论实时数据仓库，不涉及数据湖组件。
为何要实时化
想必大家也看到了在当前大数据的火热前沿领域，OLAP 数据库的热度是持续走高，无论是老牌大哥 ClickHouse，还是从 21 年开始发力的 Apache Doris，无论是从认知还是从实践上，都把数据时效性这个概念要求标准，提升了不少。
从过往的传统 T+1 或者小时级的数据时效性，突然之间提升到分钟级到秒级，这种感官上巨大的差异性给从业者带来的是一波又一波的焦虑和渴望。
焦虑是负责平台基础建设的同学们思考的事情，要求提速、降本、增效，但是现阶段也没有特别通俗适合的案例做参考，一时之间不知道从何下手；渴望的是负责业务开发和数据应用的同学，因为新的时效性带来的可能不仅仅是取数、出数的快与慢，而在于对于业务本身的帮助，可能非同日而语了。
这里多说几句，为啥时效性会比较大比重的提升整个数据平台在公司/集团内部的重要性呢？
很简单，因为真的会降本增效。
举个例子：
电商公司在某一次新品上市活动中投入了大量的人力物力，做了广泛的渠道宣发和营销触达等动作，营销总监希望尽快的拿到这一波触达后的营销数据，因为无论是根据已触达的人群的反馈做二次营销，还是根据未成功触达的人群做二次触达，时间越前置，那么二次触达/营销的效果就越好。
根据上述理论举个不是特别恰当的比喻：
情景一：你点了一个外卖，感觉质量还不错，店家在你刚刚酒足饭饱满意的剔牙的时候给你打电话求一个五星好评
情景二：第二天了你都忘了昨天的那味咋样了，或者已经又吃了一家，觉得昨天那味道也就一般般，这时候店家打电话过来索要好评
这两种情况下，成功概率完全是不一样的。
所以在业务场景，提升到分钟级和秒级的时效性对业务形态的帮助会很大。
同时重中之重的一点一定是比较关键的，这也是很多公司匆匆组建大数据部门，随后又匆匆裁剪的原因：阐述不清楚数据部门对公司业务产生的帮助价值，换句话说就是业务部门不认可数据部门提供的价值。
而平台部门和数据部门，往往都是整个公司/集团的成本部门，想要成本部门逐步做强做大，或者最起码保住基本盘，就是让那些受你技术利好的业务方认可你的价值，而时效性是最能很明显的提升业务价值和使用体感的方面。
所以实时化一方面是为了满足日益增强的业务应用诉求，一方面是为了降本增效，还有一方面，是为了讲明价值、提升不可替代性。
数仓中实时的含义
首先我们明确一个点，实时数仓的实时怎样界定？
纳秒？微秒？毫秒？还是秒级？分钟级？
从我接触和实践的数百家企业的具体应用来看，这不是一个明确的概念值，以下个人结论加粗标识：
应以业务方接受的最大延迟限度作为实时的研发标准。
道理很简单，无论是开发 APP，还是做基础平台，我们一定应以用户体感和用户看问题的角度来做整体架构设计和能力定位，比如：
- 1. 你的用户对象是之前是用 Hadoop-Hive 那一套的同学，那么从 T+1 或小时级提升到分钟级，他们就会觉得，这已经很实时了；
- 2. 你的用户对象是用 ClickHouse 做 OLAP 查询的同学，那么你想在查询端更实时，那很困难了，但是如果链路性时效性提升呢？比如之前都是离线数仓的 ADS 层报表通过 Sqoop 同步一份到 ClickHouse，现在用 Flink 做直接部分业务指标的实时计算，这时候他就会觉得，这很实时了；
- 3. 你的用户对象之前是用 Hadoop-Spark 的同学，那么你只有提升到时效性到秒级，他才会有比较大的感触；
- 4. 你的用户对象之前是用 Flink+Kafka+Hbase 做纯流式指标计算，那么你无论怎样提升链路时效性，他都会没啥太大的感觉，这时候如果你能解决 Flink+Kafka+Hbase 不太好完成复杂运算、整体任务编排运维复杂、中间态数据重复利用等问题【比如数据迟到等等问题】，那么他才会有比较大的感触。
所以针对不同的同学，对实时的体感或者要求是不一样的，像之前我遇到的有金融行业的部分核心系统，需要关联数据查询时延在 5ms 内，对你没看错，是五毫秒内，这种就对单一组件的要求极高了。
这里还有两个关于实时的概念我们掰开来扯一扯。
- 1. 实时数仓的实时定义是哪些部分实时？
- 2. 我们需要完全纯流式实时的数仓么？
第一个问题，我认为实时数仓是在满足业务方接受的最大延迟的限度下，接、存、管、算、查全链路的实时化才叫现代化实时数仓，不是单纯查的快或者存的快，完整链路的时效性提升才算实时化。
第二个问题，我认为时效性趋近实时化是大势所趋，但是完全纯流式实时的数仓是一个伪命题，这里我想表述两个点：
- 1. 从我参与或者主导过的数百家企业的数仓演进方案的角度而言，绝大部分的业务场景，尤其是分析类场景，数据时效性只需要3-5分钟级，在这个级别的业务诉求占据了绝大部分，同时有少量的业务场景需要秒级的全链路实时性，有极少数的业务场景才存在毫秒级及以内的数据时效性诉求。
换而言之，从 T+1 进化到分钟级，以当前的解决方案和组件能力而言，可能不是什么难事，反而还可能降低机器成本，同时业务方一般在分析查询领域，分钟级其实对他们而言是完全够用的，一个查询结果生成到后续人工讨论出决策方案然后再落地执行，这种周而复始的工作周期分钟级的时效性粒度可以充分的满足，这就完美的实现全面的降本增效，打了一手好牌。 - 2. 那如果是从分钟级要求到毫秒级，这时候随便划拉一个场景：一批数据（可认为是有界流的方式）生成后需要根据这批数据的各个维度做复杂链路加工，数据量级每日新增 1TB。有经验的同学一看就头大了，因为这种你要支持到毫秒级，那花的资源可就不是降本增效了，而是超级加倍也可能完成不了。
加倍了资源，可能得到了一个做不到的结论或者不稳定的一个业务服务系统，那么接下来的结果可能就不是很乐观了~
所以综上，一个小建议给大家，尽可能不要给业务许诺太过于好看的时效性，尽可能给自己争取到更多的冗余空间，因为无论咋说，保住工作才会有各种后续，对吧 ^_^
实时常见方案常见诉求
那聊完了两个概念的定义以后，我们来看看我们需要怎样的解决方案。
按需求的优先级，我们划拉一下我们需要解决的问题。
我们希望的是（或者你期待解决的场景如果是）：
- 1. 大部分的简单业务时效性足够高，最好实时，但是数据要保证一致性，最终一致性
- 2. 整体架构复杂度低一些，不想引入太多组件增加运维成本
- 3. 能做主数仓，不需要强依赖使用离线数仓做数据校对
- 4. 能处理一些复杂计算，但是时效性要求不要太迟
- 5. 数据存储压缩比不要太高，可以降低一些存储成本
- 6. 整个实时数仓的架构生态拓展性要好，比如可以对接其他组件做联邦之类的，减少工作复杂度
- 7. 最好能流批一体、离在线一体，共用一份数据，减少数据冗余性
- 8. 稳定性要足够好，最好像 MapReduce 一样稳定……
基于 Apache Doris 的实时数据仓库
能力描述
查询能力
- 1. 大宽表查询
「ClickBench-Top1」 - 2. Join查询
「等量资源下比 Impala 快 5-10 倍」 - 3. 高并发点查
「单台节点可至 3w QPS 20-50ms 延迟」 - 4. 联邦查询
「数据湖、十几个支持 JDBC 协议的 TP 库」 - 5. 日志检索
「速度与 ES 持平，存储下降 80%，吞吐提升 5 倍」 - 6. 库内 ELT
「等资源下数仓调度比 Hive 快 8-10 倍」
在整个数据分析领域，实质上绝大部分查询都是以上六种查询姿势，所以这也是为什么 Apache Doris 能做一个轻量级实时数据仓库的底气所在。
导入能力
- 1. 文件
「JSON、CSV、Parquet、ORC 等」 - 2. 业务数据库
「MySQL、Oracle、DB2、SQLServer 等」 - 3. 程序运行数据
「Java、Go、Python 等」 - 4. 消息中间件和日志采集工具
「Kafka、logstash、flume 等」 - 5. 计算引擎和工具
「Spark、Flink、DBT、Airbyte 等」 - 6. 数据同步工具
「X2Doris、Datax、SeaTunnel、Hop、Kettle 等」
还有未尽的其他方向的导入能力
存储能力
- 1. 单次导入事务性控制，可保证精准一致性语义
- 2. 存储默认3副本，以多数派原则满足写时可靠性
- 3. 导入后自动进行 Compaction，无需手动执行
- 4. 3副本下若有坏片可自动调度修复
- 5. 数据均衡 Rebalance 自动完成
- 6. 增删节点数据迁移自动完成无需手动
- 7. 冷热分层大幅度降低存储成本
- 8. 备份恢复机制
- 9. 数据吞吐速度最高可至 1GB/s【日志场景】
内核能力
- 1. 分布式 Join MPP 计算框架
- 2. CBO + RBO
- 3. Pipeline 执行引擎
- 4. 向量化计算引擎
- 5. Catalog 联邦能力
- 6. 行列混存 + 短路径优化
- 7. WorkLoad Group
- 8. 库、表、行、列【重构中】完备权限
综上，数据从接入到存储再到查询，Apache Doris 的全链路生态完备齐全，能力覆盖范围齐全，各项性能也基本都是T0梯队的，所以基于以上的各方面综合能力论述，Doris 是可以满足轻量级实时数据仓库这一现代化数据仓库演进路线的诉求的。
没错，它就是海纳百川的那个海~
构建建议
基于 Apache Doris 构建实时数仓基本上有如下几种方案：
- 1. 微批调度方案
- 2. 物化视图方案
- 3. 流批结合方案
- 4. 离在线一体化（湖仓一体化）方案
这里由于篇幅过长，就不展开做各项方案的介绍了，这一块会另起一篇来做介绍。
这里来介绍一些在构建实时数仓时候的实现建议：
- 1. 分层构建理论永不过时，但是由于实时数仓追求的时效性要求相对离线数仓较高，同时实时数仓的计算能力又强于离线数仓的计算能力，故而分层不必按离线数仓的 4-5 层进行划分，若业务复杂性低，一般 2 层就可以提供服务，若业务复杂性高，3 层也基本可满足大部分的业务场景，把构建模型做薄有利于数据流转和数据治理。
- 2. 调度尽量以分区调度为主，Partition 粒度应当随着业务粒度进行合理划分，常见粒度为天级别粒度，往往在业务上 1-7 天的数据使用率会比较高，同时在近七天这个区间内，往往以当天数据使用占比最大，所以合理的分区可大幅度降低数据加工时的资源压力和调度速度，以此来提速整理数据流转效率。
- 3. 在业务开发复杂度、模型复用性、并发度和单查询资源消耗比四个粒度来综合分析开发时的分层模型构建选择，比如若是并发查询度较高的，就尽量固化成上层表来减少资源消耗和提升查询速度与并发度，比如灵活查询较多的，就开放 DW 集市层出去，降低开发工作量，但是这里还得再评估单资源查询复杂度，以及是否开启 SQL 审计和黑白名单等等，以保证大小查询的稳定性，实时数仓建模比较考量业务时效性以及开发成本和集群资源成本的综合性评估能力。
- 4. 在资源管控方面做更多考量，如多租户的资源划分、WorkLoad Group 的资源限制、黑白名单和审计日志的异常阻拦、权限细粒度化控制、内外表及冷热分层的成本缩减等各方面的综合能力利用。需要在一定资源量的情况下完成更多和更合理的资源利用，保证重点任务。因为实时数仓与离线数仓最大的一个不同点在于实时数仓需要更贴近上层应用来完成直接性的业务支撑，所以上层业务的敏感度会非常高，对底层要求也随之变高了。
还有一些余着后面慢慢唠~
小结
本篇主要介绍了实时数仓的基本概念、同时介绍了以 Doris 为基准的实时数仓构建能力选型和构建建议，也没有追求什么语言上的华丽和遣词造句的规整，以大白话的形式给大家写了一篇，还望大家多多见谅~
也是希望以这样的行文，给大家带来一些不一样的思考：我们追求的实时到底是什么东西？
如果大家喜欢，就点个在看和赞，让我更有动力写下去，哈哈哈
老规矩，微信号：fl_manyi
努力更新！争取让看官老爷们看到更广泛的 Doris 使用姿势方法以及经验建议，让大家在实践路上更轻松自在和信心满满！
