七幕 发布时间: 2019-01-11 14:51:34 浏览 194 评论 0
架构
性能
SQL
模块
数据库
高并发
OLAP
分析型数据库
兼容性
GPU
adb
存储
AnalyticDB
在线实时分析
摘要: 2018 年, 对 AnalyticDB 来说注定是非同凡响的一年, 在架构演进, 稳定性, 生态建设以及兼容性上均取得了长足的进步
题记
分析型数据库 AnalyticDB(下文简称 ADB), 是阿里巴巴自主研发, 唯一经过超大规模以及核心业务验证的 PB 级实时数据仓库. 截止目前, 现有外部支撑客户既包括传统的大中型企业和政府机构, 也包括众多的互联网公司, 覆盖外部十几个行业. 同时, ADB 在阿里内部承接着广告营销, 商家数据服务, 菜鸟物流, 盒马新零售等众多核心业务的高并发低延时的分析处理.
2018 年, 我们新增了深圳和湾区研发中心迎来更多专业精兵强将的加入, 也受到了众多业务场景挑战极大的客户鼎力支持, 注定让这一年在发展史上将留下深深的印记. 在过去的这一年, ADB 在架构以及产品化演进上, 迎来了飞速发展, 谨以此文记录一起走过的 2018 年.
架构演进
一. 接入层和 SQL Parser
1. 全面采用自研 Parser 组件 - FastSQL
由于历史原因, ADB 的各模块中曾有多个 Parser 组件, 例如当时存储节点用的是 Druid https://github.com/alibaba/druid/wiki/SQL-Parser , 接入层 SQL 解析用的是 Antlr Parser, 导致 SQL 兼容性难提升. 对于一个上线多年, 服务于内外众多数据业务的 ADB 来说, 熟悉数据库的同学都知道, 替换 Parser 难度之大, 堪比飞行中换引擎.
经过半年多的努力, ADB 完成了将上述几大 Parser 组件统一升级替换为 FastSQL ( Base on Druid, 经过开源社区 8 年的完善, 语法支持已经非常完备). 升级为 FastSQL 后, 在 SQL 兼容性大幅度提升, 复杂场景解析速度提升 30-100 倍的同时, FastSQL 还能无缝结合优化器, 提供常量折叠, 函数变换, 表达式转换, 函数类型推断, 常量推断, 语义去重等功能支持, 方便优化器生成最优的执行计划.
2. 实时写入性能提升 10 倍
在 ADB v2.7.4 版本开始, 在 SQL Parser 上做了深度技术优化, 大幅度提升了 INSERT 环节的性能, 在实际生产环境中性能 10 倍性能提升, 以云上 4*C4 为例, item 表可以压测到 15w TPS.
3. 海量数据流式返回
在 ADB v2.7 以前的版本, 计算框架返回的数据, 需要在内存中堆积, 等待全部执行完才返回到客户端. 在并发大或者结果大时, 可能有内存溢出的风险. 从 2.7 版本开始, 默认采用流式返回, 数据实时返回客户端, 能降低延时, 极大的提升了大结果集返回的调用稳定性.
二. Query Optimizer
2018 年, 一方面云上云下业务全面从 ADB 上一代的 LM 引擎, 迁移至羲和 MPP 引擎, 另一方面越来越多的客户不希望走离线或者流计算清洗, 实时数仓场景迸发, 同时越来越多自动生成 SQL 的可视化工具开始对接 ADB, 对优化器团队提出了极高挑战.
为了应对这些挑战, 在这一年里优化器团队从无到有, 逐渐组建起来一支精练的国际化团队. 在不断打造磨合过程中, ADB 优化器这一年的斩获如下:
1. 建立并完善 RBO Plus 优化器
不同于传统 RBO 优化器, 在 RBO Plus 设计中实现了下列关键特性:
1). 引入代价模型和估算, 利用 ADB 的高效存储接口, 引入 dynamic selectivity & cardinality 估算优化 join reorder, 使得 ADB 可以应对多达 10 + 表 join 的复杂查询场景.
2). 针对 MPP 特别优化 data shuffling,aggregation 等执行计划, 相对于 LM 引擎业务场景性能接近零回退.
3). 从功能和性能两个维度, 对各种常见以及复杂关联子查询场景进行了深度优化, 设计了一系列关联规则算法, 在各种标准 benchmark 中相应的查询中, 部分场景 up to 20X 提升.
4). 针对超短时延 (ms) 点查, 设计了 parameterized plan cache, 将这些场景的优化时间成本降低 10 倍以上.
2. 打造 CBO 优化器
面对越来越复杂的业务查询场景, RBO 及 RBO Plus 有其相应的局限和挑战, CBO 成为 ADB 优化器迈向通用商业优化器的关键, 我们没有采用虽广泛使用但局限性也很多的 Calcite 优化器, 而是着手打造自主可控的 CBO 优化器, 提升 ADB 的核心竞争力:
1) 建立高效的统计信息收集体系, 平衡准确性与收集代价, 为 CBO 提供 "基础信息设施";
2) 构建 Cascades 架构的 CBO 框架, 将其打造成可扩展的优化平台.
三. 羲和 MPP 引擎
这一年, ADB 架构全面从上一代的 LM 引擎切换至羲和 MPP 引擎, 羲和引擎一方面既要支撑完成切换, 满足客户更灵活自由查询的重任, 又要通过大幅度的性能优化来消除引擎切换带来的某些场景下的性能开销.
1. 全 Binary 计算
基于 Binary 的计算, 省去 Shuffle 的序列化和反序列化开销, 并且与存储深度绑定, 做到存储计算一体化, 整个计算过程没有多余的序列化和反序列化开销.
2. 内部池化
通过定长的内存切片完成池化, 在计算过程中减少了连续内存扩容带来的消耗, 同时通过池化完全自主管控内存, 避免了在复杂 SQL 场景下的 GC 消耗.
3.CodeGen 深度优化
1). Cache 使用, 通过对算子, 表达式的 CodeGen 常量抽取, 缓存 CodeGen 生成的代码, 在高并发场景下避免了每次都需要动态编译代码的开销, 为支持高并发和 QPS 的业务打好了基础.
2). 通过算子融合减少算子之间物化的开销.
4. 其它优化
1). 按列计算, 通过列式计算与 JVM 团队合作引入 JDK11 支持新的 SIMD 指令集进行计算优化
2). 自动算法优化, 根据数据分布, 数据采样自动优化部分执行算法和内存;
3). 算子自适应的 Spill, 支持动态的内存分配和抢占, 支持 join,agg 等算子落盘;
4). 引入新的序列化和反序列框架替换原有的 JSON 协议, 引入新的 Netty 替换原有 Jetty
5). 支持运行时统计信息收集, 包括算子级, stage 级, query 级的内存, CPU cost 统计, 支持部分自动识别慢 SQL.
四. 玄武存储引擎
为了满足业务高并发写入, 低延时的查询, ADB 做了读写分离架构设计. 在历史的版本中, 读写分析架构下有 2 个问题: 1. 写入到可见是异步的, 部分场景有读写强一致性的诉求. 2. 增量数据写入较大的情况下, 查询变慢. 同样, 今年存储引擎在增量数据的实时性和性能上也做出了重大突破.
1. 支持读写强一致性
最新的 ADB 版本中, 设计了一套完备的一致性读写分离架构, 如下图所示:
蓝色线代表写入链路, 橙色线代表读取链路. 以一次写入和读取为例, 当用户新写入某表的数据后, 立即发起查询, 此时 FN 会收集该表在所有 BN 上的最新写入版本号 (step 3), 并将该版本号(标记为 V1) 信息随同查询请求一同发往对应的 CN 节点 (step 4),CN 比对该表在本地的消费版本(记为 V2) 和请求的版本号.
若 V1>V2,CN 消费到该最新写入数据 (step 5) 后提供查询; 若 V1
2. 提升增量数据区的查询性能
在 ADB 的存储节点对于突发的大批量实时写入, 在增量数据区可能短时间内积累较多数据. 如果查询发生在增量数据区, 大量的 table scan 读取会拖慢整个数据分析性能. 为此增量数据区引入 RocksDB 构建增量数据的索引, 保证增量数据区的访问性能, 通过 LSM-Tree 的分层存储结果, 提供良好的写入性能, 及较好的查询能力.
五. 分布式 Meta 服务
历史版本元数据稳定性挑战大, 各模块各自访问元数据存在 race condition,meta 压力大, DDL 体验差. 今年我们重构了元数据模块, 上线 GMS 服务提供元数据统一管理, 同时提供分布式 DDL 能力, 并通过分布式缓存降低 meta 库压力, 提供高效元数据访问效率.
全局元数据服务发布
1). Global Meta Service (GMS)上线生产, 提供分布式 DDL 和数据调度能力, 同步建删表提升用户体验.
2). 表分区分配算法改进, 为计算调度优化, 支持多表组场景下的数据均匀分布
3). 数据更新 (上线), 数据重分布(Rebalance) 稳定性大大提升
六. 硬件加速
GPU 虽然已经广泛用于通用计算, 但是通常是用于图形处理, 机器学习和高性能计算等领域. 如何将 GPU 的强大计算能力和 ADB 进行有机结合, 并不是一个容易解决的问题. 要想用好 GPU, 在 GPU 资源管理, 代码生成, 显存管理, 数据管理, 执行计划优化等方便, 均有诸多挑战.
2018 年, ADB 引入了 GPU 作为计算加速引擎, 原本依赖离线分析引擎, 隔天才能完成的计算, 现在只需要秒级延迟即可完成, 成功将数据价值在线化, 为客户带来了巨大的价值.
1.GPU 资源管理
如何让去访问 GPU 资源是首先要解决的问题. ADB 通过 jCUDA 调用 CUDA API, 用于管理和配置 GPU 设备, GPU kernel 的启动接口封装. 该模块作为 Java 和 GPU 之间的桥梁, 使得 JVM 可以很方便地调用 GPU 资源.
2.CodeGen
ADB 的执行计划是为 CPU 做准备的, 无法在 GPU 上执行. 而且由于 GPU 架构的特殊性, GPU 的编程模型也和 CPU 不同. 为了解决这一问题, 引入新的 CodeGen 模块. CodeGen 先是借助 LLVM API 将物理计划编译成 LLVM IR,IR 经过优化以后通过转换成 PTX 代码. 然后调用 CUDA 将 PTX 代码转换成本地可执行代码, 并启动其中的 GPU 计算函数.
CodeGen 可以针对不同的处理器生成不同的代码, 在 GPU 不可用时, 也可以转至 CPU 进行执行. 相对传统火山模型, ADB 的 CodeGen 模块有效减少函数调用的开销, 充分利用 GPU 的并发能力. 另外 Code Generator 利用了算子融合, 如 group-by 聚合, join 再加聚合的融合, 大大减少中间结果 (特别是 Join 的连接结果) 的拷贝和显存的占用.
3. 显存管理
ADB 开发了 VRAM Manager 用于管理各 GPU 的显存. 有别于现在市面上其他 GPU 数据库系统使用 GPU 的方式, 为了提升显存的利用率, 提升并发能力, 结合 ADB 多分区, 多线程的特点, 我们设计基于 Slab 的 VRAM Manager 来统一管理所有显存申请.
性能测试显示分配时间平均为 1ms, 明显快于 GPU 自带的显存分配接口的 700ms, 有利于提高系统整体并发度.
4.Plan 优化
SQL 从 FN 发送到 CN,Task Manager 先根据计算的数据量以及查询特征选择由 CPU 还是 GPU 处理, 然后根据逻辑计划生成适合 GPU 执行的物理计划. GPU Engine 收到物理计划后先对执行计划进行重写. 如果计划符合融合特征, 则启动复合算子融合, 从而大量减少算子间临时数据的传输成本.
产品化能力升级
一. 易用性提升
1. 全面切换羲和 MPP 引擎
从 2.6.2 版本开始, 集团内和公有云全部默认 MPP 引擎, 彻底告别上一代 LM 引擎的各种查询限制. MPP 对 SQL 写法支持更加自由灵活, ADB 客户迎来 Full MPP 时代.
2.SQL 兼容性大幅度提升
接入层, 存储层 Parser 模块全部升级为 FastSQL 后, 外加切换 MPP 成功, ADB v2.7 以后的 SQL 兼容性较历史版本有了非常大提升. SQL 其他优化还包括支持了流式后不再限制查询结果集返回, 分页兼容 MySQL 等等.
3. 自动扩缩容, 升降配
6 月份发布了重磅功能: 自动扩缩容 + 灵活升降配. 除了扩缩基本能力外, 客户还可以在规格之间切换. 例如从 10c4 切换至 4c8, 可以从 4c8 切换至 10c4, 同时实时表还支持在高性能 SSD 实例和大存储 SATA 实例间来回切换.
上线效果: 配置切换做到读不中断, 写入中断约 1-2 分钟, 后续通过动态漂移分区, 写入也能做到完全不停服.
4. 新版控制台和 DMS 上线
公有云新版的控制台展示的内容更加丰富, 支持控制台打点, 查看用户画像; 增加了更多和用户交互的地方. 用户管理, acl 和子账号授权更加便捷等. DMS 全新改版, 体验大幅度提升, 方便导入导出, 支持 SQL 提示和 SQL 记忆功能.
5. 发布面向用户侧的监控告警系统
为提升客户的自助化服务能力, 用户侧的监控支持的指标有 CPU 使用量, 查询和写入量, 数据倾斜, Top Slow SQL 等.
6. 全网数据库监控大盘上线
这是全网数据库的眼睛, 弹内云上数据库运行状况一览无遗. 通过对数据库和系统层各种指标的埋点分析, 时刻监控着数据库的运行状况, 如下图所示(demo 数据), 同时支持将异常指标推送客户钉钉群, 大幅度提升了运营值班效率.
7. 发布可用区
这一年公共云发布多可用区支持, 彻底解决单个 region 卖空的问题, 企业客户还可以有选择的利用可用区做服务容灾.
二. 发布新的核心功能
1. 向量分析
今年 9 月正式发布向量分析能力, 使得结构化与非结构化数据具备融合分析的能力. 基于向量聚类规律的向量分区规则, 按照聚类结果分区, 让距离相近的向量就近存储. 在某专有云项目里, 支持 1:10 亿的人脸识别, QPS 过万, 延迟在 100 毫秒内, 数据量达到数 TB 级别.
同时首次支撑银泰, 盒马等新零售场景的人脸识别, 算法推荐, 与结构化数据实时融合分析, 毫秒级打通线上线下会员体系, 支撑实时数据化线下互动, 营销.
2. 全文检索
ADB v2.7.4 版本后, 通过 SQL 语言提供全文检索功能, 将常用的结构化数据分析操作, 与灵活的非结构化数据分析操作统一, 使用同一套 SQL 语言操作多种类型数据, 降低了学习和开发成本. 一方面提供结构化数据, 非结构化文本的融合检索, 多模分析能力, 另一方面基于 MPP+DAG 技术提供了完善的分布式计算能力, 同时内置了来自淘宝, 天猫搜索的智能分词组件, 分词效果更好, 速度更快.
3. 新数据类型 JSON & Decimal
在 2.7 版本, 正式发布 JSON 数据类型, 完整的支持了包括 Object,NULL,Array 在内的所有 JSON 类型的检索分析, 为业务提供了 Schema Less 的极大灵活性, 同时也提供了快速的检索性能. 为了更好方便金融客户, 同样在 2.7 版本里, ADB 正式发布 Decimal 数据类型, 向传统数据库的数据类型兼容性上又迈出了重要的一步.
三. 生态建设
1. 数据接入
客户数据往往有多种多样, 存储在各种地方. 为了追求更低成本, 更高效率的数据接入能力, 打造实时数仓的能力, ADB 今年在数据接入上做了诸多的完善.
1). Copy From OSS & MaxCompute 开发完成, 元旦后上线.
2). ADB Uploader 发布, 方便本地文件快速导入.
3). ADB 发布 Logstash 插件, 方便日志数据 format 后直接写入 ADB, 中间无需经过 MQ 或者 HUB.
4). ADB Client SDK 发布并开源, 客户端写入编程逻辑简化, 聚合写入性能大幅度提升.
5). Batch 表导入稳定性大大提升, 同时完成 MaxCompute SDK 升级和 OpenMR 切换.
6). Connector Service 上线, 提供统一数据源接入层
接下来 ADB 计划基于现有框架接入更多数据源(图中灰色部分)
2. 行业云接入
完成金融云, 物流云, 聚石塔三大行业云接入, 使得金融, 物流, 电商中小企业也能享受到低成本的实时数据分析能力, 提升企业精细化数据运营的水平.
望未来
2018 年, 对 AnalyticDB 来说注定是非同凡响的一年, 在架构演进, 稳定性, 生态建设以及兼容性上均取得了长足的进步. 这一年我们成功入选全球权威 IT 咨询机构 Forrester 发布 "The Forrester Wave™: CloudData Warehouse,Q4 2018" 研究报告的 Contenders 象限, 以及 Gartner 发布的分析型数据管理平台报告 (Magic Quadrant forData Management Solutions for Analytics), 开始进入全球分析市场.
展望未来, 我们接下来将继续在分析性能, 稳定性, 以及产品化(易用性, 数据通道, 任务管理, 可视化等周边生态建设) 上继续做广, 做深! ADB 旨在帮客户将整个数据分析和价值化从传统的离线分析带到下一代的在线实时分析模式. 谢谢一路陪我们成长的客户! 感恩, 感谢!
点击即可 0 元试用 AnalyticDB
来源: https://yq.aliyun.com/articles/686256