在本節中，咱們將介紹一些有關Hudi插入更新、增量提取的實際性能數據，並將其與實現這些任務的其它傳統工具進行比較。數據庫
插入更新
下面顯示了從NoSQL數據庫攝取得到的速度提高，這些速度提高數據是經過在寫入時複製存儲上的Hudi數據集上插入更新而得到的，
數據集包括5個從小到大的表（相對於批量加載表）。微信
因爲Hudi能夠經過增量構建數據集，它也爲更頻繁地調度攝取提供了可能性，從而減小了延遲，並顯著節省了整體計算成本。工具
Hudi插入更新在t1表的一次提交中就進行了高達4TB的壓力測試。性能
有關一些調優技巧，請參見這裏。測試
索引
爲了有效地插入更新數據，Hudi須要將要寫入的批量數據中的記錄分類爲插入和更新（並標記它所屬的文件組）。
爲了加快此操做的速度，Hudi採用了可插拔索引機制，該機制存儲了recordKey和它所屬的文件組ID之間的映射。
默認狀況下，Hudi使用內置索引，該索引使用文件範圍和布隆過濾器來完成此任務，相比於Spark Join，其速度最高可提升10倍。優化
當您將recordKey建模爲單調遞增時（例如時間戳前綴），Hudi提供了最佳的索引性能，從而進行範圍過濾來避免與許多文件進行比較。
即便對於基於UUID的鍵，也有已知技術來達到一樣目的。
例如，在具備80B鍵、3個分區、11416個文件、10TB數據的事件表上使用100M個時間戳前綴的鍵（5％的更新，95％的插入）時，
相比於原始Spark Join，Hudi索引速度的提高約爲7倍（440秒相比於2880秒）。
即便對於具備挑戰性的工做負載，如使用300個核對3.25B UUID鍵、30個分區、6180個文件的「100％更新」的數據庫攝取工做負載，Hudi索引也能夠提供80-100％的加速。spa
讀優化查詢
讀優化視圖的主要設計目標是在不影響查詢的狀況下實現上一節中提到的延遲減小和效率提升。
下圖比較了對Hudi和非Hudi數據集的Hive、Presto、Spark查詢，並對此進行說明。.net
Hive設計
Spark3d
Presto
本文分享自微信公衆號 - ApacheHudi（ApacheHudi）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。