需求

本文件描述大段落文字資訊的儲存，查詢功能實現

需求：能夠從Web頁面上通過各種條件檢視大段文字資訊，能夠下載完整文字資訊

環境資訊

Hadoop2.6，HBase1.2，Elasticsearch6.0

當前大段文字資訊直接作為field儲存在Elasticsearch中

方案設計

根據需求，可以有兩套方案可供參考，具體實現和依賴我會在下面詳細說明

HDFS之SequenceFile解決方案：

選型依據

• HDFS儲存海量小檔案導致塊過多，namenode記憶體需求增大，導致namenode節點負載變高，穩定性受影響，sequenceFile可以很好的解決該問題

• sequenceFile可以很好的支援壓縮，減少磁碟佔用

• sequenceFile可以分塊儲存，不會影響諸如mapreduce、spark以及Flink等元件的高效使用

實現方案

• 為了方便管理，sequenceFile按天建立，採用塊壓縮（Block Compression）來進行壓縮，當天文字資訊資料按照kv的方式進行儲存寫在sequenceFile中，key為唯一標識該文字資料的id,value為文字資料的明細資訊

• elasticsearch中的資料正常儲存支援前端的查詢，將原本的data欄位文字明細資料的欄位修改成sequenceFile中該崩文字資訊對應的key（如果上面1中的key如果可以通過該條資料其他欄位拼接而成的話，那麼該欄位可以直接刪掉）

• 查詢時可以保留原查詢介面，通過查詢到的資料去HDFS對應的sequenceFile查詢取得文字資訊；如果遇到列表展示，則建議將文字資訊作成lazy load，節省頻寬並提高響應速度

• HDFS上的sequenceFile支援按天老化

查詢介面變更

前端和後端的介面不變，後端從Elasticsearch中的document取文字資料的邏輯改成從sequenceFile中獲取

實現依賴

需要CDH或者Hadoop環境

HBase之MOB解決方案：

選型依據

• HBase的MOB是HBase專門為儲存小物件而設計的解決方案，10M以下的小檔案儲存效果和效率比sequenceFile要好很多

• HBase底層儲存的優化能保證文字資訊穩定高效的儲存

• HBase資料查詢速度比sequenceFile查詢速度要快

實現方案

• HBase專門建立一個table用於儲存崩潰棧資訊，該表的列族啟用MOB屬性，採用snappy進行壓縮，可以根據需求設定資料儲存的ttl，rowkey為唯一標識該崩潰棧資料的id,value為文字的明細資訊

• elasticsearch中的資料正常儲存支援前端的查詢，將原本的data欄位存文字明細資料的欄位修改成HBase中該文字資訊對應的rowkey（如果上面1中的key如果可以通過該條資料其他欄位拼接而成的話，那麼該欄位可以直接刪掉）

• 查詢時可以保留原查詢介面，通過查詢到的資料去HBase對應的table中查詢取得文字資訊；如果遇到列表展示，則建議將文字資訊作成lazy load，節省頻寬並提高響應速度

• HBase上文字資料按配置的ttl進行老化，老化粒度優於sequenceFile方案

查詢介面變更

前端和後端的介面不變，後端從Elasticsearch中的document中取文字資料的邏輯改成從HBase中獲取

實現依賴

需要CDH或者Hadoop環境，並且HDFS要支援HFile v3，HBase版本要升級到2.X

最後結論

• 在HDFS以及HBase版本未升級的情況下，只能採用sequenceFile方案進行處理，如果版本升級的情況下，建議使用HBase的MOB方案

• 優於兩種方案的介面設計是相容的，所以可以先採取sequenceFile方案對文字資料進行處理，後續版本升級後根據需求決定是否將方案遷移到HBase上，遷移的代價可控可接受

文章到這裡就結束了，最後路漫漫其修遠兮，大資料之路還很漫長。如果想一起大資料的小夥伴，歡迎點贊轉發加關注，下次學習不迷路，我們在大資料的路上共同前進！