Tablestore Adhoc 分析性能测试白皮书

2021-08-05 06:28:33

本文主要介绍 Tablestore 在 Adhoc 分析场景下的性能测试，主要包括测试环境、测试工具、测试方案、测试结果以及测试结论等。

Tablestore 是什么

Tablestore 启发自 Google 的 Bigtable 论文，从2009年开始，在阿里云的飞天团队内，开始孵化。经过 10 年的锤炼，如今在集团、公有云和专有云积累了各式各样的客户和场景。

Tablestore 是一款 Serverless 云原生存储引擎，Serverless 相比实例售卖类型的产品，在业务有波峰波谷时天生就有较大的优势，基于 Bigtable 的主存储采用行的方式进行存储，可以支撑单表亿级别的 QPS。下面列了一些 Tablestore 的核心特性：

Tablestore Adhoc 分析性能测试白皮书

Tablestore 除了有强大的主存储满足海量业务的实时读写外，基于主存储的分布式日志提供了完整的数据派生能力（详情参考），海量实时写入 Tablestore 的数据，可以实时订阅进行消费。这样就满足了我们的实时计算需求。

Lambda 架构中除了实时数据写入，实时计算之前，全量数据需要提供高性能扫描能力，Tablestore 采用行列混合，双引擎的架构，在主存储之外内部通过通道服务实时构建一个列存储，支撑 PB 级别数据的高吞吐扫描。同时在海量的数据场景下，我们相信数据是需要分层存储，所以在构建自身列存的同时，我们会帮助用户构建推送云上数据湖的链路，通过全托管的数据湖投递，降低用户的存储成本。

Tablestore Adhoc 分析性能测试白皮书

基于 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查询的性能测试。

测试范围

  • 在线场景

  • 离线场景

    • 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 Adhoc 分析性能测试白皮书

于是，针对离线场景，我们测试 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

测试结论

在线场景

  • 时效性：秒级

  • 主键查询建议使用 Spark 直接查询 Tablestore 表引擎，针对简单查询场景来说性价比较高

  • 非主键查询，复杂查询（如空间查询）建议使用 Spark 查询 Tablestore 多元索引，查询性能比表引擎提升明显，且支持更灵活的查询

离线场景

  • 时效性：分钟级（甚至小时级）

  • 冷热数据分层和大规模离线数据分析场景建议使用 Tablestore 数据湖投递功能，可选用的计算引擎有 DLA 和 EMR

欢迎加入

表格存储 Tablestore 推出了很多贴近用户场景的文章与示例代码，欢迎大家加入我们的钉钉公开交流群一起讨论，群号：23307953。（1 群已满员，欢迎加入 2 群）

Tablestore Adhoc 分析性能测试白皮书

上一篇：云原生大数据架构中实时计算维表和结果表的选型实践


下一篇：JavaScript：Array 对象