社区人物志｜王博：每一位你，都是前进道路上的一团星光。
「社区人物志」是 Apache Doris 社区推出的系列专栏，我们关注每一个对 Doris 做出过贡献的 Contributor ，会定期从对 Doris 做出突出贡献的小伙伴中选出一位「社区之星」，并会对「社区之星」进行专访，希望 TA 与 Doris 的故事可以被大家听见，也希望有更多的小伙伴参与到社区建设中来。
本期我们采访了来自美团 OLAP 团队的研发工程师王博，来听听他与 Doris 的故事。
关于自己
Q：请先简单介绍一下自己过往的技术经历？
大家好，我叫王博，目前在美团 OLAP 团队做 Doris 开发。
毕业之后的一两年主要做一些数据报表开发的工作，基本处于迷茫摸鱼期，总是有一种想用力但是不知道如何用力的感觉。后来有幸加入美团的 OLAP 团队，才感觉找到了正确的方向，找到了正确的人，一起做了正确的事情。也是运气比较好遇到了两位非常厉害的同事，学习了很多，我觉得我这辈子抽奖的运气都用在这了。
Q：除了 OLAP 方向以外，还在关注哪些技术方向或领域呢？
目前主要对增量生产比较感兴趣，也一直在思考当上游生产链路都改成增量生产后， Doris 作为对接的下游组件还需要有哪些事情可以做。
关于 Doris
Q：您是如何了解到 Doris 的？
因为最初是做数据报表相关开发的，当时查的引擎是 Impala，发现稳定性有些问题。于是引入 Palo（当时 Doris 还叫 Palo）做尝试。
Q：使用 Doris 期间您有没有遇到过什么问题或挑战，是如何解决的呢？
主要是 0.13 版本的升级过程比较痛苦，因为比较缺乏全面测试的工具，永远不知道明天会不会出新的 Bug 导致整体进度延迟，而这种不确定性十分煎熬。解决方案就是，调整心态，遇到问题解决问题，更重要的是在这个过程中思考下次升级如何不再这么痛苦。
Q：除了遇到的问题以外，还有没有一些有趣的案例或故事可以分享呢？
我觉得，每过一段时间再回头看自己之前提交的代码以及方案设计是个非常有趣的体验。
Q：您认为 Doris 有哪些做得比较好的地方？有哪些方面还需要继续优化？
Doris 做的比较好的地方就是简单可依赖，包括用户的角度以及运维的角度。
需要持续优化的部分首先是稳定性，然后是性能。主要问题在于随着 Doris 集群规模越来越大，大数据量下很多模块都会暴露出一些问题，比如数据 Balance 的速度、Compaction 速度、Stream Load 高频导入稳定性与性能等，每个模块以较大的数据规模去审视，都还是有一些改进空间的。
其中优先级比较高的应该是关于大版本升级相关的稳定性问题。这次 0.13 升级搞了半年，集群数较多是客观因素，但是主观上还是有比较大的改进空间的。从我们团队内部的视角看的话，内部测试工具确实比较简单，只测了最常用的流程，比较缺少压力和并发测试，以及复杂的 SQL 性能校验的流程。从社区视角看的话，目前比较缺乏一些信息共享的机制，包括升级过程中 Bug 修复以及回归测试样例的共享。比如我用的第一个三位版本做升级，上线遇到问题，好一顿定位，可能没过多久第二个三位版本就修复了，这中间其实是有重复劳动的。因此，对于由于升级引入的 Bug 是可以做一个专门的 Issue 用于追踪所有由升级引入的 Bug 从发现到定位到 PR 修复的全部流程。这样其实从全局视角看，修复和升级速度是增加了。
其次是对于测试用例的共享。目前看 0.13 版本是缺乏压力测试的，这个直接表现是内部一些百亿量级的导入场景，升级完 0.13 后出现了比较严重的性能问题。这个应该主要和业务场景有关，有些场景在单个公司内部没有遇到，但是其他公司内部是有可能遇到的，我了解小米那边的同学也遇到了类似的问题。所以我觉得不仅代码可以共享，测试的 case 最好也是可以共享的。长期看最好是有一个专门的测试工具，大家都可以往里提交各种 case，这可以保证同样的场景，下次不会再复现同样的问题。短期可以做的是，Doris 在发版前可以先挑选一些公司内部大数据集的场景做一些压力的测试。
总之，稳定性问题是十分重要的，因为软件的维护是一个比较长期成本也比较高的过程。
大版本升级稳定性问题如果过多，是会影响用户升级的积极性的。如果说各种眼花缭乱的新特性是用户拉新的关键，那么稳定性与可维护性应该是用户留存的关键了，个人认为是十分值得花时间去搞的。
参与社区
Q：是什么样的契机，让您开始向 Doris 提交 PR 及贡献代码呢？
团队选型，工作需要。
Q：在参与社区建设的过程中，您有什么样的收获？
首先技术上进步比较大吧，毕竟社区里高手很多，只要能够主动看代码并且提问就可以学习到很多。其次是多了一种思考问题的角度吧。比如现在我提一个 PR 或者加一个新的功能，会去考虑这个东西是适合公司内部场景的还是适合通用场景的。如果仅仅是特定 Case 的优化，是否可以做成很通用的功能。如果不能做的很通用，那么是公司内部场景有啥特殊之处吗，业界广泛的场景是怎样的。总之是会让我思考更多。
Q：后续会更关注或计划参与哪些方面的 Issue 呢？
向量化模块的持续优化吧，能走到这个方向的边界是最好的。
Q：对于 Doris 社区的建设，您有什么样的建议呢？
目前社区给我的感觉像是一个无情的代码提交和代码 Review 机器，所以对社区是有更多期望的。
平台化的意思是，社区的主要发力点在于高质量平台的搭建，而不在于产出多少代码，代码层面的要求应该是足够抽象，方便多人参与即可。比如 PingCAP 社区在搞优化器重构以及向量化重构的时候，会把一些优先级不高且比较独立的函数以及表达式实现以 Issue 的形式发布到社区，邀请社区的开发者共同参与开发。这种操作比较容易出圈。
首先是可以尝试进行一些新场景的探索，比如在 Doris 上跑生产任务。事实上我们公司内部已经有用户这样用了，只不过受限于 Doris 现有能力（资源隔离很差以及长查询不太稳定），没有推广成一个很主流的用法。
然后是对大环境变化相结合吧，比如现在 Hadoop 生产感觉明显已经没落了（各种公众号都不提 Hadoop 了，张口闭口流批一体）。国内比较火的替代方案是 Flink 流批一体，而国外比较知名的应该是 Snowflake 体系。目前我比较感兴趣的是，下一代数仓到底是 Flink 标准还是 Snowflake 标准。这些其实都是大的环境，而当大的环境发生变化时，Doris 的定位又会是怎样呢？如果从现在就开始思考这些问题并作出尝试，那么其实就是迈出了进化的第一步。
最后是社区是可以尝试定期举办一些围绕 Doris 引擎展开的 Hackathon 的，这个毫无疑问是迸发出关于 Doris 引擎技术建设的金点子的绝佳机会。比如我就一直想，如果把 Doris 的读本地盘的接口直接改成读云存储会是什么样。
开源社区的用户群体或组织大概可以分为以下几类：一，体量较大，具备构建完整大数据上下游生态的公司；二，体量相对较小，不具备具备构建完整大数据上下游生态的公司；三，Doris 代码的开发者；四，普通用户。
上述第一类，选型时主要关注是否有落地场景的背书，性能/功能是否能够满足需求，运维成本是否很低，社区活跃度是否高，目前 Doris 服务这类组织其实基本没啥问题。
上述第二类，这个应该主要是面向 B 端用户的场景，平时没接触过所以不评价了。
上述第三类，我觉得开源项目让开发者获得的收益可以不仅仅局限于一个 Contributor 或者 Committer 的称号，而是可以更多。比如成为这个领域真正的技术专家，这点其实是可以通过知识传播实现的。当谈到知识的传播时，第三类群体的范围又可以更大，可以是在校学生，可以是对 Doris 感兴趣的人，可以是对 OLAP 技术感兴趣的人。当 Doris 可以让更多人在这个社区收获更多的时候，那么反过来 Doris 也可以收获更多的拥趸，收获更广泛的口碑。具体落地的措施可以参考 PingCAP 社区定期的 Paper Reading，它的好处不仅仅是知识传播，也可以为 Doris 在新技术新场景的探索提供指导性建议。
上述第四类，对于这类用户来说最基本的诉求就是，易学易用，尽量节约用户的时间和脑力。
这块个人感觉可能出一些视频教程，然后弄一个系列出来会比较好。可以从技术选型，业务场景，环境搭建，基本使用，常见报错等几个方面来讲。
个人认为影响一个开源产品好不好用，有两个决定性因素，一个是内在，另一个是外在，内在是要有积极活跃的代码提交者，而外在就是要有足够多的业务场景，二者缺一不可。一个产品只有经历过足够丰富的业务场景的打磨，才具备变得更好的可能。
因此对于社区的贡献，个人感觉可以不仅仅局限于提交了多少代码；能够为 Doris 引入更加丰富的业务场景，并愿意用 Doris 进行验证并且最终在这个场景落地的，其实本身对于 Doris 迭代进化是做了很大贡献的。
从社区运营的角度来说，为 Doris 撰写文章，制作视频等，完善文档，对外传播过程有帮助的，其实都可以视为对社区的贡献。而这些贡献我觉得也是需要得到社区认可的。比如可以每半年或者一年一次颁个奖杯发个社区证书。当然如果有物质奖励那肯定是更好的，比如程序员喜闻乐见的游戏主机啊，显卡啊什么的。
目前看 Clickhouse 代码的时候，感觉他们的接口层面代码风格抽象度很高，每个模块或者小的功能都有一套接口以及对应实现。Doris 的代码风格就是没有风格，一锅乱炖的感觉。我比较感兴趣的是一个开源的项目，代码提交者来自不同的组织，风格是如何做到这么统一的。我觉得后续可以作为一个 Doris 代码建设的一个方向。
展望未来
Q：您如何看待 OLAP 引擎未来的技术趋势呢？
我对这个问题的思考一般是从两个层面。
第一点是技术视角，我首先想的是如何杀死 OLAP 数据库这个领域，或者说 OLAP 数据库存在的意义是什么。
为什么我用一个查询引擎直接查数仓数据不可行？因为性能和 OLAP 数据库差太多。那么具体产生性能差异的原因是啥呢？应该是特定的文件格式以及与文件格式完美契合的执行器。那么我如果做一个数据格式转化的插件，可以把每天生产的数据转成这种特定的格式，然后直接性能是否可以媲美 OLAP 数据库呢？是不是就可以把 OLAP 数据库干掉？这个问题我目前也无法回答，也是一直在思考的问题。
总结来说就是，从技术角度看，如果数仓的存储和查询确实可以做到媲美 OLAP 数据库的地步，那么 OLAP 数据库确实没有存在的必要了。而数仓的生产数据和分析数据可以共享并且查询，这样是可以最大限度发挥数据的价值的，这也是单一一个 OLAP 数据库做不到的事情。
技术之外的其实主要是用户和产品视角了，还是分为两种用户吧。
对于体量较大的公司，其实主要考虑的问题是迁移成本，如果新的技术架构没有特别杀手级的优势，能不动就不动，其实对技术趋势变化本身不是十分敏感的。对于体量较小公司，对成本和易用性比较敏感，他们可能更希望的是透明，技术细节越少越好。
决定技术趋势的其实不是写代码的人，而是业务场景与用户的需求。所以这个问题最终还是要回归用户需求本身，Doris 可能进化成云上的 Doris 比较合适的实践，一切对用户透明，用户看到的可能只是一个提交 SQL 的框框或者提交 SQL 查询的接口，至于接口后边是一个 OLAP 数据库还是一个数仓 OLAP 插件，其实也都没那么重要。这点目前做的比较好的我觉得是Kylin 社区搞的 Excel 直接自动取数进行分析的功能，简直是杀手级别的应用。
Q：对于云原生时代，您有什么样的展望呢？
其实如果只是服务公司内部的场景的话，上云的价值不能说没有，只是非必选项。因为 OLAP 分析那点数据量用不了太多机器，和生产场景相比动辄几万台的量级比其实是很少了，因此对弹性其实没啥需求。但是如果是面向 To B 场景，以及 Doris 后续如果想往生产的场景做扩展，Doris 上云是一定是需要的，因为集群规模是会变大很高的，相对应的成本也会变高。
Q：最后有什么话想对社区的小伙伴们说呢？
祝 Doris 社区越办越好。
写在最后
感谢王博给 Doris 社区提的宝贵建议，我们关注和认可每一位社区小伙伴对 Doris 作出的贡献，不仅仅只是作为无情的代码提交和 Review 机器，不管是提交 Issue 或参与讨论、帮助我们打磨产品和丰富功能，或者是修改和完善系统文档，或者是贡献应用案例、让我们知道 Doris 在真实业务场景中还能发挥出超出我们想象的能力，亦或是口碑相传、让 Doris 被更多人知晓，每一位参与的小伙伴，都是照亮社区前进道路上的一团星光。这也是「社区人物志」系列栏目成立的宗旨，我们期待与你，不期而遇，共襄盛举。
对于更广大范围的用户，从 Doris 开源到现在，我们所期望的一直都是让 Doris 能帮助更多人，希望每一个 Doris 的用户都能受益。近期我们会在社区建设方面投入更多精力，建立全新的用户沟通渠道，希望与更多的用户走得更近、更清晰聆听用户的声音，也欢迎大家持续关注社区动态。
与此同时，我们诚邀社区的小伙伴一同参与开发，共同打造一款世界级高效易用、性能卓越、技术领先的分析型数据库系统。如果你对 Doris 的技术方向感兴趣，希望一同开发，或者有其他建议或意见，可以通过以下渠道参与：
1.订阅并发送邮件至dev@doris.apache.org
以 Apache Way 的方式参与社区，订阅方式见官网：
http://doris.incubator.apache.org/master/zh-CN/community/subscribe-mail-list.html#_1-发送订阅邮件
邮件列表是 Apache 社区最常用的沟通方式。我们会积极回复邮件列表中的问题。
2.在Doris论坛发帖留言
在百度开发者社区Doris论坛发帖留言讨论：
https://ai.baidu.com/forum/topic/list/209
我们也会不定期的将一些用户常见问题在论坛中进行汇总和答复，方便用户查找。
3. 微信公众号后台留言
直接在 ApacheDoris 微信公众号后台留言，您可以留下您的联系方式，我们将与您取得联系。
4. 加入 Baidu Doris 团队
Baidu Doris 团队主要负责 Doris 内核研发、商业化支持、云端服务和私有化部署。同时也负责维护 Doris 开源社区，欢迎有大数据系统内核研发经验的同学加入我们。您可以通过公众号后台留言或者发送简历至 talent-doris@baidu.com，我们虚位以待。
社区人物志｜张家锋：一个人可能走得更快，但一群人会走得更远活动回顾｜ Apache Doris 的过去、现在与未来活动回顾｜ 基于 Iceberg 拓展 Doris 数据湖能力的实践
欢迎扫码关注：
Apache Doris(incubating)官方公众号
相关链接：
Apache Doris官方网站：
http://doris.incubator.apache.org
Apache Doris Github：
https://github.com/apache/incubator-doris
Apache Doris 开发者邮件组：
dev@doris.apache.org