在開源技術棧,我該如何對大數據存儲引擎做選型?雷達簡圖揭答案

在開源技術棧,我該如何對大數據存儲引擎做選型?雷達簡圖揭答案

大數據技術棧通常包括數據採集、存儲計算、分析可視化、開放共享、業務應用等幾個關鍵分層,在這些能力引擎中,數據存儲是一個關鍵的能力域。在海量數據聚集整合後,首先就是要將數據存放起來,所以存儲引擎的技術選型會直接影響後續的數據用途和分析效果。

存儲引擎的選型要考慮一些關鍵因子,比如數據源類型(結構化/非結構化)、數據規模(GB/TB/PB)、數據增長係數(每年都會增長20%?)、數據加工分析的方式(長期存儲?SQL查詢?交互式訪問?),這些因子必將決定存儲引擎的選型方法。


傳統關係型數據庫(RDB),是企業生產經營中最為普遍的IT存儲系統,大多存放業務系統的結構化數據集。在初期往往單節點服務器就能駕馭存儲需求,後續隨著存儲容量逐漸增加大多采用集群的方式去擴展支撐,而且RDB能夠支持數據的操作與更新,對增刪改查來說絕對是好手,完全遵循了ACID的特性,而且支持標準的SQL語法。因此RDB應用場景非常廣泛,技術也非常成熟。但即便如此,似乎RDB沒有能在今天大數據時代有所作為。首先今天有很多半結構化/非結構化數據集需要存儲並處理,傳統關係型數據庫並不支持,就更別談數據規模了。而且RDB主要採用行存儲的方式保存數據,從後期查詢的支持來講很難於隨機訪問,而且系統的擴展性並不出色,不論MqSQL還是PostgreSQL,原生版本的擴展性能需要大量的調優。


對於傳統RDB的特點,其實Hadoop生態圈的HDFS具有較多特性差異。比如大規模文件存儲支持了海量非結構化數據,什麼視頻音頻、文本日誌、社交物聯網統統不是問題,而且可以根據節點數量大規模擴展,以提升系統整體的存儲容量。HDFS可以承載Hive任務作業,依託於M/R機制實現大規模數據的加載和分析。但Hive只適用於一次寫入、多次讀取的場景,對於頻繁更新和隨機訪問而言並非長項,因為些都受限於M/R機制和對標準SQL的支持。在大數據早期,HDFS+Hive長期支撐了很多客戶的系統,比如電信運營商的詳單數據存儲和預處理、互聯網公司的網絡日誌採集和分析等,直至今日仍然有很多企業在持續使用,正可謂大數據的關鍵技術組件。

除了傳統SQL結構化數據外,在大數據領域還有NoSQL數據庫。當時隨著互聯網web2.0的興起,傳統的關係數據庫在應對大規模和高併發的SNS純動態網站顯得力不從心,暴露了很多難以克服的問題,而非關係型的數據庫(NoSQL)則由於其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰,尤其是大數據應用難題。NoSQL數據庫主要有四大分類:鍵值(Key-Value)存儲數據庫、列存儲數據庫、文檔型數據庫和圖形數據庫,所以是典型的支持非結構化數據,這裡面由於時間關係暫不展開。在NoSQL四種類型中,以Hbase為代表的列存儲數據庫是非常有代表性的。由於存儲方式的特點使其對海量數據的隨即訪問支持非常好,而且底層也支持HDFS存儲,其系統擴展性也不是問題,列存儲大大提高了存儲壓縮率。現在Hbase不僅支持一級索引,還可以通過功能開發實現二級索引的支持,所以技術成熟度也是不錯的。

上述介紹中,你會發現海量數據的大規模分析與高效低延遲訪問有較大差別,兩者各有優勢不可兼得。在現實情況中會經常發現兩套存儲引擎的交替使用,分別用於實時讀寫與海量數據分析,可以先將數據寫入HBase中,再定期通過ETL到Parquet進行數據同步。但是這樣做有很多缺點,比如第一:用戶需要在兩套系統間編寫和維護複雜的ETL邏輯;第二,時效性差,因為ETL通常是一個小時、幾個小時甚至是一天一次,那麼可供分析的數據就需要一個小時至一天的時間後才進入到可用狀態;第三,更新需求難以滿足。在實際情況中可能會有一些對已經寫入的數據的更新需求,這種情況往往需要對歷史數據進行更新,代價太大;第四,存儲資源浪費。兩套存儲系統意味著佔用的磁盤資源翻倍了,造成了成本的提升。所以Cloudera開發了Kudu存儲引擎,解決了前面種應用場景的問題。但是新技術需要磨合才能實際生產運用,否則會帶來風險。

通過上述介紹,如果你需要常規結構化數據集的存儲管理和查詢分析,那麼你需要RDB存儲引擎;如果系統將承載海量非結構化數據集,那麼存儲和分析就需要用到HDFS+Hive的存儲引擎;如果你需要海量非結構化數據集的低延遲隨機讀寫場景,那麼你需要使用類似於Hbase這樣的存儲引擎;如果你需要支持結構化數據,而且支持行級的插入、更新、刪除,並嘗試新技術去應對海量數據分析和低延遲隨機訪問,那麼Kudu也可以選擇。

大數據存儲引擎是一個既複雜而又關鍵的領域,一個好的存儲技術架構有助於後續業務的“生根發芽”。


分享到:


相關文章: