如何创造一款极速数据湖分析引擎
发布时间：2022-03-09 10:27:22 所属栏目：大数据 来源：互联网
导读：随着数字产业化和产业数字化成为经济驱动的重要动力，企业的数据分析场景越来越丰富，对数据分析架构的要求也越来越高。新的数据分析场景催生了新的需求，主要包括三个方面： 用户希望用更加低廉的成本，更加实时的方式导入并存储任何数量的关系数据数据(
|
随着数字产业化和产业数字化成为经济驱动的重要动力，企业的数据分析场景越来越丰富，对数据分析架构的要求也越来越高。新的数据分析场景催生了新的需求，主要包括三个方面： 用户希望用更加低廉的成本，更加实时的方式导入并存储任何数量的关系数据数据(例如，来自业务线应用程序的运营数据库和数据)和非关系数据(例如，来自移动应用程序、IoT 设备和社交媒体的运营数据库和数据) 用户希望自己的数据资产受到严密的保护 用户希望数据分析的速度变得更快、更灵活、更实时 数据湖的出现很好的满足了用户的前两个需求，它允许用户导入任何数量的实时获得的数据。用户可以从多个来源收集数据，并以其原始形式存储到数据湖中。数据湖拥有极高的水平扩展能力，使得用户能够存储任何规模的数据。同时其底层通常使用廉价的存储方案，使得用户存储数据的成本大大降低。数据湖通过敏感数据识别、分级分类、隐私保护、资源权限控制、数据加密传输、加密存储、数据风险识别以及合规审计等措施，帮助用户建立安全预警机制，增强整体安全防护能力，让数据可用不可得和安全合规。 为了进一步满足用户对于数据湖分析的要求，我们需要一套适用于数据湖的分析引擎，能够在更短的时间内从更多来源利用更多数据，并使用户能够以不同方式协同处理和分析数据，从而做出更好、更快的决策。本篇文章将向读者详细揭秘这样一套数据湖分析引擎的关键技术，并通过StarRocks 来帮助用户进一步理解系统的架构。 在数据湖这个概念出来之前，已经有很多企业或组织大量使用 HDFS 或者 S3 来存放业务日常运作中产生的各式各样的数据(例如一个制作 APP 的公司可能会希望将用户所产生的点击事件事无巨细的记录)。因为这些数据的价值不一定能够在短时间内被发现，所以找一个廉价的存储系统将它们暂存，期待在将来的一天这些数据能派上用场的时候再从中将有价值的信息提取出来。然而 HDFS 和 S3 对外提供的语义毕竟比较单一(HDFS 对外提供文件的语义，S3对外提供对象的语义)，随着时间的推移工程师们可能都无法回答他们到底在这里面存储了些什么数据。为了防止后续使用数据的时候必须将数据一一解析才能理解数据的含义，聪明的工程师想到将定义一致的数据组织在一起，然后再用额外的数据来描述这些数据，这些额外的数据被称之为“元”数据，因为他们是描述数据的数据。这样后续通过解析元数据就能够回答这些数据的具体含义。这就是数据湖最原始的作用。 随着用户对于数据质量的要求越来越高，数据湖开始丰富其他能力。例如为用户提供类似数据库的 ACID 语义，帮助用户在持续写入数据的过程中能够拿到 point-in-time 的视图，防止读取数据过程中出现各种错误。或者是提供用户更高性能的数据导入能力等，发展到现在，数据湖已经从单纯的元数据管理变成现在拥有更加丰富，更加类似数据库的语义了。 用一句不太准确的话描述数据湖，就是一个存储成本更廉价的“AP 数据库”。但是数据湖仅仅提供数据存储和组织的能力，一个完整的数据库不仅要有数据存储的能力，还需要有数据分析能力。因此怎么为数据湖打造一款高效的分析引擎，为用户提供洞察数据的能力，将是本文所要重点阐述的部分。下面通过如下几个章节一起逐步拆解一款现代的 OLAP 分析引擎的内部构造和实现： RBO vs CBO 基本上来讲，优化器的工作就是对给定的一个查询，生成查询代价最低(或者相对较低)的执行计划。不同的执行计划性能会有成千上万倍的差距，查询越复杂，数据量越大，查询优化越重要。 Rule Based Optimization (RBO) 是传统分析引擎常用的优化策略。RBO 的本质是核心是基于关系代数的等价变换，通过一套预先制定好的规则来变换查询，从而获得代价更低的执行计划。常见的 RBO 规则谓词下推、Limit 下推、常量折叠等。在 RBO 中，有着一套严格的使用规则，只要你按照规则去写查询语句，无论数据表中的内容怎样，生成的执行计划都是固定的。但是在实际的业务环境中，数据的量级会严重影响查询的性能，而 RBO 是没法通过这些信息来获取更优的执行计划。 为了解决 RBO 的局限性，Cost Based Optimization (CBO) 的优化策略应运而生。CBO 通过收集数据的统计信息来估算执行计划的代价，这些统计信息包括数据集的大小，列的数量和列的基数等信息。举个例子，假设我们现在有三张表 A，B 和 C，在进行 A join B join C 的查询时如果没有对应的统计信息我们是无法判断不同 join 的执行顺序代价上的差异。如果我们收集到这三张表的统计信息，发现 A 表和 B 表的数据量都是 1M 行，但是 C 表的 数据量仅为 10 行，那么通过先执行 B join C 可以大大减少中间结果的数据量，这在没有统计信息的情况下基本不可能判断。 随着查询复杂度的增加，执行计划的状态空间会变的非常巨大。刷过算法题的小伙伴都知道，一旦状态空间非常大，通过暴力搜索的方式是不可能 AC 的，这时候一个好的搜索算法格外重要。通常 CBO 使用动态规划算法来得到最优解，并且减少重复计算子空间的代价。当状态空间达到一定程度之后，我们只能选择贪心算法或者其他一些启发式算法来得到局部最优。本质上搜索算法是一种在搜索时间和结果质量做 trade-off 的方法。 （编辑：PHP编程网 - 湛江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐