您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

(doris怎么读)-fairy怎么读

数据,业务,用户(doris怎么读)-fairy怎么读

发布时间：2016-12-08加入收藏来源：互联网点击：

在当时，由于种种原因，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。通过此种方式，将 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

OLAP Engine，突破底层存储束缚

另一方面 Doris3 支持报表分析场景时，底层通用 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 是负责存储数据，以及进行具体的查询执行。

 2/3   首页 上一页 1 2 3 下一页 尾页