TableStore是阿里云自研的在線數據平臺，提供高可靠的存儲，實時和豐富的查詢功能，適用于結構化、半結構化的海量數據存儲以及各種查詢、分析。

爬蟲數據特點

在眾多大數據場景中，爬蟲類型的數據非常適合存儲在TableStore。主要是因為爬蟲類型數據的一些特征和TableStore和匹配：

數據量大

爬蟲數據一般都是抓取的互聯網上的某個行業或領域的數據，數據規模和這個行業的數據規模有關，比如資訊類，每時每刻都在產生大量新聞報道，這個數據規模可能在10 TB到100 TB級別，如果考慮到歷史存量數據，那么規模可能會更大。這么大量的數據存儲已經不適合用單機的關系型數據庫了，也不適合分庫分表了，而需要一款分布式NoSQL數據庫，這樣可以將數據按一定的路由規則分布到不同機器上，實現自動的水平擴展，非常適合存儲海量數據，尤其是爬蟲類。

寬行和稀疏列

爬蟲的數據一般來源于多個數據源，比如資訊數據可以來自人民網、新浪或者騰訊，每個數據源的數據特征不可能完全一樣，每家有每家的特殊性，這樣就會出現每一行數據的屬性列有差異，雖然可以歸一化處理后，可以將通用的屬性列統一，但是不同數據源還是會存在一定差異性。如果為每個數據源建立一張表，那么工作量就會非常大，也不適合。這時候，就需要用到寬行和稀疏列功能，既能保證列數無上限，也能保證不同行不同列，還可以不額外增加存儲成本和運維成本。

查詢類型多樣

爬蟲數據的存儲后，一般有兩個出口，一個是數據處理程序，數據處理程序會讀取最新的爬蟲數據，然后按照自定義的處理邏輯做數據加工，處理完后會新數據寫入原表或新表。

數據處理完之后，數據可以提供給下游企業客戶或終端用戶使用了，場景的查詢需求有下列幾種：

• 多種屬性列組合查詢。比如全網簡歷信息里面，通過年齡、學歷、專長查詢，且每個人查詢的條件可能都完全不一樣，需要多種屬性列的自由組合查詢。
• 分詞查詢。不管是咨詢類，還是簡歷類，都有大量的文本描述，這部分內容都需要支持分詞后再查詢。
• 排序能力。比如資訊類數據中，查詢某個新聞后，需要按時間逆序返回，越新的數據價值越大。
• 隨機讀能力。如果是用來做全局數據分析或處理，那么隨機讀是一種必須要有的能力。
• 輕量級統計分析。比如資訊類，想查看某個熱點新聞的傳播時間段和趨勢，就需要統計每個時間段的此類新聞出現次數。
  這些查詢能力，在傳統的關系型數據庫或者開源NoSQL中都無法提供。

開源解決方案

爬蟲數據存儲的方案已經演進了將近二十年了，千奇百怪的各種方案都有，主要的差異來源于兩點：

• 當前能獲取到的存儲系統能力。
• 自身對系統可靠性、可用性的要求高低。
  我們下面以當前業界流行的開源系統為材料，打造一個爬蟲數據存儲的系統。

當前業內的開源存儲系統有兩大類，一類是開源的關系型數據庫，比如MySQL等，一類是NoSQL，比如HBase等。這兩類數據存儲系統都不能支持分詞查詢，那么還需要一個全文檢索的系統，當前可選的有solr和Elasticsearch。

基于上述的素材，我們就可以搭建一個存儲爬蟲的系統了：

• 首先，選擇存儲系統，MySQL和HBase都可以，如果使用MySQL，則需要分庫分表，兩者架構圖差不多，這里我們就選擇HBase。
• 再次，選擇查詢系統，可選的solr和Elasticsearch，雖然是同一類型系統，但是Elasticsearch的目前更流行，那我們也選擇Elasticsearch。
  這樣，架構圖大致如下：

大概解釋下：

• 流程：爬蟲系統將抓取的數據寫入HBase離線集群，然后數據處理系統周期性或流式的處理新到的數據，將處理后的結果寫入HBase在線集群。HBase在線集群存儲所有屬性列的值，然后將需要查詢的列通過co-processor發送給消息隊列，最后再將消息隊列中的數據被Elasticsearch消費，生成索引。最后，用戶通過索引查詢到PK，然后通過proxy到HBase在線集群讀取這一行完整數據，最后返回給用戶。
• 數據存儲集群有兩個，一個是在線集群，一個是離線集群，原因是為了避免減少離線集群對在線查詢的影響，因為離線系統重吞吐，而在線系統重延遲，所以，這里會分成兩個集群，目的是挺高系統可用性。
• 消息隊列的目的是削峰填谷，減少對下游系統：Elasticsearch的壓力，同時當Elasticsearch寫入慢或者出故障后，不至于影響上游系統，目的也是為了提高系統可用性，避免單點故障導致整個系統雪崩。
• Proxy的目的是減輕客戶端工作量，提高易用性的工具，原因是爬蟲數據是系數列，這些列不可能全部都在Elasticsearch中創建索引，只有部分需要查詢、分析的屬性列才會在Elasticsearch中建立索引，但是查詢的時候也需要未建立索引的字段，這樣就需要一個系統做反查和合并，就是先查Elasticsearch獲取到PK，然后通過PK到HBase在線集群查詢這一行完整數據。
• 這個系統中，需要運維6個不同開源系統，運維壓力比較大。

TableStore云解決方案

最開始，我們說TableStore很適合存儲爬蟲數據，在介紹了開源系統的解決方案后，我們再來看一下TableStore的解決方案，以及相對于開源系統，可以為客戶帶來的收益。

也先看一下架構圖：

大概解釋下：

• 爬蟲系統抓取的數據寫入TableStore的離線表，然后經過TunnelService的流式通道，數據進入數據處理系統做處理加工，再將加工后的數據寫入在線表，用戶直接查詢在線表即可。
• 將離線表和在線表同時放在TableStore服務中，會不會出現離線表干擾在線表的情況？這個不會的，TableStore服務內部有自動的負載均衡和隔離系統，會自動處理這些問題。
• 所有的查詢都可以直接查詢在線表及其索引，提供了多字段組合查詢、分詞查詢、排序和統計分析等功能，完全可以滿足用戶對查詢的需求。
• 數據處理部分一般有兩種處理方式，一種是離線全量處理，這種可以使用阿里云的MaxCompute系統，MaxCompute可以直讀TableStore的數據做計算，不需要額外把數據導過去。另一種是流式實時處理，TableStore提供了TunnelService系統，可以獲取到實時的Table中的數據更新記錄，然后將更新記錄發送到函數計算、流式計算系統，或者自己的應用、flink等系統處理。
• 這個架構中，用戶只需要運維2個系統即可。

示例

我們接下來舉一個簡歷類爬蟲數據存儲和查詢的示例，幫忙讀者快速理解。

簡歷一般是一個PDF文檔或者doc文檔，是一個文件，但是我們可以從這些文件中抽取出結構化的信息，比如姓名、電話號碼、身份證、郵箱、畢業學校、學歷、專業領域、項目經驗、興趣、期望薪水和工作年限等。

首先，我們設計TableStore中主表結構：

主鍵列屬性列屬性列屬性列屬性列屬性列屬性列屬性列屬性列屬性列

身份證	姓名	電話號碼	郵箱	畢業學校	學歷	專業領域	項目經驗	興趣	期望薪水	工作年限
String	String	String	String	String	String	String	String	String	Long	Double
61xxx5	王一	152xxx7	aa@xx.com	MIT	碩士	[數據庫，MySQL]	1.數據庫binlog優化。	[足球]	20000	3.5

大概解釋下：

• 主鍵列需要一個唯一值，用來唯一確定某個人，這里我們用了身份證，有些場景獲取不到身份證，那可以用手機號或其他ID。
• 后面幾個全部是屬性列，包括姓名，電話號碼等。期望薪水因為都是整數，所以可以選擇Long類型，工作年限由于有小數，所以可以是Double類型。
• 通過這張表，我們可以通過身份證，查詢到該用戶的詳細信息。但是無法通過屬性列查詢，如果需要通過屬性列查詢，則需要創建多元索引。

然后，我們再創建多元索引，多元索引的結構如下:

屬性列屬性列屬性列屬性列屬性列屬性列屬性列屬性列屬性列

姓名	電話號碼	畢業學校	學歷	專業領域	項目經驗	興趣	期望薪水	工作年限
Text：單字分詞	Keyword	Keyword	Keyword	Keyword Array	Text：多層語義	Keyword Array	Long	Double

解釋下：

• 上面的多元索引結構中包括9列，比Table中少了2列，是因為不需要通過“郵箱”和“身份證”兩個屬性列查詢，所以，在建立index的時候就不需要為這兩列創建index了。但是如果業務中確實需要通過郵箱查詢，那么多元索引創建時加上郵箱即可。
• 姓名的類型是Text：單字分詞，意思是類型是Text，分詞是單子分詞，這樣好處就是我可以通過搜索“小剛”搜索到“王小剛”、“馮小剛”等。
• 電話號碼、畢業院校、學歷都是Keyword類型（對應Table中的String），因為這些都字符串都比較短，且查詢方式是直接完全匹配或者前綴查詢，那么用String就可以了。
• 專業領域和項目經驗兩個屬性列是Keyword Array的，因為是這兩個屬性列中會包括多個值，查詢的時候只要有一個滿足就可以返回，比如某個人的專業領域是：數據庫、MySQL，那么我們查詢“數據庫”的時候，希望這個人返回。
• 期望薪水和工作年限是數字類型的Long和Double，這樣這兩個屬性列就可以支持范圍查找，比如查找工作年限大于2年，小于5年，且期望薪水小于2萬的簡歷。

至此，我們就把簡歷庫的table和index都建好了，用戶就可以往Table中開始寫數據，數據寫入后會異步同步到Index中，這樣就可以通過Index查詢了。

總結

使用TableStore解決方案后，相對于開源解決方案，可以帶來不少的收益：

減少運維負擔

使用開源系統的架構中，需要運維6個系統，包括了3個開源系統：HBase、Kafka和Elasticsearch，為了運維這三個開源系統，需要有人對這三個系統比較熟悉，否則很難運維好。就算比較熟悉，也很難處理線上遇到的所有的問題，總會碰到無法解決的棘手問題而影響生產環境。

如果使用了TableStore云解決方案，那么就不需要運維任何開源系統，只需要運維自己開發的兩個系統，同時關注TableStore中的兩個表就可以了，這兩張表的運維全部是TableStore服務負責，且提供SLA保障，絕對比自己運維開源系統的可用性要高。

同時，采用TableStore方案后，由于TableStore支持實時自動擴容，客戶不再需要提前規劃水位和集群容量，也不用擔心高水位和突發流量對系統的沖擊，將這些工作都交給了更擅長的云服務處理。

這樣，不僅降低了運維的工作量和壓力，同時也降低了系統風險，提高了系統整體的可用性。

減少時間成本

TableStore云架構方案相對于開源方案，系統更少，從零開始到上線需要的開發時間更少，同時，TableStore是serverless的云服務，全球多個區域即開即用，可以大大降低客戶的開發上線的時間，提前將產品推出，搶先爭取市場領先優勢。

同時，TableStore支持按量付費，用戶完全可以根據真實使用量付費，不再需要擔心低峰期系統資源的浪費了，一定程度上，也能降低使用成本。

最后

目前，已經有不少行業的客戶在使用TableStore存儲爬蟲數據，比如資訊類、生活類、文章類等等，也有部分用戶在小數據量級時使用MySQL等關系型數據庫，等數據規模大了后被迫遷移到TableStore存儲。同時歡迎更多的客戶開始使用TableStore存儲你們的爬蟲數據。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的TableStore：爬虫数据存储和查询利器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。