TiFlashTiSpark？那都是AP团队开的坑！

前面两期我们介绍了 TiDB 团队和 TiKV 团队&＃xff0c;颇受好评&＃xff0c;今天我司数据库专家马晓宇老师将为大家介绍 PingCAP 最具活力的团队—— AP&＃xff08;Analytical Product&＃xff09; 团队&＃xff0c;如果你对亲手打造酷炫的大数据分析产品感兴趣&＃xff0c;就快快投个简历来和我们聊聊吧&＃xff5e;

大家都知道 TiDB 是一款定位于在线事务处理/在线分析处理&＃xff08; HTAP: Hybrid Transactional/Analytical Processing&＃xff09;的融合型数据库产品&＃xff0c;加强和补齐 HTAP 中的 AP 环节是这个团队的重要工作职责。

TiDB 的 Coprocessor&＃xff08;协处理器&＃xff09;架构使得大量计算可以并行进行&＃xff0c;例如由协处理器进行谓词过滤&＃xff0c;预聚合等等&＃xff0c;这样一来很多计算被众多 TiKV 资源分担&＃xff0c;并且汇聚到 TiDB 的计算将大大减少&＃xff0c;由此虽然 TiDB 本身仍然是单机&＃xff0c;却可以很大程度满足 AP 需求。

不过这并不是 AP 团队工作的全部。

TiFlash

TiFlash 是一个相对独立完整的分析型数据库产品。独立&＃xff0c;说明历史包袱会比较小&＃xff0c;可以尝试各种可能的设计&＃xff1b;同时&＃xff0c;我们也希望它尽可能完整&＃xff0c;能承担一个分析型数据库应有的职责。这个项目需要熟悉 C&＃43;&＃43;&＃xff0c;熟悉分布式系统的 Infra 工程师同学们入伙。

Why

也许您看了 TiDB / TiSpark 的架构&＃xff0c;会有个疑问。TiDB 仍然使用的是行格式存储&＃xff0c;但似乎大多数分析型数据库都是列式存储喔&＃xff1f;

没错。这就是我们开新坑的主要目的之一。

列式存储能提供更高的压缩比&＃xff08;why&＃xff1f;&＃xff09;&＃xff0c;增加 IO 效率&＃xff08;毕竟 IO 在很多时候是最慢的一环&＃xff09;&＃xff0c;也使引擎能只读取需要的列&＃xff0c;更进一步加快读取速度。但是列式存储在 TP 场景下会使 IO 变得零散&＃xff0c;如果使用了压缩就会更麻烦。因此基本上交易型系统还是会使用行格式存储的&＃xff08;就像 TiDB 现在这样&＃xff09;。

另外&＃xff0c;HTAP 系统面临的另一个挑战是资源隔离。当所有计算任务都依赖于 TiKV 存储的时候&＃xff0c;我们很难有效地进行资源隔离&＃xff1a;不管如何处理&＃xff0c;AP 任务都有可能影响 TP 的稳定。因此&＃xff0c;我们希望有一组独立的资源提供 AP 服务。

Raft 和列存副本

Multi-Raft 协议使我们有了另一种选择&＃xff1a;何不把列存当做一个 Raft Learner 副本来实现呢&＃xff1f;Raft Learner 接入让我们得以在对 TP 端极低的消耗下&＃xff0c;提供一致性的数据读取&＃xff0c;同时又兼顾了资源隔离。这大概算是一个相当有创新的做法了 :)

其实您也可以认为列存副本是某种奇特索引结构&＃xff0c;因此计算层其实可以在行存和列存中根据代价进行选择。例如我们进行两表 Join&＃xff0c;也许一张表可以通过索引过滤大部分数据&＃xff0c;而另一边则希望通过列存减少扫描代价&＃xff0c;那么我们也可以同时使用行存&＃43;索引和列存进行 Join。

列存 &＃43; Raft 副本是一个正在进行的任务&＃xff0c;为了使列存能够支持快速的 MVCC 更新和删除&＃xff0c;我们专门开发了新的存储引擎&＃xff0c;同时也在和 TiKV 组紧密合作对接 Raft 协议。

如上图&＃xff0c;这就是一个 TiFlash &＃43; TiDB 集群。最上层仍然是 TiSpark &＃43; TiDB 的计算层&＃xff0c;而下层则是类似 TiKV 的存储 &＃43; 协处理器的架构。其中一部分存储引擎节点将通过 Raft 协议和 TP 区连接&＃xff0c;实时同步数据&＃xff1b;而另一部分则作为独立的写入区&＃xff0c;支持纯 AP 需求。

现在我们的列存引擎还只是初版&＃xff0c;我们正在进行更多的探索&＃xff0c;尝试不同的存储格式和技术&＃xff0c;让它变得更快&＃xff0c;适合更多场景。而要支持独立写入&＃xff0c;也代表 TiFlash 本身将会向一个完整的 MPP 数据库演进&＃xff0c;而这无疑需要耗费大量人力。总之&＃xff0c;非常期待各位同学的加盟。

TiFlash MPP Engine

另一个计划中但是仍然没有开工的事情是&＃xff0c;我们希望在协处理器层加入 Exchange / Shuffle 功能&＃xff0c;让数据可以通过网络进行 MPP 模型的重分布操作。

如果我们在协处理器层加入 Pipeline 模型的数据交换&＃xff0c;计算层 TiDB 作为一个单节点服务器也可以享受到集群计算的加速。而 TiSpark 在运行非长时间 ETL 任务时也可以选择下推计算到 MPP 计算节点以避免 Spark Shuffle 高容错模型带来的消耗。

实际上要实现基于 Exchange 和重分布的 Query Engine 是非常庞大的一件事。几乎大部分算子都需要重新改造&＃xff0c;完全做到需要很久。不过好在我们的计算层各自都已经实现了完备的算子集&＃xff0c;这样我们可以按照合理的进度逐步构建 MPP 引擎&＃xff0c;逐步开放更多可下推的算子。

与此同时&＃xff0c;在这个引擎上&＃xff0c;我们也希望试验一些更新的计算模型&＃xff0c;例如完整的向量化算子实现&＃xff0c;或者结合 JIT 进行加速&＃xff0c;甚至尝试 GPU 等&＃xff0c;都是预期中的任务。

TiSpark

TiSpark 是我们组的另一个产品。TiSpark 是一款深度订制的 Spark Connection Layer&＃xff0c;将 Spark 平台深度整合到现有的 TiDB 产品栈里。它借助了 Apache Spark 的计算平台&＃xff0c;直接对接存储层&＃xff08;TiKV 和 TiFlash&＃xff09;读取数据&＃xff0c;并下推可能的计算以加速。

TiSpark 的定位是多重的&＃xff1a;一方面在 TiFlash 还无法完整承担 MPP 引擎职责的当下&＃xff0c;它是我们在超规模计算下的首选&＃xff1b;另一方面&＃xff0c;借助 Spark 我们将 TiDB 延伸到了大数据领域&＃xff0c;配合 TiFlash&＃xff0c;我们可以替代相当一部分传统上需要 Hadoop 集群的场景。

通过对接 Spark 的 Extension 接口&＃xff0c;TiSpark 得以在不直接修改 Spark 源代码的前提下&＃xff0c;深度订制 Spark SQL 的根本行为&＃xff0c;包括加入算子&＃xff0c;扩充语法&＃xff0c;修改执行计划等等&＃xff0c;让它看起来更像是一款 Spark 原生产品而非第三方扩展。

由于直接对接了存储&＃xff0c;我们也可以像传统数据库一样利用好存储的特点&＃xff0c;实现一些 Hadoop 体系无法完成的功能&＃xff0c;例如 IndexJoin&＃xff0c;Index only scan 等。另外&＃xff0c;安全和审计体系&＃xff0c;基于 Spark Streaming 的异步触发器和看板&＃xff0c;或者 PL/SQL 等&＃xff0c;都是之后可能的选择。总之&＃xff0c;这个项目还很初步&＃xff0c;还有很多可以折腾的事情。

另外&＃xff0c;TiSpark 暂时还是一个只读的系统&＃xff0c;但是我们也准备加入写入和修改的支持&＃xff08;数据编码&＃xff0c;索引维护&＃xff0c;事务支持等等&＃xff09;&＃xff0c;这样 TiSpark 也将成为一个能相对独立使用的完整产品。

我们也期待您的加盟。如果您是大数据领域新手&＃xff0c;这个项目可以让你深入了解 Spark 的架构和实现细节&＃xff1b;如果您是老鸟&＃xff0c;除了一起快乐写代码&＃xff0c;还可以一起制定产品 Roadmap 也许也是您乐意做的事情&＃xff1b;总之&＃xff0c;这是一个老少咸宜的项目。

所以来聊聊看吧&＃xff1f;这两个项目是眼下 AP 团队正在折腾的东西&＃xff0c;很多部分都还处在比较初期的阶段&＃xff0c;而且这里写的都只是我们比较确定会开展的工作&＃xff0c;有一些想法因为人力不足经验不足我们只敢想却没办法写在这里。如果有了各位同学的加盟&＃xff0c;相信这些产品可以变得更完善&＃xff0c;更野心勃勃。