當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

数据仓库如何实现湖仓一体数据分析？

發布時間：2024/9/3 编程问答 48 豆豆

生活随笔收集整理的這篇文章主要介紹了数据仓库如何实现湖仓一体数据分析？小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

簡介：隨著云計算的普及和數據分析需求的擴大，數據湖+數據倉庫的湖倉一體分析能力成為下一代數據分析系統的核心能力。相對于數據倉庫，數據湖在成本、靈活性、多源數據分析等多方面，都有著非常明顯的優勢。IDC發布的十項2021年中國云計算市場趨勢預測中，有三項和數據湖分析有關。可以預見，跨系統集成能力、數據控制能力和更加全面的數據驅動能力，將會是未來數據分析系統重要的競爭領域。

一.?背景

隨著云計算的普及和數據分析需求的擴大，數據湖+數據倉庫的湖倉一體分析能力成為下一代數據分析系統的核心能力。相對于數據倉庫，數據湖在成本、靈活性、多源數據分析等多方面，都有著非常明顯的優勢。IDC發布的十項2021年中國云計算市場趨勢預測中，有三項和數據湖分析有關。可以預見，跨系統集成能力、數據控制能力和更加全面的數據驅動能力，將會是未來數據分析系統重要的競爭領域。

AnalyticDB PostgreSQL版(簡稱ADB PG)是阿里云數據庫團隊基于PostgreSQL內核(簡稱PG)打造的一款云原生數據倉庫產品。在PB級數據實時交互式分析、HTAP、ETL、BI報表生成等業務場景，ADB PG都有著獨特的技術優勢。作為一個數據倉庫產品，ADB PG是如何具備湖倉一體分析能力呢？本文將會介紹ADB PG如何基于PG外表、打造數據湖分析能力。

ADB PG繼承了PG的外表(Foreign Table)功能，目前ADB PG的湖倉一體能力主要是基于外表打造的。基于PG外表，ADB PG可以對其他數據分析系統的數據進行查詢和寫入，在兼容多種數據源的同時，復用ADB PG原有的優化器和執行引擎優勢。ADB PG的湖倉一體分析能力目前已經支持OSS、MaxCompute、Hadoop、RDS PG、Oracle、RDS MySQL等多種數據源的分析或者寫入。用戶可以靈活地將ADB PG應用于數據存儲、交互式分析、ETL等不同領域，可以在單個實例中實現多種數據分析功能。即可以用ADB PG完成數據分析的核心流程，也可以作為眾多環節中的一環去搭建數據鏈路。

不過，外表數據的分析依賴于外部SDK和網絡IO來實現數據讀寫，由于網絡本身的特性與本地磁盤有巨大差異，因此需要在技術層面與本地存儲不同、需要不同的性能優化方案。本文以OSS外表數據讀寫為例，介紹ADB PG在構建湖倉一體分析能力時，所遇到的一些重要問題和解決方案。

二.?問題分析

ADB PG內核可以分為優化器、執行引擎和存儲引擎。外表數據分析可以復用ADB PG原有的優化器和執行引擎的核心部分，僅需少量修改。主要擴展是存儲引擎層的改造，也就是通過外表接口對外表數據進行讀寫。外表數據是存儲在另一個分布式系統當中，需要通過網絡與ADB PG進行連接，這是和讀取本地文件的最核心的區別。一方面，不同的外表數據會提供不同的遠程訪問接口，需要在工程上進行兼容，比如OSS、MaxCompute的數據讀取接口都不相同。另一方面，通過網絡訪問遠程機器上的數據有一定的共性，比如網絡的延遲、網絡放大、帶寬限制、網絡穩定性問題等。

本文將會圍繞上述核心挑戰，介紹ADB PG外表分析項目在支持OSS數據分析過程中的一些重要技術點。OSS是一種阿里云推出的一種低成本分布式存儲系統，存儲了大量的冷熱數據，有較大的數據分析需求。為了方便開發者進行擴展，OSS提供了基于Java、Go、C/C++、Python等主流開發語言的SDK。ADB PG采用了OSS C SDK進行開發。目前ADB PG已經完美支持OSS外表分析的各項功能，除建表語句不同外，用戶可以像訪問本地表一樣訪問OSS外表。支持并發讀取和寫入，支持CSV、ORC、Parquet等常見數據格式。

三.?外表分析技術優化

接下來，我們介紹ADB PG在基于OSS C SDK開發OSS外表分析過程中，解決的一些核心技術問題。

3.1?網絡碎片請求問題

在分析型數據庫場景，業界普遍認為列式存儲在IO性能上強于行式存儲。因為列式存儲在掃描數據時，只需要掃描特定列，而行式存儲畢竟掃描全量數據，因此列式存儲可以節約一些IO資源。但是在開發過程中，團隊發現在一些場景下，如字段較多的大寬表掃描，掃描性能較高的列存格式竟然比掃描CSV行存文本格式性能還要差。后經過定位發現一方面掃描ORC/PARQUET?格式時，客戶端與OSS服務端交互次數過于頻繁，另一方面ADB PG單次向OSS請求的數據量比較小。這兩個原因帶來了很大的性能問題。

我們知道，相比于本地磁盤IO，網絡IO所產生的往返時延往往可以放大幾個量級。因此，如果解析一些列存格式（如ORC/PARQUET）時，如果將網絡請求當作本地磁盤請求處理，高壓縮比所帶來的網絡帶寬占用的減少不足以抵消碎片化請求帶來的往返時延放大，因此性能測試結果低于預期。問題的解決方案，就是通過緩存來減少碎片化的網絡請求。ADB PG每次掃描OSS數據都會“預加載”足夠的數據并緩存，請求時，判定是否命中緩存，如果命中，則直接返回緩存；否則，繼續下一輪次的“預加載”，從而降低網絡請求次數，提高單次請求效率。“預加載”的緩存大小開放配置，默認大小為1MB。

3.2?列過濾與謂詞下推

由于網絡本身的IO性能往往是低于本地存儲的IO性能的，因此在掃描外表數據時，要盡量減少IO的帶寬資源消耗。ADB PG在處理ORC、Parquet格式的文件時，采用了列過濾和謂詞下推技術，來達到這一目的。

列過濾，即外表只請求SQL查詢所需的數據列、忽略不需要的數據列。因為ORC、Parquet都是列式存儲格式，所以外表在發起網絡請求時，只需請求所需列所在的數據范圍即可，從而大幅減小網絡I/O。同時，ORC、Parquet會對列數據進行壓縮處理，進一步減小I/O。

謂詞下推，是將執行計劃里的上層的過濾條件(如WHERE子句中的條件)，移動到下層的外表掃描節點，使外表掃描進行網絡請求時，過濾掉不符合查詢條件的數據塊，從而減少網絡I/O。在ORC/Parquet格式文件中，會在每一個block頭部保存該block中每一列數據的min/max/sum等統計信息，當外表掃描時，會先讀取該block的頭部統計信息，與下推的查詢條件進行比較，如果該列的統計信息不符合查詢條件，則可以直接跳過該列數據。

這里簡單介紹ORC格式的外表的謂詞下推的實現方案。一個ORC文件按數據行分成若干個Stripe組成，Stripe中數據按列式存儲。每個Stripe又分為若干個Row Group,?所有列的每10000行組成一個Row Group。如下圖所示。

ORC文件保存3個層次的統計信息，文件級別與Stripe級別的統計信息存儲在ORC文件末尾，Row Group級別的統計信息在每個Stripe塊頭部存放。使用這3個層次的統計信息，ORC外表可以實現文件級過濾，Stripe級過濾以及Row Group級別過濾。具體做法是，每當掃描一個新的ORC文件，會先讀取文件末尾的文件級統計信息，若不符合查詢條件，則直接跳過整個文件的掃描；接著讀取文件末尾所有Stripe級別的統計信息，過濾掉不符合條件的Stripe塊；對于每個符合條件的Stripe塊，讀取塊頭部的Row Group?級別的統計信息，過濾掉不必要的數據。

3.3 “996”問題

OSS C SDK定義了一類錯誤代碼，用于表示異常情況，這里的996是OSS C SDK中定義的錯誤碼-996。類似的還有錯誤碼-998、-995、-992等。這一類錯誤，通常都是網絡異常導致的OSS外表導入導出失敗。-996是最為常見的一種。

OSS C SDK內部使用CURL與OSS服務端進行網絡交互，相應的CURL錯誤碼，常見CURL 56（Connection reset by peer）、52等。這些網絡異常，通常是由于OSS服務端在負載較高情況下，服務端主動剔除其認為“不活躍”的客戶端連接所致。當需要導入或導出較大規模OSS數據時，由于客戶端處于執行計劃的不同階段，不能長時間持有連接進行連續通信，從而被OSS服務端當作“不活躍”的客戶端連接而關閉。

通常對于這種情況，客戶端需要嘗試重試解決。實際開發過程中發現，即使客戶端接口增加了自動異常重試機制，這種異常依然得不到改善。后經過定位發現，OSS C SDK為提高連接效率，增加了CURL句柄的連接池，但這些網絡異常的CURL句柄，也會存放到池中，因此，即使重試，還是會使用異常的CURL句柄進行通信，所以996異常的問題得不到改善。

既然知道了根本原因，解決的方法也很直觀。我們在CURL句柄的回收接口中，增加對CURL句柄狀態檢查，對于異常的CURL句柄進行銷毀，而不是加回連接池中。這樣避免了連接池中存在無效的CURL句柄。客戶端接口重試時，選擇有效的或者創建新的CURL連接再次通信即可。當然，自動異常重試機制只能針對那些可以重試解決的情況。

① ADB PG訪問OSS外表時，先從CURL連接池中獲取連接，若不存在則新建。

② ADB PG使用CURL連接句柄與OSS Server請求通信。

③ OSS Server通過CURL連接句柄返回通信結果。

④?正常返回的CURL連接句柄使用完畢后加回連接池待下次使用。

⑤?異常狀態的CURL連接句柄銷毀。

3.4?內存管理方案的兼容問題

ADB PG基于PostgreSQL內核打造，也繼承了PostgreSQL的內存管理機制。PostgreSQL的內存管理采用了進程安全的內存上下文MemoryContext，而OSS C SDK是線程安全的內存上下文APR Pool。在MemoryContext內存環境下，每個已經分配的內存，都可以顯式的調用free釋放，由MemoryContext進行內存碎片的整理，但在APR Pool中，我們只看到內存池的創建、內存的申請和內存池的銷毀等操作，卻沒有內存的顯式釋放接口。

這種情況意味著，我們需要對于OSS C SDK接口所持有的內存的生命周期有明確的了解，否則極易出現內存泄漏和訪問已經釋放的內存等問題。通常我們會按照如下兩種方式申請APR Pool的內存。

·?方式一適用于重入低頻的操作接口，如獲取OSS文件清單列表。

·?方式二適用于多次重入的操作接口，如周期性向OSS請求指定文件指定范圍的數據。

通過這種方法，可以很好地解決ADB PG與OSS C SDK在內存管理方面的不兼容問題。

3.5?數據格式的兼容和優化

OSS上的數據，大部分采用CSV、ORC、Parquet等格式。由于ORC/Parquet等格式對數據的底層存儲編碼，與ADB PG的數據編碼并不一致，所以當進行外表掃描時，數據類型轉換是必不可少的步驟。類型轉換，本質上是將數據從一種編碼，改變成另一種編碼方式。例如ORC對于Decimal類型的表示方式和ADB PG不相同，在ORC中Decimal64類型由一個int64存放數據的數字值，再由precision和scale表示數字個數和小數點位數，而在ADB PG中, Decimal類型由int16?數組來存放數據的數字值。格式轉換算法需要對每個數據進行循環的除法與取模操作，這是非常耗費CPU的。

為了減少類型轉換帶來的CPU消耗，進一步優化外表查詢性能，ADB PG在使用外表進行導出數據時，跳過類型轉換步驟，直接將ADB PG的數據，以二進制形式寫入到外表文件中，這樣在查詢外表時，也無需進行任何數據類型轉換。例如，在導出ORC外表時，外表可以將任意的數據類型，都直接寫入為ORC的Binary類型，在ORC中存儲的二進制數據，都是按照對應ADB PG的數據類型來編碼，于是在查詢該ORC外表時，可以直接省略類型轉換步驟，減少了CPU消耗。根據TPCH查詢測試結果，整體查詢性能可以提升15%-20%左右。

四.?性能測試

關于在ADB PG中如何使用外表分析功能，請參考阿里云產品手冊（https://help.aliyun.com/document_detail/164815.html?spm=a2c4g.11186623.6.602.78db2394eaa9rq）。除建表語句不同外，對外表的操作和對本地表的操作幾乎沒有區別，學習難度很低。我們在這里對比一下OSS外表分析場景，與本地表分析場景的性能問題。

環境配置。我們測試采用的機器是阿里云ECS d1ne.4xlarge機型，單機配置16個Intel Xeon E5-2682v4核心、64GB內存，每臺ECS配置4塊HDD本地磁盤，每塊盤讀寫速度約200MB/s。測試一共用了4臺ECS，兩臺用于做Master節點、4臺用于做Segment節點，共部署16個segment。本次測試使用的是TPCH查詢，使用了官方工具生成的1TB數據集。

本地表我們測試了經過壓縮的列存表(AOCS)和HEAP表兩種格式, OSS外表我們測試了CSV、ORC、Parquet和JSON四種格式。TPCH 22條查詢的總執行時間見下表。從測試數據可以看出，兩種本地表中，AOCS表的查詢性能略優于HEAP表。外表方面，CSV格式、ORC格式和Parquet格式的外表查詢性略慢于本地表的查詢性能，差距在50%左右。JSON格式的外表查詢性能明顯慢于其他格式，這主要是由于JSON格式本身解析速度慢導致的，與外表無關。

下圖是TPCH 22條查詢的詳細時間。本地表與外表的性能差距在不同的查詢上差距有所不同。考慮到外表在存儲成本、靈活性、擴展能力方面的優勢，ADB PG外表分析在應用場景的潛力是巨大的。

五.?總結

湖倉一體是下一代數據倉庫產品的一個重要能力，ADB PG作為一款功能強大、擴展性強的數據倉庫產品，基于PG?外表開發了多種數據源的分析和寫入能力，并且沉淀了很多性能優化技術。未來ADB PG將繼續在產品功能、性價比、云原生能力、湖倉一體等方向繼續發力，為用戶提供更多的功能、性能和成本優化。

原文鏈接：https://developer.aliyun.com/article/782998?

總結

以上是生活随笔為你收集整理的数据仓库如何实现湖仓一体数据分析？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：从实战中了解数据开发全流程——DataW
下一篇：关于写文章的一点经验