前言
随着数字产业化和产业数字化成为经济驱动的关键能源，企业的数据剖析场景越来越丰盛，对数据剖析架构的要求也越来越高。新的数据剖析场景催生了新的需求，关键包括三个方面：
数据湖的发生很好的满足了用户的前两个需求，它准许用户导入任何数量的实时取得的数据。用户可以从多个起源搜集数据，并以其原始方式存储到数据湖中。数据湖领有极高的水平裁减才干，使得用户能够存储任何规模的数据。同时其底层通经常常使用便宜的存储方案，使得用户存储数据的老本大大降落。数据湖经过敏感数据识别、分级分类、隐衷包全、资源权限控制、数据加密传输、加密存储、数据危险识别以及合规审计等措施，协助用户建设安保预警机制，增强全体安保防护才干，让数据可用无法得和安保合规。
为了进一步满足用户关于数据湖剖析的要求，咱们须要一套实用于数据湖的剖析引擎，能够在更短的期间内从更多起源应用更少数据，并经常使用户能够以不同方式协同处置和剖析数据，从而做出更好、更快的决策。本篇文章将向读者详细揭秘这样一套数据湖剖析引擎的关键技术，并经过StarRocks来协助用户进一步了解系统的架构。
之后咱们会继续宣布两篇文章，来更详细地引见加快数据湖剖析引擎的内核和经常使用案例：
什么是数据湖
什么是数据湖，依据 Wikipedia 的定义，“A>了解完数据湖的定义之后，咱们人造而然地想知道数据湖能为咱们提供什么共同的才干，咱们为什么要经常使用数据湖?
在数据湖这个概念进去之前，曾经有很多企业或组织少量经常使用 HDFS 或许 S3 来寄存业务日常运作中发生的各式各样的数据(例如一个制造 APP的公司或许会宿愿将用户所发生的点击事情事无巨细的记载)。由于这些数据的价值不必定能够在短期间内被发现，所以找一个便宜的存储系统将它们暂存，等候在未来的一天这些数据能派上用场的时刻再从中将有价值的消息提取进去。但是HDFS 和 S3 对外提供的语义毕竟比拟繁多(HDFS对外提供文件的语义，S3对外提供对象的语义)，随着期间的推移工程师们或许都无法回答他们究竟在这外面存储了些什么数据。为了防止后续经常使用数据的时刻必需将数据逐一解析才干了解数据的含意，痴呆的工程师想到将定义分歧的数据组织在一同，而后再用额外的数据来形容这些数据，这些额外的数据被称之为“元”数据，由于他们是形容数据的数据。这样后续经过解析元数据就能够回答这些数据的详细含意。这就是数据湖最原始的作用。
随着用户关于数据品质的要求越来越高，数据湖开局丰盛其余才干。例如为用户提供相似数据库的 ACID 语义，协助用户在继续写入数据的环节中能够拿到point-in-time的视图，防止读取数据环节中发生各种失误。或许是提供用户更高性能的数据导入才干等，开展到如今，数据湖曾经从单纯的元数据治理变成如今领有愈加丰盛，愈加相似数据库的语义了。
用一句不太准确的话形容数据湖，就是一个存储老本更便宜的“AP数据库”。但是数据湖仅仅提供数据存储和组织的才干，一个完整的数据库不只要有数据存储的才干，还须要有数据剖析才干。因此怎样为数据湖打造一款高效的剖析引擎，为用户提供洞察数据的才干，将是本文所要重点论述的部分。上方经过如下几个章节一同逐渐拆解一款现代的OLAP 剖析引擎的外部结构和成功：
怎样在数据湖上启动加快剖析?
从这一节开局，让咱们开局回到数据库课程，一个用于数据湖的剖析引擎和一个用于数据库的剖析引擎在架构上别无二致，通常咱们以为都会分为上方几个部分：
关于一个数据湖剖析引擎而言，Optimizer 和 Execution Engine是影响其性能两个**模块，上方咱们将从三个维度入手，逐一拆解这两个模块的**技术原理，并经过不同技术方案的对比，协助读者了解一个现代的数据湖剖析引擎的始末。
基本过去讲，优化器的上班就是对给定的一个查问，生成查问代价最低(或许相对较低)的口头方案。不同的口头方案性能会有不可胜数倍的差距，查问越复杂，数据量越大，查问优化越关键。
Rule Based Optimization (RBO) 是传统剖析引擎罕用的优化战略。RBO的实质是**是基于相关代数的等价变换，经过一套预先制订好的规定来变换查问，从而取得代价更低的口头方案。经常出现的 RBO 规定谓词下推、Limit下推、常量折叠等。在 RBO中，有着一套严厉的经常使用规定，只需你依照规定去写查问语句，无论数据表中的内容怎样，生成的口头方案都是固定的。但是在实践的业务环境中，数据的量级会重大影响查问的性能，而RBO 是没法经过这些消息来失掉更优的口头方案。
为了处置 RBO 的局限性，Cost Based Optimization (CBO) 的优化战略应运而生。CBO经过搜集数据的统计消息来预算口头方案的代价，这些统计消息包括数据集的大小，列的数量和列的基数等消息。举个例子，假定咱们如今有三张表 A，B 和 C，在启动 Ajoin B join C 的查问时假设没有对应的统计消息咱们是无法判别不同 join 的口头顺序代价上的差异。假设咱们搜集到这三张表的统计消息，发现 A 表和B 表的数据量都是 1M 行，但是 C 表的 数据量仅为 10 行，那么经过先口头 B join C可以大大缩小两边结果的数据量，这在没有统计消息的状况下基本无法能判别。
随着查问复杂度的参与，口头方案的形态空间会变的十分渺小。刷过算法题的小同伴都知道，一旦形态空间十分大，经过暴力搜查的方式是无法能 AC的，这时刻一个好的搜查算法分内关键。通常 CBO经常使用灵活布局算法来失掉最优解，并且缩小重复计算子空间的代价。当形态空间到达必定水平之后，咱们只能选用贪心算法或许其余一些启示式算法来失掉部分最优。实质上搜查算法是一种在搜查期间和结果品质做trade-off 的方法。
(经常出现 CBO 成功架构)
Record Oriented vs Block Oriented
口头方案可以以为是一串 operator(相关代数的运算符)首尾相连串起来的口头流，前一个 operator 的 output 是下一个 operator的 input。传统的剖析引擎是 Row Oriented 的，也就是说 operator 的 output 和 input 是一行一行的数据。
举一个繁难的例子，假定咱们有上方一个表和查问：
上述查问语句开展为口头方案的时刻大抵如下图所示：
通常状况下，在 Row Oriented 的模型中，口头方案的口头环节可以用如下伪码示意：
依据 DBMSs On A Modern Processor: Where Does Time Go? 的评价，这种口头方式存在少量的 L2>随着磁盘等配件技术的蓬勃开展，各种经过 CPU 换 IO 的紧缩算法、Encoding 算法和存储技术的宽泛经常使用，CPU的性能逐渐成为成为剖析引擎的瓶颈。为了处置 Row Oriented 口头所存在的疑问，学术界开局思索处置方案，Block orientedprocessing of Relational>
可以看到，Column Oriented 领有更好的数据部分性和指令部分性，无利于提高 CPU Cache 的命中率，并且编译器更容易口头 SIMD优化等。
Pull Based vs Push Based
数据库系统中，通常是将输入的 SQL 语句转化为一系列的算子，而后生成物理口头方案用于实践的计算并前往结果。在生成的物理口头方案中，通常会对算子启动pipeline。经常出现的 pipeline 方式通常有两种：
Push Based 的口头形式提高了缓存效率，能够更好地优化查问性能。
参考：Push vs. Pull-Based Loop Fusion in Query Engines
现代数据湖剖析引擎的架构
经过上一节的引见，置信读者曾经对数据湖剖析引擎的前沿通常有了相应了解。在本节中，咱们以 StarRocks为例，进一步引见数据湖剖析引擎是怎样无机的联合上述先进通常，并且经过优雅的系统架构将其出现给用户。
如上图所示，StarRocks 的架构十分繁复，整个系统的**只要 Frontend (FE)、Backend (BE)两类进程，不依赖任何外部组件，繁难部署与保养。其中 FE 关键担任解析查问语句(SQL)，优化查问以及查问的调度，而 BE则关键担任从数据湖中读取数据，并成功一系列的 Filter 和 Aggregate 等操作。
FE 的关键作用将 SQL 语句经过一系列转化和优化，最终转换成 BE 能够意识的一个个 Fragment。一个不那么准确但易于了解的比喻，假设把 BE集群当成一个散布式的线程池的话，那么 Fragment 就是线程池中的 Task。从 SQL 文本到 Fragment，FE的关键上班蕴含以下几个步骤:
BE 是 StarRocks 的后端节点，担任接纳 FE 传上去的 Fragment 口头并前往结果给 FE。StarRocks 的 BE节点都是齐全平等的，FE 依照必定战略将数据调配到对应的 BE 节点。经常出现的 Fragment 上班流程是读取数据湖中的部分文件，并调用对应的 Reader(例如，适配 Parquet 文件的 Parquet Reader 和适配 ORC 文件的 ORCReader等)解析这些文件中的数据，经常使用向量化口头引擎进一步过滤和聚合解析后的数据后，前往给其余 BE 或 FE。
总结
本篇文章关键引见了加快数据湖剖析引擎的**技术原理，从多个维度对比了不同技术成功方案。