Kylin Committer｜从“青铜玩家”到 Apache Committer 的开源贡献之旅
面向云原生的 Apache Kylin 4 于今年 9月正式发布，Kylin 社区也迎来了第一批尝鲜 Kylin 4 的社区用户，有赞、小米等公司从 alpha 版本起就给了社区很多反馈～
其中来自有赞的郑生俊同学对 Kylin 4 的查询、构建以及元数据升级等功能做出了许多贡献，同时他也推动了 Kylin 4 在有赞的落地和上线，从开源青铜玩家到 Apache Kylin Committer，想听听他和 Apache Kylin 社区之间的小故事吗？一起和小编看看吧～
Q
简单介绍一下自己？
大家好，我是郑生俊，就职于有赞，负责有赞数据基础平台，涉及到离线计算、实时计算、在线存储和 OLAP 等相关工作。和大部分程序员差不多，我也挺喜欢打篮球和打 Dota（又菜又爱玩那种），不过工作和有了娃之后就从“球场”和“赛场”光荣退役了，除了工作之外就专注带娃了。
更多彩蛋见文末
Q
你是什么时候接触到开源的？有什么开源社区的小故事可以分享吗？
最早接触开源和大数据差不多是在我刚毕业在厦门的时候，到现在已经差不多六年了。当年厦门在 IT 圈里有点处在江湖之外的感觉，我所在的公司刚刚成立大数据部门，我们其实对大数据都没有了解过，但是公司的数据量和集群量又是非常大的（全公司当时大概有5万+的服务器），集群数量多，最大的 HDFS 集群数据有上百 PB ，每天的增量也非常大。
我们那个时候就像青铜玩家，入了一个王者局， 数据量大，我们采用的技术选型也很丰富（被逼的），除了常规的 Spark、Storm、HBase、ClickHouse 等，还有一些比较小众的东西比如 CDAP，我也就是从那个时候开始真正接触开源以及大数据的。
Q
您是如何成为 Kylin committer 的？
我是2020年11月份开始参与 Kylin 社区的，通过 bug fix、性能提升、新的 feature 开发等贡献成为了 Kylin Committer。Kylin 社区最吸引人的点是包容性非常强，来自 Kyligence、eBay 等各个公司的贡献者都很优秀，和大家沟通起来特别顺畅。
在参与 Kylin 社区之前，我更像是一个自 high 型选手，fork 社区分支后就自己玩了。接触 Kylin 也是一次偶然的机会，因为业务调整从其他团队接手了 Apache Kylin。当时遇到了一个全局字典分裂导致编码不正确的问题。
相比一些其他公司的大数据部门，有赞将大数据体系用在了更多线上的核心链路，包括商详、交易等核心环节。就 Kylin 而言，它涵盖了商家日常经营的各个环节，比如库存、流量、订单、财务等各种数据报表，商家基于此会做数据化决策、绩效管理等，由于 SaaS 场景都是付费用户，对稳定性要求较高。刚接触 Kylin，我当时也太不确定自己的 Bug Fix 的做法是否会有坑，就想在社区提个 Issue 让专业的大佬们看看，没想到 Kylin PMC 霄翔非常热情，利用周末时间给了 Review 和建议，从此就上车了，之后和社区其他 Committer 智超（Kylin Committer｜左手代码，右手家庭的劳模青年）和亚倩（Kylin Committer｜95 后程序媛 C 位出道！）也都很好，他们也经常周末帮忙 Review PR！
在参与 Kylin 社区开发的一年内，我参与了大约三十个 Issue 的开发工作，并且贡献了四篇文档，也在 Qcon、Data & Cloud Summit、Kylin Meetup 等线上线下技术演讲场合分享了和 Kylin 相关的内容。
Q
加入 Kylin 社区以来，您最有成就感/最困难的事情是什么？
最有成就感的事情就是发展了两个团队内部的 Apache Kylin Contributor，他们也有动力成为下一个committer，能够吸引越来越多人参与到 Apache Kylin 社区也挺有成就感。
我印象中最困难的地方在于某个 Feature 的实现，我们通过优化 SQL 执行计划，动态消除分区维度来混合使用 Cuboid，为复杂查询减少数十倍的 IO 和计算量。因为 Apache Kylin 4 目前既保留了 Calcite，也保留了 Spark，在有些场景扩展起来不是那么方便，相信这在 Kylin 未来的版本中会改善。
Q
加入开源社区以来，您最大的收获是哪些？
Community Over Code，最大的收获还是认识到一群志趣相同的朋友(网友)，毕竟技术总是不断迭代更新，但友谊长青。这个过程有点像交笔友，刚开始时大家都是远程协作，素未谋面，后来有机会在线下 Meetup 面基，感觉挺亲切的。
Q
成为 Committer 之后，对开源项目/社区有没有什么新的感触？
在最开始接触开源项目的时候，流计算比较火的还是 Storm，我们团队当时做了对 Storm 做了很多功能性的扩展，比如 SQL on Storm ，也基于 ORC 实现了类似Hudi/ Delta Lake 这类的支持更新的存储方式。
之前觉得自己造轮子是没问题的，但是参与社区之后，尤其是在和 Kyligence 和 eBay 等公司交流后，大家都有一个共同的观点就是：自己造轮子的那些项目其实生命力是比较脆弱的，也没有经过更加复杂场景检验，但是开源社区就不一样了，它是全世界的公司都在用，是全世界的研发团队在维护的，它的生命力还有产品迭代非常快。所以说，在成为 Committer 之后，我对于开源项目/社区的一些观点都发生了很大的改变。
Q
你觉得 Kylin 4 最吸引你的点是什么呢？目前迁移到 Kylin 4 还顺利吗？用户反馈怎么样？
当时接触到 Kylin 4 是因为遇到了 Kylin on HBase 的性能瓶颈，想调研一些更适合的 MOLAP 引擎。在调研过程中了解到了 Kylin 4，相比采用其他技术栈，Kylin 存储计算分离的特性可以让我们很轻松地应对流量的高峰低估，Cloud Native 也是未来趋势（我们目前也有把 Kylin 的查询节点在夜间弹性调度到离线计算集群 Spark on K8s上），而且升级不影响现有业务是一更个为平滑选择。关于一些升级和性能优化的内容我其实也写了相关的技术博客，欢迎大家来多多讨论👉 有赞出品｜升级 Kylin 4 最强攻略！
其实这段时间，我们一直在把 Kylin on HBase 迁移到 Kylin on Parquet。有赞 on HBase 的集群都已经迁移到 Kylin 4 了，我们目前有三个集群，总 QPS 在 300~400 之间，95RT 是 650ms 左右，99RT 是 908ms 左右。
在我看来，Kylin 4 解决的主要是构建的瓶颈和对复杂查询性能的提升，当然还有存储计算分离的能力。为了提升查询的稳定性，我们也针对小查询也做了一些特殊的优化，大部分是基于 Spark 上去做的。对于小查询的话，Kylin 4 的 RT 也是足够的，总体的稳定性也是很不错的，相比 Kylin 2.6 我觉得是有绝对的优势。业务方们的反馈不管是构建时长还有查询性能都提升了很多，不少场景是直接给有赞十万左右的月活商家使用的，对 QPS、RT 和稳定性都有比较高的要求，目前 Kylin 4 可以满足。
最近我也看到 Kylin 社区也出了：性能全面提升：Kylin 4 vs Kylin 3 官方性能测试报告全新出炉！，感兴趣的小伙伴可以去看看～
Q
请问您持续贡献的动力是什么？您下一步的贡献计划有哪些？
对我来说更多的是业务驱动。随着业务场景越来越多地使用预计算，Kylin 4 也运行大半年了，过程中我们不断地遇到和解决 Bug 和性能瓶颈，把这些 Bug 和性能瓶颈解决之后 ，我们对 Apache Kylin 能做的事情和底层技术也了解得也更加深入，进而堆上了更多稳定性和性能要求更高的 OLAP 场景。这种良好的刺激和反馈机制不断循环，成了很好的驱动力。
至于下一步的贡献计划，一是帮团队其他小伙伴成为 Committer，二就是希望是为 Kylin Native Engine 贡献一些力量。
Q
作为最早选择 Kylin 4 的用户之一，你遇到了哪些问题？
在 Kylin 4 早期遇到了不少问题，基本上都是自己解决，但作为门外汉，有许多考虑不周的地方，社区的 PMC 和 Committer 给了很多建议和帮助。到现在，我们其实已经使用了 Kylin 4 有了大半年的时间，Kylin 4.0 相对于 Kylin 2.6 帮助我们解决了很多业务上的挑战，当然 Kylin 4 也尚有一些不足。
首先， Kylin 这个引擎的学习和维护成本还是偏高，在学习过程中可能就劝退了一部分用户。因为 Kylin 有 Model/Cube/Cuboid 这些概念，Kylin 用户需要经过一系列复杂的学习培训才能成为一个相对熟练的 Kylin 用户。我理想中更简便更高效的方式可能是，我们更进一步，屏蔽掉 Model/Cube/Cuboid 这些概念，用户只需要使用标准的 SQL 语法来创建模型、导入数据、增删索引等操作。如果能做到这样的话，我觉得会吸引更多的用户来使用 Kylin。
第二点，Kylin 4 相比一些 OLAP 引擎具备了很不错的self service 能力了，这也是我们将它作为 MOLAP 平台很重要的原因。但在自我保护机制这块还不够。比如对用户查询的约束，缺少一些可以为查询打分的策略，拒绝不健康查询的能力（比如查询数据量限制、前缀索引匹配机制限制等）
第三点，Kylin 4 是 fully on Spark 的，不过 Spark 是针对离线设计的不是为 Adhoc 而生。就会有些小缺点，一是 Rule 太重，不少基于递归的实现 overhead 的代价太大，查询性能还是会有瓶颈，二是调度模型非 Pipeline，三是开源 Spark 并非 Native 引擎， 进一步提升查询性能需要改造或者替换 Spark。
郑生俊同学带来了参与开源的心路历程以及 Kylin 4 在有赞的落地与最佳实践，相信也给许多 Kylin 的用户带来了可供参考的经验。当然我们也知道社区小伙伴们都对 Apache Kylin 的未来抱有很大的期待，也欢迎大家参与社区，一起为 Apache Kylin 未来更多新功能贡献你的力量！听说成为 Contributor 就有社区周边可以领取哦～
如果你也想讨论更多 Kylin 相关话题，欢迎订阅 Apache Kylin 官方邮件组，或者添加 K 小助（uncertainly5）加入用户群～
彩蛋来啦
专心带娃的郑生俊同学
点击阅读原文，下载 Kylin 4