从NoSQL到Lakehouse，Apache Doris的13年技术演进之路
整理 | 蔡芳芳、Tina
采访嘉宾：
百度 Apache Doris 主创团队
从 2008 年第一个版本开始到今天，Apache Doris 已经走过了 13 个年头。从推出之初为了满足百度商业系统的业务专用需求，到后来为解决通用报表与数据分析需求进一步改造，并在 2017 年改名 Palo 开源（详见 InfoQ 当时报道），再到 2018 年用回 Doris 这个名字并进入 Apache 软件基金会孵化，Apache Doris 的愿景一直是成为世界顶级的分析型数据库产品。但与此同时，进入云原生时代，Apache Doris 也已经有了它新的定位和目标。
早在 Apache Doris 开源之初，InfoQ 就曾采访过项目负责人马如悦，而今年正好是这个项目开源的第四个年头，我们再一次找到百度 Apache Doris 主创团队，跟大家聊聊 Apache Doris 的过去、现在和未来。据透露，目前 Apache Doris 的毕业筹备工作已经启动，团队接下来的工作重心之一就是推动 Apache Doris 尽快从 Apache 基金会毕业成为顶级项目。
以下内容整理自访谈实录。
Apache Doris 团队：Doris 的十多年历史，走到今天，我们重新去审视，去掉细枝末节，大体可以分为三个阶段：
“NoSQL”阶段（2008-2011 年）
这个阶段主要是满足百度商业系统几个大业务的专用需求。这几个业务，需要给几十万到几百万的客户或者用户提供实时的报表分析与可视化能力。而传统的分析数据库，基本上主要支撑公司内部自己的 BI 需求，而这些 BI 需求，对数据入库的时效性、查询的并发性、查询的延迟性要求都不是很高。所以使用传统的分析数据库根本无法支撑互联网公司全新的分析需求。当时，我们采用了那时候市场上比较火的 NoSQL KV 数据库来存取数据，并且自己实现了一个专用的分布式查询引擎，这个查询引擎不是 SQL 接口，而是类似 REST API，提供了一些聚合函数调用给业务使用来解决需求。
“NewSQL”阶段（2012-2020 年）
这一阶段的研发重点主要是满足以下新的需求：1) 通用的报表与数据分析需求开始增多，大家需要 SQL 接口；2) 原来的 KV 存储引擎无法提供足够的性能支撑越来越多的需求。所以，我们开始研发新的 Doris 系统。首先，我们研发了全新的单机列式存储引擎 olapengine，先是使用单机 MySQL 来做 SQL 查询引擎，通过分库分表方式来解决分布式大规模问题；后来又将单机的列式存储引擎改造为全分布式列式存储引擎，把单机 MySQL 查询引擎改造为 MPP 的 SQL 查询引擎。分布式存储和分布式 SQL 查询引擎的改进，大大提升了性能和应用场景满足度，Doris 在百度被大规模采用。2017 年，Doris 也正式对外开源。
“LakeHouse”阶段 （2021 年开始）
随着用户需求不断进化和云计算技术的广泛推进，Doris 需要考虑离线在线一体化、存算分离、实时更新、半结构化数据分析支持等需求。这些需求总结下来，简单地说就是用户希望拥有传统 MPP 数仓和基于数据湖的湖分析融合能力。目前 Doris 就处在这一阶段，正在全力研发这些新的功能。
Apache Doris 团队： 因为技术和需求会随着时间发生变化，Doris 也会跟着每个阶段去制定不同的目标。
第一阶段 Doris 主要还是满足专用系统的统计分析需求，第二阶段主要是满足通用的报表与数据分析可视化需求。
到今天，我们发现用户或者客户对数据的分析需求，逐渐收敛为三大块：
50% 的需求依旧是各类报表和数据分析可视化需求，就是我们经常提的 BI 的需求；
20-30% 的需求，是对日志等半结构化数据的搜索分析需求；
20-30% 的需求，是对数据科学与机器学习的需求；
而新的 Doris 将会针对这三类场景，进行重点功能和性能设计，以便支撑这三类需求。
Apache Doris 团队：Doris 最初的定位是新式数仓，满足在线的数据分析场景，主要以高并发小查询的性能最为出色。但是发展到今天，它的定位正在发生变化，这个主要变化可以用一个 T 形（一纵两横）来说明。一纵就是指把原来 Doris 最擅长的在线结构化 MPP 数据分析性能优化到最快，而导入实时化、存储读写性能优化、计算性能优化，这些会学习和借鉴 ClickHouse 的一些设计。两横之一是支持半结构化数据，当前全球很多对日志等半结构化数据分析都使用 Elasticsearch，Doris 后续会加强对 ES 所支持场景的满足能力；另一横，就是拥抱云原生技术，支持存算分离，支持较大的查询，满足对数据科学与机器学习场景的支持，这一块需要多去借鉴 Snowflake 和 Databricks 的一些设计。
当前 Doris 的新目标，就是主攻这个类似 T 形的一纵两横。
Apache Doris 团队：Doris 和很多其它竞品不大相同的，主要是源于产业实践。数据库技术不同于应用层软件，数据库技术的研发需要积累多年，并且还要经历大规模的实践检验。在实践中发现问题、发现需求，然后解决，这样整个系统才会比较实用。
Doris 运维非常友好：很多数据库公司研发数据库，但是自己又没有大规模使用，所以对运维友好性支持欠缺。Doris 来自于实践，所以在多年的发展中增加了大量方便运维的特性，比如高可用、方便的扩缩容等。
比如为了节省成本，Doris 支持分层存储，即一个表的一个 Partition 分区，可以设置为过了多久以后自动从 SSD 磁盘转移到 SATA 硬盘上。
比如 Doris 的后端节点，需要管理员在前端主节点手动添加，好多人可能不理解，为什么不是后端节点自动汇报？问出这个问题，就可以发现其没有一线工程经验，自动汇报会带来很多潜在的运维风险，都是我们曾经有过的血泪教训，比如一个很久以前死掉的节点，突然重新启动，那么很可能就会误加入进来，造成查询不可控。
比如 Doris 支持物化视图和基础表的数据一致性，这都是源自一线业务对数据一致性的强烈要求，业务无法接受物化视图表和基础表的不一致，因为对终端用户来讲，不一致会带来很多的理解问题。
综上，Doris 里面有大量的这种设计，这些功能对于不是一线运维的同学，或者运维经验不丰富的同学，可能不会了解到其好处，反而还会认为是坏处。
Doris 主要做的不好的我认为有两处，一个是对传统数仓的兼容性，毕竟它来自互联网公司，在推广到传统数仓领域时，在一些 SQL 兼容性上遇到了一些问题，当前正在优化解决；另一个是对云原生技术的全面拥抱，Doris 最初设计时，主要还是考虑私有化部署，那时云计算还不火。但当前云技术的采用正在加速，所以 Doris 后续也会加强对云原生的深度融合适配。
Apache Doris 团队： 我们的观点还是没有变化，虽然市场上依旧是看性能为主。我们认为一个生产级别的数据库，要综合考虑各个方面，稳定性、易用性等，都需要考虑在内。比如，很多人一直抱怨 Doris 没有 ClickHouse 快，这个我是认为比较片面的。
就拿性能来说，一个在线系统，尤其针对高并发的在线分析系统，需要关注整个系统对众多并发查询都能提供稳定的响应，还要充分考虑预留足够的资源给可能突发的一些查询。如果一个查询就把所有磁盘和 CPU 全部用满，那么其它查询如何保证得到足够的资源进行响应？多并发来了，如何保证系统内存不崩？所以，有些设计不是能不能做到的问题，而是要考虑应该不应该这样做的问题。 比如 Doris 的每个查询，就会控制内存和 IO 线程的使用，并不是全量将系统的算力资源耗尽，而是在尽量满足性能响应需求的情况下，理性控制其使用量。
而易用性、运维友好这个可以追求极致，你会看到 Doris 为了不额外引入 ZooKeeper 这种系统造成运维复杂，自己研发了一套内置的多 FE 系统。
当然，我们在面向 To B 推广 Doris 时，很多人经常会通过单一 SQL 的查询性能来衡量这个系统优还是劣，POC 测试对性能非常看重。针对这些情况，Doris 后面会采用类似汽车中的驾驶模式那种形式，提供 Normal 和 Sport 模式。当你将 Doris 设定为 Sport 模式时，Doris 将会以性能最快方式运行，榨取系统每一滴算力。而 Normal 模式，我们更建议在线上使用，以保持系统的稳定性和应对突发请求的能力，不要让系统始终运行在崩溃边缘。
Apache Doris 团队： 这几年团队成员有过变化，但团队规模一直在稳步增加，目前好几个方向的人员数量加起来有 40 多人，既包含了 Doris Core 核心数据库的研发，也包含了百度智能云上产品和外围生态组件的前后端开发人员，还有一支实力强大的产品和运营团队。
从开源至今，在社区的共同努力下，Doris 得到了前所未有的飞速发展，做了非常多的功能迭代和更新。主要包括以下几方面：
流式导入功能帮助 Doris 从分钟甚至小时级别的导入延迟推进到了秒级，更好地支撑了准实时的业务需求； 完全重构了存储引擎，提升扩展性的同时，支持了包括二级索引、字典压缩编码在内的多项实用功能； 进行了大量的大数据生态打通工作，包括 Spark、Flink、ES、Hive、Kafka 的直接连通，使得 Doris 不再成为数据孤岛； 在明细数据上扩展了预聚合模型，完成了明细、聚合模型的数据统一访问； 全新的向量化执行引擎和资源隔离方案也即将发布，将进一步提升 Doris 的数据分析性能和业务应用场景； 还有其他非常多的稳定性和易用性的提升，也是得益于开源后社区用户的不断打磨和反馈。
Apache Doris 团队：Doris 最初设计是存算一体化的 MPP 数据仓库，偏在线分析。而数据湖架构的分析，主要是存算分离，偏离线或者交互式分析，存储引擎一般是 HDFS 或者对象存储，而分析引擎类似 Spark/Hive/Presto。
从去年开始，大家已经开始广泛地推进 Data Warehouse 和 Data Lake 架构的融合，即是所谓的湖仓一体，Lakehouse 的架构。Doris 也正在从数仓架构向 Lakehouse 演进。
Apache Doris 团队：最大的变化就是 SQL 的取胜，实时的取胜，云原生的取胜。
SQL 的取胜：从使用 Java 写 MapReduce、Pig，用 Scala 写 Spark 程序到 PySpark，最终还是 SQL 笑到了最后，SQL 占据了数据分析的 80%； 实时的取胜：人们对于速度的追求是无止境的，一个事情不能做，希望可以做到，这个事情可以做到了，希望能越快越好。数据分析领域正在全面拥抱实时化的需求，希望实时的数据导入，希望实时的数据产出。从离线做起的 Hive、Spark 正在不断优化查询性能，而那些直接从实时性能切入的 MPP 数仓和实时湖分析，比如 Presto，正在全面攻占在线实时市场； 云原生的取胜：云原生已经不再是噱头，而是正在成为关键赋能技术，Snowflake 的大卖，让云原生成为每个数据分析产品都绕不开的领域。
基础设施软件必然要开源
Apache Doris 团队：Doris 从 13 年设计新版时，就考虑到了未来会开源出去，所以，我们在 13 年设计时，就没有依赖百度内部任何一个库，并且整个系统也不依赖百度任何服务就可以独自运作。
百度很多系统难以开源，主要是开始设计时，对百度内部闭源库和内部系统的依赖较多，导致开源的时候需要大量重写，最终使得开源难度非常大。Doris 没有这个问题。
Doris 从 13 年就坚信未来基础设施软件必然是开源的，只有开源才能保持活力和持续迭代。并且像 Doris 这种基础软件，需要较大投入，如果不开源，不寻找其它价值点，是很难让一个大公司持续投入资源来维持其不断发展的。
Apache 是对开源极其友好的基金会，在大数据领域，Apache 软件基金会的项目都极具影响力，比如 Hadoop 和 Spark 都是 Apache 软件基金会的项目，所以 Doris 开源时也选择了 Apache 软件基金会。
Apache Doris 团队： 我们认为衡量开源的成功与否关键在于以下三点：
被广泛认可的产品价值
繁荣、自治、良性发展的社区生态
开源与商业化的平衡与共存
Apache Doris 团队： 作为任何一个技术人员，开源已经成为了一种信仰，一方面是解决更多人的问题所带来的成就感，另一方面就是社区的广泛参与必定为项目带来更好的活力，所以我们非常鼓励团队成员参与开源。
Apache Doris 团队： 开源社区不是只有维护团队，每一个开源产品的使用者其实都是开源社区的一份子。在使用开源产品的同时，也可以多多回馈社区，这样开源产品才能有更旺盛的生命力。
这里引用我们社区里一些用户的话 “在开源过程中，你会结识志同道合的朋友，获得朋友的认可与支持，甚至能够与自己崇拜的业界大佬共同交流。”、“我们每个人都有能力让社区变得更好，在社区帮助我们成功支持业务的同时，我们也应该尽自己所能，去回馈社区、帮助社区，哪怕只是一个文档的修复，也是帮助。”
上面其实也是我们想传达的理念，参与开源其实没有什么门槛，我们希望能有更多的小伙伴参与到社区建设中来。不论是提交 Issue 或参与讨论、帮助我们打磨产品和丰富功能，或者是修改和完善系统文档，或者是贡献应用案例、让我们知道 Apache Doris 在真实业务场景中还能发挥出超出我们想象的能力，亦或是口碑相传、让 Apache Doris 被更多人知晓，都是帮助 Apache Doris 在成长道路上更进一步！
Apache Doris 团队：开源社区之间其实不存在竞争一说，倒是有非常大的合作空间。
代码和社区其实不用一概而论，代码是代码，社区是社区。 使用代码的人是用户，这些用户是完全自由的，如何选择一款开源产品及其代码是由用户自己的技术认知和业务需求来决定的，这里的竞争是存在于代码层面的。而开源社区其实在代码之上，也就是 Apache 理念的 Community Over Code，每个人都可以参与到社区，不管是不是用户，不管有没有需求，都可以作为独立的身份加入到社区里来。
社区的发展有先后之分，社区间的合作可以帮助社区在更大范围的人群中得到传播，也能帮助新兴社区更快成长，还可以让开源代码汲取到更丰富的养分。
对于中国开源市场，希望能有更多的开源项目可以蓬勃发展，这也会让每一个人从中受益。
Apache Doris 团队： 当前大量底层技术产品都采用开源模式，客户也愿意采用开源产品，所以大环境也会逼着你去开源；另外，在商业市场中存在着 2/8 原则，即 80% 的收入来自 20% 的付费用户，而另外 80% 的用户贡献收入并不高，然而前者无论开源与否，都可能付费；而后者则更喜欢开源产品；但是，其中最重要的一条规律是，前面 20% 付费用户的选择会参考后面 80% 用户的选择。因此从商业上来看，让产品开源，让 80% 的用户免费使用你的产品，必然会带来很好的口碑，这直接会影响到那 20% 的高付费用户，20% 的这群高付费用户更多地关注服务。
所以，对于未来的技术产品，开源可能成为必须，这个“必须”不一定损害商业模式，反而会促进商业上的成功。 最近一两年我们也跟很多面向开源软件领域的投资人有过多次沟通，开源和商业化的之间必定是相互成就的。
但开源与商业化如何协同是当前和未来开源面临的问题。开源与商业化需要找到一个良性并存的方式，才能将开源推向另一个高度。
当前开源与商业化如何协同，业内都在探索，还在苦苦寻求中。付费技术支持、Open Core、SaaS 模式仍然是三个主要的商业化模式，但是在实际操作中都有其大的问题。
但是，我相信，随着各类基于开源的商业化公司的不断探索，成功与失败，最终一定会探索出比较好的商业模式。
Apache Doris 团队： 商业化路径方面，我们认为云上才是未来，因此我们数年前就在百度智能云上推出了基于 Apache Doris 的企业版产品 Palo 并提供了云端托管服务，通过云服务的优势（比如按需取用和更加可控的海量资源、从繁琐的运维工作中解放人力等）去满足更多企业上云的需求。我们 云上 Palo 的核心代码与开源版完全一致，避免用户可能担心被公有云厂商强绑定。我们公有云托管服务的价格，比用户购买物理机甚至云上虚机自行搭建的费用还要低。我们还基于 Palo 提供了管控运维平台等一系列云上组件，通过丰富的外围组件给用户带来体验更加的云上服务，目前我们的自助分析平台 Studio 和可视化运维监控 Manager 已经逐步成熟起来。
目前我们已经拿下的商业化客户大概有接近 50 家，包括银联商务、知乎、四川航空等，更具体的数字就不进一步展开了。
Apache Doris 团队： 数据分析场景主要是三大块：数据仓库与商业智能、日志检索与分析、数据科学与机器学习场景，这三大场景占据了客户 80% 的数据分析需求。这三大场景的不断发展，未来一定会将数据分析的需求推为企业 No.1 的需求。从各大咨询调研报告来看，数据分析产品的增长依旧位列各种软件产品的第一位。
本文选自《中国卓越技术团队访谈录》（2021 年第五季），扫描二维码查看更多独家专访↓
欢迎扫码关注：
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