本文主要介绍 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
- 地域：华东1-杭州

测试工具

原始数据集

数据源选用 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	select count(*) from tpch1 where l_orderkey = 1;	Tablestore 多元索引	1s	-
		Tablestore 表引擎	0.9s	-
Non-key lookup	select count(*) from tpch1 where l_shipdate >= '1994-05-02' and l_shipdate < '1994-11-30' and l_discount < 0.03 and l_quantity < 4;	Tablestore 多元索引	6s	600万行/s
		Tablestore 表引擎	1197s	1200万/s
Scan table with projection	select l_orderkey from lineitem_index_512 order by l_orderkey limit 1;	Tablestore 多元索引	703s	1200万/s
		Tablestore 表引擎	1069s	1200万/s
Scan table without projection	select * from tpch1 order by l_orderkey limit 1;	Tablestore 多元索引	预计3200s	260万/s
		Tablestore 表引擎	预计1860s	457万/s

-：表示该数据无法测量或者测量无意义。

离线场景

Tablestore 提供数据湖投递的能力，将主表数据同步到 OSS，以 parquet 文件的方式存储。详细文档请参考官方文档 - Tablestore 数据湖投递。
利用数据湖投递可以实现如下场景需求：

冷热数据分层
数据湖投递结合表格存储的数据生命周期功能，可以快速实现 OSS 低成本存储全量数据，表格存储提供热数据的低延迟查询和分析的需求。
全量数据备份
数据湖投递可以自动将表格存储的全表数据投递到 OSS Bucket 中，作为备份归档数据。
大规模实时数据分析
数据湖投递可以实时（每2分钟）投递增量的表格存储数据到 OSS，投递的数据支持按系统时间分区、Parquet 列存格式存储；再利用 OSS 的高读带宽和列存面向扫描场景优化实现高效实时数据分析。
加速 SQL 分析性能
当表格存储数据未建立多元索引且查询条件中不包含主键列的过滤条件时，可以通过数据投递自动同步数据到 OSS，再利用 DLA+OSS 数据扫描实现 SQL 分析加速。

于是，针对离线场景，我们测试 Tablestore 数据湖方案中的查询性能表现。

测试项	SQL 命令	访问方式	SQL 总耗时	吞吐量
Count table	select count(*) from lineitem_index_512;	DLA + OSS	3s	28亿/s
		EMR + jindoFS + OSS	先后3次查询耗时： 11s 4s 4s	21亿/s
Key lookup	select count(*) from tpch1 where l_orderkey = 1;	DLA + OSS	2s	44亿/s
		EMR + jindoFS + OSS	11s 3s 3s	30亿/s
Non-key lookup	select count(*) from tpch1 where l_shipdate >= '1994-05-02' and l_shipdate < '1994-11-30' and l_discount < 0.03 and l_quantity < 4;	DLA + OSS	43s	2亿/s
		EMR + jindoFS + OSS	10s 8s 9s	10亿/s
Scan table with projection	select l_orderkey from lineitem_index_512 order by l_orderkey limit 1;	DLA + OSS	8s	10亿行/s
		EMR + jindoFS + OSS	14s 5s 4s	21亿行/s
Scan table without projection	select * from tpch1 order by l_orderkey limit 1;	DLA + OSS	178s	4775万/s
		EMR + jindoFS + OSS	68s 50s 50s	1.7亿/s