基於TableStore的數據採集分析系統介紹

摘要： 摘要 在互聯網高度發達的今天，ipad、手機等智能終端設備隨處可見，運行在其中的APP、網站也很是多，如何採集終端數據進行分析，提高軟件的品質很是重要，例如PV/UV統計、用戶行爲數據統計與分析等。雖然場景簡單，可是數據量大，對系統的吞吐量、實時性、分析能力、查詢能力都有較高的要求，搭建起來並不容易。

摘要

在互聯網高度發達的今天，ipad、手機等智能終端設備隨處可見，運行在其中的APP、網站也很是多，如何採集終端數據進行分析，提高軟件的品質很是重要，例如PV/UV統計、用戶行爲數據統計與分析等。雖然場景簡單，可是數據量大，對系統的吞吐量、實時性、分析能力、查詢能力都有較高的要求，搭建起來並不容易。今天咱們來介紹一下基於阿里雲表格存儲，以及相關的大數據產品來採集與分析數據的方案。

TableStore

TableStore(表格存儲)是阿里雲自主研發的專業級分佈式NoSQL數據庫，是基於共享存儲的高性能、低成本、易擴展、全託管的半結構化數據存儲平臺，支撐互聯網和物聯網數據的高效計算與分析。

目前不論是阿里巴巴集團內部，仍是外部公有云用戶，都有成千上萬的系統在使用。覆蓋了重吞吐的離線應用，以及重穩定性，性能敏感的在線應用。表格存儲的具體的特性能夠看下面這張圖片。

基於TableStore的數據採集分析系統

一個典型的數據採集分析統計平臺，對數據的處理，主要由以下五個步驟組成：

對於上圖流程的具體實現，網上有許多能夠參考的案例，數據在客戶端採集完之後，若是量比較小，咱們可能直接在後端的API上作一次透傳，而後持久化到RDBMS類型的數據庫中就行了，經過Sql能夠進行數據分析。若是數據量很大，就須要一些中間件來輔助收集和上傳，而後分別將數據寫入到在線和離線的系統中，好比先上傳到Flume，Flume能夠作數據的採集與聚合，再將Flume做爲消息的生產者，將生產的消息數據經過Kafka Sink發佈到Kafka中，Kafka做爲消息隊列的角色，能夠對接後端的在線和離線計算平臺。以下圖所示：

引入Flume和Kafka的緣由有不少，好比他們能夠處理大流量的數據、作數據聚合、保證數據不丟失等，但最關鍵的緣由是他們擁有高吞吐的能力。引入的組件多，系統的複雜性和成本也會相應的增長，上圖中，Spark Streaming/Storm分析完成之後，結果數據還須要引入另外的存儲組件進行存儲，好比HBase/MySQL，若是引入MySQL可能還須要再引入Redis作熱點數據緩存，這樣一來就更加複雜了。
咱們嘗試一種基於TableStore和阿里雲其餘大數據產品的新方案，咱們先看架構圖：

圖中關鍵路徑分析：
一、Web頁、APP等客戶端先經過埋點系統收集數據，而後經過表格存儲的SDK將數據寫入TableStore的原始數據表。
二、MaxCompute直讀TableStore原始數據表的數據進行分析，而後QuickBI讀取MaxCompute的數據進行展現，具體操做可參考：MaxCompute直讀直寫表格存儲、QuickBI新建雲數據源。
三、TableStore原始數據表中的數據可增量同步到ElasticSearch或者openSearch中，同步方法參考：TableStore數據同步到ElasticSearch，TableStore數據同步到OpenSearch。
四、TableStore中的數據可增量同步到Blink/Flink進行分析，分析完之後的數據再寫回TableStore的結果數據表中，DavaV讀取結果數據表的數據進行展現。

新架構優點分析：
一、客戶端數據直讀直寫TableStore，不須要再引入API層進行數據透傳，下降了複雜度，對於大型應用來講也減小了很多的服務器成本。
二、TableStore已經對接了豐富了大數據組件，包括阿里雲的大數據產品和開源大數據產品，數據的同步與讀寫很是容易。
三、實時分析與離線分析後的結果數據再寫回TableStore，DataV直接讀取結果數據進行展現，由於TableStore具有高性能與高吞吐特色，不須要再引入Redis等緩存組件，能夠簡化整個系統。

直讀直寫安全問題：
關於數據直讀直寫TableStore，你們可能都會想到一個安全的問題，客戶端直連TableStore不是要把AccessKey和AccessId暴露在客戶端嗎？答案是不用，咱們使用STSToken受權訪問TableStore，過程以下圖所示：

TableStore提供的SDK都支持使用STS受權的方式進行訪問，示例可參考TableStore NodeJs SDK使用STSToken，使用STS方式訪問TableStore須要控制好受權策略，客戶端不須要的接口請不要受權。

瀏覽器跨域訪問TableStore： 若是在瀏覽器端直接訪問TableStore，因爲瀏覽器有同源策略的限制，會產生跨域問題。由於TableStore的EndPoint域名與用戶Web站點的域名不一樣。解決這個問題的思路有兩個：一是Web端不直接訪問TableStore，改成先請求本身的Web Server端，Web Server端再使用TableStore SDK來發起請求，這樣其實就是後端訪問了，問題解決了但也沒了咱們直讀直寫的優點；二是TableStore服務端經過某種方式直接支持js跨域請求，這條路咱們正在支持當中，當前處於開發階段，支持的方式是cors協議支持跨域。但目前也有快捷的支持方式，若是您有瀏覽器直接訪問TableStore的需求，能夠直接聯繫咱們，支持起來也很快。 做者：boxiao