摘要：今天我們來介紹一下基于阿里云表格存儲，以及相關(guān)的大數(shù)據(jù)產(chǎn)品來采集與分析數(shù)據(jù)的方案。我們嘗試一種基于和阿里云其他大數(shù)據(jù)產(chǎn)品的新方案，我們先看架構(gòu)圖圖中關(guān)鍵路徑分析頁等客戶端先通過埋點系統(tǒng)收集數(shù)據(jù)，然后通過表格存儲的將數(shù)據(jù)寫入的原始數(shù)據(jù)表。

摘要： 摘要 在互聯(lián)網(wǎng)高度發(fā)達的今天，ipad、手機等智能終端設(shè)備隨處可見，運行在其中的APP、網(wǎng)站也非常多，如何采集終端數(shù)據(jù)進行分析，提升軟件的品質(zhì)非常重要，例如PV/UV統(tǒng)計、用戶行為數(shù)據(jù)統(tǒng)計與分析等。雖然場景簡單，但是數(shù)據(jù)量大，對系統(tǒng)的吞吐量、實時性、分析能力、查詢能力都有較高的要求，搭建起來并不容易。

摘要

在互聯(lián)網(wǎng)高度發(fā)達的今天，ipad、手機等智能終端設(shè)備隨處可見，運行在其中的APP、網(wǎng)站也非常多，如何采集終端數(shù)據(jù)進行分析，提升軟件的品質(zhì)非常重要，例如PV/UV統(tǒng)計、用戶行為數(shù)據(jù)統(tǒng)計與分析等。雖然場景簡單，但是數(shù)據(jù)量大，對系統(tǒng)的吞吐量、實時性、分析能力、查詢能力都有較高的要求，搭建起來并不容易。今天我們來介紹一下基于阿里云表格存儲，以及相關(guān)的大數(shù)據(jù)產(chǎn)品來采集與分析數(shù)據(jù)的方案。

TableStore

TableStore(表格存儲)是阿里云自主研發(fā)的專業(yè)級分布式NoSQL數(shù)據(jù)庫，是基于共享存儲的高性能、低成本、易擴展、全托管的半結(jié)構(gòu)化數(shù)據(jù)存儲平臺，支撐互聯(lián)網(wǎng)和物聯(lián)網(wǎng)數(shù)據(jù)的高效計算與分析。

目前不管是阿里巴巴集團內(nèi)部，還是外部公有云用戶，都有成千上萬的系統(tǒng)在使用。覆蓋了重吞吐的離線應(yīng)用，以及重穩(wěn)定性，性能敏感的在線應(yīng)用。表格存儲的具體的特性可以看下面這張圖片。

基于TableStore的數(shù)據(jù)采集分析系統(tǒng)

一個典型的數(shù)據(jù)采集分析統(tǒng)計平臺，對數(shù)據(jù)的處理，主要由如下五個步驟組成：

對于上圖流程的具體實現(xiàn)，網(wǎng)上有許多可以參考的案例，數(shù)據(jù)在客戶端采集完以后，如果量比較小，我們可能直接在后端的API上做一次透傳，然后持久化到RDBMS類型的數(shù)據(jù)庫中就好了，通過Sql可以進行數(shù)據(jù)分析。如果數(shù)據(jù)量很大，就需要一些中間件來輔助收集和上傳，然后分別將數(shù)據(jù)寫入到在線和離線的系統(tǒng)中，比如先上傳到Flume，F(xiàn)lume可以做數(shù)據(jù)的采集與聚合，再將Flume作為消息的生產(chǎn)者，將生產(chǎn)的消息數(shù)據(jù)通過Kafka Sink發(fā)布到Kafka中，Kafka作為消息隊列的角色，可以對接后端的在線和離線計算平臺。如下圖所示：

引入Flume和Kafka的原因有很多，比如他們可以處理大流量的數(shù)據(jù)、做數(shù)據(jù)聚合、保證數(shù)據(jù)不丟失等，但最關(guān)鍵的原因是他們擁有高吞吐的能力。引入的組件多，系統(tǒng)的復(fù)雜性和成本也會相應(yīng)的增加，上圖中，Spark Streaming/Storm分析完成以后，結(jié)果數(shù)據(jù)還需要引入另外的存儲組件進行存儲，比如HBase/MySQL，如果引入MySQL可能還需要再引入Redis做熱點數(shù)據(jù)緩存，這樣一來就更加復(fù)雜了。
我們嘗試一種基于TableStore和阿里云其他大數(shù)據(jù)產(chǎn)品的新方案，我們先看架構(gòu)圖：

圖中關(guān)鍵路徑分析：
1、Web頁、APP等客戶端先通過埋點系統(tǒng)收集數(shù)據(jù)，然后通過表格存儲的SDK將數(shù)據(jù)寫入TableStore的原始數(shù)據(jù)表。
2、MaxCompute直讀TableStore原始數(shù)據(jù)表的數(shù)據(jù)進行分析，然后QuickBI讀取MaxCompute的數(shù)據(jù)進行展示，具體操作可參考：MaxCompute直讀直寫表格存儲、QuickBI新建云數(shù)據(jù)源。
3、TableStore原始數(shù)據(jù)表中的數(shù)據(jù)可增量同步到ElasticSearch或者openSearch中，同步方法參考：TableStore數(shù)據(jù)同步到ElasticSearch，TableStore數(shù)據(jù)同步到OpenSearch。
4、TableStore中的數(shù)據(jù)可增量同步到Blink/Flink進行分析，分析完以后的數(shù)據(jù)再寫回TableStore的結(jié)果數(shù)據(jù)表中，DavaV讀取結(jié)果數(shù)據(jù)表的數(shù)據(jù)進行展示。

新架構(gòu)優(yōu)勢分析：
1、客戶端數(shù)據(jù)直讀直寫TableStore，不需要再引入API層進行數(shù)據(jù)透傳，降低了復(fù)雜度，對于大型應(yīng)用來說也減少了不少的服務(wù)器成本。
2、TableStore已經(jīng)對接了豐富了大數(shù)據(jù)組件，包括阿里云的大數(shù)據(jù)產(chǎn)品和開源大數(shù)據(jù)產(chǎn)品，數(shù)據(jù)的同步與讀寫非常容易。
3、實時分析與離線分析后的結(jié)果數(shù)據(jù)再寫回TableStore，DataV直接讀取結(jié)果數(shù)據(jù)進行展示，因為TableStore具備高性能與高吞吐特點，不需要再引入Redis等緩存組件，可以簡化整個系統(tǒng)。

直讀直寫安全問題：
關(guān)于數(shù)據(jù)直讀直寫TableStore，大家可能都會想到一個安全的問題，客戶端直連TableStore不是要把AccessKey和AccessId暴露在客戶端嗎？答案是不用，我們使用STSToken授權(quán)訪問TableStore，過程如下圖所示：

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

瀏覽器跨域訪問TableStore：
如果在瀏覽器端直接訪問TableStore，由于瀏覽器有同源策略的限制，會產(chǎn)生跨域問題。因為TableStore的EndPoint域名與用戶Web站點的域名不同。解決這個問題的思路有兩個：一是Web端不直接訪問TableStore，改為先請求自己的Web Server端，Web Server端再使用TableStore SDK來發(fā)起請求，這樣其實就是后端訪問了，問題解決了但也沒了我們直讀直寫的優(yōu)勢；二是TableStore服務(wù)端通過某種方式直接支持js跨域請求，這條路我們正在支持當(dāng)中，當(dāng)前處于開發(fā)階段，支持的方式是cors協(xié)議支持跨域。但目前也有快捷的支持方式，如果您有瀏覽器直接訪問TableStore的需求，可以直接聯(lián)系我們，支持起來也很快。
作者：boxiao