简介：2021 年双十一刚刚闭幕，已间断多年稳固反对双十一大促的云原生数据仓库 AnalyticDB，往年双十一期间依然判若两人的稳固。除了稳固顺滑的根本盘之外，AnalyticDB 还有什么亮点呢？上面咱们来一一揭秘。
作者 | AnalyticDB
起源 | 阿里技术公众号
一 前言
2021 年双十一刚刚闭幕，已间断多年稳固反对双十一大促的云原生数据仓库 AnalyticDB，往年双十一期间依然判若两人的稳固。除了稳固顺滑的根本盘之外，AnalyticDB 还有什么亮点呢？上面咱们来一一揭秘。
二 长风破浪 | AnalyticDB 再战双十一
往年双十一，AnalyticDB 的战场横跨阿里数字经济体、公共云和混合云，三个战场都稳如泰山、成绩斐然。在阿里数字经济体内，AnalyticDB 撑持的业务简直笼罩了所有 BU，诸如手淘订单搜寻、菜鸟、淘特、盒马、飞猪、猫超、阿里云等近 200 个双 11 相干的外围业务；在私有云上，AnalyticDB 撑持着数云、聚水潭等诸多电商相干的外围业务；在专有云上，AnalyticDB 次要反对中国邮政团体的各类业务。往年 AnalyticDB 撑持的业务负载特地多元化，从单库百万级峰值 TPS 的实时数据写入到外围交易链路的高并发在线订单检索和关键字精准举荐，从各种业务场景下的简单实时剖析到各种人群和标签数据的大批量离线 Batch&ETL 工作以及数据导入导出工作，这种形形色色的业务负载，甚至离在线混合负载同时执行的场景，对 AnalyticDB 提出了微小的挑战。
面对这些业务场景和技术挑战，AnalyticDB 迎难而上，今年以来，全面拥抱云原生构建极致弹性，全面推动存储计算拆散架构，通过冷热温分层存储大幅升高存储老本，通过降级向量化引擎和优化器框架大幅晋升计算性能，全面推动离在线一体化架构，进一步晋升在一套技术架构下同时稳固运行在线实时查问和离线批量计算工作的能力。正是有了这些技术积攒和积淀，AnalyticDB 在往年的双十一战场上能力更加稳固从容，各项业务指标持续再创新高，往年双十一期间累计实时写入 21 万亿条数据，批量导入 113 万亿条数据，实现 350 亿次在线查问和 2500 万个离线工作，累计 590PB 数据参加计算。
不论是从反对业务场景的复杂度上看，还是从数据规模和计算规模上看，AnalyticDB 作为离在线一体化架构下的新一代云原生数据仓库曾经越来越成熟，能够为各种业务提供外围报表计算、实时剖析决策、流动大屏与系统监控、智能营销等通用能力。同时，往年 AnalyticDB 重点联合手淘订单搜寻和举荐、实时订单同步等外围业务场景，以技术创新为外围，帮忙业务解决了不少长期困扰的辣手问题，助力业务在用户体验、绿色低碳、业务翻新、平安稳固等方面获得新冲破。
1 体验第一：看 AnalyticDB 如何优化手淘交易订单搜寻
手淘订单搜寻反对用户输出关键词或订单号查问历史订单，是通过历史订单关联商品和店铺从而产生复购的重要流量入口之一。不过因为用户的历史订单信息量十分大，达数千亿之多，而用户往往仅记得商品或店铺的含糊信息，导致用户输出的关键词要么不精确可能搜不到订单，要么关键字很短导致查找到订单很多响应工夫很长，极大影响手淘用户的产品体验，长期为用户所诟病。
AnalyticDB 基于新实时引擎 + 行存表 + 非结构化索引 + 宽表检索的在线能力，首次实现了在线和历史交易订单的对立存储、剖析，赋能交易业务中台对全网用户十年全量的交易订单进行多维搜寻，并依据用户的搜寻关键字进行精准举荐。大促峰值期间用户反馈“订单查不到”的舆情同比大幅降落，查问性能也失去大幅晋升，大大晋升了手淘订单搜寻的用户体验。
2 绿色低碳：看 AnalyticDB 如何助力业务降本增效
公共云客户数云赢家 2.0 全域 CRM 平台通过采纳以云原生数据仓库 AnalyticDB 为外围的整体计划，在双 11 期间对客户洞察和细分、自动化营销等外围性能进行全面降级。基于云原生、资源池化和冷热数据拆散能力，业务研发周期比平常缩短 39%，整体老本降落 50%，经营效率晋升 3 倍，解决了洽购施行老本过高难题，助力商家疾速响应业务变动，降本增效成绩显著。
阿里团体外部一个外围业务的数据分析服务每天须要执行大量 ETL 离线作业，同时须要反对大量实时数据写入，以满足准实时的人群圈选服务和在线人群透视服务需要，反对数据实时写入和离在线混合负载的 AnalyticDB 始终是该服务的不二之选。往年双十一期间，AnalyticDB 承当了该服务数十 PB 数据读写申请，数百万次的离在线混合查问，实现 PB 级数据量的 ETL 作业。得益于 AnalyticDB 3.0 的云原生弹性能力，联合存储 / 计算 / 优化器 的全链路优化，老本同比去年双十一降落近 50%。
3 唯快不破：看库仓一体化架构如何反对高吞吐实时业务
往年双十一首次采纳 AnalyticDB+DMS 库仓一体化架构替换了 DRC+ESDB 实现全实时历史订单搜寻等外围场景，疾速搭建毫秒级提早的实时数据链路和数据利用，让实时数据的价值失去充分发挥，助力业务在更加实时的数据利用场景和更加极致的用户体验上产生新变动、获得新冲破。
在交易订单搜寻业务中，依据交易业务特点搭建了多路数据同步链路并采纳 AnalyticDB 主备容灾部署计划，双十一大促期间轻松反对 RPS 达数百万的峰值流量，全程毫秒级提早。
三 常胜之秘 | AnalyticDB 最新核心技术解析
1 离在线服务化存储
AnalyticDB 的存储层往年实现了服务化革新，具备一份数据、一套存储格局同时反对实时更新、交互式查问、离线 ETL 及明细点查多场景一体化能力。基于存储服务层、行列混存、分层存储、自适应索引等技术，可同时反对在线低提早 + 强统一和离线高吞吐两种数据读写场景。
存储服务：离在线对立拜访接口
接口层方面，AnalyticDB 存储向上提供对立的数据拜访接口，数据交互采纳 Apache Arrow[1]数据格式，基于零拷贝技术实现高效传输，计算层能够基于 Arrow 内存列式的接口进行 CPU 敌对的向量化计算减速；元数据兼容 Hive MetaService 的 Thrift 交互协定，开源计算引擎能够无缝对接 AnalyticDB 存储系统。
服务层方面，AnalyticDB 存储采纳类 LSM 架构[2]，把存储分为实时数据和历史数据两局部，实时数据存储在在线存储节点上，作为“热”数据，反对低提早数据拜访，且反对强统一 CURD。历史数据存储在 OSS 或 HDFS 等低成本的分布式文件系统上，作为“冷”数据，反对高吞吐数据拜访。同时，AnalyticDB 存储服务层还反对谓词、投影、聚合、Top N 等计算下推能力，缩小数据的扫描和读取量，进一步减速查问。
行列混存：离在线对立存储格局
既然提供了一体化的存储服务，必然会波及到在线低提早查问和离线高吞吐计算场景，AnalyticDB 存储格局采纳 PAX 格局 [3] 兼顾了离在线两种场景。
在线场景，与索引配合提供高效的检索查找能力。AnalyticDB 的存储格局每个 Chunk 定长存储，可能和索引深度交融，能够基于行号随机查找，保障高效的随机读性能，能够很好地满足在线多维度筛选的场景。此外，还提供了丰盛的统计信息，能够和索引配合做叠加优化，从而进一步减速查问。
离线场景，AnalyticDB 的存储格局能够依照 Chunk 粒度切分数据读取的并行度，多 Chunk 并行拜访，进步离线读的吞吐性能。AnalyticDB 的一张表反对多个分区，且分区内反对多 Segment，能够通过切分 Segment 来进步数据写入的并行度，从而进步离线写的吞吐性能。此外，每个 Chunk 提供了 Min/Max 等粗糙集索引信息，能够利用这些索引信息缩小离线读的数据扫描量和 IO 资源耗费。
自适应索引
AnalyticDB 另一个特色之一是自研自适应索引框架，反对五种索引类型：字符串倒排索引、Bitmap 索引、数字类型 KDTree 索引、JSON 索引和向量索引；不同类型的索引能够反对多种条件（交、并、差）下列级索引的任意组合；相较于传统数据库，AnalyticDB 的劣势在于，无需手工构建组合索引（组合索引须要精美的设计、且容易引起索引数据的空间收缩）、且反对 OR/NOT 等更多条件的索引下推。为了升高用户应用门槛，AnalyticDB 在建表时能够一键主动开启全列索引，查问时通过 Index CBO 自适应动静筛选索引下推，确定下推的索引链会通过谓词计算层进行流式渐进多路归并输入。
冷热分层：升高用户老本、按量计费
AnalyticDB 提供的冷热分层存储能力 4 能够为用户带来更高性价比的体验。用户能够按表粒度、表的二级分区粒度独立抉择冷、热存储介质，比方指定用户表数据全副存储在热存储介质，或指定表数据全副存储在冷存储介质，或指定表的一部分分区数据存储在热存储介质，另一部分分区数据存储在冷存储介质，齐全能够按业务需要自在指定，并且冷热策略能够自在转换。同时，热数据和冷数据的空间应用是按量计费的。业务能够依据本人的业务特点，基于 AnalyticDB 的冷热存储分层技术治理业务数据的生命周期，须要频繁拜访的数据分区指定为热数据存储在热存储介质以减速查问，不须要频繁拜访的数据分区指定为冷数据存储在冷存储介质以升高存储老本，通过数据分区的生命周期管理机制主动清理过期的数据。
2 离在线混合负载
在线场景的计算负载（比方在线查问）对响应工夫要求高，对数据读取和计算引擎的要求就是快；而离线场景的计算负载（比方 ETL 工作）对响应工夫不敏感，但对计算吞吐有较高要求，不仅数据计算量大，数据读取和写入量也可能很大，工作执行工夫长。离在线两种齐全不同场景的负载要在一套零碎、一个平台上同时执行始终以来都是一个微小的挑战。目前业界的支流解决方案依然是：离线工作运行在离线大数据计算平台（比方 hadoop/spark/hive）上，在线查问运行在另外一个或多个独自的 OLAP 零碎（比方 ClickHouse/Doris）上。不过在这种架构下，多个零碎外部的数据存储和格局不对立，计算逻辑示意（比方 SQL 规范）也不对立，导致数据须要在多个零碎之间互相导入导出，计算逻辑也须要别离适配对应的零碎，数据链路简短，数据计算和应用老本高，数据的时效性也不好。
为了解决此类问题，AnalyticDB 往年全面降级离在线混合负载能力，除了存储层提供离在线对立存储格局和对立拜访接口用以解决离在线混合负载的数据读取和写入问题，计算层也实现了全面降级，雷同的 SQL 查问能够同时反对 Interactive 和 Batch 两种执行模式，通过资源组、读写负载拆散、多队列隔离和查问优先级等机制对不同类型的负载进行资源隔离和管控，通过分时弹性满足不同负载的扩缩容和错峰需要。同时，计算引擎全面降级为向量化引擎，大幅晋升计算性能。
雷同 SQL 两种执行模式
AnalyticDB 反对 Interactive 和 Batch 两种执行模式，以别离满足在线查问和离线计算的不同场景需要。Interactive 模式下，查问以 MMP(Massive Parallel Processing)形式执行，所有 Task 同时调度启动，流式读取数据并计算输入后果，所有计算都在内存中进行，尽可能减少查问执行工夫，适宜在线场景负载。Batch 模式下，计算工作以 BSP(Bulk Synchronous Parallel)形式执行，整个工作会依据语义切分成多个阶段（Stage），依据 Stage 间的依赖关系进行调度和执行，上游 Stage 执行完才会执行上游 Stage，Stage 之间的数据传递须要落盘，计算过程中内存不足时也会将中间状态落盘，因而工作整体的执行工夫会较长，但对 CPU 和内存等计算资源的需要绝对较少，适宜数据大、计算资源绝对无限的离线场景。
在 AnalyticDB 外部，不论是 Interactive 模式还是 Batch 模式，表白计算逻辑的 SQL 是对立，产生的逻辑执行打算也是齐全一样的，只是依据不同的模式生成不同的物理执行打算，且计算引擎中绝大部分的算子实现也是雷同的，也为对立降级到向量化计算引擎奠定架构根底。
全新向量化查问引擎
向量化是当代查问引擎优化查问性能的热点技术之一，相干思路最早能够追溯到 Array programming 在科学计算畛域的钻研，在数据库畛域的摸索则缘起于 MonetDB/X100[6]。目前工业界各支流零碎都领有本人的向量化实际，但仍不足规范的形式化定义。一般来讲，它被认为是查问引擎面向 CPU microarchitecture 一系列优化计划的统称，波及 Batch based iterator model[7]，CodeGen，Cache-awareness 算法 [8] 以及 SIMD 指令集利用等技术利用，以及计算 / 存储一体化的架构设计。而摸索并辨认这些技术间正交 / 依赖的关系是利用好向量化技术获得显著性能晋升的关键问题。
AnalyticDB 实现了外围算子的全面向量化，包含 Scan，Exchange，Group-by/Agg，以及 Join 算子；计划里联合利用了 Batch Processing，Adaptive Strategy，Codegen 以及 Cache-awareness 算法，并通过与 JVM 团队共建，基于 AJDK intrinsic 能力 [9] 翻新地实现了算法要害门路上 SSE2，AVX512 等指令集的利用。显著晋升查问执行过程中 CPU IPL 和 MPL，热点算子 Agg/Join 的吞吐性能晋升 2x-15x。
混合负载隔离和稳定性保障
多种负载在同一架构下运行，甚至在同一时刻运行，不可避免存在资源竞争、相互影响的问题。AnalyticDB 有一套较为残缺的的机制和策略来保障集群的稳定性，并且尽可能满足不同业务负载的 SLA 要求。
首先，在混合负载场景或实例外部多租户场景下，能够通过资源组进行无效的业务负载隔离。不同资源组之间的计算资源在物理上齐全隔离，防止不同类型或业务的负载之间产生相互影响。不同的业务能够通过绑定账号、提交查问时指定资源组等多种形式指定运行在对应的资源组上。
其次，AnalyticDB 外部会主动辨别写入负载（局部 insert 和 delete）、查问负载（比方 select 查问）和读写负载（局部 insert/update/delete），不同类型的负载工作主动分派到不同的队列上，且调配不同的执行优先级和计算资源。具体来看，写入申请有独自的减速写入链路和资源保障，查问负载默认有较高的执行优先级，而读写负载则默认是较低的执行优先级。另外，在执行过程中，AnalyticDB 会依据集群的以后负载状况和查问工作已运行的时长，动静升高运行工夫较长的查问工作的执行优先级，以缓解 Slow Query 或 Bad Query 对其它查问产生的不利影响。
最初，很多业务都有非常明显的出现周期性的波峰波谷，特地是离线计算工作往往是周期性进行调度和执行的，业务高峰期时资源需要暴增可能导致业务不稳固，业务低峰期时资源闲置又导致额定的老本。AnalyticDB 提供分时弹性性能，能够帮忙用户在业务高峰期资源有余时扩容资源以保障业务负载稳固执行，在业务低峰期时缩减资源以节约老本。通过正当的业务布局和资源组治理，用户甚至能够让某些资源组在低峰期时开释所有资源，极大地节约老本。
3 全新优化器框架
近年来，自治（Autonomous）能力曾经成为数据库倒退的重要方向和趋势。与传统数据库相比，云数据库提供一站式托管服务，也对自治能力提出了更高的要求。为此，AnalyticDB 研发了全新的优化器架构，向更加智能化的自治数据库方向迈进，为用户带来更好的体验。
AnalyticDB 优化器进行了大面积的重构降级，主体上拆分成 RBO (Rule-based optimizer) 和 CBO (Cost-based optimizer)。RBO 负责做确定性的优化。比方，将过滤条件尽可能下推，以缩小后续算子的运算量。CBO 负责做不确定性的优化。比方，调整 JOIN 运算的程序。调整的收益是不确定的，所以须要通过代估模块来决策。为了让这两大模块更好的工作，给予用户更好的体验，AnalyticDB 引入了全新的四大个性。
个性 1：Histogram
直方图的引入，能够无效晋升代估的品质，让 CBO 选出更好的打算。直方图能够无效解决用户数据值的散布不均问题，无效解决代估中“均匀分布假如”问题。为了验证直方图成果，AnalyticDB 还构建了一套代估品质评估零碎。在灰度实例中，代估综合错误率降幅可达 50% 以上。
个性 2：Autonomous statistics
如何治理好表的统计信息，也是一个十分头疼的问题。如果把这个问题抛给用户，让用户执行命令去收集统计信息，会给用户带来微小的困扰。为此，AnalyticDB 引入了统计信息自治框架，来治理这个事件。AnalyticDB 会尽可能升高收集动作对用户的影响，带来最好的体验。AnalyticDB 会辨认出每一列须要收集的统计信息等级，不同等级收集开销不同。同时也会辨认出统计信息是否过期，来决定是否要从新收集。
个性 3：Incremental statistics
传统的统计信息收集形式，须要进行全表扫描。全表扫描开销大，对用户影响大，不合乎晋升用户体验的初衷。为此，AnalyticDB 引入了增量统计信息框架，能够只更新单个分区的统计信息，而后通过全局合并技术，失去整个表全局的统计信息。这样能够大幅升高收集的开销，缩小对用户的影响。
个性 4：Property derivation
如何让打算变得更优，属性推导对此有着重要的意义。它就像电影中的彩蛋，须要你去挖掘。咱们通过这个个性能够挖掘 SQL 中隐含的信息，从而进一步优化打算。比方，用户 SQL 写了“A=B”条件，之后又做了一次“GROUP BY A,B”，那么其实是能够简化成“GROUP BY A”或“GROUP BY B”。因为咱们通过属性推导，晓得了 A 等价于 B。
4 智能诊断和优化
智能诊断
AnalyticDB 的智能诊断性能交融逻辑执行打算和物理执行打算，从「Query 级别」,「Stage 级别」，「算子级别」三个档次诊断剖析，帮用户疾速定位问题 Query、Stage 和算子，间接给出直观的问题剖析，如数据歪斜、索引不高效、条件没下推等，并给出对应的调优倡议。目前曾经有 20+ 诊断规定上线，波及查问相干的内存耗费、耗时、数据歪斜、磁盘 IO 以及执行打算等多个方面，后续还有更多诊断规定陆续上线。
智能优化
AnalyticDB 的智能优化性能提供针对数据库、表构造的优化性能，为用户提供升高集群应用老本、进步集群应用效率的调优倡议。该性能基于 SQL 查问的性能指标以及应用到的数据表、索引等信息进行算法统计分析，主动给出调优倡议，缩小用户手动调优的累赘。智能优化目前提供三种类型的优化倡议：
1）冷热数据优化：剖析数据表的应用状况，对长期未应用的数据表，倡议将其迁徙至冷盘存储，约 60% 的实例能够通过该倡议的提醒，将 15 天未应用的数据表移至冷存，节俭 3 成以上的热存空间；
2）索引优化：剖析数据索引的应用状况，对长期未应用的数据索引，倡议将其删除，约 50% 的实例能够通过该倡议的提醒，将 15 天未应用的索引进行删除，节俭 3 成以上的热存空间；
3）分区优化：剖析数据查问理论须要应用的散布键与数据表定义的散布列之间的差别，对设计不合理的散布键，倡议变更该数据表的散布键，以进步数据的查问性能。
四 总结和瞻望
通过多年双十一的淬炼，AnalyticDB 不仅抗住了一年高过一年的的极其负载和流量，也在不断丰富的业务场景中逐渐成长，一直赋能到团体内外各种新老业务和场景中，逐渐成长为新一代云原生数据仓库的佼佼者。接下来 AnalyticDB 将持续以“人人可用的数据服务”为使命，进一步拥抱云原生，构建数据库 + 大数据一体化架构，建设极致弹性、离在线一体、高性价比、智能自治等企业级能力，进一步赋能用户开掘数据背地的商业价值。
原文链接
本文为阿里云原创内容，未经容许不得转载。