前言
2022年，是阿里巴巴双11的第十四个年头，同时是云原生数据仓库AnalyticDB（简称ADB）助力双11的第八个年头。ADB是阿里巴巴自主研发支持高并发低延时查询的新一代云原生数据仓库，高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准，可以对海量数据进行即时的多维分析透视和业务探索，快速构建企业云上数据仓库。从最初离线导入查询加速场景到实时写入毫秒级分析的实时数仓，再到湖仓一体化的实时湖仓，ADB始终围绕着数据价值，为阿里集团、公共云及混合云的各行各业提供服务，在双11支撑新零售的生态，包括不限于阿里集团内的订单交易、菜鸟物流/仓储、数据银行、盒马、阿里妈妈、聚水潭等。
今年的云栖大会上ADB重磅发布了湖仓版公测，帮助用户打造云原生一体化数据分析平台。那么，让我们看下今年双11中ADB有哪些亮点呢？
业务亮点
实时分析 | 订单交易
淘宝核心订单交易业务基于ADB的实时引擎、行存表、非结构化索引、宽表检索的在线能力，完成了对全网用户十年全量的交易订单进行多维搜索，并根据用户的搜索关键字进行精准推荐，大大提升了手淘订单搜索的用户体验。今年双11，ADB一如既往为业务提供了稳定支撑。
通过DTS多单元同步，实时写入峰值达到百万级TPS。通过实时热点散列技术、热点秒级发现、分钟级追平等多种技术手段，保障十万级爆品订单毫秒级查询延迟，加速卖家仓内作业。最终，提升了商家退款处理效率，降低钱货两失风险。
降本增效 | 数据银行
品牌数据银行业务面对上万头部品牌，积累了千亿级数据量，其中人群圈选、透视分析等核心功能日均人群应用百亿人次，助力品牌生意增长。今年，数据银行发起了OLAP统一项目，一份数据，基于ADB承载数据银行分析业务，策略中心在线计算业务以及相关实时计算业务，并在双11顺利通过大促考验，保障项目平稳落地。
通过OLAP统一项目，数据银行团队与ADB团队一起落地了湖仓一体共享存储架构，通过底层架构改造和创新，解决了数仓频繁数据交换效率低等痛点。大促期间预售圈人业务量达到历史峰值，不仅平稳度过，且结合升级的Bitmap SQL能力，圈人计算任务从10分钟提升到5s内完成计算，提升了用户圈人体验。此外，通过业务及资源合并，月成本降低40%+。
湖仓一体 | 数据自治服务DAS
数据库自治服务DAS（Database Autonomy Service）是一种基于机器学习和专家经验实现数据库自感知、自修复、自优化、自运维及自安全的云服务，帮助用户消除数据库管理的复杂性及人工操作引发的服务故障，有效保障数据库服务的稳定、安全及高效。
基于ADB湖仓一体架构，通过新发布的高速数据通道、湖仓一体存储、统一元数据服务、Spark/XIHE离在线混合引擎核心技术，首次支撑DAS双11业务，写入吞吐达到8GB/s，存储总量达到20PB+。其中，ADB内建数据通道支持SLS/Kafka等数据源高吞吐低延迟入湖入仓，并通过横向扩容、负载均衡、热点打散等技术手段，使大促期间提供平时2倍以上的吞吐能力。此外，基于统一的元数据服务、统一的存储API接口，可以轻松打通湖仓边界，使得离线、在线计算引擎可直接访问湖和仓的数据。真正做到了一套体系同时支撑了面向离线的SQL模板趋势分析、以及面向在线的日志查询分析，为DAS业务持续发展提供丰富想象力。
技术亮点
众所周知，随着IT基础设施的日益成熟以及互联网的高速发展，早期的单机关系型数据库，在数据规模日益增加的背景下，开始了向大数据系统的探索，而Google的三驾马车（分布式存储、调度、计算）几乎奠定了早期大数据处理系统的架构。并基于此，快速进入到以Hadoop生态为主的大数据处理新纪元，并诞生了以ORC/Parquet为主的开放存储格式。随着大数据处理系统的日益成熟，考虑到易用性、实时性，又开始探索基于SQL描述语言的分布式数据库。
早期的ADB就是在这样的背景之下应运而生，高度兼容MySQL协议的自研实时数仓。另一方面，云平台设施的持续发展也在推动着数据库向云原生化、Serverless化方向的不断演进。从去年开始，有关湖仓一体化的讨论也愈演愈烈，几乎各个云厂商都在推出自己的湖仓一体的产品。当然ADB也不一例外，经过了一年多的时间沉淀和打磨，ADB湖仓版也重磅发布了，让用户能够基于数据湖的数据规模，拥有数据库的体验，一站式地进行离在线一体的数据分析。
ADB湖仓版
橙色部分是「湖仓版」相对于「数仓版」新增的功能，灰色部分是「湖仓版」相对于「数仓版」迭代升级的功能。其中，左框是我们的自研引擎，包括「羲和计算引擎」和「玄武存储引擎」。右框是我们集成的开源引擎，包括「Spark计算引擎」和「Hudi存储格式」，希望借助开源的能力提供更丰富的数据分析场景。同时打通自研和开源之间的互相访问，提供更一体化的体验。我们将湖仓版的新特性总结为四个方面，分别对应 1、0、2、4 这四个关键字，接下来将详细介绍。
▶︎ 1份数据
「一份数据」是指一份全量数据，能够同时满足高性能的在线分析、以及低成本的离线处理，避免额外的数据同步。而这两种场景对于存储的诉求是不一致的。在线分析场景希望数据尽量在高性能存储介质上提高性能，离线处理希望数据尽量在低成本存储介质上降低存储成本。
在ADB湖仓版中，首先将一份全量数据存在低成本高吞吐存储介质上，低成本离线处理场景直接读写低成本存储介质，降低数据存储和数据IO成本，保证高吞吐。其次将实时数据存在单独的存储IO节点（EIU）上，保证「行级」的数据实时性，同时对全量数据构建索引，并通过Cache能力对数据进行加速，满足百ms级高性能在线分析场景。因此，数据湖中的数据可以在数仓中加速访问；而数仓中的数据，也可以利用离线资源进行计算。
为了满足这个需求，ADB继续增强了存储服务化能力，统一存储接口层及数据访问格式，具备一份数据、一套存储格式同时支持实时更新、交互式查询、离线ETL及明细点查多场景一体化能力，同时为离线（Spark/XIHE BSP）、在线（XIHE MPP）等多种计算引擎提供存储服务。其中，接口层支持列投影、谓词下推、分区裁剪，并且提供了面向高吞吐的Skipping Index扫描过滤、面向低延迟的Secondary Index过滤这两种访问模式。计划层支持灵活的数据分片策略，最大化并发查询能力，为离线高吞吐场景提供有力的支撑。此外，基于时间片的并行执行模型、异步数据流以及数据流级别的流控与反压，也提高了存储服务化的多场景能力和稳定性。
▶︎ 0度弹性
云原生的最大优势就是弹性，ADB湖仓版通过全新基于神龙 + ECS/ECI构建的两层管控底座，提供更充足的库存保证，保证弹得起；满足了弹得起，接下去就是要弹得快。如果启动一个离线Query的资源需要10分钟，这样的效率使用体验不好，且会有较大的额外成本。湖仓版除了适合在线分析场景的「分时弹性」模式，新推出了适合离线处理场景的「按需弹性」模式，弹性速度上可以做到1200ACU（1ACU约为1Core4GB）规模的Query，弹性时间在10s左右；最后，借助WorkLoad Manager（WLM）和自感知业务负载技术，保证弹得准，贴合业务负载，降低资源成本。
「弹得起」
不管是离线负载的Query弹性，还是在线实例级别节点的弹性，都需要有库存的保障。如果囤一批机器来满足弹性需求，当用户资源缩容的时候，会给ADB MySQL服务带来巨大的库存成本负担。为了既满足在离线的弹性资源供给，同时最小化ADB MySQL的成本，构建了基于画像运营的两级弹性库存供给能力。库存包括固定池、弹性池两部分。其中固定池的库存供给周期在0.5天-15天，提供更好的弹性效率且库存可估计；弹性池的库存供给周期在7s-180s级别，成本较高且库存不可估计。基于不同资源的库存水位画像进行预测，从而来决策不同资源的购买释放数量。
「弹得快」
支持负载的弹性除了库存供给技术外，另外一个重要技术是弹性效率。如果启动一个离线Query的资源需要10分钟，势必会影响用户体验，且会有较大的额外成本。为了达到10s内完成1200ACU的弹性资源，ADB MySQL团队做了从Query执行模型、Pod的存储、Pod的网络等端到端的优化。
一条Query执行需要一个Master Pod及若干个Executor Pod，查询执行期间会生成Shuffle数据存储到Pod的Cache盘中。此外，每个Pod的网络使用的是云原生的ENI方案。为了降低启动Master Pod的开销、按需去挂载云盘/ENI的开销，构建了多个缓存池，如图所示。
「弹得准」
混部负载场景既有在线分析，也会有ETL离线分析，“离在线负载不解耦”的架构下在线查询和离线分析的执行task会混用计算节点，存在相互影响，并且可能承担额外的成本。ADB采用离在线负载解耦的方式，离线负载可以按Query进行极致的资源弹性；在线负载则通过构建负载感知-> 库存供给-> 实例弹性的闭环反馈链路来做到按需自动弹性。
▶︎ 2种模式
ADB数仓版支撑高性能在线分析的背后，计算部分主要是自研的「羲和计算引擎」MPP模式，但这种流式计算模式并不适合离线处理低成本和高吞吐的特点。所以，在ADB湖仓版「羲和分析计算引擎」中新增加了BSP模式，通过DAG进行任务切分，分批调度，满足有限资源下大数据量计算，支持计算数据落盘。
为了便于用户使用，ADB湖仓版又进一步把「羲和计算引擎」升级成「羲和融合计算引擎」，同时提供MPP模式和BSP模式，并提供自动切换能力。ADB基于线上的运行时统计信息、历史Query的执行指标构建了Query级别的Workload Managerment，对不同负载的查询请求可以做到自动识别、分类，并结合多队列优先级调度、启发式的规则干预等，大大提升了系统整体的稳定性和用户体验。此外，当查询使用MPP模式无法在一定耗时内完成时，系统会自动切换为按需弹性的BSP模式执行。未来也将引入机器学习算法，进一步提高Workload Managerment的智能化，对查询的资源消耗、执行时间的预测更加准确，增强对未知查询的感知能力。并在此基础上，定义实例级别的Workload画像，增强自动弹性能力，帮助用户降本增效。
▶︎ 4个统一
ADB湖仓版提供的一站式分析体验，主要得益于元数据管理、数据访问、数据通道、计费单位这4个方面的统一。
通过对湖、仓元数据的统一管理，避免了系统内部低效的元数据同步，也让湖、仓系统的联动更加敏捷。而数据访问格式也统一成面向列存的arrow开源数据结构，便于对接更加多样的计算引擎，大大增强了湖仓版的开放能力。
此外，ADB在深化自身湖仓能力建设的同时，还推出了APS（ADB Pipeline Service）数据通道组件，为用户提供实时的数据流服务，支持SLS/Kafka等数据源低成本、低延迟入湖入仓，单链路可达到4GB/s吞吐。同时，数据通道也支持白屏化配置（资源配置、同步任务的管理、延迟告警等），用户可以随时查看同步速率、延迟信息，及时了解数据入湖入仓情况。
最后，为了简化现有的计费模型，ADB湖仓版统一计费单位为ACU(AnalyticDB Compute Unit)，是分配计算资源和存储资源的最小单位，让用户核算成本时更加清晰。
总结和展望
ADB经过八年的双11大促锤炼，始终保持初心，坚持以数据价值为核心，为用户提供更好的数据分析体验。未来也将持续打造云原生一站式数据分析平台，逐步完善周边的生态服务，让用户可以更方便的数据治理，更灵活的数据链路，更智能的数据分析，更一体化的平台体验，让数据价值最大化。
公测说明
AnalyticDB MySQL湖仓版从7月份开始，历时4个月的邀测后，11月1日正式开始公测。其中一个邀测客户是哔哩哔哩，来自B站的陈浩也在云栖大会上分享了猫耳业务使用AnalyticDB湖仓版的价值和过程。“B站猫耳FM业务通过引入阿里云AnalyticDB MySQL湖仓版，替换原有开源离在线数据仓库，大幅降低数据仓库运维成本，并且基于AnalyticDB MySQL的分时弹性能力实现资源按需伸缩，实现资源高效利用。目前，猫耳FM业务实现数据离在线处理效率从原来的在 T+1 或 H+1大幅提升至毫秒级，支撑打赏榜排名实时刷新，提升用户参与积极性，通过提高广播剧的评论/弹幕活跃度，促进用户停留时长与付费转化。”（新华网报道）对于低成本离线处理ETL有需求，同时又需要使用高性能在线分析支撑BI报表/交互式查询/APP应用的用户，可以通过点击「阅读原文」进行公测申请。
/ End /
