AnalyticDB MySQL版：云原生离在线一体化数据仓库支持实时业务决策
内容介绍：
一、AnalyticDB MySQL整体的产品定位
二、整体技术架构
三、核心技术方向
今天介绍一下AnalyticDB MySQL。客户成长以及客户案例是产品发展的重要输入，AnalyticDB MySQL云原生这个数仓。在过去的这一年，AI变得越来越火，客户的场景和客户的需求也有对应的变化，今天就跟大家讲讲我们在过去这一年时间看到的一些客户场景上的使用，对我们需求上的变化以及我们这基础上所做的新功能。
一、AnalyticDB MySQL整体的产品定位
近年来越来越多的数据弧开始具备数据库的能力，数据库也慢慢向数据弧方面扩展，AnalyticDB MySQL能够作为一个数据仓库，提供数据库的应用性，同时也能像大数据一样支撑用户越来越大的规模使用。
二、整体技术架构
可以从两个方面上来考虑，一个是希望作为一个资源的产品，可以有自己的特色。从底层的存储：基于oss把底层的整个共享重组，让用户所有操作都在一份数据上，不需要反复拷贝，同时基于用户混合负责的查询及对应的计算，通过新的计算引擎，支持不同类型的大小查询，离线、在线能够在一个系统上执行。
作为一个资源系统，另外一个重要方式是现在用户越来越多的构建自己的数据库，能够或者在他已经有一套大数据的组件的情况下，更好的和现有组件结合，支持越来越多已有的弧的格式，从iceberg，Dota lake，包括派蒙，能够和用户的系统集成在一起，集成Spark，提供像click house这样的接口，一步步融合到用户已有的生态里面去。
三、核心技术方向
1.混合负载
随着AI的场景越来越多，用户开始把更多的数据集成到数仓里面来，用户数据怎样更好支撑越来越多的写入，包括在线的离线的，也包括其他各种的数据同步。另外一方面随着NLtoc这些场景越来越丰富的使用，更多的数据查询被下发到数据库和数差里，很多查询因为是AI生成的，并不高效，怎么能更好的支持不同类型的查询和负载？另外一部分是随着这些写入负载越来越高，以及用户查询越来越丰富，资源消耗越来越大，如何能够更好依赖弹性把整体数仓的成本降低。
2.异构加速
数据中心越来越会是一个异构的数据中心，CPU摩尔定律的增长已经很难再适应，随着AI以及数据量、计算量的增长，CPU已经很难能够跟得上，我们开始尝试一些新的硬件，包括GPo，FAJ，一些专用特殊的定制的计算硬件，在这上面也都有取得一些成就。最后讲我们在AI之上做了哪些东西能够服务AI的应用，以及AI怎么能够更好的支撑数据库。
（1）混合负载
主要讲三个数据源、数据库、日志。数据库提出了Zero-ETO。Zero-ETO一方面对用户来说是零成本使用链路，另一方面对用户来说是零运维的。
零运维:在整体的链路、系统上，当设置一个数据同步的时很多数据源同时在做专用的目标端接入，通过中间的传输链路连接起来。在做CLETL时，我们对原核目标端做了定制链路，从poDB到ADB做到高传输效率，数据之所以能够到600兆每秒甚至更快，是因为做了存储层的打通，可以把proDB下面的数从存储层直接同步到ADB里面来，这比往常同步链路效率高很多，这是做ZEQ比原先链路会有更好的效率的原因。
运维成本:链路进行了定制开发，定制开发后进行了很多假设。作为通用系统，很多假设是不成立的，作为定制链路在面临链路中断或者是遇到用户临时的分值时，可以进行整条链路的自修复和和自优化，我们在线上观测到百分之七八十以上的中断和任务，都可以做到自动修复和自动优化，让用户整条同步链路跑的更稳定，相对于通常手段在数据同步上碰到的问题，我们在ZE上都能够修复好。
离线:离线数据的导入是数仓很大的系统资源消耗，因为数据量大，计算节点需要很多的资源来处理写入数据及构建索引。在进行存算分离后，导入任务可以直接往OSS上写，不需要经过当前服务的Worker节点，从而降低整个数据库正常在线的服务影响做到100%的资源隔离。存储基于共享存储之后，在OSS上面进行写入操作，为线上的负载提供更好的隔离soa，防止影响数据的导入查询。
日志:随着AI的分析，用户的行为、打点和标签被导入到数差，基于这些构建feature进行AI的训练以及后续的AI的推理。日志并不是一个很新的场景，对ADB来说已经有多年，近年来从日志方式导入进来，一方面是数据量增加，另外一方面是原有日志先到弧再入仓，从日志源导入进行更实时的分析以及对应的推理计算，显示出更高的吞吐量，前几年阿里集团内部能够达到该量级，在公共云上还较少见，近年来越来越多的用户达到该级别。
面对实时流量，对突发流量的处理也很重要，面对用户大流量的分值时，通过弹性方式把写入支撑起来，基于弹性能够做到更好的成本。把前面的这一切串起来可看到流批一体的架构，从前面的日志到ADB，ADB本身也提供MySQL binlog的订阅能力，可以把ADB进行改动，再通过binlog方式订阅出来，同步到下游。ADB也支持批量数据的导入整个流批一体的链路就串联起来。此外该产品还支持雾化视图，这是物化视图和其他的产品的区别。
和多数仓的产品相比，物化视图能够支持实时增量，其他数仓的物化视图计算是异步的，或者同步的场景有很多限制，比如他是单表的，或者是对这些函数有很多限制。该产品把这些限制都抹出来，让用户可以方便使用视图。相对于流计算的这个场景，用户通过flink来搭物化视图，在整个数据库里搭建C口不再需要搭入Flink的计算。整个框架一条CQL就可以建这条链路，整个运维更方便。
混合负载一是基于固定的资源，基于数据和资源能够做灵活的弹性，在不同的计算之间来做调度。二是在云上可以利用云的弹性，对复杂及突发计算做弹性，在QPS上利用弹性的资源，对复杂查询加更多量，但仍存在一个问题，就是多少资源合适，加多少量才是最优的，很多时候云的弹性如果过高，对用户的成本其实会有更高消耗。
3.智能弹性与硬件
阿里云的底座有不同机器类型可以选择，包括神龙ECS和ECI，每一类资源有不同的SOA保障，包括eclport的instance成本会更低，保障有对应的限制。如何在不同资源间做更好调度，包括跨可用区的调度，让用户进行分值的弹性，弹出更大的一些资源出来。大用户在网上做ETL时候，有几万盒以上单客的这个弹性的这个需求，怎么在阿里云整个跨可用区来做对应的调度，怎么做智能的弹性，今年在数据库的一个顶会、Smo上发表了一篇论文，讲的就是怎么基于机器学习来做更好的预测。
大的思路上，很多时候数差的负载是重复性的，基于过往负载，可以较好预测出每一条查询所跑时间、访问数据及资源消耗。基于又可以预测出之前没有见过的查询会消耗多少资源，可以做到对资源预估99.9以上的准确率，弹性可以支撑更多的一些用户的场景和负载。
(1)叙述案例：multi class multi class
可以监测到用户对应负载变化，弹出新集群来支撑用户访问，AnalyticDB MySQL可以做到20秒，其实整体弹性时间更短可以做到5秒以内把集群给拉起来。选20秒是因为不想有太大波动，不希望在尖峰这样的流量做资源的弹起和弹降，整体的性能上有更大提升。
(2)快弹性：
计算节点做弹性的很多时间是在做原有存储状态准备，要把存储状态剥离出来，需要把底层的存储数据放到oss上，然后把在线状态放到在线的KB存储里，把整个数据剥离开后就变成只是一个纯计算节点的弹性。弹性时间三分钟的和在20秒以内做弹性，两个时间上是有区别的，这边讲的是纯拉起的时间。把所有存储状态都剥离还要花3分钟是因为需要有ECS的申请，镜像拉取、网卡挂载已经做到最低到3分钟。为什么可以进一步做到5秒以内是因为已经把节点预期好，能够更好的直接拉起挂载使用，有热词而没有额外成本消耗是因为有足够大的资源池，有足够多的用户，所以保证每个用户都有对应的资源使用，大家共享一个池子，整体池子的成本就低，可以做到在5秒之内拉起。
异构加速是怎么提升CPU使用效率？一个是和英特尔和MD已有的CPU厂商的合作，整个向量化引擎基于英特尔或者是MD上面的一些CMD指令集，把Spark以及这些这计算引擎内部节点，单机引擎都换成CR＋，同时也对下面缓存做智能加速，把CPU速度加上之后IO就变成瓶颈，通过缓存再把IO的瓶颈解除，进一步把整体的性能拉上。
在智能硬件这块，GPU是一个场景，已和NVDIA做了对应合作，用的不是大容量A10或者A1版的卡，而是最低档的tfour。老一代GPU，可以做到跟CPU相同的成本的时候，我们可以到1.68倍的整体的性能，GPU在一些大的用户以及一些复杂的计算场景，比较适合的场景是数据量大，计算复杂，在这些用户上面做到大性价比提升，用户自己去买GPU的机器，成本很高，GPU对一些短查询是劣势，我们通过云本身秒级的GPU调度，按量计费，更好的解决成本的收益。目前，我们也不单单在做GPU，也在做FPGA和SC卡基于数仓产品的定制，硬件的一些开发和优化，可以看到更通用的一些场景，而不仅仅只是限制在复杂计算，对一些短查询也有一些比较快的加速。
4.AI
基于存算分离将数据传输到oss上，原有存储和分析基于Spark以及对于一些NVDIA的计算加速，对大数据量的一些复杂计算和数据加工可以更高效率，数据加工会变得更好。基于这些已经加工和准备好的数据，也集成了NVDIA的treatment推理服务，能够把很多推理能力内置到数据库里面来。数据就在数仓里面，更好的发挥数据在它所拥有的价值，支持Twitter服务器，允许用户部署自己的推理服务，支持调用像通易和阿里云一系列已有的推理服务，直接对数仓里面的数据来做分析。基于这一整套架构，可以看到用户整体的成本更低，整体的纯算以及弹性，计算效率会更高，基于Spark整体的性价比在一些复杂计算上更具优势。
基于这些推理的服务，从存储分析到数据的加工准备，再到最后AI的部署和推理，形成一个端到端的链路，基于存算分离的架构，以及暖硬结合的能力形成解决方案，帮助用户部署AI的应用。今年落地的几个AI的场景，主要在在投放和分析上，是和钱最相关的部分。通过日志的导入用户，把用户的上线时间，升级、提升进度，对应日志流进来之后，通过这些AI的分析出来哪些是大玩家，哪些是可能有付费意愿的这些玩家，能够给这些对应的游戏公司有更好的一个投放的这些规划和预测输入。
怎么能够更好用AI来帮助数据库和数差用的更好，通过AI来做百万盒的线上调度，是怎么能够通过AI来做集群的自动运维和告警，把这些ADB已有数据通过ET，日志，导入到ADB里面来，然后跑ADB里面的算法和分析，通过这个能够很好的产出一些用户比较关心的指标，包括哪些是badSQL。很多时候是数据平台在维护。我们上面的业务方有各种各样的SQL，哪些是用户业务方下发的badSQL对整体其他用户有影响的，能够发现出来哪些是一些新增的pattern，那可能对使用会有一些问题的，以及包括用户建模上的一些问题，包括表的清洗，分布件，对应都能够给用户预警及修改建议。对于SQL修改建议很大一部分是跟AI相关的能力，通过智能改写来做这方面判断。
整体上就是这四个方向，一个讲的是混合负载，能够来支持在AI场景上新的一些写入和查询一些pattern的变化，通过弹性把成本降的更低。同时也在探索一些新的硬件，希望在突破软件的瓶颈，不单单是在看软件，而是通过硬件的方式能够带来更大效率提升，sking law或者是其他一些新的硬件带来一些可能的变化，最后讲一下AI怎么和我们当前素材的场景来做结合，来带来这些对应的变化。
过去一年的时间，把ADB从上线到现在10年的经验，以及国外的案例做了总结，和华东师范大学从学术和工业界的角度来做了整体思考，接下来由华东师范大学的周烜教授分享，讲一下这本书写的一些心路历程。
周烜在华师大主要负责数据库科研团队的工作。现在这个时代是一个数据爆炸的时代。数据变成了一种重要的生产要素，重要的核心资产。数据最终会存在什么地方，在我们看来，随着技术的不断发展和优化，云数仓是一个最核心的数据的基础设施，无论未来做什么样，数据相关的这些技术，无论是AI还是这种分析报表，传统的东西，最后基于的应该都是云数仓这样的一个产品，国内外关于云数仓的这个技术的发展实际上是非常快的，国外的各种云数仓的产品，我们国内的各大云厂商上面都有这种云数仓的非常典型的产品，技术更替非常快，所以华东师范大学和阿里的这云数仓技术专家的团队一起花了一年多的时间对现在的最前沿的云数仓的技术做了一些总结和提炼，然后有了我们这本书，一方面是面向使用云数仓的这种技术人员，另外一方面也可以面向我们的这种学生，让大家共同来深入理解，现在云数仓的核心与趋势。
