共计 3691 个字符，预计需要花费 10 分钟才能阅读完成。
简介：本篇内容为 2021 云栖大会 - 云原生数据仓库 AnalyticDB 技术与实际峰会分论坛中，阿里云数据库资深技术专家 姚奕玮对于“AnalyticDB MySQL 离在线一体化技术揭秘”的分享。
本篇内容将通过三个局部来介绍 AnalyticDB MySQL 离在线一体化技术。
一、传统大数据架构面临的问题和挑战
二、云原生数据仓库的架构与弹性
三、云原生数据仓库诊断和运维
一、传统大数据架构面临的问题和挑战
传统大数据架构面临的挑战和问题次要有：第一，数据散乱、不统一，没有一套对立的系统对这些数据进行剖析。第二，剖析不实时，个别会在夜间 12 点后对数据进行 ETL 荡涤和转换，数据直到第二天的早上能力被查问到，数据时效性差。第三，零碎简单，为了解决数据时效性差的问题，个别的做法是在批处理上又引入了流式计算的引擎，造成驰名的 lambda 架构，让整套零碎变得越来越简单。第四，高学习老本。业余的研发人员是非常少的，导致他们的工资十分高，所以要保护这一套零碎的老本也十分高。
二、云原生数据仓库的架构与弹性
为了解决以上问题，咱们构建这套离在线一体的架构。咱们的愿景是：让用户会用数据库就会用大数据。第一，是咱们是高度兼容 MySQL，咱们对 MySQL 的兼容超过了 99%。AnalyticDB MySQL 是一个云原生的架构，并且是存储计算拆散的，存储计算能够别离扩缩容。咱们用一套存储系统反对了实时写入以及多维的剖析，并且通过智能索引来反对任意维度的剖析。除此之外，咱们具备例如审计、自建账号等齐备的企业级的能力以及整套的备份还原能力。你如果误删了数据，AnalyticDB 能够把数据闪回到你想要的工夫点上。最初，咱们的交融的计算引擎在同一套架构外面同时反对了离线和在线、结构化和非结构化数据的查问。
云原生数据仓库 AnalyticDB 的整个架构分为三层，最下面的是接入层，它负责生成一个执行打算，并且咱们的优化器会优化这个执行打算、产生最终最优的物理打算、切分打算并且下发到计算层进行执行。整个数据的存储，咱们是分为两级分区。一级分区，把数据打散在各个分片下面，保障了整个零碎的程度扩大能力。第二局部提供了用户自定义的二级分区。你能够依照工夫来分区，比方依照天或者小时来进行分区。咱们的计算引擎也会主动依据这些分区来做分区裁剪。整个存储引擎反对强统一的实时增删改，你能够高并发的写入这些数据，并且数据写入后实时可见。与此同时，咱们的计算引擎还反对混合负载。
如果用户须要一个离在线一体化的零碎的话，须要哪些性能？第一个，你须要有反对多维分析以及 ETL 的能力。同时，必须反对数据的明细查问和检索。最初，你还要反对实时的高吞吐的查问和写入。这三个需要的交加就是 AnalyticDB 想要做到的局部。咱们通过反对混合负载的交融计算引擎来做到高性能的查问；咱们通过行列混存以及深度优化的写入形式来达到高并发以及高吞吐的写入；而后咱们通过智能索引来做到明细的查问以及数据内文本的检索。
接下来看一看咱们具体是怎么做的。首先是写入局部，离在线一体化的写入局部有两个需要。第一，高并发的数据流式地写入。第二，对于曾经有的存量数据，可能高吞吐的把它导入到 AnalyticDB 里边。右边的局部，它是高并发的，整个流程当中，咱们实现了数据的编码和传输的各种优化，使得数据在整个过程中的流转是零拷贝的，并且通过 shard 级并行和 shard 外部的表级并行做到了高并发。通过这套架构咱们实现了千万级每秒的数据写入。左边的局部是高吞吐写入的架构。咱们通过源头向量化读数据源、计算引擎向量化间接写入到存储来做到高吞吐的写入。
这部分讲的是 AnalyticDB 提供的高性价比。如果用户想把数据全副存在 AnalyticDB 下面的话，必定会有冷存数据和热存数据。比如说用户想存三年的数据，然而有可能你只对最近一个星期的数据有热存的要求。因为最近一个星期的数据须要常常查，剩下的数据，用户心愿低成本的把它存在 AnalyticDB 上，那就会放在冷存下面。所以咱们提供了三种类型的表，一种是全热的表，数据全副存在热存。一种是全冷的表，数据全副存在冷存。还有一种是冷热混合，也就是局部数据能够存在热存里，剩下的数据存在冷存里。
接下来，看一下咱们明细查问。明细查问利用了 AnalyticDB 的智能索引能力。咱们对于不同的数据类型有不同的索引。咱们通过 CBO 来估算索引筛选率的高下，来决定是否应用索引。AnalyticDB 依据不同的过滤条件应用不同的索引，最初渐进地多路归并返回查问后果的行号。咱们外部的数据通过行列混存的形式进行存储，并且通过 meta 外面存储的粗糙集来进一步过滤数据。咱们还用了字典编码来压缩字符串类型的数据。
咱们在一套计算零碎里实现了离线和在线的交融。对于在线的查问场景，用户心愿它的查问可能尽量的快。咱们能够做到几十毫秒甚至几毫秒的剖析型的查问后果返回。咱们通过调起所有的 stage，并且算子流式地、不落盘地解决数据来达到极短的延时。左边的是离线的场景，延时并不是第一优先级。用户心愿离线场景查问可能在固定的工夫内稳固地跑完。
ETL 类型查问有可能会跑个几天，这时候咱们采取另一种 batch 的执行形式，整个过程十分稳固。数据在 stage 间的 shuffle 都会落盘。咱们对 Coordinator 和 Executor 节点的宕机都做了 failover 的反对，同时咱们通过自适应的分批调度来实现子打算的规模化调度。在整个计算的过程当中，咱们通过 Codegen 缩小虚函数的开销、缩小数据物化到内存，从而进一步优化咱们的查问。
Adaptive Execution 解决的问题是, 优化器估的再准，总是有误差的。有可能最终生成的打算和我想要生成的最优的打算是不一样的。那咱们就须要在打算执行的过程当中去自适应地调整这个打算。咱们实现了基于数据两头后果的自适应分区和基于数据后果的自适应打算，起到了 runtime 改正打算的作用。
说完了计算和存储，再说一下优化器。咱们实现了整套智能的优化。优化器分为两个局部，第一个局部是底层统计信息的采集局部。咱们会依据查问条件，主动在某些列上采集统计信息。第二，咱们会在规定的工夫内通过 Cascades 的框架搜寻出最优的执行打算，咱们用一套优化器反对了整套离在线的查问。并且咱们的优化器，不仅对接了 AnalyticDB 外部的数据源，还反对了内部的例如存储在 OSS、HDFS 上的数据源。做到了湖仓一体的查问优化。
除了下面提及的一些性能的优化之外，咱们还做了很多其余的性能优化：比方源头向量化读取；向量化算法优化；主动物化视图的改写；基于代价的最大执行子树复用等等。
AnalyticDB 是反对多维的弹性的，计算反对从 1 个节点到 5000 节点，ETL+ 在线剖析按需动静扩大。存储的弹性分为两个维度：存储的容量反对从 GB 到 100PB；存储节点的 QPS 反对从 1 到百万级。
来看一下咱们为什么要做弹性的性能。这是咱们 AnalyticDB 在去年的某一周的所有的查问。咱们对它进行了剖析。咱们发现只有万分之五的查问期待超过了 1 秒。然而通过另一个维度从实例级别来看，反而有大概有 10% 的查问超过 1 秒或者 5 秒的期待。这阐明这万分之五的查问扩散在不同的实例下面。阐明业务有很多场景，它的查问量，在十分短的工夫内会临时超过它的预估或者期望值，造成查问排队。这时候弹性就能很好的解决这个问题。
AnalyticDB 提供了三种弹性能力，第一种是分时弹性。比方你晓得下午 4 点到 8 点会有一个大促流动。那 4 点之前，咱们会把这些计算节点帮用户给弹出来。第二个是租户隔离的能力，如果两个部门有不同的查问在同时跑，A 部门的查问并不会影响 B 部门的查问。第三个是按需弹性。这个次要为了解决不可预期的流量，咱们能够按需地弹出用户所想要的节点来保障高优先级业务的 SLA。
咱们的分时和按需弹性是怎么做的呢？咱们本人保护了一个资源池，而后在池子上写了一套资源管理器。当用户有弹性须要时，咱们会从这个池子外面取出节点，加到用户的 AnalyticDB 里。当他用完时，咱们会主动把这个节点偿还回资源池里。整个过程是十分快的，咱们能够在分钟级别实现这个操作。
AnalyticDB 提供了资源组隔离的能力。不同的资源组的资源在物理上是隔离的。比方 A 部门的测试查问并不会影响 B 部门的营销查问。
三、云原生数据仓库诊断和运维
一个优良的数据仓库，不仅仅内核要做的好，咱们还要给用户智能诊断的能力。可能让用户晓得本人的零碎的问题出在哪里。所以咱们做了一整套的智能诊断系统。这套智能诊断系统有很多技术组件，性能组件，这些都深度联合到咱们的内核里。当你有新的查问来的时候，咱们会依据聚类算法来检测是否有异样呈现。如果有异样的话，咱们会对接智能告警零碎，通过钉钉、电话或者邮件给你发送音讯。
咱们的智能优化提供了主动剖析的能力；提供了数据仓库建模倡议，依据零碎的理论运行状况，咱们会给出具体的倡议来批改数据分布或者分区，让零碎更加平滑地运行；同时，咱们提供了智能巡检告警的能力。
原文链接
本文为阿里云原创内容，未经容许不得转载。
