“他们团队都是committer!”—— 小米Kudu开源实践 ｜小米技术立业

#What is KUDU?

Kudu官网的描述是“A new addition to the open source Apache Hadoop ecosystem, Apache Kudu completes Hadoop's storage layer to enable fast analytics on fast data.”。Apache Kudu作为一种对Hadoop生态圈的补充，它实现了对快速变化的数据做快速分析的存储层支持。
Kudu项目最先是由Cloudera公司发起的一个开源项目，2016年7月成为Apache软件基金会顶级项目。
Kudu的定位是提供一个既有媲美HDFS顺序扫描的性能，也同时具有HBase随机读写特性的分布式存储系统，在与Spark SQL或Impala结合后，能够提供高性能的OLAP服务。

图片来自《Getting Started with Kudu》

Kudu Server使用C++实现，采用列式存储格式，存储结构化数据，使用针对顺序扫描优化的LSM存储架构，使用RAFT协议来保证高可用。能够提供实时高效的insert、update、delete和scan等操作。
不直接支持SQL，而是提供相应算子的API，目前提供了C++、Java和Python的客户端，同时也提供官方的Hadoop套件支持，跟计算引擎结合后来对外提供类SQL的查询。非常适合作为需要实时查询的数据仓库，是Hadoop生态圈的一个很好的补充。
Kudu实现的理论基础在论文《Kudu: Storage for Fast Analytics on Fast Data》中有详细的论述。

01

我们是怎样

参与开源的

在Kudu项目进入Apache孵化器之前的2014年，小米就参与到Kudu项目的核心开发了，是Kudu的最早期的支持者之一，2015年我们开始在生产环境中使用Kudu。Kudu在小米内部整个存储系统中的体量虽不算很大，但每天也有百亿级行数据写入，为小米内部提供了稳定可靠的存储和分析服务。
经过几年的磨炼，对于Kudu宝贵的经验和心得也都传承下来。我们不断从社区获得新的特性支持和性能优化，同时也持续积极地回馈社区。到目前，我们共产生了3名committer，同时他们也是PMC member。
Kudu项目的用户来自全球各地，活跃的项目贡献者很多来自Cloudera公司内部，国内除了我们小米以外，蚂蚁金服、网易等公司也有一些活跃贡献者。与这些高手切磋技艺，不仅能把社区建设得更好，同时也能提升自己的技术水平。

02

那些年我们

贡献的patch

以下将抽几个从2019年开始，我们贡献到社区的patch来简单阐述这些patch的动机和效果。

1数据扫描和数据拷贝工具

这两个工具是在我们的系统运维过程中，针对遇到的一些问题而提出的解决方法的沉淀。
● 数据扫描工具 主要用于分析表各个分片的数据量、扫描时间，还可以查询表的详细数据以及谓词条件。可以查出一个表是否有数据倾斜的问题、某些分片是否存在扫描缓慢的故障等，从而帮助我们发现可能的业务数据问题或schema设计问题。

●数据拷贝工具 主要用于一个静态表（无数据变更）的数据搬迁和备份，同样也支持谓词条件。

这两个工具patch也体现了我们参与开源项目的策略，即从外到内，从易到难，从修复bug到优化功能，直至开发新特性。通过这样的策略，能降低参与的门槛，不断获得参与感和成就感，逐渐融入社区，对于参与项目的个人来说这是很重要的。

2数据compaction的表级优先级设置

和其他分布式存储系统类似，Kudu中也有表的概念，他对集群中的数据提供了逻辑上的隔离。在实际应用环境中，一个集群通常会有多租户，各个业务表的使用场景不尽相同，体现在Kudu系统里就是读写频率不一样，对延迟要求也不一样。

在Kudu中，有一个后台管理线程池用于各个tablet replica（表的分片单元）的flush、compaction和GC任务的调度执行，根据各个任务的类型和score分数高低判断是否需要执行（具体见Reference1,2）。
执行compaction后，分片数据会更规整，读写频率也会更高。但由于各个表都是扁平化的，延迟敏感的表可能由于分数较低而迟迟得到不compaction的调度，进而影响用户的读写延迟。
我们提出并实现了一种基于表的优先级调度方式，可以对指定表设定compaction的优先级。对于高频使用的、延迟敏感的表可以设定更高的优先级；对于低频使用的，延迟不敏感的表设定低优先级，从而使得有限的计算资源能够得到充分的利用。 当前表的优先级还需要手动设定，后面我们也计划通过自动感知读写频率、读写延迟，由系统自动的完成优先级设定。

3tserver启动加速

Kudu tserver的启动速度缓慢一直为Kudu用户所诟病。在我们的生产环境中，某些集群的tserver的完全重启时间长达30分钟，这不论是对SRE的日常运维操作还是对服务的可用性都是难以接受的。
通过分析tserver启动流程和生产环境的启动日志，我们发现有多处可以优化的点。截至目前我们做了3个优化，分别是：
*需要指出的是，在做这种性能优化时，最好是能够给出benchmark结果，在Kudu社区对这类优化也比较谨慎，需要拿数据说话。

其中第一个优化是将一个全局的大map sharding成多个小map，同时将这个大map的锁改造成这多个小map各自的锁。针对sharding数目的选择我们做了如下的测试：指定block数，对比不同的sharding数目下benchmark测试用例的耗时。
最终发现在sharding数量为16（即sharding shift为4）时能够得到最好的性能。

选定sharding数量后，我们对比新老版本，测试在不同block数量下实际的优化效果。


第二个优化是发现项目代码中有对std::vector的误用，即新元素的插入使用了“头插法”。
了解STL的程序员都应该知道std::vector在实现上是将数据存放在连续的存储空间上，“头插法”会带来频繁的数据拷贝，时间复杂度是O(n)而不是O(1)的，会严重影响性能。
我们只是简单地改为“尾插法”，即带来了明显的性能提升。
*4000/8000下的vector head insert耗时过长，绘图忽略
第三个优化是将blockcontainer的加载改造成多线程来完成。针对多线程的数量，我们也做了对比，最终选择8线程。
根据benchmark结果显示，在跟我们生产环境接近的数据量的case下（Block count约为800万），该优化带来约25%的耗时缩减。

以上的测试结果是benchmarktest case在单块SSD磁盘上的测试数据，如果是多盘，效果会更好。从我们的线上环境来看，该阶段的耗时能从450秒缩减到120秒。
需要指出的是以上3点都是针对tserver启动过程中block manager加载阶段的优化，还有其他阶段如tablet的bootstrap阶段，我们也会持续探索优化的方法。

4tserver优雅下线

在Kudu集群的日常运维中，出于节省资源或是替换老旧服务器等目的，有时会 需要下线一些tserver。要优雅地下线一个tserver，通常要遵循以下步骤：

步骤一：将这个tserver上所有的replica全部迁移到集群中其它服务器上

步骤二：停止运行该服务器上的tserver进程

步骤三：在master节点上删除该tserver的注册信息
由于Kudu没有可以批量自动化迁移replica的工具，要完成第一个步骤，我们只能手动迁移该tserver上的所有replica，这对于较大规模的Kudu集群来说几乎是不可能的。
如果跳过第一个步骤直接停止tserver进程，虽然leader replica也会在follower失联一段时间（默认是5分钟）后重新补齐副本，但这样的方式还是不够安全和优雅。因此开发一个自动化的工具来迁移某些tserver上的所有replica是非常必要的。

Kudu原有的rebalance工具就是批量通过replica迁移来达到负载均衡的目的，因此我们想到可以通过改进rebalance工具来实现迁移指定tserver上所有replica的功能。我们首先开发了一个内部版本，试用了一段时间后，把这个功能贡献给了社区。
有了该工具后，如果要下线某些tserver，我们可以先将这些tserver设置成”维护模式“，新创建的replica将不会被放置到处于”维护模式“中的tserver上，然后使用rebalance工具指定需要下线的tserver，接着master将会为所有需要迁移的replica创建一个替换replica，并将它们尽量均匀地放置在集群中的其它tserver上，最后再删除被替换的replica。
对于用户来说，只需要执行几条命令，就可以实现批量自动化迁移指定tserver上的所有replica，这对于提升运维效率是很有帮助的。

5如何实现自己的监控工具

Kudu的开源版本并没有提供集成的监控系统（CDH版虽然提供了一些可视化的监控，却也比较有限），但提供了非常丰富的监控指标，可以通过http接口获取监控数据。开源用户通常的使用方式是自己另外写一个collector，它负责完成原始数据的收集、汇聚，以及上报到第三方监控系统上。
我们也实现了自己的collector，并经历实现语言从Python向C++的改写、监控数据从部分到全局的改进过程。整体来讲，我们的collector有如下特点：
—
● 使用C++实现，集成在小米内部的Kudu分支。
● 收集的数据来源于master和tserver的”/metrics”接口，以及Kudu的CLI工具。
● 收集了当前Kudu暴露的所有metrics，包括tablet类型和server类型。
● tablet类型的metric数据汇聚成多个视图：server级的table视图、server视图、table视图和cluster视图。
● server类型的metric数据直接上报不需汇聚。
● 使用Kudu的CLI工具来收集集群的健康状态信息。
● 监控系统使用了小米自研的Falcon。
—
比如我们可以看到server视图下的delta_file_lookups指标的监控图：

通过它可以看到这项指标在各个tserver上的差别，从而找出可能的故障节点。

再如table视图下的on_disk_size指标的监控图：

通过它可以看到不同表的数据量，以及历史的变化情况。

此外，我们还在collector中周期性调用了集群的rebalance任务，这会使得集群各表的tablet副本可以在各个server上尽量均衡。
后续，我们还计划在collector中集成集群的可用性探测功能，通过探测数据的读写操作来判断集群的可用性、读写延迟等信息。
由于collector目前绑定使用了falcon监控系统，所以暂时还没有贡献到社区，我们也有计划将相关模块提高抽象度后，再贡献到社区。

03

我们的

一些感悟

Kudu的设计和代码质量在开源系统中是比较高的，但通过上面这些patch可以看出，它仍有不少提升空间，这些提升点从技术上来说并非很难实现，但需要在系统的实际使用过程中不断总结、不断思考，逐步深入理解项目进而提出优化方案。
而在这个过程中，参与者不知不觉就完成了从开源项目使用者向开发者的角色转换。这也正是开源的优势，能让更多人参与到系统的使用和改进中来，让系统不断演进，变得更好。 —
作者 赖迎春

目前是存储平台KV系统组负责人，该小组负责Kudu、Pegasus、Doris多个系统的研发和运维。他深度参与Kudu开源社区，2019年向社区贡献了40多个patch，并于2019年6月受邀成为Kudu Committer及PMC成员。

张一帆
2018年毕业，2019年向社区贡献了20多个patch，并于2020年1月受邀成为Kudu Committer及PMC成员。

Reference
1.https://kudu.apache.org/docs/background_tasks.html 2.https://github.com/apache/kudu/blob/master/docs/design-docs/tablet.md 3.https://github.com/open-falcon/falcon-plus