本文主要介绍 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 群）