基于Kudu的結構化數據存儲方案設計分析

李松濤

摘要：本文主要圍繞以Kudu為基礎結構化的數據存儲整體方案設計開展深入地研究探討，希望能夠為今后方案設計及完善相關實踐工作的有效進展提供建議參考。

關鍵詞：Kudu;結構化;數據存儲;方案設計

中圖分類號：TP311.13 文獻標識碼：A 文章編號：1007-9416（2019）10-0183-01

0 引言

因受到傳統數據庫的存儲架構方面設計所限制，傳統模式下結構化的數據在擴展性、時效性方面均相對較差，優化難度相對較高。對此，深入研究以Kudu為基礎結構化的數據存儲整體方案設計，對提升結構化的數據在擴展性、時效性各方面性能有著極大的現實意義及價值。

1 總體框架設計

結構化的數據存儲方面分析引擎組成部分包括：接入數據、分布式Kudu存儲引擎、轉儲數據引擎、Hadoop Cluster、Hplsql、交互數據處理Impala引擎、分布式Spark計算引擎。如下，為各個功能系統模塊組件的功能詳細介紹[1]：

（1）接入數據。接入數據系統模塊，它主要是提供著標準化REST網關，經REST網關的隔離，將寫入Kudu數據要求必須連通著集群內部全部Tablet Server網絡安全性及連通性方面問題妥善解決;同時，還將Kudu接口處錯誤調用所致集群方面穩定性相關問題，可實現跨語言式調用操作。接入數據該系統模塊內，設計支持Kettle、Flume接入，Flume Agent當中的sink即可實現，經avro協議、文件、命令等輸出各種方式接入數據，促使Kettle 輸出轉換的操作接口可集成STE所輸出的插件，Kettle內科直接拖拽應用STE所輸出的組件，自關系的數據庫與文件等各種Kettle 支持輸入的方式，數據可被輸出至Kudu內。（2）轉儲數據引擎。轉儲數據引擎，其主要是為把Kudu內部歷史數據及時轉儲至Hadoop內，采用parquet的格式實現存儲操作。如此操作的好處即為：多數實時化查詢均已最近數據為基礎，歷史數據全部歸檔至Hadoop內，則Kudu內實際數據量存儲必然減少，它的實時化存儲及分析方面的能力能夠得到很好利用;同時，數據全部歸檔成為parquet的格式，則Impala實際分析的速度 將會得到提升。因Impala 自身支持著parquet該格式查詢數據，故僅需把Kudu內部數據存儲 于Hadoop內部，數據經表UNION后，全量的數據分析即可實現。（3）分布式Kudu存儲引擎。存儲數據引擎，經設計數據表，主要包含著列壓縮、分區、主鍵等設計，數據存儲的空間占用得以縮小，系統的IO性能能夠得以提升，且數據實際的檢索效率也將得到提升。（4）Hadoop Cluster。通過Hadoop Cluster的使用，Kudu當中的歷史數據均可實現較高可靠性的歸檔及存儲處理，它支持著Spark、Impala的數據訪問操作。（5）Hplsql。在提供著存儲期間，可充分滿足于傳統的數據庫在存儲期間遷移方面需求。（6）分布式Spark計算引擎。借助Kudu 當中Spark Datasource，能支持著Spark的內存計算，將Impala內部部分復雜的SQL較慢查詢、復雜性的SQL維護等問題予以妥善處理，計算分析的能力能夠得到提升。（7）交互數據處理Impala引擎。提供著MPP架構交互SQL的查詢引擎，經查詢引擎，能夠將數據的聚合類計算分析妥善處理好，此引擎還支持著函數的自定義系統功能，經函數的自定義該項功能，SQL功能能夠得到擴展，促使傳統以SQL為基礎分析更具簡單便捷性。

2 方案設計

2.1 存儲方面

依據數據時間屬性，數據的存儲設計可由兩個部分所構成，即為：存儲于Kudu內部實時化數據及頻繁分析的數據方面存儲設計;parquet該格式下存儲于Hadoop內部數據方面存儲設計[2]。

2.1.1 冷數據的存儲

（1）通過parquet該格式把表數據存儲至Hadoop內，可高效率過濾及壓縮處理數據;（2）表通過snappy的壓縮處理，可折中數據的檢索及解壓方面性能;（3）設置parquet該文件的大小，以1GB為宜。為能夠將parquet文件有效存儲至 Hadoop內部，Hadoop塊大小一般可設256MB或126MB。故設為1GB，防止過于小所致Hadoop的存儲性方面問題，還可防止因過于大所致檢索性方面問題等。分別存儲數據經劃分后的冷、暖數據后，可經Impala實現分別外表映射處理，視圖可實現對外統一，如把Kudu內數據表Table1于Impala當中多對應冷數據，把它映射成Impala外表的Table1_Parquet，Impala內構建起視圖的Table1即為Table1_Kudu UNION Table1_Parquet，Table1的全量數據分析即可實現。

2.1.2 暖數據的存儲

（1）設計主鍵。因Kudu表有著主鍵牽引功能，對此，應把條件查詢當中關鍵詞當初主鍵部分，促使數據的檢索效率得以提升;（2）實施分區設計。該Kudu，它支持著RANGE、HASH兩種分區的方式，以不同業務場景相結合，經適宜分析來合理分布數據，將數據檢索性及插入性提升;（3）實施列壓縮性設計。經振動于數據不同類型配置相應壓縮算法，數據可實現高效化壓縮處理，磁盤的占用空間得以縮小，IO的訪問效率得以提升。Impala內實施表JOIN的查詢期間，性能優化較為突出。

2.2 轉儲方面

借助STE轉儲數據引擎，把Kudu內部部分的歷史數據有效抽取至Hadoop內成為冷數據的存儲，Spark程序即為STE轉儲數據引擎設計，經Oozie相應大數據的工作流式引擎調度周期任務，STE引擎內檢查該Kudu當中所滿足相應冷數據的標準數據，從Kudu內把數據抽取至Hadoop當中，成功抽取后對于 Kudu內部相關數據做好刪除處理。

2.3 分析方面

經用戶的數據分析不同場景，用戶分析主要包含著實時化交互式的分析、內存計算式分析、離線批的處理計算式分析，以下為具體設計：

（1）實時化交互式的分析。此分析為用戶進行查詢與分析條件的輸入，點擊查詢后觸發到分析，此分析方式需在秒級的時延之內返回，針對該部分數據查詢分析，分析引擎可選用Impala，用戶們可借助jdbc、odbc實現與Impala的連接，將查詢命令提交出去。（2）內存計算式分析。該內存計算式分析，它主要是為能夠將部分的分析任務難以用過SQL實現編寫方面問題有效妥善處理，且還能處理SQL使用期間過慢的分析速度方面問題，此類型分析人物無需較高實時性要求，可分鐘級別內完成，以Spark作為計算引擎，經相關計算任務的編寫，可通過直接訪問Hadoop、Kudu內部數據來實現。（3）離線批的處理計算式分析。該離線批的處理計算式分析，比較適合報表相關可靠性的結果需求情況下使用，但針對于時間分析方面要求并不是較高情況下，可實現分級別化實現，直接通過Hadoop內設Mapreduce的引擎實現高效處理。

3 結語

綜上所述，該方案設計式以Kudu作為基礎的引擎，借助城市的Spark、Hadoop大數據科學技術，開發設計出一種比較適合結構化海量數據的存儲分析實施方案，可廣泛應用至網絡報文、海量日志、電子商務、物聯網的數據等各種數據的存儲分析相應場合當中，此方案具備較為突出的應用優勢，值得廣泛推廣及應用。

參考文獻

[1] 王博.面向全基因組關聯分析的大數據存儲架構設計與實現[D].華南理工大學，2018.

[2] 寧群儀，周超.基于Kudu+Impala的交通大數據存儲和分析平臺[J].電腦編程技巧與維護，2018（11）：91-92+111.