騰訊余根茂：基于Iceberg的大規(guī)模數(shù)據(jù)分析優(yōu)化加速實踐｜DataFunTalk

隨著企業(yè)數(shù)據(jù)量的不斷增長，數(shù)據(jù)格式的不斷增多，在保證數(shù)據(jù)查詢準(zhǔn)確性的條件下，數(shù)據(jù)分析人員對查詢速度的要求變得越來越高。在探尋更快查詢速度的過程中，Apache Iceberg提供了基于文件Metrics的DataSkipping技術(shù)，實現(xiàn)查詢時快速篩選所需的數(shù)據(jù)文件。但是，我們在日常使用中發(fā)現(xiàn)，當(dāng)查詢條件中的篩選字段增多時，DataSkipping技術(shù)效率急劇下降，即最終需要掃描的數(shù)據(jù)文件大大增加，甚至需要全表掃描，此時DataSkipping帶來的效率提升幾乎可以忽略不計。為了能夠使Apache IceBerg的DataSkipping技術(shù)能夠發(fā)揮更好的效果，我們需要進(jìn)行數(shù)據(jù)組織優(yōu)化。接下來，我將和大家分享我們的思路、設(shè)計以及最終的效果。

今天的介紹會圍繞下面五點展開：

• 查詢分析的IO效率
• 數(shù)據(jù)組織優(yōu)化設(shè)計
• 技術(shù)實現(xiàn)剖析
• 性能測評
• 未來規(guī)劃

01

查詢分析的IO效率

1. 一個查詢例子

首先通過一個常見的查詢案例，給大家介紹一下數(shù)據(jù)查詢時Apache Iceberg為提高查詢IO效率所提供的一些功能。

案例SQL：

SELECT count(*)
FROM employee
WHERE first_name like ‘Tho%’AND last_name like‘Frank%’AND birthplace=‘newyork’;

以上的SQL是一個常見的查詢語句，其中birthplace字段是分區(qū)字段。

這樣的查詢語句在Apache Iceberg中會經(jīng)過以下的查詢步驟：

• 分區(qū)裁剪：根據(jù)分區(qū)字段birthplace定位具體需要掃描的文件位置，過濾掉大量無效文件。
• 文件過濾：經(jīng)過第一步篩選后，根據(jù)留下來的每一個數(shù)據(jù)文件上的first_name和last_name的min-max信息，以判斷該數(shù)據(jù)文件是否存在目標(biāo)結(jié)果數(shù)據(jù)。
• Row Group過濾：根據(jù)parquet文件內(nèi)部對數(shù)據(jù)的統(tǒng)計信息，可以快速過濾掉parquet文件塊中不在查詢范圍內(nèi)的Row Group。

就這樣，經(jīng)過三層IO的篩選過濾，最終只需要掃描很少的數(shù)據(jù)文件就可以完成此次的查詢，提高總體查詢效率。

以上便是Apache Iceberg提高總體查詢效率的原因。但是，這里面有一些潛在的問題。

2. 潛在的問題

首先，min-max的出現(xiàn)需要基于數(shù)據(jù)經(jīng)過排序的基礎(chǔ)上，如果字段沒有經(jīng)過排序，那么分散在每一個數(shù)據(jù)文件中的字段是無序的，min-max其實也就失去了過濾的意義。

其次，一張表的查詢往往涉及多個字段。如果多個字段進(jìn)行排序，排序的效果會隨著字段的增加而差強(qiáng)人意，前幾列的效果可以保證，但是后序列的排序效果甚至可能出現(xiàn)亂序的情況。一旦亂序的情況產(chǎn)生，那么min-max的過濾效果失效，查詢也將面臨全表掃描，IO效率再次降低。

如下圖中的第三列，如果查詢會以此為篩選字段，那么將會掃描分區(qū)中所有的數(shù)據(jù)文件。

02

數(shù)據(jù)組織優(yōu)化設(shè)計

為了解決上述的問題，我們將解決方案關(guān)注在數(shù)據(jù)組織優(yōu)化上。

1. 空間填充曲線（Space-filling curve）

我們先來了解一個數(shù)學(xué)上的概念：空間填充曲線。

我們不用太理解這個曲線數(shù)學(xué)上的意義，重點是它為我們解決問題帶來的思路：降維。解決問題其實就是想要利用空間填充曲線，對多維數(shù)據(jù)（例如一張表中的多列）進(jìn)行降維處理，以提升相關(guān)數(shù)據(jù)的聚集效果以及相應(yīng)的數(shù)據(jù)min-max的使用效率。

2. 例子：地理位置編碼

下面舉一個空間填充曲線的使用案例，也就是地理位置編碼（Geohash），也更方便理解我們將如何使用這個概念。

地理位置編碼（Geohash）是一種分級的數(shù)據(jù)結(jié)構(gòu)，把空間劃分為網(wǎng)格。舉個例子，我們要搜索區(qū)域為二維（x，y）的，其中x的范圍是[2,3]， y的范圍是 [4,5]，從圖中也能看出它的總掃描范圍是一個正方形的網(wǎng)格。

那怎么樣用地理位置編碼將其范圍轉(zhuǎn)化成一維（z）的呢？

• 首先取二維的上下界進(jìn)行定位，即，剛剛x和y的范圍按照上下界拆分，可以寫為：
• 上界：x=3， y=5
• 下界：x=2， y=4
• 轉(zhuǎn)化一維地址，根據(jù)Geohash的規(guī)則，將偶數(shù)位放經(jīng)度，奇數(shù)位放在緯度，對上下界的值進(jìn)行錯位編碼（即轉(zhuǎn)換二進(jìn)制），此時：
• 下界：100100
• 上界：100111
• 即轉(zhuǎn)為了一維的搜索空間：[100100,100111]，其中包含了4個值，分別為100100，100101，100110，100111，從上圖可以看出，這四個值正好就是在二維的四方格中的四個值，降維后的含義是不變的。

當(dāng)然，降維不是這么簡單的，很容易能找到反例：

如圖所示，當(dāng)范圍在x為[1,3]，y為[3,4]時，計算出的一維地址空間實際內(nèi)容就遠(yuǎn)超過二維表現(xiàn)的空間，例如上圖中紅色部分，這種在降維后的范圍中但不在降維前的范圍中的這部分，一般稱為fault數(shù)據(jù)。這樣的fault數(shù)據(jù)會增加搜索的成本，降低搜索的效率，當(dāng)然在后面我將給大家分享我們是如何在Apache Iceberg中避免這樣fault數(shù)據(jù)出現(xiàn)的。

3. ZOrder算法的誕生及其意義

借鑒了上述的概念和思路，為了解決多列排序帶來的查詢效率的降低以及min-max的無效過濾問題，騰訊Iceberg實現(xiàn)了基于ZOrder算法的數(shù)據(jù)組織優(yōu)化，并提供了原生的OPTIMIZE語法。

至于上述的fault數(shù)據(jù)問題，Apache Iceberg對文件中的數(shù)據(jù)提供了詳細(xì)的統(tǒng)計信息，就例如我們一直提到的min-max，就能夠在降維后對數(shù)據(jù)再次精準(zhǔn)過濾，避免fault數(shù)據(jù)帶來的危害。

數(shù)據(jù)組織優(yōu)化能帶來什么？

如上圖所示，綠色的點為我們此次查詢的目標(biāo)數(shù)據(jù)，紅色的點為其他數(shù)據(jù)。從Snapshot N開始，如果我們不做組織優(yōu)化，我們可以看到數(shù)據(jù)是分散在1000個文件中的，分布很均勻，導(dǎo)致查詢的時候需要掃描大量文件。

在做OPTIMIZE優(yōu)化后，例如Snapshot N+1，我們會將數(shù)據(jù)做聚合和重新排列，將數(shù)據(jù)整合成為4個文件，并且數(shù)據(jù)基本分布在少量幾個文件中，這樣的情況下掃描的文件就大大降低了。

而在后續(xù)，因為不斷有數(shù)據(jù)寫入，形成新的小文件，那繼續(xù)使用增量的OPTIMIZE語法，可以不斷對增量的小文件進(jìn)行聚合整理，就如Snapshot N+2和Snapshot N+3。

這樣會帶來兩個好處：

• 減少小文件，提升元數(shù)據(jù)質(zhì)量和IO效率；
• IO優(yōu)化，提升查詢效率。

03

技術(shù)實現(xiàn)剖析

接下來給大家介紹一下OPTIMIZE是如何實現(xiàn)組織優(yōu)化的。

示例SQL語法：

OPTIMIZE TABLE employee ZORDER BY first_name, last_name

1. 篩選候選文件

首先，使用OPTIMIZE時需要限定進(jìn)行組織優(yōu)化的是哪些文件。文件選擇有兩個篩選原則：

可以選擇全表或者具體的分區(qū)文件夾進(jìn)行組織優(yōu)化；

支持多種策略，如上面描述的全量優(yōu)化和增量優(yōu)化。

2. 根據(jù)多維列值生成z地址

例如，某一行數(shù)據(jù)中，first_name是Thomas，last_name是More

• 初始數(shù)據(jù)：Thomas, More
• 數(shù)字化：68, 102
• 數(shù)字化的計算方式：對該列中的所有數(shù)據(jù)進(jìn)行采樣統(tǒng)計，而這個數(shù)據(jù)在采樣區(qū)間中的位置的下標(biāo)，即為數(shù)字化對應(yīng)的值。
• 使用2字節(jié)bits表示：0000000001000100，00000000 01100110
• 現(xiàn)在分享的是2字節(jié)，實際實現(xiàn)時往往采用的是4字節(jié)或8字節(jié)進(jìn)行處理。
• 交錯位（轉(zhuǎn)化一維）：00000000 00000000 00110100 00110100
• 這個值就是z地址，也就是zOrderAddress。

3. 根據(jù)z地址進(jìn)行Range重分區(qū)

根據(jù)計算出來的zOrderAddress進(jìn)行重新分區(qū)的操作，合并小文件，優(yōu)化數(shù)據(jù)組織，這個操作等價于

Dataset.repartitionByRange(ZOrderAddress)

4. 事務(wù)寫回存儲

通過Copy on Write的方式寫回表中，生成新的快照文件。

以上就是OPTIMIZE運(yùn)行中的流程。

原生的語法支持：

OPTIMIZE table_identifier [ WHERE predictate ]
ZORDER BY col_name1, col_name2

再次強(qiáng)調(diào)，where條件中僅支持分區(qū)列，用作分區(qū)組織優(yōu)化的篩選。

04

性能測評

我們做了性能評測，測試了數(shù)據(jù)組織優(yōu)化以后帶來的查詢性能的提升情況。主要分為以下兩類測試：

• 關(guān)鍵參數(shù)測試
• 聚合列：很明顯，不同的列做聚合效果不同
• 輸出文件大?。号渲脤懗鑫募拇笮?/li>
• CUBE大?。簩嶋H參與進(jìn)行多維聚合的最小單元
• SSB基準(zhǔn)測試

關(guān)鍵參數(shù)測試測試配置：

1. 關(guān)鍵參數(shù)測試-聚合列

首先，我們固定了輸出文件大小為1G，CUBE大小為150G，準(zhǔn)備了兩組不同數(shù)量的聚合列進(jìn)行測試。

測試結(jié)果顯示，聚合列越多，效果越差，相應(yīng)的文件過濾效果越差，因為相同的查詢需要掃描更多的文件，但是相比于組織優(yōu)化前查詢效率還是有顯著提升的。

因此建議在滿足業(yè)務(wù)需求的前提下，避免對過多的列進(jìn)行聚合優(yōu)化。

2. 關(guān)鍵參數(shù)測試-輸出文件大小

接下來，我們限定了聚合列和CUBE大小，設(shè)置不同的輸出文件大小來測試查詢效率。

從結(jié)果上來看，文件輸出大小對查詢效率的影響并不大，因為數(shù)據(jù)較為集中，小文件的數(shù)據(jù)總量更少，節(jié)省了文件IO，所以查詢效率要更好些。但是并不建議合并后的文件大小設(shè)計的太小，小文件數(shù)量的增加很容易出現(xiàn)文件掃描數(shù)量的增加，這個平衡不易把控，所以更建議默認(rèn)1G的輸出大小比較合適大部分場景。

3. 關(guān)鍵參數(shù)測試-CUBE大小

我們限定了聚合列和輸出文件大小，設(shè)置不同的CUBE大小來測試查詢效率。

從測試結(jié)果來看，CUBE越小，性能越差。但CUBE設(shè)置的如果很大，反而容易在增量OPTIMIZE的時候，導(dǎo)致需要讀取大量的數(shù)據(jù)來滿足小部分?jǐn)?shù)據(jù)增量的優(yōu)化。所以建議還是使用默認(rèn)配置，使用150G的CUBE較為均衡，對大部分場景是更為適用的。

4. SSB基準(zhǔn)測試

SSB測試是基于Kyligence官方提供的開源SSB（Star Schema Benchmark）壓測工具，對其中的查詢做了部分改造，主要選取使用Q3.1到Q3.4進(jìn)行測試。

SSB測試的配置：

性能結(jié)果：

• 查詢耗時方面：經(jīng)過ZOrder排序后，查詢耗時基本在1s以下，相比于不做任何優(yōu)化的情況下，1w個小文件總查詢耗時在12s以上，如果單純只做小文件合并，查詢耗時在4-7s之間，由此看到數(shù)據(jù)組織優(yōu)化帶來的效果是非常明顯的。
• 數(shù)據(jù)文件過濾：不論是最初的狀態(tài)還是合并小文件后，掃描的數(shù)據(jù)文件都是全表掃描，沒有區(qū)別，但是ZOrder數(shù)據(jù)組織優(yōu)化后，可以過濾掉大量的數(shù)據(jù)文件，進(jìn)一步加速查詢效率。

05

未來規(guī)劃

騰訊Iceberg的未來規(guī)劃是：

• 提升數(shù)據(jù)持續(xù)接入的能力；
• 提升數(shù)據(jù)查詢性能，包括存算分離的場景，索引支持等；
• 提升可運(yùn)維性；
• 提升系統(tǒng)擴(kuò)展，包括接入新的計算引擎，集成云上的catalog等。

今天的分享就到這里，謝謝大家。