TableStore:爬虫数据存储和查询利器
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:爬虫数据存储和查询利器的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 一次开发、多端分发,阿里巴巴发布AliO
- 下一篇: 阿里云参加ONS EU 2018,飞天洛