VLDB 2019 笔记: AnalyticDB: Real-t

2019-10-11  本文已影响0人  haitaoyao

最近开始刷 VLDB 2019 中感兴趣的 paper, 今天开始第一篇: 来自阿里云的分析性数据库 AnalyticDB

由于这是一个云厂商的商业产品, 因此写之前还是事先说明一下: 我没有用过阿里云的 AnalyticsDB 产品以及 Paper 中提到的相关产品例如 AWS 的 Redshift 和 Google 的 BigQuery; 本文中所有的观点仅代表个人, 如有不对的地方, 还请指正.

什么是 AnalyticDB

AnalyticsDB(下文简称 ADB)是一个 OLAP 数据库, 对标类似的产品是 AWS 的 Redshift/Google 的 BigQuery 或者开源的 Druid/Pinot

架构

ADB 架构, 来自 Paper 截图

ADB 的一个优势是可以实时更新数据, 因此在设计上将读写节点做了分离:

架构上来说个人认为一个大的亮点是虽然整体的数据库引擎是自研的, 但 ADB 却选择了支持 MySQL 和 PostgreSQL 两种协议, 直接享受了 MySQL 和 PostgreSQL 两个数据库相关的生态优势.

数据写入流程

第一个 Writer Node 启动后, 会作为 Master 分派后续的 Writer Worker Node. 当一个 Write 请求到达 Coordinator 后, Coordinator 先解析写入请求的 SQL 后在分配写入的节点. Writer Node 写入一定数据后再刷盘到 Pangu.

疑问 1: 如果在中途 Writer Node 停机, 是不是没有刷盘到 Pangu 的数据就丢失了?

疑问 2: 所有的写请求都通过单一的 Coordinator 做路由转发, 如果写入请求非常多(例如 paper 中提到的 handle tens of millions of online write requests per second), Coordinator 会不会成为瓶颈?

数据读取流程

数据读取流程

由于 ADB 的 table 是分区的, 因此具体数据的放置就可以实现 Storage-aware Query Optimizer.

数据分布

Reader Node 启动时会从 Pangu 拉取数据文件, 因此猜测 Reader Node 还是会通过本地盘的方式加速查询的. 实时读取时, Reader Node 会时不时从 Writer Node 拉取最新的增量数据. Reader Node 也可以设置 replication factor 来提升 concurrency 和 reliability. 每个 Reader Node
都会分别从 Writer Node 获取最新的增量数据.

疑问 3: Reader Node 是间隔多少时间拉取 Writer Node 的数据的? 这期间岂不是根本查询不到增量写入的数据? 多个 Reader Node replica 获取并构建增量数据索引, 会不会导致不同 replica 在某些情况下数据不一致(拉取增量有快有慢)?

集群管理

除了使用 Fuxi 做基础计算资源的申请外, ADB 里面还有一个 Gallardo 服务做资源分配, 据称是为了多个 ADB instance 之间采用 Control Group 做隔离.

疑问 4: 这个 Gallardo 有必要吗? 难道不是直接从 Fuxi 申请物计算资源就可以吗? 是多个 ADB instance 共用 Fuxi 分配的一台计算节点的?

存储

数据存储设计

文件格式

ADB 设计了自己的存储文件格式(Hybrid Row-Column Store):

疑问 5: 说实话, 我没看懂为啥这个 Hybrid Row-Column Store 能够同时对 OLAP 和 Point lookup 查询都有优势.

疑问 6: 如果数据量非常大而 Partition 数据量有不是足够多(比如 100TB 数据的 Table 只有 100 个 Partition), 岂不是单个 Detail 文件会很大? 这样设计在移步构建索引的时候岂不是降低了任务的并发度? 还是说构建索引的后台任务可以使用 RowGroup 切分 Detail File 提升任务并发度?

数据查询

数据查询流程

由于有数据频繁更新的场景, 因此 ADB 在数据查询上采用的是 Lambda 架构:

数据 Merge 流程

索引设计

索引是所有的数据库系统提升性能的法宝. ADB 也设计了自己的索引. 简单总结几个我能看懂的点吧:

索引大小对比

Optimizer

OLAP 数据库的查询优化器肯定是非常关键的. 可惜我在这个领域了解是在不多. 感兴趣的自己去看吧, 我就不瞎 BB 了.

测试结果

测试查询

Paper 中给出了三个测试查询(SQL 见上图), 一共有三种类型:

跟着对比的是 PrestoDB, SparkSQL, Druid 和 Greenplum

1TB 数据查询 Latency

P50 和 P95 latency

从上图可以看出, 整体的 latency ADB 都是在 1s 内返回的, 即便是 Q3 这种复杂的查询. 注意 Y 坐标轴的刻度和单位(秒).

10TB 数据查询 Latency

10TB 数据

当数据量增长到 10TB 时, 查询 P50 latency 依旧影响不太大, 结果见上图. 不过不知道为啥没有贴出 P95 的数据, 毕竟 P95 更有说服力吧.

写入性能

ADB 写入性能数据

可以看出, 基本上写入性能是跟着 Writer Node 数量线性增长的.

TPC-H 对比

TPC-H 的查询就比上面 Paper 中自己定义的三个 Query 复杂多了, 例如 TPC-H Q7 的查询如下:

select
supp_nation,
cust_nation,
l_year, sum(volume) as revenue
from (
select
n1.n_name as supp_nation,
n2.n_name as cust_nation,
extract(year from l_shipdate) as l_year,
l_extendedprice * (1 - l_discount) as volume
from
supplier,
lineitem,
orders,
customer,
nation n1,
nation n2
where
s_suppkey = l_suppkey
and o_orderkey = l_orderkey
and c_custkey = o_custkey
and s_nationkey = n1.n_nationkey
and c_nationkey = n2.n_nationkey
and (
(n1.n_name = '[NATION1]' and n2.n_name = '[NATION2]')
or (n1.n_name = '[NATION2]' and n2.n_name = '[NATION1]')
)
and l_shipdate between date '1995-01-01' and date '1996-12-31'
) as shipping
group by
supp_nation,
cust_nation,
l_year
order by
supp_nation,
cust_nation,
l_year;

感兴趣的可以自己去看看 TPC-H 规范

ADB 的 TPC-H 结果如下图(注意 Y 轴), 可以看出优势还是很明显, 超过 10 秒的查询都没有几个.

TPC-H

总结

从架构上来说, ADB 走的是 shared-storage 的路线, 大体架构跟 Azure SQL 数仓和当红炸子鸡 Snowflake 架构类似, 都是采用"无状态" 的节点实现数仓横向扩展的, 本质上说跟 Redshift 还是不一样. 对 Cloud Data Warehousing 感兴趣的同学也强烈建议去看 大神 Dr David DeWitt 的演讲: Data Warehousing in the Cloud

Azure SQL 数据仓库架构 Snowflake 架构

疑问 7: 从 Azure SQL 和 Snowflake 的架构图看, 二者都是采用云服务的 Object Storage 作为 shared-storage 架构中的 Storage 选型的, 那么为何 ADB 没有直接使用 OSS 而是选择了 Pangu?

个人认为, ADB 这个架构设计上最大的亮点就是既然都徒手撸了一个 OLAP 数据库了, 还选择了支持 MySQL 和 PostgreSQL 两种最为广泛的协议, 而不是安耐不住自己设计了一个协议然后再苦哈哈的去构建所谓的生态. 原因很简单: MySQL 协议和 PostgreSQL 协议应该算是这个领域使用最为广泛的, 支持这两种协议, 用户就可以有大量的生态体系中的工具或则其他产品整合, 大为降低了 ADB 的使用门槛. 反观 Snowflake, 几乎是为主流语言都开发了 SDK, 也不知道这满满一屏幕的产品是如何被 Snowflake 拿下的.

Snowflake ecosystem Overview Snowflake 官网关于 SDK 截图

Reference:

上一篇 下一篇

猜你喜欢

热点阅读