作者介绍: 王天宜，TiDB 社区部门架构师。曾就任于 Fidelity Investment，Softbank Investment，领有丰盛的数据库高可用方案设计教训，对 TiDB、Oracle、PostgreSQL、MySQL 等数据库的高可用架构与数据库生态有深入研究。
数据仓库是公司数据倒退到肯定规模后必然须要提供的一种根底服务，也是“数据智能”建设的根底环节。晚期数仓多为离线模式，次要解决的是 T+1 的数据，随着互联网时代的到来，实时数据处理的场景日益增多，离线数仓已无奈满足业务倒退的实时性需要。为更好的解决业务场景的实时化需要，实时数仓建设已成必然趋势，这也是 HTAP 数据库的重要能力之一。
实时数仓相较于离线数仓，次要解决的是 T+0 的数据，实时性更高，完满符合业务高效运行的需要。在架构上，实时数仓通常应用 Flink 来生产 Kafka 中的数据，将数据流实时的写入数据库中。这种计划尽管解决了数据处理的时效问题，但很多时候，因为 Kafka 没有落盘机制，可能在极其的状况造成音讯队列中数据失落。
针对上述问题，笔者调研了页面上的数据库与存储引擎，发现了能彻底解决 Kafka 落盘问题的，更高效精确的实时数仓新计划。
首先，在数据库的抉择上，思考可扩展性更高的分布式数据库 TiDB，从数据库层面解决海量数据存储的问题，其次是分布式流存储引擎 Pravega，解决应用传统音讯队列数据失落问题和主动伸缩难题，进步了实时数仓零碎的并行性，可用性与安全性。以下将详细分析。
TiDB 偶遇 Pravega
Pravega 是一款 DellEMC 开源的流存储我的项目，并曾经进入 CNCF 的 sandbox 阶段。从性能上来看，除与 Apache Kafka、Apache Pulsar 类似，Pravega 提供了 stream、schema registry。除此之外，Pravega 最重要特点是: (1) 无需应用程序感知的主动伸缩能力 (auto-scaling) 和 (2) 是一个残缺的存储接口，提供以 stream 为形象的接口反对下层计算引擎对立的拜访。
分布式消息传递个别都基于牢靠的音讯队列，在客户端利用和音讯零碎之间异步传递音讯。提到音讯队列，无论如何都无奈绕过 Kafka。Kafka 是一个 分布式、多分区、多正本、多订阅者，基于 Zookeeper 协调的分布式日志零碎。Pravege 是在应用 Kafka 实际中总结进去的新的架构。
Pravega 重构了 流式存储的架构。作为流式实时存储的解决方案，应用程序能够间接将数据长久化到 Pravega 中。也正是因为 Pravega 将数据落盘到 HDFS/S3 上，能够不再受限于数据的 retention，并且整个大数据流水线中数据只存储了一份。
Pravega 为何要再造轮子
作为一个浅显的 Kafka 使用者，有 三个问题 使我感到困扰：
- 丢数据的问题，吃进的数据多，吐出的数据少，offset 提交了，会存在丢数据的危险。
- acks = all，只有当所有消费者确认保留了音讯时，才会返回 ack，不会丢数据。
- acks = 1，当 leader 消费者保留音讯就返回 ack，接管的 leader 如果确认后没有来得及备份就挂了，会丢数据。
- acks = 0，不期待任何确认，接管方挂掉时会丢数据。
- Kafka 数据受限于 retention，没有简略高效的 hdfs/S3 落盘计划。商业版本尽管提供了这个性能，然而数据一旦搬运后，你必须应用 2 套存储接口混合拜访处于不同层级的数据。
- 引入 flume，能够走 kafka -> flume -> hdfs 的链路。
- 引入 kafka hadoop loader，能够走 kafka -> kafka hadoop loader -> hdfs 的链路。
- 引入 kafka-connect-hdfs，能够走 kafka -> kafka-connect-hdfs -> hdfs 的链路。
- Consumer rebalance 过程危害甚多。
- 在 consumer reblance 的过程中可能会因为减少 cunsumer 导致暂停队列的生产。
- 在 consumer reblance 的过程中可能因为提交距离长，引发反复生产的问题。
- 暂停生产和反复生产都有可能导致音讯积压，reblance 完结后存在生产突刺的问题。
那么在 Pravega 造轮子的过程中，解决了那些问题呢？以下为 Pravega 与 Kafka 的比照：
Pravega 的特别之处在于，尽管它与不少开源产品一样，也应用 Bookkeeper 去解决并行实时数据低提早写问题，然而 Bookkeeper 在 Pravega 中只作为数据聚合写（batch write）到 HDFS/S3 的第一阶段（惟一例外是在节点意外故障后做复原的时候）。所有对 Pravega 读都间接作用到 HDFS/S3 上以利用它们的高吞吐能力。
所以 Pravega 并不把 BookKeeper 当做数据缓存层，而只是提供了一个基于 HDFS/S3 新的存储层用来同时满足“低延时尾读尾写 ”和“ 高吞吐追赶读”的形象。因而，不像大部分应用“分层”设计的我的项目那样，当数据在 BookKeeper 和 HDFS/S3 之间挪动时候性能将无奈保障。
回归到痛点问题
大部分的 DBA 或者运维人员最关怀的有三件事：数据的正确性，零碎的稳定性，以及零碎的易用性。数据的正确性是 DBA 的立身之本，数据失落，数据损坏，数据反复对于公司来说都是微小的打击；稳定性与易用性解放了 DBA 的双手，让 DBA 从简约的运维工作中解脱进去，有更多的工夫关注与架构选型和零碎适配的问题。
从这三点来看，Pravega 的确解决了绝大部分运维人员的痛点问题。Long-term retention 保障了数据的平安，Exactly-Once Semantics 保障了数据的准确性，Auto-scaling 使得保护自身变得轻松。这些特点令人更违心对 Pravega 进行深一步的调研与适配。
TiDB 与 Pravega 的实时数仓新计划
之前，TiDB 5.0 公布后，其 MPP 架构次要是将业务负载切分成若干的工作下推到多个服务器和节点上。在每个结点的计算工作实现后，合并成最终后果交付给用户。在 TiDB 5.0 中，TiFlash 会全面补充 TiDB 的计算能力，TiDB 在 OLAP 场景下就会进化成一个 master 节点。基于 MPP 架构，用户会向 TiDB Server 发送查问 SQL，这个查问 SQL 会由共享的 TiDB 服务器来承当。这些 TiDB 服务器会进行 Join，而后交给优化器去决策。优化器会把应用行存、列存、某些索引、单机引擎、MPP 引擎，或者是应用不同组合产生不同的执行打算，都纳入到同一个代价模型中进行评估，最初选出一个最优的执行计划。
在一些订单交易系统，可能因为促销流动在短时间内迅速达到业务顶峰。往往这种刹时流量顶峰须要咱们可能疾速的进行剖析类的查问，从而在限定工夫内给出反馈以影响决策。传统的实时数仓架构很难承载短时间内的流量顶峰，随之的剖析操作可能会须要大量的工夫来实现。如果应用传统的计算引擎，可能无奈做到秒级的聚合剖析操作。有了 MPP 计算引擎，就能够 将能预测的流量顶峰转换成扩容的物理老本，做到秒级的响应。在 MPP 计算引擎的加持下，TiDB 可能更好的解决剖析类型的海量数据查问。
实时数仓计划的架构
实时数仓经验了 三个重要的里程碑：
- Storm 的呈现突破了 MapReduce 的繁多计算形式，让业务可能解决 T+0 的数据；
- Lambda 到 Kappa 架构的进化，将离线数仓转化为实时数仓；
- Flink 的呈现给出了批流一体更好的实际形式。
实时数仓的架构始终是在不停变动的。很多时候，当咱们刚刚选定一套架构模型的时候，数据仓库的技术栈仍在高速迭代。咱们无奈预测到 Lambda，Kappa 之后会呈现什么样的技术架构，但能够通过当初的架构窥探一二。一般来说，咱们能够将实时数仓划分为四个局部：实时数据采集端，数据仓库存储层，实时计算层，实时应用层。多技术栈的交融能够帮咱们构建一套无边界的大数据根底平台，帮忙咱们同时撑持剖析开掘，业务上线和批流解决。
需要摸索：构建 Pravega + Flink + TiDB 的实时数仓
随着数字化转型的推动，越来越多企业正面临前所未有的数据规模，随着商业竞争的日趋加剧，无论是内部的用户还是公司外部的决策曾经无奈依赖时效性不佳的离线数据分析，须要更实时的数据分析，甚至是对正在产生的交易数据进行剖析，以撑持更加麻利的商业决策。
举例来说：
- 风控场景的最佳成果是防患于未然，所以事先事中和预先三个计划中，以事先预警和和事中管制成果最好。这要求风控系统肯定要有实时性。
- 电商大促期间心愿可能安稳及时的监控到销售的状况而非历史数据。
传统上，以 Hadoop 还是剖析型数据库为根底的数据分析 / 数据仓库计划都存在着无奈良好反对实时剖析的阻碍；相似 HBase 等 NoSQL 计划尽管能够反对很好的扩展性和实时性，但无奈提供所需的剖析能力；而传统单机数据库则无奈提供数据分析所需的扩展性。
在集成了 TiFlash 之后，TiDB 实现了 OLTP 与 OLAP 的联合，既能够利用于事务性数据库场景，能够利用于剖析性数据库场景，也能够在 OLTP 业务中划分出独立的区域实现剖析类查问。借助与 Flink，TiDB 能够很好的与 Pravega 适配，提供实时的、高吞吐的、稳固的数仓零碎。满足用户在大数据场景中对各类数据的剖析需要。
🌟 首次尝试：应用 Pravega + Flink 将数据流入 TiDB
为了不便读者更好的了解，咱们在 github tidb-pravega-quick-start 中提供了一个基于 docker-compose 的 Pravega -> Flink -> TiDB 的通路。在 docker-compose 启动后，能够通过 Flink SQL Client 来编写并提交 Flink 工作，并通过 HOST_IP:8081 来察看执行状况。
以后，TiDB + Pravega 构建实时数仓计划面向社区招募体验官！数仓新计划领先体验，还可额定获取 TiDB 社区及 Pravega 社区精美周边。您在摸索实际的过程中有任何问题，社区提供肯定技术支持～ 感兴趣的小伙伴，赶快扫码报名吧！
👇 数仓新计划，扫码领先试用 👇
补充浏览：为什么抉择 TiDB？
TiDB 是一款 HTAP 为特点的数据库，定位于在线事务处理 / 在线剖析解决 HTAP（Hybrid Transactional / Analytical Processing）的交融型数据库，具备一键程度伸缩，强一致性的多正本数据安全，分布式事务，实时 HTAP 等重要个性，同时兼容 MySQL 协定和生态，迁徙便捷，运维成本低。
相较于其余开源数据库，TiDB 在实时数仓的构建中，既可能用来存储高并发的事务数据，又能应答简单的剖析类查问，对于用户来说无疑是十分敌对的。从 4.0 开始，TiDB 引入了 TiFlash 列存引擎，能够将实时业务需要与剖析类的需要在存储层中做物理隔离，此外 TiDB 还具备以下劣势：
- 基于行存和列存的 HTAP 架构：
- 提供残缺的索引以及针对明细数据精确定位的高并发拜访，满足高 QPS 的点查。
- 高性能的 MPP 框架以及可更新的列存引擎，在数据进行更新之后，能够实时的同步批改到列存引擎，使得零碎能够用剖析型数据库的读取性能拜访最新数据，满足用户的实时查问需要。
- 一套入口同时满足 AP 和 TP 需要，优化器会主动依据申请的类型决定是进行 TP 类拜访，索引抉择，还是列存或则 MPP 计算模式，简化架构的复杂度。
- 弹性扩缩容：对线上环境的 TiDB、PD、TiKV 组件进行灵便便捷的扩缩容而不会对生产环境产生影响，操作通明。
- SQL 规范与兼容 MySQL 协定：反对规范的 SQL 语法，包含聚合，JOIN，排序，窗口函数，DML、online DDL 等性能，用户能够通过规范的 SQL 对数据进行灵便的剖析运算。
- 治理简略：应用 TiUP 工具能够疾速的实现集群环境的搭建部署；失常运行时不须要依赖其余零碎，运维上手简略；提供自带的监控零碎，不便进行性能瓶颈剖析和问题排查。
另外，在架构上，TiDB 在实时数仓场景中的利用也具备独特劣势。
首先，内核设计，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间相互通信，组成残缺的 TiDB 零碎。对应的架构图如下：
- TiDB Server：SQL 层，对外裸露 MySQL 协定的连贯 endpoint，负责承受客户端的连贯，执行 SQL 解析和优化，最终生成分布式执行打算。
- PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布状况和集群的整体拓扑构造，提供 TiDB Dashboard 管控界面，并为分布式事务调配事务 ID。
- 存储节点
- TiKV Server：负责存储数据，从内部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的根本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。
- TiFlash：TiFlash 是一类非凡的存储节点。和一般 TiKV 节点不一样的是，在 TiFlash 外部，数据是以列式的模式进行存储，次要的性能是为剖析型的场景减速。
其次，TiDB 5.0 通过 TiFlash 节点引入了 MPP 架构这使得大型表连贯类查问能够由不同 TiFlash 节点分担共同完成。
当 MPP 模式开启后，TiDB 会通过代价决策是否应该交由 MPP 框架进行计算。MPP 模式下，表连贯将通过对 JOIN Key 进行数据计算时重散布（Exchange 操作）的形式把计算压力摊派到各个 TiFlash 执行节点，从而达到减速计算的目标。加上之前 TiFlash 曾经反对的聚合计算，MPP 模式下 TiDB 能够将一个查问的计算都下推到 TiFlash MPP 集群，从而借助分布式环境减速整个执行过程，大幅度晋升剖析查问速度。
Benchmark 测试显示，在 TPC-H 100 的规模下，TiFlash MPP 提供了显著超过 Greenplum，Apache Spark 等传统剖析数据库或数据湖上剖析引擎的速度。借助这套架构，能够间接针对最新的交易数据进行大规模剖析查问，并且性能上可能超过传统离线剖析计划。同时，测试结果显示 TiDB 5.0 在等同资源下，MPP 引擎的总体性能是 Greenplum 6.15.0 与 Apache Spark 3.1.1 两到三倍之间，局部查问能达 8 倍性能差别。在数据分析性能上领有显著劣势。