本文主要介紹 Tablestore 在 Adhoc 分析場景下的性能測試，主要包括測試環境、測試工具、測試方案、測試結果以及測試結論等。
Tablestore 是什麼
Tablestore 啟發自 Google 的 Bigtable 論文，從2009年開始，在阿裡雲的飛天團隊内，開始孵化。經過 10 年的錘煉，如今在集團、公有雲和專有雲積累了各式各樣的客戶和場景。
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，在線上和離線兩個場景分别進行 Adhoc 分析的性能測評。
測試環境
本次測試會用到表格存儲、EMR、OSS、DLA等多個服務，以下是相關配置：
- 表格存儲
- 執行個體類型：高性能執行個體
- 執行個體地域： 華東1-杭州
- 多元索引配置：ParallelScan MaxParallel = 512
- EMR叢集
- 叢集地域：華東1-杭州
- 配置：Master (24核96GB) * 1，CORE（24核96GB） * 25
- OSS
- 地域：華東1-杭州
- DLA
測試工具
- 原始資料集
資料源選用 TPC-H 的 lineitem 表(CSV檔案)，大小為 1TB，總行數為 85 億行。
測試方案
本次性能測試将通過運作幾種典型場景的SQL查詢，來進行Adhoc查詢的性能測試。
測試範圍
- 線上場景
- Tablestore 多元索引引擎查詢，512并發。其中，Tablestore 多元索引請參考： 官方文檔 - Tablestore 多元索引
- Tablestore 表引擎查詢，1000并發
- 離線場景
- DLA + OSS
- EMR + JindoFS + OSS，開啟緩存
測試場景
- Count table: 全表count
- Key lookup: 基于主鍵的查詢
- Non-Key lookup: 非主鍵查詢
- Scan table with(/without) projection: 全表掃描
測試名額
本次測試主要包含以下幾項名額：
- SQL 執行總耗時：表示的是執行 SQL 的總時間，機關為秒(e.g. 37.122s)。其中，EMR + JindoFS + OSS方案中會開啟緩存，SQL執行耗時将會展示先後的3次查詢耗時。
- SQL 執行吞吐量：表示的是 SQL 執行時的平均處理行數，其值為 SQL 掃描行數/執行總耗時，機關為(行/s)。
測試結果
針對線上場景，我們主要通過 EMR Spark 測試通路 Tablestore 主表和多元索引的性能表現。
| 測試項 | SQL 指令 | 通路方式 | SQL 總耗時 | 吞吐量 |
|---|---|---|---|---|
| Count table | select count(*) from lineitem_index_512; | Tablestore 多元索引 | 692s | 1800萬/s |
| Tablestore 表引擎 | 1056s | 1200萬/s | ||
| Key lookup | tpch1 where l_orderkey = 1; | 1s | - | |
| 0.9s | ||||
| Non-key lookup | where l_shipdate >= '1994-05-02' and l_shipdate < '1994-11-30' and l_discount < 0.03 and l_quantity < 4; | 6s | 600萬行/s | |
| 1197s | ||||
| Scan table with projection | l_orderkey lineitem_index_512 order by l_orderkey limit 1; | 703s | ||
| 1069s | ||||
| Scan table without projection | * | 預計3200s | 260萬/s | |
| 預計1860s | 457萬/s |
-：表示該資料無法測量或者測量無意義。
Tablestore 提供資料湖投遞的能力，将主表資料同步到 OSS，以 parquet 檔案的方式存儲。詳細文檔請參考
官方文檔 - Tablestore 資料湖投遞。
利用資料湖投遞可以實作如下場景需求：
-
冷熱資料分層
資料湖投遞結合表格存儲的
資料生命周期 功能，可以快速實作 OSS 低成本存儲全量資料，表格存儲提供熱資料的低延遲查詢和分析的需求。 -
全量資料備份
資料湖投遞可以自動将表格存儲的全表資料投遞到 OSS Bucket 中，作為備份歸檔資料。
-
大規模實時資料分析
資料湖投遞可以實時（每2分鐘）投遞增量的表格存儲資料到 OSS，投遞的資料支援按系統時間分區、Parquet 列存格式存儲；再利用 OSS 的高讀帶寬和列存面向掃描場景優化實作高效實時資料分析。
-
加速 SQL 分析性能
當表格存儲資料未建立多元索引且查詢條件中不包含主鍵列的過濾條件時，可以通過資料投遞自動同步資料到 OSS，再利用 DLA+OSS 資料掃描實作 SQL 分析加速。
于是，針對離線場景，我們測試 Tablestore 資料湖方案中的查詢性能表現。
| 3s | 28億/s | |||
| EMR + jindoFS + OSS | 先後3次查詢耗時： 11s 4s 4s | 21億/s | ||
| 2s | 44億/s | |||
| 11s 3s 3s | 30億/s | |||
| 43s | 2億/s | |||
| 10s 8s 9s | 10億/s | |||
| 8s | 10億行/s | |||
| 14s 5s 4s | 21億行/s | |||
| 178s | 4775萬/s | |||
| 68s 50s 50s | 1.7億/s |
測試結論
- 時效性：秒級
- 主鍵查詢建議使用 Spark 直接查詢 Tablestore 表引擎，針對簡單查詢場景來說成本效益較高
- 非主鍵查詢，複雜查詢（如空間查詢）建議使用 Spark 查詢 Tablestore 多元索引，查詢性能比表引擎提升明顯，且支援更靈活的查詢
- 時效性：分鐘級（甚至小時級）
- 冷熱資料分層和大規模離線資料分析場景建議使用 Tablestore 資料湖投遞功能，可選用的計算引擎有 DLA 和 EMR
歡迎加入
表格存儲 Tablestore 推出了很多貼近使用者場景的文章與示例代碼，歡迎大家加入我們的釘釘公開交流群一起讨論，群号：23307953。（1 群已滿員，歡迎加入 2 群）