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

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

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

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

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

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

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

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

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

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

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

轉(zhuǎn)載自：
https://medium.com/@leighton....