Apache Doris (incubating) 从2008年第一个版本开始到今天(2019年)已经走过了11个年头。期间,Doris从最初的只为解决百度凤巢报表的专用系统,已经成长为目前国内唯一的分析型数据库孵化项目。一路走来,Doris的初心从未改变。
「Apache Doris —— 为分析而生」
从诞生之日起,Doris的每一步都是为了解决切实的业务痛点,每一次转变都是在面对不同的业务挑战。一路上,Doris砥砺前行,凝结了众多前辈的心血。相信未来,Doris还会有更多的新鲜血液加入,我们一起走的更快,更远。
Doris发展历程
Doris自第一版诞生以来,经过了11年的发展,中间做过无数改进。这里只罗列对Doris发展来说比较重要的关键节点与事件。
#2008
Doris1 ,「筑巢引凤」的重要基石
早年,百度最主要的收入来源是广告。广告主需要通过报表服务来查看广告的展现、点击、消费等信息,并且能够需要通过不同维度来获得广告的消费情况,用以指导后续的广告的投放策略。
在Doris1诞生之前,百度使用MySQL Sharding方式来为广告主提供广告报表支持。随着百度本身流量的增加,广告流量也随之增加,已有的MySQL Sharding方案变得不再能够满足业务的需求。主要体现在以下几个方面:
第一,大规模数据导入会导致MySQL的读性能大幅降低,甚至还有锁表情况,在密集导入数据的情况下尤为明显。同时在数据导入时,MySQL的查询性能大幅下降,导致页面打开很缓慢或者超时,用户体验很差;
第二,MySQL在大查询方面性能很差,因此只能从产品层面来限制用户的查询时间范围,用户体验很差;
第三,MySQL对数据量的支持是有限的。单表存储的数据有限,如果过大,查询就会变慢。对此的解决方案只有拆表、拆库、迁移数据。随着数据量的快速增长,已经无法维护。
当时数据存储和计算成熟的开源产品很少,Hbase的导入性能只有大约2000条/秒,不能满足业务每小时新增的要求。而业务还在不断增长,来自业务的压力越来越大。在这种情况下,Doris1诞生了,并且在2008年10月份跟随百度凤巢系统一起正式上线。
Doris1的主要架构如上图所示。数据仍然通过用户ID进行Hash,将同一个用户ID的数据交由一台机器处理。其中Hm-Storage负责数据的存储。ODP、OMG负责将业务数据导入到Hm-Storage中。AS负责解析、规划查询请求,并将查询请求发给Hm-Storage处理,并对Hm-Storage返回的数据进行一些业务相关的计算后将查询结果返回给用户。
相比于MySQL的方案,Doris1主要在如下几个方面进行了改进。
首先,Doris1的数据模型将数据分为Key列,Value列。比如一条数据的Key列包括:用户ID、时间、地域、来源等等,value列包括:展现次数、点击次数、消费额等。这样的数据模型下,所有Key列相同的数据Value列能够进行聚合,比如数据的时间维度最细粒度为小时,那同一小时多次导入的数据是能够被合并成一条的。这样对于同样的查询来说,Doris1需要扫描的数据条目相比MySQL就会降低很多。
其次,Doris1将MySQL逐条插入改成了批量更新,并且在通过外围模块将同一批次数据进行排序以及预聚合。这样一个批次中相同Key的数据能够被预先聚合,另外排序后的数据能够在查询的时候起到聚集索引的作用,提升查询时候的性能.
最后,Doris1提供了天表、月表这种类似物化视图的功能。比如用户是想将数据按天进行汇聚展现,那么对于这种查询是可以通过天表来满足的。而天表相对于小时表数据量会小几倍,响应的查询性能也会提升几倍。
通过Doris1的工作,完全解决了MySQL Sharding遇到的问题。并于2008年10月于凤巢系统一起上线,完美的支撑了广告统计报表需求。
#2009
Doris2,解「百度统计」燃眉之急
2008年的百度统计服务大约有50-60台MySQL,但是业务每天有3000万+条增量数据,由于MySQL的存储和查询性能无法满足需求,对存量数据的支撑已经到了极限,问题频出,万般无奈之下百度统计甚至关闭了新增用户的功能,以减少数据量的增加。
Doris1由于当时时间紧、任务重,所以设计、实现的时候只为了能够满足凤巢的业务需求,并没有兼顾其他的应用需求。由于Doris1方案对于凤巢成功的支持,百度统计同学开始基于Doris1打造Doris2系统,主要将Doris1进行通用化改造,包括支持自定义schema等,使Doris能够应用于其他产品。此外还进行一些优化以此来提升系统的查询、存储性能。
2009年Doris2研发完成后上线百度统计,并且成功支撑百度统计后续的快速增长,成功的助力百度统计成为当时国内规模最大,性能、功能最强的统计平台。由于在凤巢、百度统计上的成功,公司内部后续其他类似统计报表类的需求也都由Doris2进行支持,比如网盟、联盟等报表服务。
#2010
Doris3 ,让查询再快一点
百度在2009-2011年发展迅猛,营收每年近100%的速度增长,与之相伴的是广告数据量也随之大幅增长。随着业务数据量的不断增长,Doris2系统的问题也逐渐成为业务发展的瓶颈。
首先体现在Doris2无法满足业务的查询性能需求,主要是对于长时间跨度的查询请求、以及大客户的查询请求。这是因为Doris2通过规则将全部数据按照用户ID进行Sharding,这虽然能够将全部数据分散到多台机器上,但是对于单一用户的数据还是全部落在一台机器上。随着单用户数据量增多,一些查询请求无法快速计算得到结果。
其次,Doris2在日常运维方面基本上都需要停服后手动操作,比如Schema Change、集群扩缩容等,一方面用户体验很差,一方面还会增加集群运维的成本。最后,Doris2本身并不是高可用系统,机器故障等问题还是会影响服务的稳定性,并且需要人肉进行复杂的操作来恢复服务。
为了解决Doris2的问题,团队开始了Doris3的设计研发。Doris3的主要架构如下图所示,其中DT(Data Transfer)负责数据导入、DS(Data Seacher)模块负责数据查询、DM(Data Master)模块负责集群元数据管理,数据则存储在Armor分布式Key-Value引擎中。Doris3依赖ZooKeeper存储元数据,从而其他模块依赖ZooKeeper做到了无状态,进而整个系统能够做到无故障单点。
在数据分布方面Doris3引入了分区的概念。首先数据会按照时间进行分区(比如天分区、月分区);在同一个分区里,数据会根据用户ID再进行Sharding。这样同一个用户的数据会落在不同的分区上,而在查询时多台机器就能够同时处理一个用户的数据了,实现了单用户的分布式计算能力。但是可能还会存在一个分区内部单个用户数据量过大的情况。对于这种情况Doris3设计了后续表功能,会将单个分区内大用户的数据进行拆分,导入到多个分片中,这样能够保证每个分片内单个用户的数据总量最高是有限度的。
另外Doris3在日常运维Schema Change,以及扩容、缩容等方面都做了针对性设计,使其能够自动化进行,不依赖线上人工操作。
在当时,由于种种原因,Doris3最终确定使用了Armor来作为底层存储系统。Armor是一款分布式Key-Value系统,支持多副本强一致,且单表内全Key有序。选用Armor作为底层存储能够使Doris3只负责管理分片,而分片的副本,以及副本的一致性都由Armor来处理。并且,集群的扩、缩容等操作也只需要Armor感知即可,Doris3本身并不需要感知。当然除了这些好处外,这样的选型也有一些弊端。
由于Armor是一个通用的Key-Value系统,并不感知上层的业务数据,它并不支持Doris这种数据模型,既相同Key的数据,Value字段是可以进行聚合的。比如数据导入的批次是五分钟一批,但是数据时间粒度是小时,那么其实一个小时的数据可能是多次导入的,但是逻辑上是可以合并成一条数据的。所以为了实现这个功能,只能是Doris3自身实现了较为复杂的数据合并策略来完成相关数据的合并。
Doris3在2011年完成开发后逐渐替换Doris2所制成的业务,并且成功的解决了大客户查询的问题。而公司内部后续的新需求,也都由Doris3来承担支持。
#2012
MySQL +Doris3 ,百度的第一个OLAP平台
2012年随着Doris3逐步迁移Doris2的同时,大数据时代悄然到来。在公司内部,随着百度业务的发展,各个业务端需要更加灵活的方式来分析已有的数据。而此时的Doris3仍然只支持单表的统计分析查询,还不能够满足业务进行多维分析的需求。由于缺少通用的SQL支持,Doris3在面对更加灵活的多维分析场景时有点力不从心。当时,公司内只有Hive以及类似系统支持大数据量的SQL查询,但是他们均是面向解决离线分析场景,而在线多维分析领域缺少一款产品来满足业务方的需求。
所以,为了能够支持业务的多维分析需求,Doris3采用了MySQL Storage Handler的方式来进行扩展。通过此种方式,将Doris3伪装成一个MySQL的存储后端,类似于MyISAM、InnoDB一样。这样既能够利用上MySQL对于SQL的支持,也能利用上Doris3对于大数据量的支持。由于这里MySQL是计算单点,为了减轻MySQL的计算压力,Doris3应用了MySQL的BKA(Batched Key Access)以及MRR(Multi-Range Read)等机制尽量的将计算下推到Doris3来完成,从而减轻MySQL的计算压力。
通过MySQL + Doris3这个方案,百度Insight团队为PS、LBS、WISE等产品线提供了百度内部第一个OLAP分析服务平台。
#2012
OLAPEngine,突破底层存储束缚
另一方面Doris3支持报表分析场景时,底层通用 Key-Value 存储引擎的弊端也逐渐显露。作为一个通用 Key-Value 存储引擎,在支持报表引擎方面暴露了一些问题。
第一,由于Key-Value系统读取只能够读取全Key,全Value,而报表分析系统中的大部分查询并不需要读取所有列,这样会带来不必要的IO开销;第二,正如前文所说,由于引擎本身不感知业务模型,不能够再进行Merge的同时完成数据的合并,这需要Doris3借助复杂的作业管理在引擎外部完成Merge工作既不简洁,也不高效;第三,为了保证业务的导入原子性,Doris3为每批次导入都赋值一个版本号,并记录在每条数据Key的最后部分。这样在查询的时候,需要对每条数据进行Key的解析,比较版本号,过滤掉不需要的版本。这样一方面需要读取无需读取的数据,一方面需要解析所有Key,从而带来不必要的CPU开销;第四,Key-Value系统无法感知数据内容,只能使用通用压缩算法,进而导致数据的压缩效率不高。这样在查询、读取时都会带来较多的IO负载。
为了能够在底层存储引擎上有所突破,OLAP Engine项目启动了。这个项目的发起者是当时从Google来的高T,为百度带来了当时业界最领先的底层报表引擎技术。OLAP Engine最大的特点包括以下几点。
第一,引擎端原生就支持Schema,并且所有的列分为Key列,Value列。这样就能够跟上层的业务模型能够对应上,查询部分列时,无需加载全部列,减少不必要的IO开销。
第二,独特的数据模型。Value列支持聚合操作,包括SUM、MIN、MAX等。在Key列相同的情况下,Value列就能够按照聚合操作类型完成对应的聚合操作。而引擎本身导入方式类似于LSM Tree,这样在引擎后台进行Merge的同时,就能够将相同Key的数据中的Value字段按照对应的操作进行聚合。这样就无需外部再进行数据合并作业管理,将引擎层与业务层合并合二为一,省去不必要的IO、CPU开销。
第三,数据批量导入,原子生效。对于每个批次的导入,都会有个Delta文件对应,并且会有个版本号。在查询的时候只是在初始化的时候来确定读取哪个文件,这样就只会读取生效版本的数据,而不会读取没有生效版本的数据,更不会浪费CPU来进行版本号比较过滤。
第四,行列式存储。多行(比如1024行)数据存储在一个Block内,Block内相同列的数据一同压缩存放,这样可以根据数据特征利用不同的压缩算法(比如对于时间字段使用RLE等)大幅提高数据压缩效率。
即使分布式层没有采用复杂的分布式管理,只是使用类似Doris2的用户ID Sharding方式,OLAP Engine后续也成功的支持了凤巢,网盟等广告业务。这充分的能够体现OLAP Engine强大的报表分析能力。虽然OLAP Engine取得了成功,但是由于硬Sharding方案带来的不易运维、不易扩展等问题仍然存在。
#2013
用PALO,玩转OLAP
底层技术的发展会激发上层业务的需求,而上层业务的需求同时会为底层的技术带来新的挑战。随着第一款OLAP产品的问世,数据分析师们的建模就更加复杂,有时查询SQL会有上千行,人为阅读已经相当吃力。而MySQL + Doris3方案的弊端也就越发突显。因为分析SQL越来越复杂,大量的计算都需要在MySQL中完成,这样MySQL的计算能力就成为整个系统的性能瓶颈,突破这个性能瓶颈也就变得极为紧迫。
因此Doris亟需一款拥有分布式计算能力的查询引擎。幸运的是当时(2013年)各种SQL on Hadoop项目也正蓬勃发展,比如Impala,Tajo,Presto等等。在有限的时间内并不充分调研的情况下,团队选取了Impala作为了后续系统的分布式查询引擎。当时的选择Impala主要的原因是因为其性能较高,并且BE的C++语言跟我们已有系统的语言一致,未来可以省去一部分序列化开销。
由于MySQL + Doris3的方案制约了业务的使用,当时公司的另一个团队邀请了Oracle的Exadata进行POC,这给了Doris团队很大的压力。如果Doris想继续在OLAP领域继续发展,就需要快速的产出原型,并且性能上还要胜出Exadata。为了快速的验证方案的可行性,团队几个月内就把Impala与Doris3进行了集成,并用TPC-H进行了测试,结果是Impala + Doris3性能比Exadata更好。这次原型的成功为我们赢得了一次机会,能够让团队继续改造Doris3从而更好的支持OLAP场景。
新产品的名字命名为PALO,意为玩转OLAP。
PALO1除了增加分布式查询层之外,因为OLAP Engine在统计报表领域的成功,PALO1放弃了Doris3依赖的通用Key-Value系统,选择了OLAP Engine作为自己的单机引擎。因为没有了分布式Key-Value系统,那么PALO1自己完成数据分片管理、副本管理等工作。
PALO1的架构如下所示。其中DM负责管理元数据、数据的分布、分片副本管理等内容,DM本身没有状态,元数据内容都存储在MySQL中。FE负责接收用户的查询请求,并且进行查询规划解析。BE是负责存储数据,以及进行具体的查询执行。
随着PALO1的正式上线,除了迁移所有Doris3已有的的业务外,也成功支持了当时百度内部大部分的OLAP分析场景。
#2015
PALO 2,让架构再简单一点
如果说PALO1是为了解决性能问题,那么PALO2主要是为了在架构上进行优化。由于PALO1模块数目较多,并且外部依赖MySQL,这其实还是增加了运维的压力的。所以我们在PALO2项目中力求将系统的架构进行简化。经过简化后的系统架构如下图所示。
PALO2中我们只存在2种模块:FE、BE。FE一方面负责管理、存储元数据,另一方面FE还负责与用户交互,接受用户查询,对查询规划,监督查询执行,并将查询结果返回给用户。FE本身是有状态的,但是它内部通过BDB JE,能够将元数据进行多副本复制,从而能够保证服务的高可用。BE与PALO1功能一致,只是PALO2的BE包含了存储引擎,一方面减少了一个模块,并且在用户查询的时候少了一次数据的序列化、反序列化操作,节约CPU消耗。
通过PALO2的工作,系统架构本身变得相当简洁,并且不需要任何依赖。因为PALO2架构的简洁,我们后续也相对容易的基于PALO2提供了公有云服务以及私有化部署;另一方面,当PALO开源之后其他用户也能够用通过较低的门槛来搭建使用PALO 。在此之后PALO虽然经过几次改进,但是整体架构仍然保持PALO2的架构。
#2017 and Future
ApacheDoris (incubating) ,是更广阔的世界
PALO2在百度内部基本服务了所有的统计报表、多维分析需求,我们相信它一定可以应用到其他公司,能够帮助更多的人更加高效、方便的支持类似的业务需求。因此,我们选择了开源,PALO于2017年正式在GitHub上开源,并且在2018年贡献给Apache社区,并将名字改为Apache Doris(incubating)进行正式孵化。贡献给Apache之后,Doris就不仅仅是百度的项目,而成为了Apache的项目。
随着开源,Doris已经在京东、美团、搜狐、小米等公司的生产环境中正式使用,也有越来越多的Contributor加入到Doris大家庭中。一路走来,Doris从未惧怕过挑战,也从未被困难击倒。时至今日,Doris已经站在了更高的舞台上,准备拥抱更多的机遇与挑战。
希望未来,会有更多的人来续写这篇Doris简史,讲述这个为分析而生的故事。
|
|
