关于大数据:6000字详解数据仓库明星产品背后的技术奥秘

本文由百度智能云高级产品经理——鲁志敬 在百度开发者沙龙线上分享的演讲内容整顿而成。内容深度解读 Polo 产品的技术架构与产品个性。心愿本次分享可能让听众对 Palo 有一个根本意识，并把握肯定的数据仓库设计办法。

文：鲁志敬
视频回放：https://developer.baidu.com/l…

本次分享的主题是：百度数据仓库 Palo 技术个性解读。内容次要分为以下三个方面：

• 产品介绍与倒退历程
• 利用场景介绍
• Palo 技术个性解读

01 产品倒退历程

百度数据仓库 Palo 是基于业内当先的 OLAP 数据库 Apache Doris（Powered By Apache Doris）构建的 MPP 架构云数据仓库，致力于帮忙企业疾速且低成本地构建极速易用的云上数据分析平台，减速企业数智化过程。

• 反对规范 SQL 并齐全兼容 MySQL 协定
• 仅需秒级甚至毫秒即可返回海量数据下的查问后果
• 无效反对多维分析、实时剖析、交互式剖析等多种数据分析场景

倒退历程

阶段一：助力外部业务

Palo 的历史能够追溯到 2008 年，过后是解决百度凤巢统计报表的专用零碎，随着百度业务飞速发展，外部对系统进行了屡次迭代，逐步承当起百度外部业务的统计报表和多维分析需要，成为百度外部第一个 OLAP 剖析平台。

阶段二：做大做强

2013 年，Palo 进行了 MPP 框架的降级，2017 以百度 Palo 的名字在 GitHub 上进行了开源，于此同时在百度智能云上公布了云端托管服务“百度数据仓库 Palo”。2018 年把 Palo 奉献给 Apache 基金会，更名为 Apache Doris。

02 利用场景

数据分析需要的演进趋势

• 查问后果能够疾速响应
  晋升查问效率始终是剖析型数据库倒退的第一能源。从过来查问一个报表、跑 SQL 须要半个小时、几十分钟到当初的秒级甚至毫秒级，这给带来效率的晋升是微小的。
• 实时业务洞察
  数据价值会随时间推移而升高，T+ 1 曾经不能满足业务对高时效性的要求。
• 灵便需要应答
  业务趋势预知与零碎建设滞后的矛盾，需要交付周期较长。
• 全民化的数据摸索
  更低的剖析门槛和学习老本，更高的并发反对。

Palo 在企业大数据体系中的多种利用场景

• 数仓查问减速

解决传统数仓和数据平台查问效率低下的窘境，达到海量数据低至毫秒 / 秒级查问耗时，海量数据无缝利用，极大幅度减速数据决策效率。

• 实时数仓构建

反对流式数据高效导入、业务指标实时聚合，保障业务数据得以实时洞察，并能够缩小数据处理链路、对立数据流向，简化大数据平台架构。

• 多源联邦查问

构建跨多个数据源的对立查问入口，实现实时数据和离线数据的联邦剖析，满足数据分析人员更多元化的查问需要。

• 交互式数据分析

以借助一些 BI 可视化工具的能力去构建交互式数据分析利用，对海量数据进行自助探查和多维度剖析，实现对业务的深层摸索和疾速决策。

03 技术个性解读

零碎架构

在架构方面，Palo 只有两个主过程模块。一个是 Frontend（FE），另一个是 Backend（BE）。

• Frontend（FE）

能够了解为 Palo 的管控节点，次要负责用户申请的接入、查问打算的解析、元数据的存储和集群治理相干工作。

• Backend（BE）

次要负责数据存储、查问打算的执行。

这两类过程都是能够横向扩大的。除此之外，Palo 不依赖任何第三方零碎（如 HDFS、Zookeeper 等）。这种高度集成的架构设计极大的简化了一款分布式系统的运维老本。

极致性能背地的核心技术

对于一个剖析型数据库，最外围的三个组成部分就是 存储引擎、查问引擎和查问优化器，这也是 Palo 极致性能的决定因素。

存储引擎

• 存储格局：列式存储
  在剖析场景，列存往往只会读取须要的列，跳过无用数据，会比行存扫描更少的数据量，缩小 IO 开销以进步性能。
  同时数据依照列进行间断存储，因为类型雷同，因而能够取得极高的压缩率，节俭磁盘空间。

• 自适应编码
  对不同的列类型还提供了不同的编码方式，如 INT 类型会应用 BitShuffle 的编码方式，而字符串类型会应用字典编码。更进一步的，Palo 还会主动依据列的值来切换编码类型。
  在编码根底上还进一步通过 LZ4 算法进行压缩，最高提供 1:8 的数据压缩比。也就是说，10G 数据进入 Palo 可能只占用 1G 多，这样能够极大节俭磁盘空间。

这种列式的存储组织模式还为下层计算的性能优化提供了很大的便当，特地是在 向量化查问 和提早物化 等方面。

• 文件组织
  文件组织模式上，Palo 的文件格式和 Parquet 比拟相似。一个数据版本会被宰割成最大 256MB 一个的 Segment，每个 Segment 对应一个物理文件。
  Segment 通常分为 Header、DataRegion、IndexRegion、Footer 这几个区域。
  Data Region 用于按列存储数据，每一列又被分为多个 Page。

Index Region 则负责存储数据的索引，Palo 提供了丰盛的索引构造来帮忙减速数据的读取和过滤。

• 索引类型
  索引的类型大体能够分为 智能索引 和二级索引 两种，其中智能索引是在 Palo 数据写入时主动生成的，无需用户干涉，包含前缀稠密索引、Min Max 索引等。而二级索引是用户能够选择性的在某些列上增加的辅助索引，须要用户自主抉择是否创立，比方像 Bloom Filter、BitMap 倒排索引等。

查问引擎

Palo 的查问引擎是 基于 MPP 的火山模型，是从晚期版本的 Apache Impala 演变而来，也是在各种数据库系统中利用最宽泛的模型。

• Exchange 节点
  绝对于一些分布式 Gette-Setter 框架，最显著的区别在于其实现了 Exchange 节点。
  在 Palo 中，一个 SQL 语句会学生成一个逻辑执行打算，而后依据数据的散布，造成一个物理执行打算。

物理执行打算会有多个 Fragment，而 Fragment 间接的数据传输则是由 Exchange 节点实现的。
有了 Exchange 节点，最大的收益是整个查问框架领有了数据 Reshuffle 的能力，通过这个能力，查问的计算节点不在局限于数据的存储节点，从而可能更好的利用多节点资源进行并行数据处理。

在 Palo 中，物理执行打算中的 Fragment 会被发往多个 BE 节点并行执行。不同 Fragment 之间的数据通过 Exchange 节点，依据规定 Shuffle 到对应的下层 Fragment 中。

除了节点间并行，Palo 还反对在一个节点外部持续拆分 Fragment，从而进行节点内的并行执行，以充分利用一个节点上的多 CPU 资源。

• 算子优化
  除了整体的执行框架通过并行设计来进步查问效率外，Palo 还对很多具体的查问算子进行了优化。

最典型的就是 聚合算子 和Join 算子。

聚合算子是一种阻塞型的算子，他须要等到全副数据处理实现后，才会将数据发送给下层节点。

在 Palo，聚合算子会被拆分成 两级聚合。第一级聚合会在数据所在节点先进行一次本地聚合，来缩小发送到第二层聚合时须要传输的数据量，而第二层聚合会将雷同的 Key 汇聚到同一个节点，进行最终的聚合计算。

在第一级聚合算子中，如果发现数据的聚合成果很低，即便聚合后也无奈无效升高须要传输的数据量时，则会主动的进行第一级聚合，而将算子转换为一个非阻塞的流式算子，间接将读取到的数据发送到下层节点，从而防止了不必要的阻塞等待时间。

针对 Join 算子，Palo 也进行了大量优化，其中 Runtime Filter 是其中很重要的一种优化形式。
在两个表的 Join 操作中，咱们通常将右表称为 BuildTable，而左表称为 ProbeTable。
在实现上：

1. 首先读取右表的数据，在内存中构建一个 HashTable（Build）。
2. 读取左表的每一行数据，并在 HashTable 中进行连贯匹配，来返回合乎连贯条件的数据。
   通常来说，左表的数据量会大于右表的数据。

Runtime Filter 的设计思路：
在右表构建 HashTable 的同时，为连贯列生成一个过滤构造。之后把这个过滤列构造下推给左表。这样一来，左表就能够利用这个过滤构造，对数据进行过滤，从而缩小 Probe 节点须要传输和比对的数据量。这种过滤构造被称为 Runtime Filter。
针对不同的数据，Palo 也实现了不同的 Filter 类型，如 In Predicate，Bloom Filter 和 Min Max，用户能够依据不同场景进行抉择。
Runtime Filter 能够实用于大部分 Join 场景，包含节点的主动穿透，将 Filter 穿透下推到最底层的扫描节点，或者在分部的 Shuffle Join 中，将多个节点产生的 Filter 进行合并后再下推等。

向量化执行引擎

向量化执行引擎，顾名思义，向量化就是算法从一次对一个值进行运算转换为一次对一组值进行运算的过程。

向量化执行引擎有以下几方面的劣势：

1. 缩小火山模型中的虚函数调用数量；
2. 以块为单位解决数据，提供了 cache 命中率，从 Cache 中读取数据和从内存中读取数据，性能有 10-100 倍晋升；
3. 多行并发解决，符合了 CPU 乱序执行与并发执行的个性。
4. 同时解决多行数据，使 SIMD 有了用武之地。

在 Palo 中咱们正在开发全新的向量化执行引擎，目前曾经实现 宽表模型上的向量化查问，Join 和存储层向量化正在开发中，预计 2021 年底就能够全面实现向量化。

查问优化器

对于一个 SQL 查问，会在 SQL 词法和语法解析实现后生成形象语法树，再进一步转换成关系代数表达式，而后生成逻辑执行打算。
查问优化器次要用于从逻辑执行打算到物理执行打算的转换，生成最优的执行打算交由查问引擎执行。在这个过程中查问优化器的作用在很大水平上决定了查问性能。

基于规定优化 RBO 就是会将原有表达式裁剪掉，遍历一系列规定 (Rule)，只有满足条件就转换。而基于代价优化 CBO 会将原有表达式保留，基于统计信息和代价模型，生成最小的执行打算。

Palo 查问优化器可能同时进行 基于规定和基于代价的查问优化，这里咱们简略列了一些优化点，例如常量折叠、子查问改写、谓词下推以及 Join Reorder、Colocate Join 和 Bucket Shuffle Join 等。

04 简略易用

通过上述在查问引擎、存储引擎以及查问优化器上做的诸多优化，实现了极致的查问性能。但性能不是数据库的全副，对用户来说，易用性才是决定是否继续应用的要害，Palo 从零碎设计之初就始终以用户的易用性作为出发点。
从一个用户剖析的全周期来看，个别能够简略演绎成四个方面，从 数据建模→数据导入→用户上手剖析→继续应用以及保护降级，Palo 的易用性无处不在。

数据建模

通过这个建表语句，就能疾速建设起分布式表。绝对于 MySQL 建表语句，在 Palo 中只减少了一些分布式系统所具备的个性，比方分辨别桶等，有过分布式应用教训的十分易于上手，就算没有应用过也能疾速把握。

Palo 目前反对三类数据模型：

• Aggregate 模型
  能够通过预聚合，极大地升高聚合查问时所需扫描的数据量和查问的计算量，非常适合有固定模式的报表类查问场景。
• Unique Key 模型
  针对须要惟一主键束缚的场景，能够保障主键唯一性束缚主键惟一模型，实现精准去重和行级别数据更新；
• Duplicate 模型
  能够保留全量明细数据，适宜任意维度的 Ad-hoc 查问。尽管同样无奈利用预聚合的个性，然而不受聚合模型的束缚，能够施展列存模型的劣势。

物化视图是将事后计算（依据定义好的 SELECT 语句）好的数据集，存储在一个对用户通明却有实在数据的视图表格中。
物化视图次要是为了满足用户，既能对原始明细数据的任意维度剖析，也能疾速的对固定维度进行剖析查问，在对立视角下对明细、聚合数据进行剖析。
用户查问时，Palo 会依据以后查问的语句去主动抉择一个最优的物化视图，从物化视图中读取数据并计算。如果产生数据导入或删除，物化视图会自动更新，保障原始表和物化视图表的数据一致性。

Palo 反对两层的数据划分。
第一层是 Partition，反对 Range 和 List 的划分形式。
第二层是 Bucket 分桶，将数据通过 Hash 进行程度划分，数据分片 Tablet 平均在集群中打散。

数据导入

Palo 提供多种数据导入计划，能够针对不同的数据源进行抉择，同时在数据导入过程中提供原子性保障。不论是应用 Broker Load 进行批量导入，还是应用 INSERT 语句进行单条导入，都是一个残缺的事务操作。导入事务能够保障一批次内的数据原子失效，不会呈现局部数据写入的状况。

同时，一个导入作业都会有一个 Label。这个 Label 是在一个数据库（Database）下惟一的，用于惟一标识一个导入作业。Label 能够由用户指定，局部导入性能也会由零碎主动生成。
Label 是用于保障对应的导入作业，仅能胜利导入一次。一个被胜利导入的 Label，再次应用时，会被回绝并报错 Label already used。通过这个机制，能够在 测做到 At-Most-Once 语义。如果联合上游零碎的 At-Least-Once 语义，则能够实现导入数据的 Exactly-Once 语义。

用户剖析

Palo 反对规范 SQL，例如单表聚合、排序、过滤以及多表 Join、子查问等都反对，并且 SQL 语法向 MySQL 兼容，无额定学习老本。
Adhoc 这类高吞吐的即席查问和库内 ETL 场景也是 Palo 的强项。
Palo 可能反对简单 SQL 语法，包含窗口函数、Grouping Set 等高级语法性能，同时还能够通过 UDF 或 UDAF 来自定义拓展 Palo 的性能。

高并发场景也是 Palo 的劣势 。Palo 是少有的可能反对高并发现在服务场景的 OLAP 零碎，单节点能够反对上千 QPS 的查问申请。
高并发的反对得益于 Palo 的分辨别桶裁剪性能。利用查问条件，Palo 能够将查问固定到极少数分片上，从而显著升高单个查问对系统资源的耗费，晋升集群整体的并发查问能力。

Palo 还反对 SQL 级别和 Partition 级别的 Cache。其中 SQL Cache 以 SQL 语句的 Hash 值作为 Key，间接缓存 SQL 后果，非常适合更新频率不高，然而查问十分频繁的场景。
而 Partition 级别的 Cache，会智能的将 SQL 后果中不同分区的后果数据缓存起来，之后的查问，能够利用已缓存分区的数据加上新分区实时查问的数据失去最终的后果，从而升高反复数据的实时查问需要，缩小对系统资源的耗费。

在用户行为剖析场景，Palo 反对 BitMap 数据类型。能够通过 Bitmap 进行疾速剖析，同时 Palo 内置了很多 Bitmap 相干的函数，用于计算画像、漏斗、留存等。

在 Palo 的最新版本中还减少了多租户和资源隔离的个性。

Palo 不仅能够反对集群内节点级别的资源组划分，还能够针对单个查问的资源限度。

保护降级

作为一款分布式系统，Palo 的降级形式却极其简略，只须要替换二进制程序，滚动重启集群即可 。
在设计上，Palo 齐全向前兼容 ，所以也能够通过灰度降级的形式进行新版本的验证和测试。而 Palo 自身的一些失败重试和故障路由，也极大水平的升高了在降级过程中对业务的影响。
同时 Palo 本身的分布式治理框架，能够主动的治理数据正本的散布、修复和平衡。比方对于正本损坏的状况，Palo 会主动感知并进行修复。
而对于节点扩容，仅需一条 SQL 命令即可实现，Palo 会主动进行数据分片的平衡，整个过程齐全不影响零碎服务，无需运维人员进行任何额定的操作。

平安稳固的云上托管服务

除此之外还充分利用了云平台劣势，例如按需取用的海量资源、更加可控的资源管理等，联合百度智能云减少了许多云上个性。包含功能丰富的云上管控平台、基于对象存储 BOS 的 冷热数据拆散架构以及高效易用的企业级生态组件。

以上是老师的全副分享内容，有问题欢送在评论区提出。

扫描二维码，备注：大数据开发，立刻退出大数据产品 & 技术交换群。