本文主要介绍 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等多个服务，以下是相关配置：
测试工具
数据源选用 TPC-H 的 lineitem 表(CSV文件)，大小为 1TB，总行数为 85 亿行。
测试方案
本次性能测试将通过运行几种典型场景的SQL查询，来进行Adhoc查询的性能测试。
测试范围
-
在线场景
-
离线场景
-
DLA + OSS
-
EMR + JindoFS + OSS，开启缓存
测试场景
测试指标
本次测试主要包含以下几项指标：
测试结果
在线场景
针对在线场景，我们主要通过 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 |
测试结论
在线场景
离线场景
欢迎加入
表格存储 Tablestore 推出了很多贴近用户场景的文章与示例代码，欢迎大家加入我们的钉钉公开交流群一起讨论，群号：23307953。（1 群已满员，欢迎加入 2 群）
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
