在“外卷”和“躺平”间挣扎过后，我陪 Doris 走过 8 年岁月

Apache Doris 是一个用于 OLAP（在线分析处理）场景的数据库系统。它集成了 Apache Impala、Google Mesa 和最先进的向量化技术，可提供亚秒级查询和高效的实时数据分析。该项目最初在百度开发为“Palo”，2017 年开源，2018 年 7 月正式进入 Apache 孵化器。

2022 年 6 月 16 日，Apache 软件基金会（ASF）官方宣布 Apache Doris 顺利毕业，正式成为顶级项目（TLP），从进入孵化器到最终毕业，Doris 项目经历了四年的时间，相比于历时 1 年就成功毕业的Dubbo，Doris 的毕业之旅走得不算平坦。

为何 Doris 经历了 4 年的孵化期才最终毕业？这背后发生过哪些值得聊一聊的故事？又是怎样的一群人陪伴着 Doris 走到了今天？近日，InfoQ 采访了陪伴 Doris 走过漫长毕业之旅的项目亲历者陈明雨，他是InfoQ DIVE大会讲师、Apache Doris PMC 成员、前百度 Doris 技术团队负责人，本文中他将和我们一同分享 Doris 项目背后关于技术和社区的一切以及一名程序员最值得回忆的 8 年。

GitHub 地址：https://github.com/apache/doris

图片来源：陈明雨个人公众号（特别陈）

Doris 十四载发展历程

2008 年，Doris 诞生于百度内部广告报表业务的 Palo 项目。最初开发百度 Palo 的团队主要是为百度广告系统开发供广告主查看的在线广告报表系统，由于在线广告报表系统需要满足上百万广告主的大量查询分析需求，这个使用传统 MySQL 分库分表的系统已经显示出诸多问题，比如运维复杂、性能跟不上、容量占用大等。而商业数据库成本高，且性能也没有想象的那么好，最大的问题是由于商业系统闭源，一旦出了问题，查找问题非常复杂。

鉴于此，当时的团队研发了第一代的 Doris 系统，并使用了 2~3 年。

随着规模和业务需求的增加，他们开始借鉴 Google 的思路，研发了百度 OlapEngine，Google 叫 Stats Server。OlapEngine 当前一直服务于百度的凤巢和网盟广告系统，比较稳定。但是由于之前使用的是 MySQL 查询层，OlapEngine 实际上只是单一的为报表类型服务的存储引擎，而在分布式管理方面还比较弱。加之使用 MySQL 查询，查询引擎时常成为性能瓶颈。

2014 年，百度开始将 OlapEngine 改造为分布式存储引擎，自带 sharding 和 replication, 然后采用 Impala 作为分布式查询引擎来替代 MySQL，产品名字也定为 Palo。

重构：从 Palo1 到 Palo 2

正是这一年，研究生毕业后的陈明雨通过校招入职了百度，研究生期间他就一直在做 Impala 相关的项目，入职百度后，也很巧合地续上了技术栈并参与到了 Palo 1 到 Palo 2 的系统重构工作中。

入职后，在 mentor 的带领下陈明雨参与了元数据和分布式管理框架设计与实现。

当时之所以会重构 Palo 系统，是因为 Palo 1 的系统架构非常复杂，有 4-5 个独立进程模块以及 3-4 种编程语言。当时升级一次 Palo 集群，需要两个人结对配合（因为流程太复杂，需要 Double Check）执行数十条命令，这对于一个系统来说无疑是灾难性的。

重构后的 Palo 2 的架构就是我们现在熟知的 Doris 架构。Doris 架构最终升级为两个独立进程（FE+BE）和两种编程语言（Java 和 C++），并且升级过程只需要依次替换二进制文件后重启服务即可。这也反映了 Palo 或 Doris 的设计原则，即为用户交付一个简单易运维的分布式系统。

据陈明雨回忆，当时 Palo 团队的氛围是非常好的，组内同学经常会和高级工程师们讨论技术方案甚至讨论到拍桌子，但都是对事不对人。

其实对于技术团队来说，能够抛开职级进行平等的技术探讨，是非常难得的一件事。我觉得这可能也是为什么 Palo 能够一直在百度内部发展并支撑众多业务的原因。尤其做这类基础软件，最终用户看的是技术实力，而不是其他什么奇怪的东西。

现在来看，当年重构Palo 系统的决定是非常明智的，如果没有这样的设计原则，一个复杂的系统部署、升级步骤会劝退一大部分刚开始试用 Doris 的用户。

2017 年，似乎是顺理成章地，Palo 正式对外开源，同年在百度智能云发布“百度数据仓库 PALO”云服务。

开源一年后，2018 年，百度将 Palo 的核心引擎捐赠给 Apache 软件基金会，并命名为 Apache Doris，自此 Doris 正式进入 Apache 孵化器。百度 Palo 团队开始全力推进 Doris 社区发展。

人员有限，初探开源圈法则，力不从心

在 2018 到 2020 年的两年时光里，陈明雨和团队中的成员们继续奋战在 Doris 项目中，每天被线上线下 Meetup、各种讨论、review 所包围，充实且快乐。

2020 年，在百度 PaLo 团队与社区伙伴的共同努力下，Apache Doris 社区走上发展快车道，荣获 2020 年度 OSC 中国开源项目“最佳人气项目”，2020 InfoQ中国技术力量年度榜单“十大开源新锐项目”，2020 年度开源中国“中国开源项目 Top10”等开源奖项。

也是这一年，Palo 团队遭遇了一些人事变动，陈明雨也从一名核心开发者成长为团队 leader。

从管理项目到管理人，角色转变后，陈明雨的工作重心发生了转移。

陈明雨笑言：“以前做核心研发人员时，做事情有人来指导、关照，但担任团队 leader 后，很多事只能自己扛。”

由于我个人性格因素，很多时候都更愿意自己一个人把事情做了，但这可能会导致自己忙得要死，但团队可能不知道该做什么。一个团队的 leader 需要能够让团队的输出最大化而不是个人输出的最大化。这一点可能是我遇到的最大的挑战，也是我认为自己做的不够好的地方。不过团队的成员都比较给力，所以其实初期并没有出现手忙脚乱的局面。

随着 Doris 社区的不断壮大和繁荣，一些新问题也随之而来，因为维护开源社区或者说维护一个开源项目并不是一件轻松的事情。

首先就是沟通问题。开源之前，Doris 只是百度的一个内部项目，团队是一个紧密的小组，所有事情都可以面对面地高效沟通，包括需求的提出、设计、开发、评审和代码合入，都能高效完成，每季度初，团队会制定好具体的开发计划，接下来的事情就是按照排期来完成。

但对于一个开源社区，沟通会变得非常复杂。因为研发力量不再只来来自于团队内部，社区也有非常强大的研发实例。整个社区其实是一个庞大但松散的组织，并且它的边界可能是未知的。

陈明雨称：“可能突然有一天，某个开发者就提交了一个重大 feature，这 feature 很有用，但之前没有人调研过，也没有人对此熟悉。那问题就来了，我们如何处理这个 feature？如果置之不理，那很可能我们不但失去了这 feature，并且失去了一个开发者。如果处理，谁来做，人力怎么安排？当然，会有一些方式来缓解这些问题，比如制定详细的 Roadmap 来保证各个开发者都能沿着主线开发。而有些社区可能更加严格，比如要求贡献 feature 的开发者必须能够维护这个 feature，才允许合入。但 Doris 当时的阶段，其实还是在很大程度上依赖社区开发者的贡献，并且也希望有更多的开发者参与的。”

所以在当时有限人力的情况下，再挤出时间来处理社区的需求，工作量是非常大的。此外，社区是一个松散的组织，即使是 Doris 团队也没有权利要求开发者做什么事情，也无法控制开发者的开发周期，这就导致需要投入更多的沟通成本来跟踪项目进度。

这些年，陈明雨和他的团队也在不断尝试各种方式来提升开源社区的协同效率，包括制定开发流程、合入准则、代码规范、Roadmap 等等，并通过邀请更多的 Committer 或 PPMC 成员来共同维护项目。

面对规模如此大的工作量，对应的人力还是很有限的，工作时间难免会挤占部分生活空间。在陈明雨身上，白天忙公司的事情，晚上回家再 Review 社区代码就变成了日常。

其次就是对开源用户的技术支持。目前有些社区会使用包括微信群在内的即时通讯软件来解答用户问题，虽然用户的体验很好，但这并不是一个开源社区能够持久存在的支持方式。因为这样会需要耗费大量人力和精力去维护，这样做短时间的确会换来一些用户口碑，但从长久看会延误一些对未来发展更重要的事情。

在陈明雨看来，

Doris 社区可能是对开源用户最友好的一个社区了。用一些用户的话讲，Doris 的社区技术支持力度甚至比一些商业软件的支持力度都要大。其实维护开源社区与其说是压力，其实更多的是一种责任感。

作为一个开源项目，除了要面对来自社区的一些压力外，来自客户的需求也不容忽视。

截至 2022 年，我国数据库市场已经有逾百款数据库产品，分析型数据库领域其实是一个很卷的领域，需求旺盛，因此也意味着竞争激烈。Doris 不仅是一个开源项目，同时在公司内部也有对应的商业化产品。这几年各个公司都开始从 to C 转型到 to B，数据库和数据仓库几乎是互联网公司 toB 的必选项之一。并且随着互联网红利的消失，各个部门也或多或少需要背负一些营收指标。

Doris 开源名声在外，自然少不了商业化需求。据陈明雨称，“有时候客户甚至会越过公司的售前团队直接联系到我们的研发部门，希望提供商业支持。但我们在公司内部毕竟只算是一个小团队，所以很多事情需要研发同学亲力亲为，比如解决客户问题，开发定制化需求甚至帮助客户解决架构问题。作为公司职员，这些工作当然是我们的本职工作，但很多时候就只能挤占工作外的时间了。”

2021 年，Doris 各项核心能力大幅增强，行业影响力进一步提升，成为中国信通院2021 年“OSCAR 尖峰开源项目及社区”，获得“首批可信开源社区共同体（TWOS）”正式成员认证。

2022 年，百度正式完成商标捐赠，推进 Apache Doris 完成毕业，正式成为 Apache 软件基金会顶级项目。

历时四年，一直坚信 Doris 能顺利毕业

从 2018 年进入 Apache 孵化器到最终毕业，Doris 项目经历了四年的时间，相比于历时 1 年就成功毕业的 Dubbo，Doris 的毕业之旅走得稍显坎坷。造成这种情况的最重要的一个原因就是社区的分裂。

社区分裂给用户、开发者甚至是 Apache 基金会都带了一些困扰：

1. 对用户造成了困扰：我应该用哪个？他们是什么关系？又有什么区别？是同一个团队吗？对于这些问题，Doris 团队只能不断地向用户做出解释。更严重的是在分裂初期，因名称混淆问题导致用户完全无法区分两个产品，以至于每次解答用户问题时不得不先确认用户到底使用的是哪个项目，随后再进行一番解释。

1. 削弱了开发者力量：分裂必然导致开发者的分流，从而导致刚刚开始发展壮大的开发者社群变得混乱无序。由于另一个项目采用和 Apache 协议不兼容的 Elastic 协议，这导致源码只能单向的从 Apache Licence 流入 Elastic License，但无法反向流动，从而带来了巨大的协议合规的隐患。（比如一个开发者拷贝了 Elastic 协议的代码并向 Apache 项目提交，而 Reviewer 很难对此做出判断，从而导致单方面的 License 违规的潜在风险。）

3. 来自 Apache 基金会的问责：Doris 当时虽然在 Apache 孵化器中，但项目的管理义务是由 PPMC 负责的。但 PPMC 成员本质上都是个人开发者，在面对一些棘手问题时（比如商标名称混淆等），有向对方问责的权利，但并没有法律层面强制执行的能力。这会导致陈明雨和他的团队付出大量的时间成本进行沟通和跟进，但又因为行为没有强制力，所以非常被动。

好在，这些问题最终在百度公司、Apache基金会导师和第三方的配合下得到了解决。但带来的后果就是社区分裂的事实和部分社区用户对 Doris 社区信心的丢失，以及需要面对外界对 Doris 项目的一些质疑和解释。

尽管经历了多重坎坷，也曾在最艰难的阶段有过沮丧甚至躺平的想法，但陈明雨始终坚信 Doris 最终能够从孵化器毕业。因为在他看来，Doris 是一款性能强大且具有核心竞争力的分布式数据库系统。

在 OLAP 领域，各家产品间竞争的激烈程度有目共睹。但如果把这些产品加上“经过现实线上业务大规模验证的”，“提供高性能复杂 SQL 分析的”，“开源的”等限定条件后，其实可选择的项目并不多，而 Doris 就是其中一个。

陈明雨强调，Doris 最强的竞争力有两点：统一数仓的能力和活跃的社区。

统一的数仓能力

可以看到，目前市场上大部分会使用多个大数据系统进行组合来支持数据业务。之所以选择多个系统，是因为每个系统都只擅长处理某一方面的需求，比如使用 hive、spark 处理离线业务，而使用 flink+实时数仓处理在线业务和流式数据。

但这并不是业务期望的数据平台架构，因为业务方总是希望能够用尽量少的系统来满足更多的需求。

从这个角度来看 ，Doris 的系统架构具备了统一数仓服务的潜力。其中，MPP 架构能够支持高吞吐的离线分析服务，并且 Doris 团队也在尝试开发基于多 stage 等方案的更稳定的 ETL 服务能力。而基于 MVCC 的数据管理、丰富的索引也能够支持包括更新需求在内的增量流式计算。

所以，虽然 Doris 不能够完全替换大规模的离线处理系统或完全的实时系统，但实际上在很多企业并没有那么大的数据体量或非常低的延迟需求的情况下，使用几十台节点规模的 Doris 集群就能够很好地满足 80%甚至全部的业务需求。再加之 Doris 简洁的架构和不依赖第三方系统的运维友好的特性，可以帮助业务以很低的成本完成大数据平台的搭建，解决以往 3-5 个人需要运维十几个系统的尴尬处境。

活跃的开源社区

除了技术实力过硬外，Doris 也有着非常活跃的用户社区和良好开发者生态，这些能够打消用户对 Vendor Locking、需要付费、无法得到技术支持等问题的疑虑。同时，开源社区能够培养大批相关技术领域的人才，企业在招聘方面也会更加灵活。

另一方面，开源极大促进了项目的发展。通过开源社区内部用户和开发者的交流，能够迸发出许多业务需求和技术亮点，从而使得 Doris 一直处于高速发展中，这些是任何闭源软件所无法获得的优势。

同时，技术的开源也反过来形成同类产品之间的竞争，虽然这些竞争有时可能被称之为“内卷”，但无疑最终受益的是用户群体，因为不断的竞争和碰撞是推动技术发展的强有力因素之一。

用陈明雨的话说，一切都是事在人为，并没有什么无法解决的问题。所有的负面情绪，都在于没有把视角放到更高的角度看待问题，而是被局部的得失带错了方向。所以一切过往，皆为序章，也正是有了这些经历，才会不断提升自己。

开源是件既简单又复杂的事

在基础软件蓬勃发展的今天，开源正在吞噬着一切。作为陪伴着 Doris 走过 8 年时光的亲历者，陈明雨如今再谈开源，已经和初入职场时的感受全然不同了。

2017 年那会儿，刚刚步入职场 3 年的陈明雨还没有真正理解开源是什么、开源社区是什么，更不懂什么是 Apache Way。

行至如今，陈明雨认为，开源这件事可以很简单，但也可能变得很复杂。

之所以认为开源很简单，是因为抛开其他因素的干扰，开源是一件非常容易理解甚至是无需解读、自然而然就可以达成的共识：公开、共建、相互尊重。

• 公开：这是开源的起点，原作者让内容对外可见；

• 共建：开源社区的基础，允许共建，才能形成社区；

• 相互尊重：参与共建的人能够相互尊重其他人的贡献。很多不同的开源协议，不论是 copyright 还是 copyleft，其实都是在通过不同的角度去诠释或定义相互尊重的具体行为或方式。

又为什么会变得很复杂，或许是因为以上三点并没有考虑人与人之间的利益关系。

人人都可以高喊出“人人为我，我为人人”这样无私的口号，但实际做起来并不容易。每个人、每个群体都有各自追求的利益中心，这就可能导致“有限制的公开”，“有限制的共建”和“非平等的尊重”。一旦这些所谓“人性”的因素开始接入，开源这件事就会变得非常复杂。

在陈明雨看来，Apache 基金会，以及其他绝大部分开源组织，其本质目的就是希望能够构建遵守可被执行的具体行为准则的组织。在这个组织内的项目、团体和个人，都必须遵守这些行为准则，否则将被问责甚至要求离开组织。开源不能只依靠道德来约束，否则也不会有这些开源协议和开源组织。他所理解的 Apache Way 归根结底就是：中立、个人贡献、公开、自治。

展望未来

四年，对于个人的人生旅程不算漫长，但对于一个在 Apache 孵化器里待了四年的项目，时间不算短。从孵化器毕业并不是 Doris 的终点，未来 Doris 有更长的路要走，当提及对 Doris 未来的规划时，陈明雨称，他对 Doris 的冀望是希望 Doris 能够成为分析型数据库领域的最知名的项目。

对我来说，Doris 的商业化像是一个大型实验，用来验证能否在 Apache Way 的行为准则下，诞生出一个基于 Doris 的、成功且健康的商业公司或商业模式。

此外，虽然 Doris 已经成为了 Apache 顶级项目，但是到目前为止，Doris 还没有形成完整的海外运营体系，这导致了几乎所有开发者都来自国内。陈明雨坦言，如何构建 Doris 在海外的影响力，也是我们在下半年需要探索和尝试的。

作为 Doris 项目的早期参与者，陈明雨完整地见证了 Doris 从进入孵化器到毕业全过程，对他来说，他陪伴 Doris 成长的 8 年，是最值得回忆的时光。

这段时光的确给陈明雨带来了很多美好的回忆，而经过项目洗礼后，沉淀下来的一些方法论同样弥足珍贵。借此次采访之机，陈明雨也为那些希望加入 Apache 孵化器的项目提供了他的一些建议：

1. 深入理解 TheApacheWay

• 重点是理解关于“中立”的描述。然后在审视自身的项目，在保持“中立”的前提下，是否还能达成自身的利益诉求。

• 理解“捐赠”的含义。捐赠，意味着原作者不再拥有对项目的所有权，仅保留“声誉”。

2. 确认项目是否有形成社区的潜力

• 项目的成熟度：如果一个项目过于成熟，人们只是使用而不参与，则无法形成社区。但如果过于稚嫩，甚至无法试用，则准入门槛太高，也无法形成社区。

• 项目是否有足够的新增需求：只有不断新增的需求才能推动社区的建立和发展。

• 是否有足够的人力维持社区：Apache 项目是自治的，并不是将项目“托管”给 Apache。所以如果没有足够的初期人力，请谨慎考虑。

3. 尽早规划社区准则

• 包括流程、规范、社区会议、沟通方式等等。一个规范化的社区能够更有效和高效地发展。

4. 注意商标保护

• 这一点尤为重要。如果在孵化期间产生商标问题，是非常麻烦的，如果没有妥善解决，后果很可能是更名、或者干脆退出孵化。

写在最后

采访的最后，陈明雨表示，陪伴 Doris 一路走来，最想说的话还是感谢。一个项目的发展和成功，离不开一群人的热爱和支持。感谢为 Doris 项目贡献过代码、修改过 Bug 的所有开发者，感谢参与过 Doris 项目的每位同学，不论是团队的努力，个人的坚持，还是公司在背后的支撑，都是前进道路上不可或缺的力量。围绕 Doris 的争议和讨论，以前有，未来也会有，无论如何，希望所有开发者能保持初心，共同前行。

嘉宾简介：

陈明雨，前百度 Doris 团队技术负责人、Apache Doris PMC 成员