内部信息源与外部信息源搜索引擎优化方法的异同(揭秘一套数据湖分析引擎内核和使用案例(一))

　　内部信息源与外部信息源搜索引擎优化方法的异同(揭秘一套数据湖分析引擎内核和使用案例(一))

　　前言

　　随着数字产业化和产业数字化成为经济重要驱动力，企业的数据分析场景越来越丰富，对数据分析架构的要求也越来越高。新的数据分析场景催生了新的需求，主要包括三个方面：

　　数据湖的出现很好地满足了用户的前两个需求，允许用户实时导入任意数量的数据。用户可以从多个来源采集数据，并将其以原创形式存储在数据湖中。数据湖具有极高的水平扩展性，用户可以存储任意规模的数据。同时，底层通常采用廉价的存储方案，大大降低了用户存储数据的成本。数据湖通过敏感数据识别、分类、隐私保护、资源权限控制、数据加密传输、加密存储、数据风险识别、合规审计等措施，帮助用户建立安全预警机制，提升整体安全防护能力，

　　为了进一步满足用户对数据湖分析的需求，我们需要一套适合数据湖的分析引擎，能够在更短的时间内利用更多来源的更多数据，让用户在不同的环境中协同处理和分析。数据的方式来做出更好、更快的决策。本文文章将向读者详细揭秘此类数据湖分析引擎的关键技术，帮助用户通过StarRocks进一步了解系统架构。

　　之后，我们将继续发布两篇文章文章，更详细地介绍Extreme Data Lake Analysis Engine的核心和用例：

　　什么是数据湖

　　什么是数据湖，根据维基百科的定义，“数据湖是以自然/原创格式存储的数据系统或存储库，通常是对象 blob 或文件”。一般来说，数据湖可以理解为廉价的对象存储或分布式文件系统上的一层，这样可以将这些存储系统中离散的对象或文件组合起来，呈现出统一的语义，比如关系型通用数据库“表”语义等

　　了解了数据湖的定义后，我们自然会好奇数据湖能给我们提供哪些独特的能力，为什么要使用数据湖？

　　在数据湖的概念出现之前，很多企业或组织使用HDFS或S3来存储业务日常运营中产生的各类数据（比如做APP的公司可能想存储用户产生的点击事件） ) 详细记录)。因为这些数据的价值可能不会在短时间内被发现，所以找一个便宜的存储系统来临时存储它们，希望将来有一天数据可以使用的时候，能从中提取出有价值的信息。不过HDFS和S3提供的语义毕竟比较简单（HDFS对外提供文件的语义，S3对外提供对象的语义）。随着时间的推移，工程师可能无法回答他们存储在其中的数据。为了防止数据被后续使用，必须对数据一一解析，才能理解数据的含义。聪明的工程师想用一致的定义组织数据，然后使用额外的数据来描述数据。这些附加数据被称为“元”数据，因为它们是描述数据的数据。这样，这些数据的具体含义就可以在以后通过解析元数据来回答。这是数据湖最原创的作用。

　　随着用户对数据质量的要求越来越高，数据湖也开始丰富其他能力。例如，它为用户提供类数据库的ACID语义，帮助用户在不断写入数据的过程中获得时间点视图，防止读取数据过程中的各种错误。或者为用户提供更高性能的数据导入能力等，直到现在，数据湖已经从简单的元数据管理变成了现在更丰富、更像数据库的语义。

　　用一个不准确的术语来描述数据湖，它是一个存储成本更低的“AP 数据库”。但是，数据湖仅提供数据存储和组织功能。一个完整的数据库不仅要有数据存储能力，还要有数据分析能力。因此，如何为数据湖打造高效的分析引擎，为用户提供洞察数据的能力，将是本文的重点。以下章节将逐步拆解一个现代OLAP分析引擎的内部结构和实现：

　　如何对数据湖进行快速分析？

　　从本节开始，让我们回到数据库课程。数据湖的分析引擎和数据库的分析引擎在架构上是相同的。通常我们认为它们会分为以下几个部分：

　　对于数据湖分析引擎，优化器和执行引擎是影响其性能的两个核心模块。下面我们将从三个维度入手，一一拆解这两个模块的核心技术原理，对比不同的技术方案，帮助读者理解现代数据湖分析引擎的起点和终点。

　　RBO 与 CBO

　　基本上，优化器的工作是为给定查询生成成本最低（或相对较低）的执行计划。不同的执行计划的性能会相差数千倍。查询越复杂，数据量越大，查询优化越重要。

　　基于规则的优化（RBO）是传统分析引擎常用的优化策略。RBO的本质是其核心是基于关系代数的等价变换，通过一套预先建立的规则对查询进行变换，从而得到成本更低的执行计划。常见的RBO规则谓词下推、Limit下推、常量折叠等。在RBO中，有一套严格的使用规则。只要按照规则编写查询语句，无论数据表中的内容如何，​​生成的执行计划都是固定的。但是在实际的业务环境中，数据的量级会严重影响查询的性能，RBO无法通过这些信息获得更好的执行计划。

　　为了解决RBO的局限性，基于成本的优化(CBO)优化策略应运而生。CBO 通过采集有关数据的统计信息（包括数据集的大小、列数和列的基数）来估计执行计划的成本。例如，假设我们现在有A、B、C三个表，在查询A join B join C时，如果没有相应的统计信息，我们是无法判断不同join的执行顺序开销的差异的。如果我们采集这三个表的统计信息，发现表A和表B的数据量都是1M行，而表C的数据量只有10行，那么先执行B join C，中间结果可以大大减少。数据量，

　　随着查询复杂度的增加，执行计划的状态空间变得非常大。看过算法题的人都知道，一旦状态空间很大，通过蛮力搜索是不可能AC的。这时，一个好的搜索算法就显得尤为重要。通常CBO采用动态规划算法来得到最优解，减少子空间重复计算的代价。当状态空间达到一定程度时，我们只能选择贪心算法或其他一些启发式算法来获得局部最优。本质上，搜索算法是搜索时间和结果质量的权衡。

　　（通用 CBO 实现架构）

　　面向记录与面向块

　　执行计划可以看成是一系列首尾相连的算子（关系代数的算子）的执行流程，前一个算子的输出就是下一个算子的输入。传统的分析引擎是Row Oriented，也就是说算子的输出和输入都是逐行的数据。

　　举个简单的例子，假设我们有下面的表和查询：

<p>CREATE TABLE t (n int, m int, o int, p int);

SELECT o FROM t WHERE m