数据仓库如何实现湖仓一体数据分析？
一.?背景
隨著云計(jì)算的普及和數(shù)據(jù)分析需求的擴(kuò)大，數(shù)據(jù)湖+數(shù)據(jù)倉庫的湖倉一體分析能力成為下一代數(shù)據(jù)分析系統(tǒng)的核心能力。相對于數(shù)據(jù)倉庫，數(shù)據(jù)湖在成本、靈活性、多源數(shù)據(jù)分析等多方面，都有著非常明顯的優(yōu)勢。IDC發(fā)布的十項(xiàng)2021年中國云計(jì)算市場趨勢預(yù)測中，有三項(xiàng)和數(shù)據(jù)湖分析有關(guān)。可以預(yù)見，跨系統(tǒng)集成能力、數(shù)據(jù)控制能力和更加全面的數(shù)據(jù)驅(qū)動(dòng)能力，將會是未來數(shù)據(jù)分析系統(tǒng)重要的競爭領(lǐng)域。
?
AnalyticDB PostgreSQL版(簡稱ADB PG)是阿里云數(shù)據(jù)庫團(tuán)隊(duì)基于PostgreSQL內(nèi)核(簡稱PG)打造的一款云原生數(shù)據(jù)倉庫產(chǎn)品。在PB級數(shù)據(jù)實(shí)時(shí)交互式分析、HTAP、ETL、BI報(bào)表生成等業(yè)務(wù)場景，ADB PG都有著獨(dú)特的技術(shù)優(yōu)勢。作為一個(gè)數(shù)據(jù)倉庫產(chǎn)品，ADB PG是如何具備湖倉一體分析能力呢？本文將會介紹ADB PG如何基于PG外表、打造數(shù)據(jù)湖分析能力。
ADB PG繼承了PG的外表(Foreign Table)功能，目前ADB PG的湖倉一體能力主要是基于外表打造的。基于PG外表，ADB PG可以對其他數(shù)據(jù)分析系統(tǒng)的數(shù)據(jù)進(jìn)行查詢和寫入，在兼容多種數(shù)據(jù)源的同時(shí)，復(fù)用ADB PG原有的優(yōu)化器和執(zhí)行引擎優(yōu)勢。ADB PG的湖倉一體分析能力目前已經(jīng)支持OSS、MaxCompute、Hadoop、RDS PG、Oracle、RDS MySQL等多種數(shù)據(jù)源的分析或者寫入。用戶可以靈活地將ADB PG應(yīng)用于數(shù)據(jù)存儲、交互式分析、ETL等不同領(lǐng)域，可以在單個(gè)實(shí)例中實(shí)現(xiàn)多種數(shù)據(jù)分析功能。即可以用ADB PG完成數(shù)據(jù)分析的核心流程，也可以作為眾多環(huán)節(jié)中的一環(huán)去搭建數(shù)據(jù)鏈路。
?
不過，外表數(shù)據(jù)的分析依賴于外部SDK和網(wǎng)絡(luò)IO來實(shí)現(xiàn)數(shù)據(jù)讀寫，由于網(wǎng)絡(luò)本身的特性與本地磁盤有巨大差異，因此需要在技術(shù)層面與本地存儲不同、需要不同的性能優(yōu)化方案。本文以O(shè)SS外表數(shù)據(jù)讀寫為例，介紹ADB PG在構(gòu)建湖倉一體分析能力時(shí)，所遇到的一些重要問題和解決方案。
二.?問題分析
ADB PG內(nèi)核可以分為優(yōu)化器、執(zhí)行引擎和存儲引擎。外表數(shù)據(jù)分析可以復(fù)用ADB PG原有的優(yōu)化器和執(zhí)行引擎的核心部分，僅需少量修改。主要擴(kuò)展是存儲引擎層的改造，也就是通過外表接口對外表數(shù)據(jù)進(jìn)行讀寫。外表數(shù)據(jù)是存儲在另一個(gè)分布式系統(tǒng)當(dāng)中，需要通過網(wǎng)絡(luò)與ADB PG進(jìn)行連接，這是和讀取本地文件的最核心的區(qū)別。一方面，不同的外表數(shù)據(jù)會提供不同的遠(yuǎn)程訪問接口，需要在工程上進(jìn)行兼容，比如OSS、MaxCompute的數(shù)據(jù)讀取接口都不相同。另一方面，通過網(wǎng)絡(luò)訪問遠(yuǎn)程機(jī)器上的數(shù)據(jù)有一定的共性，比如網(wǎng)絡(luò)的延遲、網(wǎng)絡(luò)放大、帶寬限制、網(wǎng)絡(luò)穩(wěn)定性問題等。
本文將會圍繞上述核心挑戰(zhàn)，介紹ADB PG外表分析項(xiàng)目在支持OSS數(shù)據(jù)分析過程中的一些重要技術(shù)點(diǎn)。OSS是一種阿里云推出的一種低成本分布式存儲系統(tǒng)，存儲了大量的冷熱數(shù)據(jù)，有較大的數(shù)據(jù)分析需求。為了方便開發(fā)者進(jìn)行擴(kuò)展，OSS提供了基于Java、Go、C/C++、Python等主流開發(fā)語言的SDK。ADB PG采用了OSS C SDK進(jìn)行開發(fā)。目前ADB PG已經(jīng)完美支持OSS外表分析的各項(xiàng)功能，除建表語句不同外，用戶可以像訪問本地表一樣訪問OSS外表。支持并發(fā)讀取和寫入，支持CSV、ORC、Parquet等常見數(shù)據(jù)格式。
三.?外表分析技術(shù)優(yōu)化
?
接下來，我們介紹ADB PG在基于OSS C SDK開發(fā)OSS外表分析過程中，解決的一些核心技術(shù)問題。
?
3.1?網(wǎng)絡(luò)碎片請求問題
在分析型數(shù)據(jù)庫場景，業(yè)界普遍認(rèn)為列式存儲在IO性能上強(qiáng)于行式存儲。因?yàn)榱惺酱鎯υ趻呙钄?shù)據(jù)時(shí)，只需要掃描特定列，而行式存儲畢竟掃描全量數(shù)據(jù)，因此列式存儲可以節(jié)約一些IO資源。但是在開發(fā)過程中，團(tuán)隊(duì)發(fā)現(xiàn)在一些場景下，如字段較多的大寬表掃描，掃描性能較高的列存格式竟然比掃描CSV行存文本格式性能還要差。后經(jīng)過定位發(fā)現(xiàn)一方面掃描ORC/PARQUET?格式時(shí)，客戶端與OSS服務(wù)端交互次數(shù)過于頻繁，另一方面ADB PG單次向OSS請求的數(shù)據(jù)量比較小。這兩個(gè)原因帶來了很大的性能問題。
?
我們知道，相比于本地磁盤IO，網(wǎng)絡(luò)IO所產(chǎn)生的往返時(shí)延往往可以放大幾個(gè)量級。因此，如果解析一些列存格式（如ORC/PARQUET）時(shí)，如果將網(wǎng)絡(luò)請求當(dāng)作本地磁盤請求處理，高壓縮比所帶來的網(wǎng)絡(luò)帶寬占用的減少不足以抵消碎片化請求帶來的往返時(shí)延放大，因此性能測試結(jié)果低于預(yù)期。問題的解決方案，就是通過緩存來減少碎片化的網(wǎng)絡(luò)請求。ADB PG每次掃描OSS數(shù)據(jù)都會“預(yù)加載”足夠的數(shù)據(jù)并緩存，請求時(shí)，判定是否命中緩存，如果命中，則直接返回緩存；否則，繼續(xù)下一輪次的“預(yù)加載”，從而降低網(wǎng)絡(luò)請求次數(shù)，提高單次請求效率。“預(yù)加載”的緩存大小開放配置，默認(rèn)大小為1MB。
3.2?列過濾與謂詞下推
由于網(wǎng)絡(luò)本身的IO性能往往是低于本地存儲的IO性能的，因此在掃描外表數(shù)據(jù)時(shí)，要盡量減少IO的帶寬資源消耗。ADB PG在處理ORC、Parquet格式的文件時(shí)，采用了列過濾和謂詞下推技術(shù)，來達(dá)到這一目的。
?
列過濾，即外表只請求SQL查詢所需的數(shù)據(jù)列、忽略不需要的數(shù)據(jù)列。因?yàn)镺RC、Parquet都是列式存儲格式，所以外表在發(fā)起網(wǎng)絡(luò)請求時(shí)，只需請求所需列所在的數(shù)據(jù)范圍即可，從而大幅減小網(wǎng)絡(luò)I/O。同時(shí)，ORC、Parquet會對列數(shù)據(jù)進(jìn)行壓縮處理，進(jìn)一步減小I/O。
?
謂詞下推，是將執(zhí)行計(jì)劃里的上層的過濾條件(如WHERE子句中的條件)，移動(dòng)到下層的外表掃描節(jié)點(diǎn)，使外表掃描進(jìn)行網(wǎng)絡(luò)請求時(shí)，過濾掉不符合查詢條件的數(shù)據(jù)塊，從而減少網(wǎng)絡(luò)I/O。在ORC/Parquet格式文件中，會在每一個(gè)block頭部保存該block中每一列數(shù)據(jù)的min/max/sum等統(tǒng)計(jì)信息，當(dāng)外表掃描時(shí)，會先讀取該block的頭部統(tǒng)計(jì)信息，與下推的查詢條件進(jìn)行比較，如果該列的統(tǒng)計(jì)信息不符合查詢條件，則可以直接跳過該列數(shù)據(jù)。
?
這里簡單介紹ORC格式的外表的謂詞下推的實(shí)現(xiàn)方案。一個(gè)ORC文件按數(shù)據(jù)行分成若干個(gè)Stripe組成，Stripe中數(shù)據(jù)按列式存儲。每個(gè)Stripe又分為若干個(gè)Row Group,?所有列的每10000行 組成一個(gè)Row Group。如下圖所示。
ORC文件保存3個(gè)層次的統(tǒng)計(jì)信息，文件級別與Stripe級別的統(tǒng)計(jì)信息存儲在ORC文件末尾，Row Group級別的統(tǒng)計(jì)信息在每個(gè)Stripe塊頭部存放。使用這3個(gè)層次的統(tǒng)計(jì)信息，ORC外表可以實(shí)現(xiàn)文件級過濾，Stripe級過濾以及Row Group級別過濾。具體做法是，每當(dāng)掃描一個(gè)新的ORC文件，會先讀取文件末尾的文件級統(tǒng)計(jì)信息，若不符合查詢條件，則直接跳過整個(gè)文件的掃描；接著讀取文件末尾所有Stripe級別的統(tǒng)計(jì)信息，過濾掉不符合條件的Stripe塊；對于每個(gè)符合條件的Stripe塊，讀取塊頭部的Row Group?級別的統(tǒng)計(jì)信息，過濾掉不必要的數(shù)據(jù)。
3.3 “996”問題
OSS C SDK定義了一類錯(cuò)誤代碼，用于表示異常情況，這里的996是OSS C SDK中定義的錯(cuò)誤碼-996。類似的還有錯(cuò)誤碼-998、-995、-992等。這一類錯(cuò)誤，通常都是網(wǎng)絡(luò)異常導(dǎo)致的OSS外表導(dǎo)入導(dǎo)出失敗。-996是最為常見的一種。
?
OSS C SDK內(nèi)部使用CURL與OSS服務(wù)端進(jìn)行網(wǎng)絡(luò)交互，相應(yīng)的CURL錯(cuò)誤碼，常見CURL 56（Connection reset by peer）、52等。這些網(wǎng)絡(luò)異常，通常是由于OSS服務(wù)端在負(fù)載較高情況下，服務(wù)端主動(dòng)剔除其認(rèn)為“不活躍”的客戶端連接所致。當(dāng)需要導(dǎo)入或?qū)С鲚^大規(guī)模OSS數(shù)據(jù)時(shí)，由于客戶端處于執(zhí)行計(jì)劃的不同階段，不能長時(shí)間持有連接進(jìn)行連續(xù)通信，從而被OSS服務(wù)端當(dāng)作“不活躍”的客戶端連接而關(guān)閉。
?
通常對于這種情況，客戶端需要嘗試重試解決。實(shí)際開發(fā)過程中發(fā)現(xiàn)，即使客戶端接口增加了自動(dòng)異常重試機(jī)制，這種異常依然得不到改善。后經(jīng)過定位發(fā)現(xiàn)，OSS C SDK為提高連接效率，增加了CURL句柄的連接池，但這些網(wǎng)絡(luò)異常的CURL句柄，也會存放到池中，因此，即使重試，還是會使用異常的CURL句柄進(jìn)行通信，所以996異常的問題得不到改善。
?
既然知道了根本原因，解決的方法也很直觀。我們在CURL句柄的回收接口中，增加對CURL句柄狀態(tài)檢查，對于異常的CURL句柄進(jìn)行銷毀，而不是加回連接池中。這樣避免了連接池中存在無效的CURL句柄。客戶端接口重試時(shí)，選擇有效的或者創(chuàng)建新的CURL連接再次通信即可。當(dāng)然，自動(dòng)異常重試機(jī)制只能針對那些可以重試解決的情況。
① ADB PG訪問OSS外表時(shí)，先從CURL連接池中獲取連接，若不存在則新建。
② ADB PG使用CURL連接句柄與OSS Server請求通信。
③ OSS Server通過CURL連接句柄返回通信結(jié)果。
④?正常返回的CURL連接句柄使用完畢后加回連接池待下次使用。
⑤?異常狀態(tài)的CURL連接句柄銷毀。
?
3.4?內(nèi)存管理方案的兼容問題
ADB PG基于PostgreSQL內(nèi)核打造，也繼承了PostgreSQL的內(nèi)存管理機(jī)制。PostgreSQL的內(nèi)存管理采用了進(jìn)程安全的內(nèi)存上下文MemoryContext，而OSS C SDK是線程安全的內(nèi)存上下文APR Pool。在MemoryContext內(nèi)存環(huán)境下，每個(gè)已經(jīng)分配的內(nèi)存，都可以顯式的調(diào)用free釋放，由MemoryContext進(jìn)行內(nèi)存碎片的整理，但在APR Pool中，我們只看到內(nèi)存池的創(chuàng)建、內(nèi)存的申請和內(nèi)存池的銷毀等操作，卻沒有內(nèi)存的顯式釋放接口。
?
這種情況意味著，我們需要對于OSS C SDK接口所持有的內(nèi)存的生命周期有明確的了解，否則極易出現(xiàn)內(nèi)存泄漏和訪問已經(jīng)釋放的內(nèi)存等問題。通常我們會按照如下兩種方式申請APR Pool的內(nèi)存。
·?方式一適用于重入低頻的操作接口，如獲取OSS文件清單列表。
·?方式二適用于多次重入的操作接口，如周期性向OSS請求指定文件指定范圍的數(shù)據(jù)。
通過這種方法，可以很好地解決ADB PG與OSS C SDK在內(nèi)存管理方面的不兼容問題。
3.5?數(shù)據(jù)格式的兼容和優(yōu)化
OSS上的數(shù)據(jù)，大部分采用CSV、ORC、Parquet等格式。由于ORC/Parquet等格式對數(shù)據(jù)的底層存儲編碼，與ADB PG的數(shù)據(jù)編碼并不一致，所以當(dāng)進(jìn)行外表掃描時(shí)，數(shù)據(jù)類型轉(zhuǎn)換是必不可少的步驟。類型轉(zhuǎn)換，本質(zhì)上是將數(shù)據(jù)從一種編碼，改變成另一種編碼方式。例如ORC對于Decimal類型的表示方式和ADB PG不相同，在ORC中Decimal64類型由一個(gè)int64存放數(shù)據(jù)的數(shù)字值，再由precision和scale表示數(shù)字個(gè)數(shù)和小數(shù)點(diǎn)位數(shù)，而在ADB PG中, Decimal類型由int16?數(shù)組來存放數(shù)據(jù)的數(shù)字值。格式轉(zhuǎn)換算法需要對每個(gè)數(shù)據(jù)進(jìn)行循環(huán)的除法與取模操作，這是非常耗費(fèi)CPU的。
?
為了減少類型轉(zhuǎn)換帶來的CPU消耗，進(jìn)一步優(yōu)化外表查詢性能，ADB PG在使用外表進(jìn)行導(dǎo)出數(shù)據(jù)時(shí)，跳過類型轉(zhuǎn)換步驟，直接將ADB PG的數(shù)據(jù)，以二進(jìn)制形式寫入到外表文件中，這樣在查詢外表時(shí)，也無需進(jìn)行任何數(shù)據(jù)類型轉(zhuǎn)換。例如，在導(dǎo)出ORC外表時(shí)，外表可以將任意的數(shù)據(jù)類型，都直接寫入為ORC的Binary類型，在ORC中存儲的二進(jìn)制數(shù)據(jù)，都是按照對應(yīng)ADB PG的數(shù)據(jù)類型來編碼，于是在查詢該ORC外表時(shí)，可以直接省略類型轉(zhuǎn)換步驟，減少了CPU消耗。根據(jù)TPCH查詢測試結(jié)果，整體查詢性能可以提升15%-20%左右。
四.?性能測試
關(guān)于在ADB PG中如何使用外表分析功能，請參考阿里云產(chǎn)品手冊（https://help.aliyun.com/document_detail/164815.html?spm=a2c4g.11186623.6.602.78db2394eaa9rq）。除建表語句不同外，對外表的操作和對本地表的操作幾乎沒有區(qū)別，學(xué)習(xí)難度很低。我們在這里對比一下OSS外表分析場景，與本地表分析場景的性能問題。
?
環(huán)境配置。我們測試采用的機(jī)器是阿里云ECS d1ne.4xlarge機(jī)型，單機(jī)配置16個(gè)Intel Xeon E5-2682v4核心、64GB內(nèi)存，每臺ECS配置4塊HDD本地磁盤，每塊盤讀寫速度約200MB/s。測試一共用了4臺ECS，兩臺用于做Master節(jié)點(diǎn)、4臺用于做Segment節(jié)點(diǎn)，共部署16個(gè)segment。本次測試使用的是TPCH查詢，使用了官方工具生成的1TB數(shù)據(jù)集。
?
本地表我們測試了經(jīng)過壓縮的列存表(AOCS)和HEAP表兩種格式, OSS外表我們測試了CSV、ORC、Parquet和JSON四種格式。TPCH 22條查詢的總執(zhí)行時(shí)間見下表。從測試數(shù)據(jù)可以看出，兩種本地表中，AOCS表的查詢性能略優(yōu)于HEAP表。外表方面，CSV格式、ORC格式和Parquet格式的外表查詢性略慢于本地表的查詢性能，差距在50%左右。JSON格式的外表查詢性能明顯慢于其他格式，這主要是由于JSON格式本身解析速度慢導(dǎo)致的，與外表無關(guān)。
下圖是TPCH 22條查詢的詳細(xì)時(shí)間。本地表與外表的性能差距在不同的查詢上差距有所不同。考慮到外表在存儲成本、靈活性、擴(kuò)展能力方面的優(yōu)勢，ADB PG外表分析在應(yīng)用場景的潛力是巨大的。
五.?總結(jié)
湖倉一體是下一代數(shù)據(jù)倉庫產(chǎn)品的一個(gè)重要能力，ADB PG作為一款功能強(qiáng)大、擴(kuò)展性強(qiáng)的數(shù)據(jù)倉庫產(chǎn)品，基于PG?外表開發(fā)了多種數(shù)據(jù)源的分析和寫入能力，并且沉淀了很多性能優(yōu)化技術(shù)。未來ADB PG將繼續(xù)在產(chǎn)品功能、性價(jià)比、云原生能力、湖倉一體等方向繼續(xù)發(fā)力，為用戶提供更多的功能、性能和成本優(yōu)化。
?
原文鏈接：https://developer.aliyun.com/article/782998?
版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。總結(jié)
以上是生活随笔為你收集整理的数据仓库如何实现湖仓一体数据分析？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 从实战中了解数据开发全流程——DataW
- 下一篇： 关于写文章的一点经验