TiFlash & TiSpark？那都是 AP 团队开的坑！

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

外包信息请发到 /go/outsourcing 节点。

不要把相同的信息发到不同的节点

这是一个创建于 2409 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

TiFlash

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

Why

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

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

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

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

Raft 和列存副本

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

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

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

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

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

TiFlash MPP Engine

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

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

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

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

TiSpark

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

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

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

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

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

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

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