本項(xiàng)目為學(xué)校大數(shù)據(jù)工程實(shí)訓(xùn)項(xiàng)目，共開發(fā)4周，答辯成績不錯(cuò)。代碼倉庫放文章尾，寫的不好，代碼僅供參考。

搜索

對(duì)于結(jié)構(gòu)化數(shù)據(jù)，因?yàn)樗鼈兙哂刑囟ǖ慕Y(jié)構(gòu)，所以我們一般都是可以通過關(guān)系型數(shù)據(jù)庫（MySQL，Oracle 等）的二維表（Table）的方式存儲(chǔ)和搜索，也可以建立索引。

對(duì)于非結(jié)構(gòu)化數(shù)據(jù)，也即對(duì)全文數(shù)據(jù)的搜索主要有兩種方法：

• 順序掃描
• 全文檢索

（1）順序掃描：通過文字名稱也可了解到它的大概搜索方式，即按照順序掃描的方式查詢特定的關(guān)鍵字。

例如一張報(bào)紙，讓找到該報(bào)紙中“平安”的文字在哪些地方出現(xiàn)過?？隙ㄐ枰獜念^到尾把報(bào)紙閱讀掃描一遍然后標(biāo)記出關(guān)鍵字在哪些版塊出現(xiàn)過以及它的出現(xiàn)位置。

這種方式無疑是最耗時(shí)的最低效的，如果報(bào)紙排版字體小。

（2）全文搜索：對(duì)非結(jié)構(gòu)化數(shù)據(jù)順序掃描很慢，是否可以進(jìn)行優(yōu)化？即把非結(jié)構(gòu)化數(shù)據(jù)整理有一定結(jié)構(gòu)。

將非結(jié)構(gòu)化數(shù)據(jù)中的一部分信息提取出來，重新組織，使其變得有一定結(jié)構(gòu)，然后對(duì)此有一定結(jié)構(gòu)的數(shù)據(jù)進(jìn)行搜索，從而達(dá)到搜索相對(duì)較快的目的。

這種方式就構(gòu)成了全文檢索的基本思路。這部分從非結(jié)構(gòu)化數(shù)據(jù)中提取出的然后重新組織的信息，我們稱之為索引。

這種方式的主要工作量在前期索引的創(chuàng)建，但是對(duì)于后期搜索卻是快速高效的。

Hbase

HBase 是一個(gè)面向列式存儲(chǔ)的分布式數(shù)據(jù)庫，其設(shè)計(jì)思想來源于 Google 的 BigTable 論文。HBase 底層存儲(chǔ)基于 HDFS 實(shí)現(xiàn)，集群的管理基于 ZooKeeper 實(shí)現(xiàn)。HBase 良好的分布式架構(gòu)設(shè)計(jì)為海量數(shù)據(jù)的快速存儲(chǔ)、隨機(jī)訪問提供了可能，基于數(shù)據(jù)副本機(jī)制和分區(qū)機(jī)制可以輕松實(shí)現(xiàn)在線擴(kuò)容、縮容和數(shù)據(jù)容災(zāi)，是大數(shù)據(jù)領(lǐng)域中 Key-Value 數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)最常用的數(shù)據(jù)庫方案。
HBase 是一個(gè)面向列式存儲(chǔ)的分布式數(shù)據(jù)庫。HBase 的數(shù)據(jù)模型與 BigTable 十分相似。在 HBase 表中，一條數(shù)據(jù)擁有一個(gè)全局唯一的鍵(RowKey)和任意數(shù)量的列(Column)，一列或多列組成一個(gè)列族(Column Family)，同一個(gè)列族中列的數(shù)據(jù)在物理上都存儲(chǔ)在同一個(gè) HFile 中，這樣基于列存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)有利于數(shù)據(jù)緩存和查詢。 HBase 中的表是疏松地存儲(chǔ)的，因此用戶可以動(dòng)態(tài)地為數(shù)據(jù)定義各種不同的列。HBase中的數(shù)據(jù)按主鍵排序，同時(shí)，HBase 會(huì)將表按主鍵劃分為多個(gè) Region 存儲(chǔ)在不同 Region Server 上，以完成數(shù)據(jù)的分布式存儲(chǔ)和讀取。

HBase 根據(jù)列成來存儲(chǔ)數(shù)據(jù)，一個(gè)列族對(duì)應(yīng)物理存儲(chǔ)上的一個(gè) HFile，列族包含多列列族在創(chuàng)建表的時(shí)候被指定。

1.Column Family

Column Family 即列族，HBase 基于列劃分?jǐn)?shù)據(jù)的物理存儲(chǔ)，一個(gè)列族可以包含包意多列。

一般同一類的列會(huì)放在一個(gè)列族中，每個(gè)列族都有一組存儲(chǔ)屬性：

是否應(yīng)該緩存在內(nèi)存中；
數(shù)據(jù)如何被壓縮或行鍵如何編碼等。
HBase 在創(chuàng)建表的時(shí)候就必須指定列族。HBase的列族不是越多越好，官方薦一個(gè)表的列族數(shù)量最好小于或者等于3，過多的列族不利于 HBase 數(shù)據(jù)的管理和索引。

2.RowKey

RowKey的概念與關(guān)系型數(shù)據(jù)庫中的主鍵相似，HBase 使用 RowKey 來唯一標(biāo)識(shí)某行的數(shù)據(jù)。

訪問 HBase 數(shù)據(jù)的方式有三種:

基于 RowKey的單行查詢；
基于RowKey的范圍查詢；
全表掃描查詢。

3.Region

HBase 將表中的數(shù)據(jù)基于 RowKey 的不同范圍劃分到不同 Region 上，每個(gè)Region都負(fù)責(zé)一定范圍的數(shù)據(jù)存儲(chǔ)和訪問。

每個(gè)表一開始只有一個(gè) Region，隨著數(shù)據(jù)不斷插入表，Region 不斷增大，當(dāng)增大到一個(gè)閥值的時(shí)候，Region 就會(huì)等分成兩個(gè)新的 Region。當(dāng)table中的行不斷增多，就會(huì)有越來越多的 Region。

另外，Region 是 Hbase 中分布式存儲(chǔ)和負(fù)載均衡的最小單元，不同的 Region 可以分布在不同的 HRegion Server上。但一個(gè)Hregion是不會(huì)拆分到多個(gè)server上的。
拓展：談一下你對(duì) HBase 的認(rèn)識(shí)？

這樣即使有一個(gè)包括上百億條數(shù)據(jù)的表，由于數(shù)據(jù)被劃分到不同的 Region上，每個(gè) Region 都可以獨(dú)立地進(jìn)行寫入和查詢，HBase 寫查詢時(shí)候可以于多 Region 分布式并發(fā)操作，因此訪問速度也不會(huì)有太大的降低。

4.TimeStamp

TimeStamp 是實(shí)現(xiàn) HBase 多版本的關(guān)鍵。在HBase 中，使用不同 TimeStamp 來標(biāo)識(shí)相同RowKey對(duì)應(yīng)的不同版本的數(shù)據(jù)。相同 RowKey的數(shù)據(jù)按照 TimeStamp 倒序排列。默認(rèn)查詢的是最新的版本，當(dāng)然用戶也可以指定 TimeStamp 的值來讀取指定版本的數(shù)據(jù)。

大數(shù)據(jù)場景下，列式存儲(chǔ)的優(yōu)勢

對(duì)于 OLAP 場景，大多都是對(duì)一整行記錄進(jìn)行增刪改查操作的，那么行式存儲(chǔ)采用以行的行式在磁盤上存儲(chǔ)數(shù)據(jù)就是一個(gè)不錯(cuò)的選擇。

當(dāng)查詢基于需求字段查詢和返回結(jié)果時(shí)，由于這些字段都埋藏在各行數(shù)據(jù)中，就必須讀取每一條完整的行記錄，大量磁盤轉(zhuǎn)動(dòng)尋址的操作使得讀取效率大大降低。數(shù)據(jù)在磁盤上是以行的形式存儲(chǔ)在磁盤上，同一行的數(shù)據(jù)緊挨著存放在一起。

對(duì)于 OLAP 場景，一個(gè)典型的查詢需要遍歷整個(gè)表，進(jìn)行分組、排序、聚合等操作，這樣一來行式存儲(chǔ)中把一整行記錄存放在一起的優(yōu)勢就不復(fù)存在了。而且，分析型 SQL 常常不會(huì)用到所有的列，而僅僅對(duì)其中某些需要的的列做運(yùn)算，那一行中無關(guān)的列也不得不參與掃描。

然而在列式存儲(chǔ)中，由于同一列的數(shù)據(jù)被緊挨著存放在了一起
列式存儲(chǔ)不僅具有按需查詢來提高效率的優(yōu)勢，由于同一列的數(shù)據(jù)屬于同一種類型，如數(shù)值類型，字符串類型等，相似度很高，還可以選擇使用合適的編碼壓縮可減少數(shù)據(jù)的存儲(chǔ)空間，進(jìn)而減少IO提高讀取性能。

Elasticsearch

ES 是使用 Java 編寫的一種開源搜索引擎，它在內(nèi)部使用 Lucene 做索引與搜索，通過對(duì) Lucene 的封裝，隱藏了 Lucene 的復(fù)雜性，取而代之的提供一套簡單一致的 RESTful API。

然而，Elasticsearch 不僅僅是 Lucene，并且也不僅僅只是一個(gè)全文搜索引擎。

它可以被下面這樣準(zhǔn)確的形容：

• 一個(gè)分布式的實(shí)時(shí)文檔存儲(chǔ)，每個(gè)字段可以被索引與搜索。
• 一個(gè)分布式實(shí)時(shí)分析搜索引擎。
• 能勝任上百個(gè)服務(wù)節(jié)點(diǎn)的擴(kuò)展，并支持 PB 級(jí)別的結(jié)構(gòu)化或者非結(jié)構(gòu)化數(shù)據(jù)。

官網(wǎng)對(duì) Elasticsearch 的介紹是 Elasticsearch 是一個(gè)分布式、可擴(kuò)展、近實(shí)時(shí)的搜索與數(shù)據(jù)分析引擎。

Lucene

Lucene 只是一個(gè)工具包，它不是一個(gè)完整的全文檢索引擎。Lucene 的目的是為軟件開發(fā)人員提供一個(gè)簡單易用的工具包，以方便的在目標(biāo)系統(tǒng)中實(shí)現(xiàn)全文檢索的功能，或者是以此為基礎(chǔ)建立起完整的全文檢索引擎。

目前以 Lucene 為基礎(chǔ)建立的開源可用全文搜索引擎主要是 Solr 和 Elasticsearch。

Solr 和 Elasticsearch 都是比較成熟的全文搜索引擎，能完成的功能和性能也基本一樣。

ES 本身就具有分布式的特性和易安裝使用的特點(diǎn)，而 Solr 的分布式需要借助第三方來實(shí)現(xiàn)，例如通過使用 ZooKeeper 來達(dá)到分布式協(xié)調(diào)管理。

倒排索引

為了創(chuàng)建倒排索引，我們通過分詞器將每個(gè)文檔的內(nèi)容域拆分成單獨(dú)的詞（我們稱它為詞條或 Term），創(chuàng)建一個(gè)包含所有不重復(fù)詞條的排序列表，然后列出每個(gè)詞條出現(xiàn)在哪個(gè)文檔。這種結(jié)構(gòu)由文檔中所有不重復(fù)詞的列表構(gòu)成，對(duì)于其中每個(gè)詞都有一個(gè)文檔列表與之關(guān)聯(lián)。這種由屬性值來確定記錄的位置的結(jié)構(gòu)就是倒排索引。帶有倒排索引的文件我們稱為倒排文件。

• Java is the best programming language.
• PHP is the best programming language.
• Javascript is the best programming language.

結(jié)果如下所示：

Term          Doc_1    Doc_2   Doc_3
-------------------------------------
Java        |   X   |        |
is          |   X   |   X    |   X
the         |   X   |   X    |   X
best        |   X   |   X    |   X
programming |   x   |   X    |   X
language    |   X   |   X    |   X
PHP         |       |   X    |
Javascript  |       |        |   X
-------------------------------------

將上面的內(nèi)容轉(zhuǎn)換為圖的形式來說明倒排索引的結(jié)構(gòu)信息，如下圖所示：

• 詞條（Term）：索引里面最小的存儲(chǔ)和查詢單元，對(duì)于英文來說是一個(gè)單詞，對(duì)于中文來說一般指分詞后的一個(gè)詞。

• 詞典（Term Dictionary）：或字典，是詞條 Term 的集合。搜索引擎的通常索引單位是單詞，單詞詞典是由文檔集合中出現(xiàn)過的所有單詞構(gòu)成的字符串集合，單詞詞典內(nèi)每條索引項(xiàng)記載單詞本身的一些信息以及指向“倒排列表”的指針。

• 倒排表（Post list）：一個(gè)文檔通常由多個(gè)詞組成，倒排表記錄的是某個(gè)詞在哪些文檔里出現(xiàn)過以及出現(xiàn)的位置。

  每條記錄稱為一個(gè)倒排項(xiàng)（Posting）。倒排表記錄的不單是文檔編號(hào)，還存儲(chǔ)了詞頻等信息。

• **倒排文件（Inverted File）：**所有單詞的倒排列表往往順序地存儲(chǔ)在磁盤的某個(gè)文件里，這個(gè)文件被稱之為倒排文件，倒排文件是存儲(chǔ)倒排索引的物理文件。

• 可以了解到倒排索引主要由兩個(gè)部分組成：

  • 詞典
  • 倒排文件

  詞典和倒排表是 Lucene 中很重要的兩種數(shù)據(jù)結(jié)構(gòu)，是實(shí)現(xiàn)快速檢索的重要基石。詞典和倒排文件是分兩部分存儲(chǔ)的，詞典在內(nèi)存中而倒排文件存儲(chǔ)在磁盤上。

Elasticsearch+Hbase

為什么做數(shù)據(jù)檢索要加上Hbase，ElasticSearch本身的存儲(chǔ)性能就足以支撐海量數(shù)據(jù).

首先ElasticSearch針對(duì)海量數(shù)據(jù)的存儲(chǔ)存在兩個(gè)較大的缺點(diǎn)：
1、寫入效率相對(duì)較低，雖然和Hbase一樣都是采用LSM樹（LSM 通過將磁盤的隨機(jī)寫轉(zhuǎn)化為順序?qū)憗硖岣邔懶阅?，而付出的代價(jià)就是犧牲部分讀性能），但是ES在寫入時(shí)需要消耗大量的時(shí)間去進(jìn)行分詞、主副本構(gòu)建倒排索引等操作。
2、在大數(shù)據(jù)領(lǐng)域，在使用數(shù)據(jù)的時(shí)候，經(jīng)常用到的字段就幾個(gè)，剩下的字段沒有價(jià)值或使用頻率極低。
以上無用或低頻字段會(huì)占用大量的索引空間，由于ES的倒排索引存儲(chǔ)在文件中，為提高訪問速度，在啟動(dòng)時(shí)都會(huì)把它加載到內(nèi)存中。上述問題會(huì)導(dǎo)致倒排索引文件過大，從而導(dǎo)致集群性能下降并降低數(shù)據(jù)訪問速度，且會(huì)增加不必要的內(nèi)存硬件成本。

架構(gòu)設(shè)計(jì)為了解決上述中出現(xiàn)的問題，需要引入Hbase對(duì)上述出現(xiàn)的問題進(jìn)行彌補(bǔ)。
1、寫入效率問題：Hbase基于HDFS存儲(chǔ)，其次因?yàn)闆]有索引，不需要考慮海量數(shù)據(jù)下因?yàn)樗饕龑?dǎo)致的性能瓶頸，所以Hbase非常適合存儲(chǔ)海量數(shù)據(jù)，寫入速度快，可擴(kuò)展性強(qiáng)。
2、字段過多導(dǎo)致的性能問題：我們可以將原始數(shù)據(jù)存儲(chǔ)至Hbase中，僅將需要進(jìn)行檢索的字段抽取出來存儲(chǔ)至ES中，這樣可以大大降低ES因?yàn)榈古潘饕募^大導(dǎo)致的性能壓力。

其次Hbase支持根據(jù)rowkey進(jìn)行模糊查詢，rowkey我們可以把它看做成Hbase中單條數(shù)據(jù)的唯一ID，同時(shí)也可以作為一個(gè)簡單的索引。

框架設(shè)計(jì)：

根據(jù)rowkey將Hbase的原始數(shù)據(jù)和ES中的檢索數(shù)據(jù)關(guān)聯(lián)起來。

在原始數(shù)據(jù)（也可以叫源數(shù)據(jù)、貼源層數(shù)據(jù)、日志數(shù)據(jù)）入庫時(shí)，可以根據(jù)數(shù)據(jù)生成rowkey（rowkey的設(shè)計(jì)因人而異，最好根據(jù)具體的業(yè)務(wù)來設(shè)計(jì)，注意要確保唯一性），之后將需要檢索的字段抽取出來形成單獨(dú)的一條索引數(shù)據(jù)，并將剛才設(shè)計(jì)好的rowkey放進(jìn)去，之后將原始數(shù)據(jù)根據(jù)rowkey寫入至Hbase，檢索數(shù)據(jù)根據(jù)rowkey寫入至ES中。
在進(jìn)行檢索時(shí)首先根據(jù)檢索條件去ES中搜索，搜索出相對(duì)應(yīng)的檢索數(shù)據(jù)后，根據(jù)檢索數(shù)據(jù)中的rowkey直接去Hbase中獲取原始數(shù)據(jù)即可。（將HBase的rowkey設(shè)定為ES的文檔ID，搜索時(shí)根據(jù)業(yè)務(wù)條件先從ES里面全文檢索出相對(duì)應(yīng)的文檔，從而獲取出文檔ID，即拿到了rowkey，再從HBase里面抽取數(shù)據(jù)。）

架構(gòu)效果

發(fā)揮了Elasticsearch的全文檢索的優(yōu)勢，能夠快速根據(jù)關(guān)鍵字檢索出相關(guān)度最高的結(jié)果；
同時(shí)減少了Elasticsearch的存儲(chǔ)壓力，這種場景下不需要存儲(chǔ)檢索無關(guān)的內(nèi)容，甚至可以禁用_source，節(jié)約一半的存儲(chǔ)空間，同時(shí)提升最少30%的寫入速度；
避免了Elasticsearch大數(shù)據(jù)量下查詢返回慢的問題，大數(shù)據(jù)量下Hbase的抽取速度明顯優(yōu)于Elasticsearch；
各取所長，發(fā)揮兩個(gè)組件各自的優(yōu)勢。

存在問題

1、兩個(gè)組件之間存在時(shí)效不一致的問題

相對(duì)而言，Elasticsearch的入庫速度肯定是要快于Hbase的，這是需要業(yè)務(wù)容忍一定的時(shí)效性，對(duì)業(yè)務(wù)的要求會(huì)比較高。

2、同時(shí)管理兩個(gè)組件增加了管理成本

顯而易見，同時(shí)維護(hù)兩套組件的成本肯定是更大的。

3、兩者的數(shù)據(jù)不一致問題

針對(duì)此項(xiàng)目，有一個(gè)核心功能點(diǎn)，如何在ES中同步對(duì)HBase中的數(shù)據(jù)建立索引？
大致有下面這幾種方案：

1：方案1

在將原始數(shù)據(jù)入庫HBase的時(shí)候，同時(shí)在ES中對(duì)數(shù)據(jù)建立索引，此時(shí)可以把入庫HBase和ES的代碼放在一個(gè)事務(wù)中，保證HBase和ES的數(shù)據(jù)一致性。

這種方案的優(yōu)點(diǎn)是操作方便，缺點(diǎn)是入庫HBase和ES的代碼綁定到一起了，耦合性太高，如果遇到ES出現(xiàn)故障，會(huì)導(dǎo)致入庫HBase的操作也會(huì)失敗，或者是ES集群壓力過大的時(shí)候，會(huì)導(dǎo)致數(shù)據(jù)入庫HBase的效率降低。

2、方案二

在將原始數(shù)據(jù)入庫HBase的時(shí)候，通過HBase中的協(xié)處理器實(shí)現(xiàn)數(shù)據(jù)同步，讓協(xié)處理器監(jiān)聽HBase中的新增和刪除操作，在協(xié)處理器內(nèi)部操作ES，實(shí)現(xiàn)對(duì)數(shù)據(jù)建立索引的功能。
HBase中的協(xié)處理器其實(shí)類似于MySQL中的觸發(fā)器。

這種方案的優(yōu)點(diǎn)是通過協(xié)處理器可以很方便的獲取到HBase中新增和變化的數(shù)據(jù)，如果入庫HBase的程序是之前已經(jīng)開發(fā)好的，此時(shí)不需要對(duì)之前的代碼進(jìn)行任何改動(dòng)，影響程度比較低。缺點(diǎn)是過于依賴HBase了，如果后期涉及到HBase集群版本升級(jí)，無法保證協(xié)處理器功能的可用性。

3、方案3

在將原始數(shù)據(jù)入庫HBase的時(shí)候，同時(shí)在Redis中使用list數(shù)據(jù)類型模擬一個(gè)隊(duì)列，存儲(chǔ)數(shù)據(jù)的Rowkey。此時(shí)將入庫HBase和Redis的操作放在一個(gè)事務(wù)里面，保證數(shù)據(jù)的一致性。然后再通過另外一個(gè)同步程序，從Redis的list隊(duì)列中讀取Rowkey，根據(jù)Rowkey到HBase中獲取數(shù)據(jù)的詳細(xì)信息，在ES中建立索引，將HBase中數(shù)據(jù)的Rowkey作為ES中數(shù)據(jù)的ID。

在這個(gè)方案里面是將入庫HBase和在ES中建立索引這兩個(gè)功能解耦了，借助于中間層的Redis實(shí)現(xiàn)的。
這種方案的缺點(diǎn)是把入庫HBase和Redis的功能耦合在一起了，但是Redis是輕量級(jí)的，出現(xiàn)問題的概率是比較低的，對(duì)性能損耗也不高，所以是可以接受的。
此時(shí)就算ES出現(xiàn)問題，只需要在同步程序內(nèi)部實(shí)現(xiàn)正常的異常處理即可，將建立索引失敗數(shù)據(jù)的Rowkey重新添加到Redis的list列表里面即可，不會(huì)導(dǎo)致HBase和ES數(shù)據(jù)不一致的問題。

使用第3種方案，可控性高一些，在項(xiàng)目中也會(huì)使用第3種方案實(shí)現(xiàn)。

四、項(xiàng)目整體執(zhí)行流程
接下來分析一下項(xiàng)目底層細(xì)節(jié)流程

如下圖所示

1：通過入庫程序向HBase中入庫數(shù)據(jù)，同時(shí)在Redis中存儲(chǔ)數(shù)據(jù)的Rowkey。

2：從Redis中獲取數(shù)據(jù)的Rowkey，根據(jù)Rowkey到HBase中查詢數(shù)據(jù)的詳細(xì)信息，然后在ES中建立索引。
此時(shí)我們的海量數(shù)據(jù)已經(jīng)存儲(chǔ)到HBase中，并且將需要查詢的字段在ES中建立索引了。

3：用戶向ES發(fā)送查詢請求。

4：ES返回符合條件的數(shù)據(jù)的ID，其實(shí)就是HBase中數(shù)據(jù)的Rowkey。在這里也可以根據(jù)需求額外再返回一些字段信息都是可以的。

5：當(dāng)用戶想要查看數(shù)據(jù)完整詳細(xì)信息的時(shí)候，需要根據(jù)Rowkey到HBase中查詢。

6：HBase會(huì)給用戶返回Rowkey對(duì)應(yīng)數(shù)據(jù)的詳細(xì)信息。

實(shí)測性能

原來只使用ElasticSearch的時(shí)候，數(shù)據(jù)只需要寫入一遍，也只需要查詢一次ES就可返回想要的數(shù)據(jù)。現(xiàn)使用了Hbase+ElasticSearch后，不僅數(shù)據(jù)需要寫入兩份，查詢也需要先查ES，然后再根據(jù)ES的查詢結(jié)果去Hbase中取數(shù)據(jù)。這樣多此一舉性能難道真的能提升嗎？

單ES架構(gòu)和Hbase+ES架構(gòu)的性能對(duì)比可由上圖直觀的展示出來：
在數(shù)據(jù)量小的時(shí)候，單ES架構(gòu)的性能是優(yōu)于Hbase+ES架構(gòu)的。
數(shù)據(jù)量過了一定量級(jí)的時(shí)候，Hbase+ES架構(gòu)的性能就遠(yuǎn)遠(yuǎn)的把單ES架構(gòu)給甩開了。

項(xiàng)目最終整體架構(gòu)

項(xiàng)目展示

地址：zjczdzs/Z-HE: 基于Elasticsearch+hbase的海量數(shù)據(jù)查詢、即時(shí)推送服務(wù)系統(tǒng) (github.com)

參考博客：
https://blog.csdn.net/mrliqifeng/article/details/111771109
https://blog.csdn.net/sdksdk0/article/details/53966430
https://blog.csdn.net/wudingmei1023/article/details/103914052
https://blog.csdn.net/weixin_40612128/article/details/123507161
https://blog.csdn.net/bxg_kyjgs/article/details/125993647文章來源地址http://www.zghlxwxcb.cn/news/detail-487043.html

到了這里，關(guān)于基于Elasticsearch與Hbase組合框架的大數(shù)據(jù)搜索引擎的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！