前言
互聯(lián)網(wǎng)的飛速發(fā)展促進(jìn)了很多新媒體的發(fā)展，不論是知名的大 V，明星還是圍觀群眾都可以通過手機(jī)在微博，朋友圈或者點(diǎn)評網(wǎng)站上發(fā)表狀態(tài)，分享自己的所見所想，使得“人人都有了麥克風(fēng)”。不論是熱點(diǎn)新聞還是娛樂八卦，傳播速度遠(yuǎn)超我們的想象?？梢栽诙潭虜?shù)分鐘內(nèi)，有數(shù)萬計轉(zhuǎn)發(fā)，數(shù)百萬的閱讀。如此海量的信息可以得到爆炸式的傳播，如何能夠?qū)崟r的把握民情并作出對應(yīng)的處理對很多企業(yè)來說都是至關(guān)重要的。大數(shù)據(jù)時代，除了媒體信息以外，商品在各類電商平臺的訂單量，用戶的購買評論也都對后續(xù)的消費(fèi)者產(chǎn)生很大的影響。商家的產(chǎn)品設(shè)計者需要匯總統(tǒng)計和分析各類平臺的數(shù)據(jù)做為依據(jù)，決定后續(xù)的產(chǎn)品發(fā)展，公司的公關(guān)和市場部門也需要根據(jù)輿情作出相應(yīng)的及時處理，而這一切也意味著傳統(tǒng)的輿情系統(tǒng)升級成為大數(shù)據(jù)輿情采集和分析系統(tǒng)。
分析完輿情場景后，我們再來具體細(xì)化看下大數(shù)據(jù)輿情系統(tǒng)，對我們的數(shù)據(jù)存儲和計算系統(tǒng)提出哪些需求：
海量原始數(shù)據(jù)的實(shí)時入庫：為了實(shí)現(xiàn)一整套輿情系統(tǒng)，需要有上游原始輸出的采集，也就是爬蟲系統(tǒng)。爬蟲需要采集各類門戶，自媒體的網(wǎng)頁內(nèi)容。在抓取前需要去重，抓取后還需要分析提取，例如進(jìn)行子網(wǎng)頁的抓取。
原始網(wǎng)頁數(shù)據(jù)的處理：不論是主流門戶還是自媒體的網(wǎng)頁信息，抓取后我們需要做一定的數(shù)據(jù)提取，把原始的網(wǎng)頁內(nèi)容轉(zhuǎn)化為結(jié)構(gòu)化數(shù)據(jù)，例如文章的標(biāo)題，摘要等，如果是商品點(diǎn)評類消息也需要提取有效的點(diǎn)評。
結(jié)構(gòu)化數(shù)據(jù)的輿情分析：當(dāng)各類原始輸出變成結(jié)構(gòu)化的數(shù)據(jù)后，我們需要有一個實(shí)時的計算產(chǎn)品把各類輸出做合理的分類，進(jìn)一步對分類后的內(nèi)容進(jìn)行情感打標(biāo)。根據(jù)業(yè)務(wù)的需求這里可能會產(chǎn)生不同的輸出，例如品牌當(dāng)下是否有熱點(diǎn)話題，輿情影響力分析，轉(zhuǎn)播路徑分析，參與用戶統(tǒng)計和畫像，輿論情感分析或者是否有重大預(yù)警。
輿情分析系統(tǒng)中間和結(jié)果數(shù)據(jù)的存儲，交互分析查詢：從網(wǎng)頁原始數(shù)據(jù)清洗到最終的輿情報表這中間會產(chǎn)生很多類型的數(shù)據(jù)。這些數(shù)據(jù)有的會提供給數(shù)據(jù)分析同學(xué)進(jìn)行輿情分析系統(tǒng)的調(diào)優(yōu)，有的數(shù)據(jù)會提供給業(yè)務(wù)部門根據(jù)輿情結(jié)果進(jìn)行決策。這些查詢可能會很靈活，需要我們的存儲系統(tǒng)具備全文檢索，多字段組合靈活的交互分析能力。
重大輿情事件的實(shí)時預(yù)警：對于輿情的結(jié)果除了正常的搜索和展示需求以外，當(dāng)有重大事件出現(xiàn)我們需要能做到實(shí)時的預(yù)警。
我們計劃分兩篇介紹完整的輿情新架構(gòu)，第一篇主要是提供架構(gòu)設(shè)計，會先介紹時下主流的大數(shù)據(jù)計算架構(gòu)，并分析一些優(yōu)缺點(diǎn)，然后引入輿情大數(shù)據(jù)架構(gòu)。第二篇會有完整的數(shù)據(jù)庫表設(shè)計和部分示例代碼。大家敬請期待。
系統(tǒng)設(shè)計
需求分析
結(jié)合文章開頭對輿情系統(tǒng)的描述，海量大數(shù)據(jù)輿情分析系統(tǒng)流程圖大體如下：
圖 1 輿情系統(tǒng)業(yè)務(wù)流程
原始網(wǎng)頁存儲庫，這個庫需要能支持海量數(shù)據(jù)，低成本，低延時寫入。網(wǎng)頁數(shù)據(jù)寫入后，要做實(shí)時結(jié)構(gòu)化提取，提取出來的數(shù)據(jù)再進(jìn)行降噪，分詞，圖片 ocr 處理等。對分詞文本，圖片進(jìn)行情感識別產(chǎn)生輿情數(shù)據(jù)結(jié)果集。傳統(tǒng)的離線全量計算很難滿足輿情系統(tǒng)的時效性需求。
計算引擎在做數(shù)據(jù)處理時，可能還需要從存儲庫中獲取一些元數(shù)據(jù)，例如用戶信息，情感詞元數(shù)據(jù)信息等。
除了實(shí)時的計算鏈路，對存量數(shù)據(jù)定期要做一些聚類，優(yōu)化我們的情感詞識別庫，或者上游根據(jù)業(yè)務(wù)需要觸發(fā)情感處理規(guī)則更新，根據(jù)新的情感打標(biāo)庫對存量數(shù)據(jù)做一次輿情計算。
輿情的結(jié)果數(shù)據(jù)集有不同類的使用需求。對于重大輿情，需要做實(shí)時的預(yù)警。完整的輿情結(jié)果數(shù)據(jù)展示層需要支持全文檢索，靈活的屬性字段組合查詢。業(yè)務(wù)上可能根據(jù)屬性字段中的置信度，輿情時間，或者關(guān)鍵詞組合進(jìn)行分析。
根據(jù)前面的介紹，輿情大數(shù)據(jù)分析系統(tǒng)需要兩類計算，一類是實(shí)時計算包括海量網(wǎng)頁內(nèi)容實(shí)時抽取，情感詞分析并進(jìn)行網(wǎng)頁輿情結(jié)果存儲。另一類是離線計算，系統(tǒng)需要對歷史數(shù)據(jù)進(jìn)行回溯，結(jié)合人工標(biāo)注等方式優(yōu)化情感詞庫，對一些實(shí)時計算的結(jié)果進(jìn)行矯正等。所以在系統(tǒng)設(shè)計上，需要選擇一套既可以做實(shí)時計算又能做批量離線計算的系統(tǒng)。在開源大數(shù)據(jù)解決方案中，Lambda 架構(gòu)恰好可以滿足這些需求，下面我們來介紹下 Lambda 的架構(gòu)。
Lambda 架構(gòu) (wiki)
圖 2 Lambda 架構(gòu)圖
Lambda 架構(gòu)可以說是 Hadoop，Spark 體系下最火的大數(shù)據(jù)架構(gòu)。這套架構(gòu)的最大優(yōu)勢就是在支持海量數(shù)據(jù)批量計算處理(也就是離線處理)同時也支持流式的實(shí)時處理(即熱數(shù)據(jù)處理)。
具體是如何實(shí)現(xiàn)的呢，首先上游一般是一個隊列服務(wù)例如 kafka，實(shí)時存儲數(shù)據(jù)的寫入。kafka 隊列會有兩個訂閱者，一個是全量數(shù)據(jù)即圖片中上半部分，全量數(shù)據(jù)會被存儲在類似 HDFS 這樣的存儲介質(zhì)上。當(dāng)有離線計算任務(wù)到來，計算資源(例如 Hadoop)會訪問存儲系統(tǒng)上的全量數(shù)據(jù)，進(jìn)行全量批計算的處理邏輯。經(jīng)過 map/reduce 環(huán)節(jié)后全量的結(jié)果會被寫入一個結(jié)構(gòu)化的存儲引擎例如 Hbase 中，提供給業(yè)務(wù)方查詢。隊列的另一個消費(fèi)訂閱方是流計算引擎，流計算引擎往往會實(shí)時的消費(fèi)隊列中的數(shù)據(jù)進(jìn)行計算處理，例如 Spark Streaming 實(shí)時訂閱 Kafka 的數(shù)據(jù)，流計算結(jié)果也會寫入一個結(jié)構(gòu)化數(shù)據(jù)引擎。批量計算和流計算的結(jié)果寫入的結(jié)構(gòu)化存儲引擎即上圖標(biāo)注 3 的 "Serving Layer"，這一層主要提供結(jié)果數(shù)據(jù)的展示和查詢。
在這套架構(gòu)中，批量計算的特點(diǎn)是需要支持處理海量的數(shù)據(jù)，并根據(jù)業(yè)務(wù)的需求，關(guān)聯(lián)一些其他業(yè)務(wù)指標(biāo)進(jìn)行計算。批量計算的好處是計算邏輯可以根據(jù)業(yè)務(wù)需求靈活調(diào)整，同時計算結(jié)果可以反復(fù)重算，同樣的計算邏輯多次計算結(jié)果不會改變。批量計算的缺點(diǎn)是計算周期相對較長，很難滿足實(shí)時出結(jié)果的需求，所以隨著大數(shù)據(jù)計算的演進(jìn)，提出了實(shí)時計算的需求。實(shí)時計算在 Lambda 架構(gòu)中是通過實(shí)時數(shù)據(jù)流來實(shí)現(xiàn)，相比批處理，數(shù)據(jù)增量流的處理方式?jīng)Q定了數(shù)據(jù)往往是最近新產(chǎn)生的數(shù)據(jù)，也就是熱數(shù)據(jù)。正因為熱數(shù)據(jù)這一特點(diǎn)，流計算可以滿足業(yè)務(wù)對計算的低延時需求，例如在輿情分析系統(tǒng)中，我們往往希望輿情信息可以在網(wǎng)頁抓取下來后，分鐘級別拿到計算結(jié)果，給業(yè)務(wù)方充足的時間進(jìn)行輿情反饋。下面我們就來具體看一下，基于 Lambda 架構(gòu)的思想如何實(shí)現(xiàn)一套完整的輿情大數(shù)據(jù)架構(gòu)。
開源輿情大數(shù)據(jù)方案
通過這個流程圖，讓我們了解了整個輿情系統(tǒng)的建設(shè)過程中，需要經(jīng)過不同的存儲和計算系統(tǒng)。對數(shù)據(jù)的組織和查詢有不同的需求。在業(yè)界基于開源的大數(shù)據(jù)系統(tǒng)并結(jié)合 Lambda 架構(gòu)，整套系統(tǒng)可以設(shè)計如下：
圖 3 開源輿情架構(gòu)圖
系統(tǒng)的最上游是分布式的爬蟲引擎，根據(jù)抓取任務(wù)抓取訂閱的網(wǎng)頁原文內(nèi)容。爬蟲會把抓取到的網(wǎng)頁內(nèi)容實(shí)時寫入 Kafka 隊列，進(jìn)入 Kafka 隊列的數(shù)據(jù)根據(jù)前面描述的計算需求，會實(shí)時流入流計算引擎(例如 Spark 或者 Flink)，也會持久化存儲在 Hbase，進(jìn)行全量數(shù)據(jù)的存儲。全量網(wǎng)頁的存儲可以滿足網(wǎng)頁爬取去重，批量離線計算的需求。
流計算會對原始網(wǎng)頁進(jìn)行結(jié)構(gòu)化提取，將非結(jié)構(gòu)化網(wǎng)頁內(nèi)容轉(zhuǎn)化為結(jié)構(gòu)數(shù)據(jù)并進(jìn)行分詞，例如提取出網(wǎng)頁的標(biāo)題，作者，摘要等，對正文和摘要內(nèi)容進(jìn)行分詞。提取和分詞結(jié)果會寫回 Hbase。結(jié)構(gòu)化提取和分詞后，流計算引擎會結(jié)合情感詞庫進(jìn)行網(wǎng)頁情感分析，判斷是否有輿情產(chǎn)生。
流計算引擎分析的輿情結(jié)果存儲 Mysql 或者 Hbase 數(shù)據(jù)庫中，為了方便結(jié)果集的搜索查看，需要把數(shù)據(jù)同步到一個搜索引擎例如 Elasticsearch，方便進(jìn)行屬性字段的組合查詢。如果是重大的輿情時間，需要寫入 Kafka 隊列觸發(fā)輿情報警。
全量的結(jié)構(gòu)化數(shù)據(jù)會定期通過 Spark 系統(tǒng)進(jìn)行離線計算，更新情感詞庫或者接受新的計算策略重新計算歷史數(shù)據(jù)修正實(shí)時計算的結(jié)果。
開源架構(gòu)分析
上面的輿情大數(shù)據(jù)架構(gòu)，通過 Kafka 對接流計算，Hbase 對接批計算來實(shí)現(xiàn) Lambda 架構(gòu)中的“batch view”和“real-time view”，整套架構(gòu)還是比較清晰的，可以很好的滿足在線和離線兩類計算需求。但是把這一套系統(tǒng)應(yīng)用在生產(chǎn)并不是一件容易的事情，主要有下面一些原因。
整套架構(gòu)涉及到非常多的存儲和計算系統(tǒng)包括：Kafka，Hbase，Spark，F(xiàn)link，Elasticsearch。數(shù)據(jù)會在不同的存儲和計算系統(tǒng)中流動，運(yùn)維好整套架構(gòu)中的每一個開源產(chǎn)品都是一個很大的挑戰(zhàn)。任何一個產(chǎn)品或者是產(chǎn)品間的通道出現(xiàn)故障，對整個輿情分析結(jié)果的時效性都會產(chǎn)生影響。
為了實(shí)現(xiàn)批計算和流計算，原始的網(wǎng)頁需要分別存儲在 Kafka 和 Hbase 中，離線計算是消費(fèi) hbase 中的數(shù)據(jù)，流計算消費(fèi) Kafka 的數(shù)據(jù)，這樣會帶來存儲資源的冗余，同時也導(dǎo)致需要維護(hù)兩套計算邏輯，計算代碼開發(fā)和維護(hù)成本也會上升。
輿情的計算結(jié)果存儲在 Mysql 或者 Hbase，為了豐富組合查詢語句，需要把數(shù)據(jù)同步構(gòu)建到 Elasticsearch 中。查詢的時候可能需要組合 Mysql 和 Elasticsearch 的查詢結(jié)果。這里沒有跳過數(shù)據(jù)庫，直接把結(jié)果數(shù)據(jù)寫入 Elasticsearch 這類搜索系統(tǒng)，是因為搜索系統(tǒng)的數(shù)據(jù)實(shí)時寫入能力和數(shù)據(jù)可靠性不如數(shù)據(jù)庫，業(yè)界通常是把數(shù)據(jù)庫和搜索系統(tǒng)整合，整合下的系統(tǒng)兼?zhèn)淞藬?shù)據(jù)庫和搜索系統(tǒng)的優(yōu)勢，但是兩個引擎之間數(shù)據(jù)的同步和跨系統(tǒng)查詢對運(yùn)維和開發(fā)帶來很多額外的成本。
新的大數(shù)據(jù)架構(gòu) Lambda plus
通過前面的分析，相信大家都會有一個疑問，有沒有簡化的的大數(shù)據(jù)架構(gòu)，在可以滿足 Lambda 對計算需求的假設(shè)，又能減少存儲計算以及模塊的個數(shù)呢。Linkedin 的 Jay Kreps 提出了 Kappa 架構(gòu)，關(guān)于 Lambda 和 Kappa 的對比可以參考 " 云上大數(shù)據(jù)方案 " 這篇，這里不展開詳細(xì)對比，簡單說下，Kappa 為了簡化兩份存儲，取消了全量的數(shù)據(jù)存儲庫，通過在 Kafka 保留更長日志，當(dāng)有回溯重新計算需求到來時，重新從隊列的頭部開始訂閱數(shù)據(jù)，再一次用流的方式處理 Kafka 隊列中保存的所有數(shù)據(jù)。這樣設(shè)計的好處是解決了需要維護(hù)兩份存儲和兩套計算邏輯的痛點(diǎn)，美中不足的地方是隊列可以保留的歷史數(shù)據(jù)畢竟有限，難以做到無時間限制的回溯。分析到這里，我們沿著 Kappa 針對 Lambda 的改進(jìn)思路，向前多思考一些：假如有一個存儲引擎，既滿足數(shù)據(jù)庫可以高效的寫入和隨機(jī)查詢，又能像隊列服務(wù)，滿足先進(jìn)先出，是不是就可以把 Lambda 和 Kappa 架構(gòu)揉合在一起，打造一個 Lambda plus 架構(gòu)呢?
新架構(gòu)在 Lambda 的基礎(chǔ)上可以提升以下幾點(diǎn)：
在支持流計算和批計算的同時，讓計算邏輯可以復(fù)用，實(shí)現(xiàn)“一套代碼兩類需求”。
統(tǒng)一歷史數(shù)據(jù)全量和在線實(shí)時增量數(shù)據(jù)的存儲，實(shí)現(xiàn)“一份存儲兩類計算”。
為了方便輿情結(jié)果查詢需求，“batch view”和“real-time view”存儲在既可以支持高吞吐的實(shí)時寫入，也可以支持多字段組合搜索和全文檢索。
總結(jié)起來就是整套新架構(gòu)的核心是解決存儲的問題，以及如何靈活的對接計算。我們希望整套方案是類似下面的架構(gòu)：
圖 4 Lambda Plus 架構(gòu)
數(shù)據(jù)流實(shí)時寫入一個分布式的數(shù)據(jù)庫，借助于數(shù)據(jù)庫查詢能力，全量數(shù)據(jù)可以輕松的對接批量計算系統(tǒng)進(jìn)行離線處理。
數(shù)據(jù)庫通過數(shù)據(jù)庫日志接口，支持增量讀取，實(shí)現(xiàn)對接流計算引擎進(jìn)行實(shí)時計算。
批計算和流計算的結(jié)果寫回分布式數(shù)據(jù)庫，分布式數(shù)據(jù)庫提供豐富的查詢語意，實(shí)現(xiàn)計算結(jié)果的交互式查詢。
整套架構(gòu)中，存儲層面通過結(jié)合數(shù)據(jù)庫主表數(shù)據(jù)和數(shù)據(jù)庫日志來取代大數(shù)據(jù)架構(gòu)中的隊列服務(wù)，計算系統(tǒng)選取天然支持批和流的計算引擎例如 Flink 或者 Spark。這樣一來，我們既可以像 Lambda 進(jìn)行無限制的歷史數(shù)據(jù)回溯，又可以像 Kappa 架構(gòu)一樣一套邏輯，存儲處理兩類計算任務(wù)。這樣的一套架構(gòu)我們?nèi)∶麨?ldquo;Lambda plus”，下面就詳細(xì)展開如何在阿里云上打造這樣的一套大數(shù)據(jù)架構(gòu)。
云上輿情系統(tǒng)架構(gòu)
在阿里云眾多存儲和計算產(chǎn)品中，貼合上述大數(shù)據(jù)架構(gòu)的需求，我們選用兩款產(chǎn)品來實(shí)現(xiàn)整套輿情大數(shù)據(jù)系統(tǒng)。存儲層面使用阿里云自研的分布式多模型數(shù)據(jù)庫 Tablestore，計算層選用 Blink 來實(shí)現(xiàn)流批一體計算。
圖 5 云上輿情大數(shù)據(jù)架構(gòu)
這套架構(gòu)在存儲層面，全部基于 Tablestore，一個數(shù)據(jù)庫解決不同存儲需求，根據(jù)之前輿情系統(tǒng)的介紹，網(wǎng)頁爬蟲數(shù)據(jù)在系統(tǒng)流動中會有四個階段分別是原始網(wǎng)頁內(nèi)容，網(wǎng)頁結(jié)構(gòu)化數(shù)據(jù)，分析規(guī)則元數(shù)據(jù)和輿情結(jié)果，輿情結(jié)果索引。我們利用 Tablestore 寬行和 schema free 的特性，合并原始網(wǎng)頁和網(wǎng)頁結(jié)構(gòu)化數(shù)據(jù)成一張網(wǎng)頁數(shù)據(jù)。網(wǎng)頁數(shù)據(jù)表和計算系統(tǒng)通過 Tablestore 新功能通道服務(wù)進(jìn)行對接。通道服務(wù)基于數(shù)據(jù)庫日志，數(shù)據(jù)的組織結(jié)構(gòu)按照數(shù)據(jù)的寫入順序進(jìn)行存儲，正是這一特性，賦能數(shù)據(jù)庫具備了隊列流式消費(fèi)能力。使得存儲引擎既可以具備數(shù)據(jù)庫的隨機(jī)訪問，也可以具備隊列的按照寫入順序訪問，這也就滿足我們上面提到整合 Lambda 和 kappa 架構(gòu)的需求。分析規(guī)則元數(shù)據(jù)表由分析規(guī)則，情感詞庫組層，對應(yīng)實(shí)時計算中的維表。
計算系統(tǒng)這里選用阿里云實(shí)時流計算產(chǎn)品 Blink，Blink 是一款支持流計算和批計算一體的實(shí)時計算產(chǎn)品。并且類似 Tablestore 可以很容易的做到分布式水平擴(kuò)展，讓計算資源隨著業(yè)務(wù)數(shù)據(jù)增長彈性擴(kuò)容。使用 Tablestore + Blink 的優(yōu)勢有以下幾點(diǎn)：
Tablestore 已經(jīng)深度和 Blink 進(jìn)行整合，支持源表，維表和目的表，業(yè)務(wù)無需為數(shù)據(jù)流動開發(fā)代碼。
整套架構(gòu)大幅降低組建個數(shù)，從開源產(chǎn)品的 6～7 個組建減少到 2 個，Tablestore 和 Blink 都是全托管 0 運(yùn)維的產(chǎn)品，并且都能做到很好的水平彈性，業(yè)務(wù)峰值擴(kuò)展無壓力，使得大數(shù)據(jù)架構(gòu)的運(yùn)維成本大幅降低。
業(yè)務(wù)方只需要關(guān)注數(shù)據(jù)的處理部分邏輯，和 Tablestore 的交互邏輯都已經(jīng)集成在 Blink 中。
開源方案中，如果數(shù)據(jù)庫源希望對接實(shí)時計算，還需要雙寫一個隊列，讓流計算引擎消費(fèi)隊列中的數(shù)據(jù)。我們的架構(gòu)中數(shù)據(jù)庫既作為數(shù)據(jù)表，又是隊列通道可以實(shí)時增量數(shù)據(jù)消費(fèi)。大大簡化了架構(gòu)的開發(fā)和使用成本。
流批一體，在輿情系統(tǒng)中實(shí)時性是至關(guān)重要的，所以我們需要一個實(shí)時計算引擎，而 Blink 除了實(shí)時計算以外，也支持批處理 Tablestore 的數(shù)據(jù)， 在業(yè)務(wù)低峰期，往往也需要批量處理一些數(shù)據(jù)并作為反饋結(jié)果寫回 Tablestore，例如情感分析反饋等。那么一套架構(gòu)既可以支持流處理又可以支持批處理是再好不過。這里我們可以參考之前的一篇文章《實(shí)時計算最佳實(shí)踐：基于表格存儲和 Blink 的大數(shù)據(jù)實(shí)時計算》。一套架構(gòu)帶來的優(yōu)勢是，一套分析代碼既可以做實(shí)時流計算又可以離線批處理。
整個計算流程會產(chǎn)生實(shí)時的輿情計算結(jié)果。重大輿情事件的預(yù)警，通過 Tablestore 和函數(shù)計算觸發(fā)器對接來實(shí)現(xiàn)。Tablestore 和函數(shù)計算做了增量數(shù)據(jù)的無縫對接，通過結(jié)果表寫入事件，可以輕松的通過函數(shù)計算觸發(fā)短信或者郵件通知。完整的輿情分析結(jié)果和展示搜索利用了 Tablestore 的新功能多元索引，徹底解決了開源 Hbase+Solr 多引擎的痛點(diǎn)：
運(yùn)維復(fù)雜，需要有運(yùn)維 hbase 和 solr 兩套系統(tǒng)的能力，同時還需要維護(hù)數(shù)據(jù)同步的鏈路。
Solr 數(shù)據(jù)一致性不如 Hbase，在 Hbase 和 Solr 數(shù)據(jù)語意并不是完全一致，加上 Solr/Elasticsearch 在數(shù)據(jù)一致性很難做到像數(shù)據(jù)庫那么嚴(yán)格。在一些極端情況下會出現(xiàn)數(shù)據(jù)不一致的問題，開源方案也很難做到跨系統(tǒng)的一致性比對。
查詢接口需要維護(hù)兩套 API，需要同時使用 Hbase client 和 Solr client，索引中沒有的字段需要主動反查 Hbase，易用性較差。
