阅读 361

TiFlash & TiSpark?那都是 AP 团队开的坑 ! | PingCAP 招聘季

前面两期我们介绍了 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 团队正在折腾的东西,很多部分都还处在比较初期的阶段,而且这里写的都只是我们比较确定会开展的工作,有一些想法因为人力不足经验不足我们只敢想却没办法写在这里。如果有了各位同学的加盟,相信这些产品可以变得更完善,更野心勃勃。

加入我们吧!

我们认为优秀的工程师或多或少有以下共同特质:

  • A Quick Learner

  • An Earnest Curiosity

  • Faith in Open Source

  • Self-driven

  • Get Things Done

如果你符合以上特质,欢迎进入招聘页面查看目前开放的工作机会:

www.pingcap.com/recruit-cn/…

简历投递通道:hire@pingcap.com

实习生:公司的各项福利和学习资源对实习生全面开放,更重要的是实习生还未毕业就有机会接触工业级项目,而且实习期间表现优异者将有机会获得校招绿色通道特权。如果小伙伴们时间不够充裕,也可以先从社区 Contributor 做起,或许下一期 Talent Plan 的主角就是你!

伯乐推荐:如果你身边有符合以上要求的小伙伴,也可以找我们聊一聊,推荐成功就有机会获得伯乐推荐奖励(iPad、iPhone、MacBook Pro 等等)。伯乐推荐邮件格式:[伯乐推荐] 候选人姓名-职位名称-推荐人姓名-推荐人手机号。

关注下面的标签,发现更多相似文章
评论