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