网站模板破解下载,长春哪里做网站好,wordpress文章在那个文件夹,一元钱购买网站空间简介#xff1a;介绍 Lakehouse 搜索引擎的设计思想#xff0c;探讨其如何使用缓存#xff0c;辅助数据结构#xff0c;存储格式#xff0c;动态文件剪枝#xff0c;以及 vectorized execution 达到优越的处理性能。
作者#xff1a;李洁杏#xff0c;Databrick资深软…简介介绍 Lakehouse 搜索引擎的设计思想探讨其如何使用缓存辅助数据结构存储格式动态文件剪枝以及 vectorized execution 达到优越的处理性能。
作者李洁杏Databrick资深软件工程师
一、Lakehouse搜索引擎设计背景
1. 数据仓库和Lakehouse
数据管理系统从早期的数据仓库Data Warehouse已经发展到今天的Lakehouse。Lakehouse可以同时存储结构化、半结构化和非结构化数据并且支持流分析、BI、数据科学和机器分析的场景。 2. Lakehouse在查询性能上的挑战
数据仓库架构可以完全控制数据的存储和查询因此可以同时设计查询系统以及适应查询系统的数据存储结构以达到优越的查询性能
而在Lakehouse架构下数据是用开放存储结构存储的如Parquet格式以便更多系统可以便捷的访问数据但是开放的存储格式并不一定适合查询操作查询系统也没有足够的统计数据来实现高效查询。
那么Lakehouse如何以开放的存储格式达到高效的查询性能
3. 解决方案
为解决以上的问题Databricks Lakehouse设计了新的搜索引擎其SQL性能在Data Lake存储系统和文件格式方面都有出色的表现。
其SQL性能优化是通过以下技术实现的
a. 高速缓存将热数据放入高速缓存中
b. 建立辅助数据结构如收集统计数据、建立索引
c. 数据布局优化以实现最小化I/O
d. 动态文件剪枝以实现最小化I/O。
二、Lakehouse中的SQL性能优化技术
1. 高速缓存
大部分的工作负载一般都会集中访问某些“热”数据上Data Warehouse经常使用SSD和内存作为缓存来加速热数据的查询。
Lakehouse可以使用与数据仓库相同的优化数据结构对其进行缓存提高查询性能。 如图所示在Databricks中用SSD作为缓存可以将数据读取速度提高3倍以上采用Delta引擎作为缓存则可以将数据读取速度提高7倍以上。
2. 建立辅助数据结构
即使数据是用Parquet格式存储的也可以建立很多额外的数据结构来加快查询同时对这些额外的数据进行事务性的维护。
示例一Parquet文件中的Data Skipping
在Parquet文件中维护表中每个数据文件的最小/最大值统计信息有助于在查询发生时可以跳过一些无关的数据。
如下图如果查询条件是year2020和uid24000利用最小/最大统计信息可知这个查询的信息只会存在于file3因此可以跳过file1和file2的读取。 示例二在Parquet文件上建立索引
如下图如果查询条件是type“DELETE_ACCOUT”可以利用在type上建立的索引直接跳到对应的数据上从而避免读取无关数据。 示例三Parquet文件上建立Bloom Filter
可以为每一个文件建立Bloom FilterBloom Filter可以快速判断表文件中是否包含需要查询的数据如果不包含则快速跳过该文件从而减少扫描数据量提升查询性能。 Bloom Filter原理
Bloom Filter对每个文件中的数据记录使用1个或多个哈希表计算其哈希值其起始值都为0当有哈希值映射在对应的位置时则为1这样在查询的时候可以跳过值为0的位置也有可能的情况是对应的位全部都为1这时候数据也有可能不在这个文件中假阳性可以通过控制使用哈希函数的个数以及Bloom Filter的大小来控制假阳性率。
3. 数据布局
a. 小文件问题
在Delta Lake中频繁执行MERGEUPDATEINSERT操作可能会产生大量的小文件。大量的小文件一方面会降低系统读取性能同时也会提高元数据操作的开销。
Lakehouse中使用了不同的技术来减少小文件的产生
优化Delta表写入
如下图所示在开源版Spark中每个executor向partition中写入数据时都会创建一个表文件进行写入最终会导致一个partition中产生很多的小文件。
Databricks对Delta表的写入过程进行了优化对每个partition使用一个专门的executor来合并其它executor对该partition的写入从而避免了小文件的产生。 自动合并小文件
在每次向Delta表中写入数据之后会检查Delta表中的表文件数量如果Delta表中的小文件size 128MB则视为小文件数量达到阈值则会执行一次小文件合并将Delta表中的小文件合并为一个新的大文件。
手动合并小文件
除了自动合并Databricks还提供Opitmize命令使用户可以手动合并小文件优化表结构使得表文件的结构更加紧凑。
b. 查询时间问题
查询运行时间主要取决于访问的数据量即使使用Parquet格式也可以通过优化表内的数据布局以减少运行时间。
表文件数据排序
将表文件存储数据排序在每个表文件中存储一定量的数据如下图中file1存储uid0...1000file2存储uid1001...2000这样在查询时就可以根据需要跳过无关的表文件减少文件扫描数量。 Z-Ordering优化
在实际查询中有些查询需要看colomn1在某个范围内的数据有些查询需要看colomn2在某个范围内的数据或者更多这时候仅仅对colomn1进行排序显然是不够的。
Z-Ordering可以在多个维度上如下图的col 1-4将关联的信息存储到同一组文件中来减少不必要的文件读取。 4. 动态文件剪枝Dynamic File PruningDFP
动态文件剪枝简称DFP我们以下面一个简单的查询为例
SELECT sum(ss_quantity)
FROM store_sales
JOIN item ON ss_item_sk i_item_sk
WHERE i_item_id ‘AAAAAAAAICAAAAAA查询说明将store_sales与item两个表连起来条件是当item_sk值相等且item_id等于一个固定值。 未启用DFP
如果不开启DFP从上图可以看出查询会先对store_sales进行全表扫描然后再和过滤后的item表的行进行join虽然结果仅有4.6万多条数据但却扫描了表store_sales中的86多亿条数据。 启用DFP
在启用DFP之后会先扫描item表查询出表item中i_item_id ‘AAAAAAAAICAAAAAA数据行然后将这些数据行的i_item_sk值作为表store_sales的ss_item_sk的查询条件在表store_sales的SCAN阶段进行过滤跳过大量无关数据。这样仅扫描了660多万条store_sales中的数据比未启用DFP时减少了近99%。
从结果上看启动DFP后该条查询实现了10倍的性能提升。
针对该特性在TPC-DS上进行测试见下图测试发现启用DFP后TPC-DS的查询速度达到4.5倍到8倍的提升。 5. 优化组合
综合使用以上优化技术协同工作让Lakehouse中的数据读取都在高速缓存中进行并且通过数据布局优化建立辅助数据结构减少对非缓存数据读取的I/O实现了Lakehouse引擎可以提供与数据仓库类似的查询性能。
如下图所示Delta Engine的查询性能与DW1类似并且超过了DW2和DW3。 三、Delta Clones
Delta Clones是Lakehouse的一项非常重要的技术可以对大型数据集进行高效拷贝支持测试、分享和机器学习的不同需求。
1. 什么是克隆
克隆也叫拷贝是原始数据在给定时间点的副本
它具有与源表相同的元数据相同表结构约束列描述统计信息和分区
两种克隆方式shallow浅克隆deep深克隆。
2. 深克隆
深克隆会完整复制源表的元数据和数据文件并生成一个全新的独立的表。
a. 深克隆语句
在SQL中运行CREATE TABLE语句在Python和Scala语句中运行DeltaTable语句。
# SQL
CREATE TABLE delta.path/to/copy CLONE customers# Python and Scala
DeltaTable
.forName(park, customers)
.clone(path/to/copy)b. 深克隆的特性
与源表相比克隆表有独立的历史记录在克隆过程中、或之后发生的对源表的任何更改都不会反映在克隆表中
3. 浅克隆
浅克隆仅复制需要克隆的表的元数据表本身的数据文件不会被复制。
a. 浅克隆语句
与深克隆语句类似只是在SQL中加入SHALLOW CLONE语句在Python和Scala中加入isShallowtrue。
# SQL
CREATE TABLE delta.path/to/copy SHALLOW CLONE customers# Python and Scala
DeltaTable
.forName(spark, customers)
.clone(path/to/copy, isShallowtrue)b. 浅克隆的特性
浅克隆不是自包含的即自身不是数据源如果源文件数据被删除则浅克隆数据可能会不可用浅克隆不复制流事务或COPY INTO相关的元数据
4. 克隆的适用场景
克隆的适用场景有很多比如数据存储、短期实验、数据分享和灾难恢复其中除了短期实验使用浅克隆其它场景都需要使用深克隆。 原文链接
本文为阿里云原创内容未经允许不得转载。
