云原生数据仓库AnalyticDB：深度智能化的数据分析洞察
内容介绍：
一、业界趋势
二、产品介绍和演进
三、数据融合
四、场景融合
五、数据驱动，智能增长
一、业界趋势
主要分享ADB MySQL产品在去年一年对于数仓领域的思考以及一些产品的演进。首先是业界的趋势，业务数据发生了什么变化。数据分析行业整体呈现了几个趋势。第一个是数据规模逐年的增加，根据idc的报告，2024年全球的数据规模已经到了160ZB，预计到2028年会到达285ZB。第二个是数据源越来越多，最初分析关系型数据库的数据，到后面慢慢分析日志数据，包括消息队列，对象存储上面的日志数据以及日志服务中的日志数据。第三个是场景变得越来越复杂，最早是t+1，每天00:00~8:00算报表，慢慢变成了需要做实时的分析。分析师可能第2天上班以后，下发一些at hulk的及时查询，去做一些实时的数据分析，近两年统计分析不满足需求，还需要做一些基于ai的预测分析。第四，为了支撑这些场景，引入了很多的组件像处理流的Flink，处理批的spark，处理at hulk的MPP引擎。整个组件变得特别的复杂，维护成本比较高。
二、产品介绍和演进
1、数据架构
总结来讲就是数据源越来越多、数据量越来越大、需要处理的场景越来越多。大体上数据源分为tp数据库，消息队列中的日志数据以及OSS上数据湖的数据，通过ADB这款产品进行统一的接入，往后可以去应对一些典型的场景，包括离线数据处理场景、在线分析场景以及基于ai的用户行为分析。
2、产品架构
ADB的定位是云原生的数据仓库。它采用的是存储、计算、访问三层分离的架构。在计算层它包含两款引擎，最早的时候从自研的MPP也就是XIHE的引擎开始做，前年的时候集成了开源的spark引擎。为了能提供更好的离线处理的能力，在XIHE引擎上，我们主打是不仅可以做mpp的战略分析操作，而且在简单的离线处理上，也可以自动转换成BSP的执行模型去执行。我们的资源可以随着业务的情况进行弹性的伸缩。在开源部分集成了Spark引擎，在接口全兼容开源的情况下，我们做了一些性能方面的演进，包括基于native的向量化执行加上数据缓存的技术。现在在ADB里spark的性能比同版本开源的spark提升7倍以上，另外我们跟内部的数仓的表的打通也做了一些工作。
3、产品架构演进
收敛到企业版，兼顾高性能和高弹性:之前ADB的产品形态比较多，有存算分离和存算一体的，对于客户选择有一些门槛。可能一开始选择了存算一体，后面想弹性比较困难，一开始选的弹性可能觉得性能不如存算一体高。今年统一收敛到了企业版，用户购买的时候可以一开始去购买高性能的预留资源，因为预留资源里面存储跟计算是放在一起的，当业务发展了以后，需要一些弹性的能力，可以再去用这个弹性的资源按需计费的方式去满足高弹性。
4、存储架构演进
之前我们的存储的数据是存在本地盘上的，它会带来一些弹性等相关方面的问题，今年发布了一个完全存算分离的架构，所有的数据都会存在oss上面，本地只会去缓存数据。当我们需要做一些弹性的时候，弹性会比较灵活，节点弹完以后数据不需要做balance，数据可以根据后面业务的需要进行动态的加载。因为数据整体从essd放到了oss，所以数据单GB的成本下降90%，弹性从之前的二三十分钟下降到三分钟级别。
三、数据融合
1、数据库:zero-ETL
在tp的数据库方面发布了zero-ETL的能力，简单来讲就是他可以免费把我们数据库中的数据，实时通过BLAO的方式同步到ADB数仓产品里面来，整个链路都是内置的，用户本身不为这个链路付费，也不感知这个链路的运维。整体同步的效率，尤其是在全量同步上面，可以达到600MB/秒的能力，以上是数据库这一块的数据同步。
2、日志数据(kafka/SLS):APS
第2块是数据量和数据规模比较大的日志数据，主要是有两个数据源，一个是消息队列kafka，一个是日志产品SLS。ADB提供了一个数据管道的产品功能APS,满足kafka和SLS的数据接入。整体的吞吐方面，因为日志数据比tp数据，它不需要实时那一部分，所以整体写入的吞吐可以达到4GB/秒，并且整体的资源也是可以随着源端kafka负载的波峰波谷进行弹性，相比这种固定的资源，整体的资源也可以下降60%以上。
四、场景融合
1、负载隔离:3层保障
要把很多的场景放到一款产品里面去做，首先核心要解决的是隔离性的问题。首先，一个公司购买一款ADB产品，希望数据是共享的，但是不同部门、不同业务之间的执行,客户希望是隔离的啊。再往下不同的分析师之间也希望跑的SQL能够尽量的减少互相的影响。基于这样一些业务的背景，我们做了三层的隔离保障。第1层业务方部门级别，首先可以定义资源组，资源组里面的资源是强隔离的，假设资源组a被某一个分析师下发的一个特别大的SQL打爆了，也不会影响到资源组B。资源组是业务部门手动去切分的，在资源组内部，许多同事下发了很多的SQL，我们有个自动路由的multi cluster的能力，他可以在多个设定好的弹性的cluster之间做自动的路由。cluster与cluster之间的负载也是隔离的。再往下cluster内部还会根据查询的特点，会再次做一个基于负载的预测的管理，因为我们知道我们今天跑的SQLPython可能在昨天跑过的大概的耗时的情况，系统就会自动的把它投入到对应的队列里面。
2、灵活弹性:两种弹性模式，满足不同场景
重点讲一下第2层multi cluster多弹性的能力，从精细的角度讲,弹性的方式在数仓领域至少分为两种，一种就是传统的Min-Max的弹性方式，可以理解成把一个脸盆变成了一个水桶，第二种是multi cluster的弹性能力，可以理解成一个脸盆变成十个脸盆，十个脸盆之间的业务跟负载都是隔离的，不像一个脸盆、一个水桶那样负载都是混在一起的。multi cluster的弹性的模型相比传统的Min-Max的模型，基于相同的资源，整体的QPS大概提升26%~28%。
3、极致性能:托管Spark相比开源Spark提升7倍
第三部分，去年托管spark引擎核心聚焦在性能这部分。性能这部分上面并没有魔改内核，而是把内核直接c++化、向量化的方式去执行。第2个就是我们经常Spark去处理、去读取的数据湖的数据，在远端通过自研的cache的能力把它缓存到本地的essd上面，然后做个淘汰算法，加速整个数据读取的效率。整体的性能基于TBCH，大概可以提升6.9倍。
4、拥抱AI:一站式AI预测能力
很多客户一开始数据分析都是停留在统计维度的，用SQL来表达的，但是慢慢发现只是做一些简单的预测觉得不够。从去年开始我们跟很多的游戏公司探讨到底需要什么样的能力支撑业务的场景。比如说一些付费的用户未来还会不会付费，未来付费的金额是怎么样的以及游戏公司比较敏感的大氪金用户流失的风险。基于这么一些业务场景，我们提供了一些ai的能力，ADB之前我们可以做一些传统的SQL分析，基于cpu的一些数据分析。今年我们在ADB上面增加了底层基于gpu算力的节点,称为ai节点。用户可以在gpu的资源上面进行模型的训练、预测、推理。整个过程跟数据处理结合起来，不管通过SQL还是通过Spark的方式,我们先把数据做一些特征的处理，处理完以后可以基于gpu的资源做一些模型相关的预测跟推理的能力。
五、数据驱动，智能增长
1、易点天下:致力于为客户提供全球营销推广服务
易点天下公司是一家广告公司，是为国内海外客户做全球营销推广的一家企业。主要服务的方向及业务是大媒体广告带头、程序化广告、ai广告创意，服务国内企业出海是我们的一些优势业务，易点天下与阿里、字节、Google、meter这些公司都有一些深度的合作。
2、以数据支撑业务发展
基于营销推广这么一个主要业务，易点天下所有的业务场景经过梳理之后，都离不开一个核心的数据要素。内部的经营决策、日常的广告营销服务、数字化风控等等，都离不开像阿里云ADB提供的数据支撑。主要选择两款在易点天下公司应用的比较深的产品进行介绍，一款是数眼智能BI的产品，一款是DMP产品。
（1）数眼智能BI:服务于买量变现业务的数据增长平台
数眼智能bi产品是一款服务于买量变现业务的数据增长平台。通过对千亿级别的数据比如说用户的行为数据、投放数据、变现数据等等这些数据的整合，结合平台的智能模型，向广告主、媒体提供专业的数据分析报告。然后还包括自助分析工具、模型分析工具等等，这个平台对于客户来说最重要的价值就是及时性、高效性、准确性。在千亿级别的数据上如何保证及时性和准确性离不开底层的数据支撑，这个就是我们面临的第一个挑战。
（2）DMP平台
DMP平台是一个受众圈选的平台，在推广营销的业务过程中，不管是上游的广告投放还是下游的送流量，都离不开精准的数据圈选。对于上游来说，我们要从几十亿的目标受众中挑选出精准的客群进行广告投放，来达到广告主的kpi。这个过程一方面可以节省广告预算，第二方面可以提升广告转化率。对于ssp这一侧来说，如果能拿到一个精准的预算画像，那就可以对上游进行精准的送量，提高上游的采买，达到广告库存收益的最大化，就是ecpm的一个单价的提升。对于这个平台，每天需要接收的也是千亿级别的数据，我们需要对这些数据进行分类、清洗、打标签，还要同时实时应用于每一次的广告营销活动，这个活动基本上是在100毫秒内要完成。把这么大的数据应用于这么高实施要求的场景下，就是我们要面临的第二个挑战。
（3）数据团队面对的业务挑战
总结来说易点天下希望得到一款数据库技术，核心诉求包括它能够按需付费，有高效的伸缩性，能快速的弹起来，而且用多少它就能弹性多少。基于这个诉求，阿里云的同事给了一套全新的方案。
3、基于云原生数据库的架构优化
易点天下之前实时数据通过fluented放到oss，借助于DLA和EMR做离线的数据计算。新的方案把DLA和EMR整体都切换成了阿里云的ADB。
（1）新老架构对比
通过客观一些对比，EMR和DLA这两个比较类似,都是执行spark的一些操作，第1个就是它的拉起速度稍微有一点慢,DLA它有带宽瓶颈，计算的资源利用率不高,整体上就加大了单位的计算成本。使用ADB的方案的弹性是比较高的，基本上能保证很快的把资源拉起，同时XIHE的物化视图还有spark lakecache可以很高的提升计算的速率。
（2）成本和时效数据分析
这边有一个对业务数据的量化分析，大概取了生产上面10天的数据量，大概在300~350t左右，对它进行了一个成本和时效的分析，可以看到在有ADB cache的情况下，它都是一个大范围的降低，即便在没有ADB cache的情况下，也能与之前的DLA在性能和成本上基本上持平。
（3）云原生数据库对广告业务带来的价值
通过这些数据的整体对比来看，每日的任务总耗时能降低30%以上，日均成本能降低20%以上，这个对未来的业务来说是有很具有很大的价值的。所以我们也很感谢阿里云团队给我们提供了这么优秀的云原生数据仓库工具。
4、携手未来:打造出海企业的数字化发展底座
基于我们与阿里云的深度合作，希望未来也继续借助阿里云的先进技术底座来共同打造出海业务的数字化发展的底座,通过易点天下数眼智能、kreadoAI、cycorAI这些平台携手阿里云在营销生态、数据生态、AI生态上为出海企业提供智能化增长和数字化提效的解决方案和产品。
