背景
Tablestore 啟發自 Google 的 Bigtable 論文，從2009年開始，在阿裡雲的飛天團隊内，開始萌發。經過10年的錘煉，如今在集團内，雲上積累了各式各樣的客戶和場景。這篇文章我們就來介紹下 Tablestore 大資料場景下的架構和使用者場景案例。看看自研的分布式存儲平台如何通過貼身了解客戶場景，帶來大資料架構的簡化和更新，并助力業務方最終快速落地他們的需求。
大資料系統建設中的痛
資料的産生是多式多樣，我們根據需求會選擇不同的存儲産品來存放這些資料，例如訂單資料，使用者資訊資料我們會選用一款 OLTP 資料庫，日志資料會選擇 SLS 日志服務，或者自建 ELK 的方案。又有一些資料我們希望做實時的 計算，并且在 ETL 後在進行長期存儲，這時會把資料雙寫到 Kafka，利用 Kafka 流式對接計算引擎的能力實作上面的需求。一些非結構化資料又會使用 HDFS/OSS 來進行長期存儲。這些資料從存儲到可以給計算引擎分析需要經過很長的鍊路。例如如果你選用了一款 OLTP 資料庫，你希望進行實時計算或者定期批量計算。考慮到避免影響 TP 線上業務，通常我們會把資料實時或者定期投遞出來，進入 Kafka/AP 資料庫再分别實作實時計算和批計算。投遞的過程可能會涉及到很多子產品，例如 DTS，Kafka，Spark 批計算，Spark Streaming，AP 資料倉庫。搭建一整套大資料架構（例如下圖的典型大資料 Lambda 架構），不論是對資料庫的研發同學，還是運維同學都帶來了較高的門檻。子產品多了以後，不論是維護成本還是開發成本都會相應提高。同時各個子產品的存儲，計算資源可能未必能很好的共享，比如寫入峰值到來的時候，可能我們的批計算需求并不大，但是此時批計算的叢集資源很難直接讓實時寫入層共享。反過來也一樣，批計算的峰值，Kafka的資源，ETL的資源又未必可以給批計算共享。那有沒有辦法解決這些問題？降低大資料架構的接入門檻，使用成本，提升開發效率，資源使用率呢？我們下一章來說。
典型的大資料 Lambda 架構
雲上 Tablestore 的大資料方案
在開始介紹雲上大資料架構之前，我們再看下，雙十一大促下需要的大資料架構會對存儲提出哪些具體的要求呢：
- 高吞吐，高可用的大資料架構同時滿足彈性和低成本
-
- 做為大資料架構，分析的資料通常是海量的，吞吐決定了大資料分析的時延，如果不能及時處理資料會導緻業務的決策滞後，進而讓大資料方案大打折扣。
- 高可用同樣是一個很重要的名額，往往業務上雲就是希望可以告别線下自建系統的不穩定性。
- 做為雙十一大促的主旋律，業務峰值是不可避免的，一套彈性的架構是幫助我們真正實作業務在大促下依然可以高可用，高吞吐的的利器。
- 資源成本
-
- 抛開成本談彈性都是沒有意義的，既然選擇了雲上的方案，我們自然希望可以獲得較好彈性的同時，控制成本。
- Serverless 雲原生的産品形态通常可以比較好的在具備彈性的同時控制我們的成本開銷。架構無需在業務低峰期預留很多不必要的資源來防禦業務峰值的到來。
- 生态完善
-
- 大資料架構中涉及到的概念和需求非常多，這些需求也會對應不同的計算引擎，例如 Spark，Flink，Presto 或者雲上的自研組建。存儲需要和這些組建，開源産品進行無縫打通，這樣可以降低使用的門檻。
- 除了計算引擎，資料通道鍊路的完善也很重要，例如日志類的資料和 OLTP 的資料能友善彙總，資料打寬等。
Tablestore 是一款 Serverless 雲原生存儲引擎，Serverless 相比執行個體售賣類型的産品，在業務有波峰波谷時天生就有較大的優勢，基于 bigTable 的主存儲采用行的方式進行存儲，可以支撐單表億級别的QPS。下面列了一些 Tablestore的核心特性：
Tablestore 除了有強大的主存儲滿足海量業務的實時讀寫外，基于主存儲的分布式日志提供了完整的資料派生能力（詳情
參考），海量實時寫入 Tablestore 的資料，可以實時訂閱進行消費。這樣就滿足了我們的實時計算需求。
Lambda 架構中除了實時資料寫入，實時計算之前，全量資料需要提供高性能掃描能力，Tablestore 采用行列混合，雙引擎的架構，在主存儲之外内部通過通道服務實時建構一個列存儲，支撐 PB 級别資料的高吞吐掃描。同時在海量的資料場景下，我們相信資料是需要分層存儲，是以在建構自身列存的同時，我們會幫助使用者建構推送雲上資料湖的鍊路，通過全托管的資料湖投遞，降低使用者的存儲成本。
基于 Tablestore 的 Lambda 架構
Tablestore 在專注于打造一款極緻性能和成本的存儲引擎同時，更加關注完整的計算生态，伴随産品核心功能疊代的過程中，我們和阿裡雲的幾大核心計算引擎做了完善的對接具體包括：
- MaxCompute 的對接，支援 MaxCompute 計算引擎通過外表的方式直讀寫 Tablestore
- EMR Spark 對接，支援流批源表讀，流批結果表寫，集團内第一款全 Connector 支援的 kv 存儲引擎
- Blink 對接，支援流批源表讀，流批結果表寫，維表讀，集團内第一款全 Connector 支援的 kv 存儲引擎
- DLA 對接，支援 SQL 直接讀寫 Tablestore 的資料
- FC 對接，支援流式增量觸發器
計算的結果集合需要提供豐富靈活的高并發查詢，支撐使用者生成實時大屏，報表的場景，Tablestore 通過主存儲結合豐富的索引能力以及 MPP 類型計算引擎來實作。
Tablestore Lambda架構結果集合存儲和報表展示
對 Tablestore 大資料架構感興趣的同學還可以參考之前的一些架構文章：
- 結構化大資料分析平台設計
- 資料中台之結構化大資料存儲設計
- Lambda plus: 雲上大資料解決方案
- 基于大資料的輿情分析系統架構 - 架構篇
- 通過EMR Spark Streaming實時讀取Tablestore資料
Tablestore 助力雙十一集團業務的落地
介紹完 Tablestore 結構化大資料存儲引擎的基礎能力後，來看看具體的一些雙十一集團業務架構：
實時酒店推薦
場景描述：
商家會實時的更新酒店房型庫存和報價，酒店的屬性等字段。實時選品過程針對同一個酒店不同供應商的庫存和報價進行計算和篩選，最終展示出有庫存且按照報價品質排序的清單給平台使用者，進行酒店搜尋的結果傳回
架構優勢：
- 線上和分析業務流量隔離
- 基于 Tablestore 對接流計算的便利性實作源表和維表的存儲統一
- 全鍊路延時要求高，商品價格變動後，5秒内可以回報至搜尋庫
基于 Tablestore 的酒店選品實時推薦架構
雙十一監控作戰大屏
海量的機器，業務監控秒級别資料，實時千萬級别每秒寫入流量，寫入 Tablestore 資料實時查詢和展示。跨時間的實時聚合，形成分鐘級别資料。關鍵名額的實時聚合和展示，離線批計算提供報表分析能力。
- 核心單表資料規模達 10 PB，可自定義資料生命周期
- 核心單表持續每秒寫入進 5000 萬個資料點
- 資料實時寫入，大大提升資料可見時效性
- 毫秒級實時查詢展示趨勢圖和報表，查詢性能不受單表規模限制
基于 Tablestore 時序監控大屏場景
全網爬蟲系統
海量爬蟲高并發高吞吐資料寫入，全量資料存儲，資料量達 PB 級，多類資料存儲，包含半結構化原始資料、結構化标簽資料以及分析結果資料，資料寫入後需要即時觸發資料實時處理，後續需要對接離線處理。
- 分布式 LSM 引擎資料存儲，提供高并發高吞吐寫入，PB 級資料存儲
- 通過資料更新捕獲，實時觸發後續對資料的自定義處理邏輯
- 與大資料平台實時資料同步，分析結果寫入結果表，供應用層實時查詢
基于 Tablestore 的爬蟲大資料架構
總結
随着處理資料量，處理實時性的變化，實體硬體處理能力的更新，大資料架構演進是非常迅速的。随着業務資料逐漸上雲後，大資料處理平台也必然會遷移至雲上，相比 TP 類業務，AP 類場景的業務峰值，處理資料帶寬可能會更大。我們希望合理的雲上大資料架構可以借助存儲計算分離，在可控的成本下提供更彈性的資料處理能力，解決各業務在大促到來所遇到的挑戰。也讓大資料平台的研發人員徹底從基礎運維中釋放出來，可以全身心的投入滿足業務對資料分析平台的需求。如果有興趣的同學歡迎與我們交流探讨（釘釘交流群：23307953）。
