怎么看一个网站做得好不好,学校网站的页头图片做,太原网站优化培训,mip网站建设公司简介#xff1a; 本篇内容为2021云栖大会-云原生数据仓库AnalyticDB技术与实践峰会分论坛中#xff0c;阿里云数据库资深技术专家 姚奕玮关于“AnalyticDB MySQL离在线一体化技术揭秘”的分享。 本篇内容将通过三个部分来介绍AnalyticDB MySQL离在线一体化技术。
一、传统大…简介 本篇内容为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部门的营销查询。
三、云原生数据仓库诊断和运维 一个优秀的数据仓库不仅仅内核要做的好我们还要给用户智能诊断的能力。能够让用户知道自己的系统的问题出在哪里。所以我们做了一整套的智能诊断系统。这套智能诊断系统有很多技术组件功能组件这些都深度结合到我们的内核里。当你有新的查询来的时候我们会根据聚类算法来检测是否有异常出现。如果有异常的话我们会对接智能告警系统通过钉钉、电话或者邮件给你发送消息。 我们的智能优化提供了自动分析的能力提供了数据仓库建模建议根据系统的实际运行情况我们会给出具体的建议来修改数据分布或者分区让系统更加平滑地运行同时我们提供了智能巡检告警的能力。 从AnalyticDB离在线一体化架构对于用户提供的价值来说第一我们提供了平台的统一用户无需自建一套复杂架构来做离在线一体化第二相比于自建的系统我们在性能上有了3到10倍的提升。并且我们整套架构是实时化的。最后我们具备良好的兼容性和生态方便用户自建集群迁移到AnalyticDB上。
原文链接
本文为阿里云原创内容未经允许不得转载。
