摘要：在修改完成之后將數據寫入分布式存儲某地址，并標記新數據的地址為該數據源地址，控制起來比較復雜，由于沒有統一的服務實例地址，本地操作之間互不知曉，所以不支持并行寫入。

簡單描述需求，當前我們的分析型數據都是不可變的，且每次的分析都是要將整體數據都加載到計算節點進行分析計算，所以基礎的存儲和緩存都是面向文件的，并不支持對某一行的修改，如果需要Update某些行或者插入新的記錄，需要將增量修改與原數據源聯合進行復雜的合并操作，對于經常需要修改的數據源尤其是更新某些行的屬性值不那么方便，如果只是Append還好，并且還有對這個數據源的實時查詢需求，用戶希望能夠在頁面上進行交互式查詢，要求響應速度亞秒級別。

看起來這個需求很像是一個數據庫所擅長的，但是從另外的角度看，這并不是典型的數據庫的應用場景，我們平時使用數據庫都是作為某個成熟的業務場景的數據保存，這個數據一般是提前定義好的結構，數量可以很大但是數一個或者一組數據庫實例服務組合在一起的這個集群，其中的表格種類一般是有限的幾十最多幾百個，而在我們的產品中，這種可變數據源不屬于產品的結構化數據，而是用戶所自定義的個人數據，屬于數據里邊的數據，格式多種多樣，作為一個個獨立的數據源，且使用的頻率非常低，有可能存在很大量的這種數據源，每個的結構完全不同且屬于不同的用戶，有可能一天也用不上一次，使用數據庫來管理這種低頻數據對資源有些浪費，大概可以采用的方案有以下三種：

也就是上邊提到的，數據不再以文件的形式存在于分布式存儲中，而是直接寫入到支持索引和復雜查詢的數據庫中，這個數據庫可以支持各種存儲結構，文檔、圖、key-value最好都支持，最好是支持很方便橫向的擴展，能夠無限制的新建很多的數據庫和表，并且可以控制將表加載到內存以及釋放內存，以減少資源的占用。從NOSQL Databases這個網站看了比較了很多的數據庫，目前看來支持以上要求的數據庫有RethinkDB和ArangoDB(ArangoDB on Github)，Mongodb由于有明確的命名空間數量限制，所以創建表有數量限制，暫時不考慮，RethinkDB理念不錯且支持對表的加載釋放，API和文檔非常友好，然而這家公司已經被收購，產品未來前景不明朗，而ArangoDB相對來說很小眾，支持的數據模型和索引種類很多，使用起來也相對比較靈活，運行效率也不錯，可以作為首選考慮。

優勢就是使用起來簡單，數據采用傳統的數據庫增刪改語句寫入到數據庫中，查詢也就直接使用索引，執行效率較高，使用數據庫的引擎可以避免我們自己去處理各種原始數據和增量數據的合并，以Write-Ahead-Log（WAL）系統為例，其實所有的修改操作都是直接寫入日志，由數據庫引擎去尋找對應的數據同步或者異步的將操作反應到底層的數據庫存儲中，可能是某種自定義的文件結構，也可能是某種更小巧的嵌入式數據庫。最終數據的存在形式一般是一個方便插入的樹型結構，常見的有B+樹，LSM樹。

缺點也比較明顯，一是資源的占用，用戶的數據作為低頻使用數據使用數據庫來做托管相對比較昂貴，如果支持從內存中釋放還可以減少數據庫自身的緩存處理壓力，如果表的數據很大數量很多則壓力會更大，二是寫入速度受限于數據庫集群的處理能力，比如有大量的插入時需要路由節點的運行效率足夠高，與Alluxio這種直接寫本地緩存的速度有較大的差距，另外插入的過程中需要建立大量的連接，否則單連接的循環寫入速度會非常慢，三是跟Spark等分布式處理框架的結合，目前數據的輸入輸出都是類Hadoop文件的，如果直接讀取或者寫入數據庫，需要自己開發，目前這方便比較少見，大家的分析型數據要么是直接從某系統導出要么就是直接生成的日志，很少直接使用分布式計算引擎去讀取已經結構化的帶索引的數據庫，這樣也會加大當前支持業務產品服務的數據庫的壓力。四是分析型數據的使用，假如這個數據源也會經常的跟其他數據聯合或者獨立的進行復雜的統計分析，這時典型的場景會通過Spark將數據都加載到內存中，相當于一次將數據庫全表導出的過程，比直接讀一個幾百M的文件要慢很多。

嵌入式數據庫相對分布式數據庫更靈活，只需要在數據需要進行讀寫的時候啟動一個實例供調用，不用的時候數據以文件的形式存在于系統中，對資源的消耗低，同時具有數據庫讀寫的各種優勢。缺點是文件只能存在于本地，如果我們需要以統一的存儲來作為嵌入式數據的來源，每次修改都需要去遠程分布式文件系統去比較數據是否有更新，如果有需要加鎖并下載數據到本地，啟動實例進行讀寫，如果這時候有其他用戶想修改則只能等待這個寫操作釋放，如果是讀操作則不影響直接下載使用。在修改完成之后將數據寫入分布式存儲某地址，并標記新數據的地址為該數據源地址，控制起來比較復雜，由于沒有統一的服務實例地址，本地操作之間互不知曉，所以不支持并行寫入。同樣也有分布式數據庫的問題，需要自己開發Spark到嵌入式數據結構的轉換代碼，如果有直接支持遠程分布式存儲的嵌入式數據庫就比較完美了，當然這種定義本身就比較矛盾，不是嵌入式數據庫的使用場景。有個比較有趣的數據庫是CouchBase，他家的嵌入式數據庫可以在聯網的時候將修改同步到遠程數據庫，適合網絡環境不穩定的移動端，如果要在我們的產品中使用也存在數據同步問題，因為數據不是在固定的某個“移動端”，隨著計算資源分配的不同，用戶的可變數據源可能是在任意一臺機器的任意的一個容器。另外就是嵌入式數據庫支持的數據量普遍規模較小。

Parquet+Druid解決方案，目前我們采用Alluxio作為文件還存，HDFS或者S3作為底層的文件存儲，具體的存儲格式采用了利于分析的Parquet格式，且經過了壓縮。但是不管是Alluxio還是Partqut，都不支持對原來數據的修改，只適合于不可變的分析型數據源，假如需要對原來的數據進行修改，需要在Spark內部進行數據的聯合，之后寫入新的數據源，這個操作消耗較大，讀寫成本高。而且直接使用SparkSQL做數據分析實時性較差，即使對DataSet做了Cache也難以在秒內返回結果，所以需要借助于額外的索引服務，這里考慮了Druid，Pinot，Kylin這三種OLAP方案，其中麒麟純粹的以絕對的空間換取時間，建立索引的時間也很長，使用不靈活，不考慮，前兩者區別不大，成熟度上Druid更高，LinkIn 所開發的Pinot對非BitMap索引支持的較好，可能未來會比Druid好，但暫時不考慮。

Druid做的事情比較簡單，就是根據預先定義的數據格式（包括timestamp, dimension, metric 列的屬性）將批量的和實時的數據經過一個Indexing service來生成目標的segment數據，生成的數據經過了壓縮，針對不同的統計列和分析列來生成對應的segment數據，以自己開發的列式存儲的形式將這些中間索引數據保存下來，用戶提交的查詢經過broker節點會根據預先保存在metadata server里邊的數據找到對應的historical節點或者realtime節點去進行索引數據的二次查詢分析，不需要查詢的節點不會收到請求，最終結果匯總到broker返回給客戶端。作為一個額外的索引服務，其數據來源可以是Hadoop文件系統或者兼容的協議，索引數據也可以保存到他所定義的deep storage里邊，也就是hdfs或者s3，保證數據也是分布式存儲的，這個額外的服務除了占用系統計算資源不對現在的存儲結構造成大的影響，也可以方便的遷移或者替換，如果我們采用了數據庫，這樣如果要切換一種數據庫，所需要的遷移工作是巨大的。

原始數據依然通過文件備份，同時發送給ES做索引服務，支持增量更新以及一些簡單的聚合運算，優勢在于查詢速度快，對于需要小規模結果返回的查詢來說優勢很大，索引同時攜帶原始數據，可以作為數據庫使用，但其核心引擎又是列式存儲，利用率很高。
ES還可以跟Spark直接連接，讀取或者寫入都有成熟的connector可用，結合ES的索引能力和Spark的分析能力，可以滿足大部分的需求。

目前看來，選擇哪種方案還是看具體的需求，能滿足產品的設計。
是否需要提供用戶交互界面修改數據，或者每次批量的更新規模非常小，這種情況適合通過數據庫來托管關系型數據源。
是否經常需要重新分析這個數據源，還是只是用來做實時查詢展示用，如果需要分析，就會涉及倒全量數據的讀取，適合采用文件。

轉載自：
https://medium.com/@leighton....