万字长文揭秘：阿里如何实现海量数据实时分析？

最新推荐文章于 2024-05-28 18:21:02 发布

阿里技术_

最新推荐文章于 2024-05-28 18:21:02 发布

阅读量3k

点赞数 1

本文链接：https://blog.csdn.net/b0Q8cpra539haFS7/article/details/85085842

版权

640?wx_fmt=jpeg

阿里妹导读：随着数据量的快速增长，越来越多的企业迎来业务数据化时代，数据成为了最重要的生产资料和业务升级依据。本文由阿里AnalyticDB团队出品，近万字长文，首次深度解读阿里在海量数据实时分析领域的多项核心技术。

数字经济时代已经来临，希望能和业界同行共同探索，加速行业数字化升级，服务更多中小企业和消费者。

欢迎转发、收藏此文

挑战

随着数据量的快速增长，越来越多的企业迎来业务数据化时代，数据成为了最重要的生产资料和业务升级依据。伴随着业务对海量数据实时分析的需求越来越多，数据分析技术这两年也迎来了一些新的挑战和变革：

在线化和高可用，离线和在线的边界越来越模糊，一切数据皆服务化、一切分析皆在线化。
高并发低延时，越来越多的数据系统直接服务终端客户，对系统的并发和处理延时提出了新的交互性挑战。
混合负载，一套实时分析系统既要支持数据加工处理，又要支持高并发低延时的交互式查询。
融合分析，随着对数据新的使用方式探索，需要解决结构化与非结构化数据融合场景下的数据检索和分析问题。

阿里巴巴最初通过单节点Oracle进行准实时分析, 后来转到Oracle RAC，随着业务的飞速发展, 集中式的Shared Storage架构需要快速转向分布式，迁移到了Greenplum，但不到一年时间便遇到扩展性和并发的严重瓶颈。为了迎接更大数据集、更高并发、更高可用、更实时的数据应用发展趋势，从2011年开始，在线分析这个技术领域，阿里实时数仓坚定的走上了自研之路。

640?wx_fmt=png

分析型数据库AnalyticDB

AnalyticDB是阿里巴巴自主研发、唯一经过超大规模以及核心业务验证的PB级实时数据仓库。自2012年第一次在集团发布上线以来，至今已累计迭代发布近百个版本，支撑起集团内的电商、广告、菜鸟、文娱、飞猪等众多在线分析业务。

AnalyticDB于2014年在阿里云开始正式对外输出，支撑行业既包括传统的大中型企业和政府机构，也包括众多的互联网公司，覆盖外部十几个行业。AnalyticDB承接着阿里巴巴广告营销、商家数据服务、菜鸟物流、盒马新零售等众多核心业务的高并发分析处理，每年双十一上述众多实时分析业务高峰驱动着AnalyticDB不断的架构演进和技术创新。

经过这2年的演进和创新，AnalyticDB已经成长为兼容MySQL 5.x系列、并在此基础上增强支持ANSI SQL:2003的OLAP标准（如window function）的通用实时数仓，跻身为实时数仓领域极具行业竞争力的产品。近期，AnalyticDB成功入选了全球权威IT咨询机构Forrester发布"The Forrester Wave™: CloudData Warehouse,Q4 2018"研究报告的Contenders象限，以及Gartner发布的分析型数据管理平台报告 (Magic Quadrant forData Management Solutions for Analytics)，开始进入全球分析市场。AnalyticDB旨在帮客户将整个数据分析和价值化从传统的离线分析带到下一代的在线实时分析模式。

整体架构

经过过去2年的架构演进和功能迭代，AnalyticDB当前整体架构如下图。

AnalyticDB是一个支持多租户的Cloud Native Realtime Data Warehouse平台，每个租户DB的资源隔离，每个DB都有相应独立的模块（图中的Front Node, Compute Node, Buffer Node），在处理实时写入和查询时，这些模块都是资源(CPU, Memory)使用密集型的服务，需要进行DB间隔离保证服务质量。同时从功能完整性和成本优化层面考虑，又有一系列集群级别服务（图中绿色部分模块）。

640?wx_fmt=png

下面是对每个模块的具体描述：

DB级别服务组件：

Front Node：负责JDBC, ODBC协议层接入，认证和鉴权，SQL解析、重写；分区地址路由和版本管理；同时优化器，执行计划和MPP计算的调度模块也在Front Node。
Compute Node：包含MPP计算Worker模块，和存储模块（行列混存，元数据，索引）。
Buffer Node：负责实时写入，并根据实时数据大小触发索引构建和合并。

集群级别服务组件：

Management Console：管理控制台。
Admin Service：集群管控服务，负责计量计费，实例生命周期管理等商业化功能，同时提供OpenAPI和InnerAPI给Management Console和第三方调用。
Global Meta Service：全局元数据管理，提供每个DB的元数据管理服务，同时提供分区分配，副本管理，版本管理，分布式DDL等能力。
Job Service：作业服务，提供异步作业调度能力。异步作业包括索引构建、扩容、无缝升级、删库删表的后台异步数据清理等。
Connector Service：数据源连接服务，负责外部各数据源（图中右侧部分）接入到AnalyticDB。目前该服务开发基本完成，即将上线提供云服务。
Monitoring & Alerting Service：监控告警诊断服务，既提供面向内部人员的运维监控告警诊断平台，又作为数据源通过Management Console面向用户侧提供数据库监控服务。
Resource Management Service：资源管理服务，负责集群级别和DB级别服务的创建、删除、DNS/SLB挂载/卸载、扩缩容、升降配，无缝升级、服务发现、服务健康检查与恢复。

数据模型

AnalyticDB中表组(Table Group)分为两类：事实表组和维度表组。

事实表组(Fact Table Group)，表组在AnalyticDB里是一个逻辑概念，用户可以将业务上关联性比较多的事实表放在同一个事实表组下，主要是为了方便客户做众多数据业务表的管理，同时还可以加速Co-location Join计算。
维度表组(Dimension Table Group)，用于存放维度表，目前有且仅有一个，在数据库建立时会自动创建，维度表特征上是一种数据量较小但是需要和事实表进行潜在关联的表。

AnalyticDB中表分为事实表(Fact Table)和维度表(Dimension Table)。

事实表创建时至少要指定Hash分区列和相关分区信息，并且指定存放在一个表组中，同时支持List二级分区。

Hash Partition将数据按照分区列进行hash分区，hash分区被分布到多个Compute Node中。
List Partition(如果指定List分区列的话)对一个hash分区进行再分区，一般按照时间(如每天一个list分区)。
一个Hash Partition的所有List Partition默认存放于同一个Compute Node中。每个Hash Partition配有多个副本（通常为双副本），分布在不同的Compute Node中，做到高可用和高并发。

维度表可以和任意表组的任意表进行关联，并且创建时不需要配置分区信息，但是对单表数据量大小有所限制，并且需要消耗更多的存储资源，会被存储在每个属于该DB的Compute Node中。

下图描述了从Database到List分区到数据模型：

640?wx_fmt=png

对于Compute Node 来说，事实表的每个List分区是一个物理存储单元（如果没有指定List分区列，可认为该Hash分区只有一个List分区）。一个分区物理存储单元采用行列混存模式，配合元数据和索引，提供高效查询。

海量数据

基于上述数据模型，AnalyticDB提供了单库PB级数据实时分析能力。以下是生产环境的真实数据：

阿里巴巴集团某营销应用单DB表数超过20000张
云上某企业客户单DB数据量近3PB，单日分析查询次数超过1亿
阿里巴巴集团内某单个AnalyticDB集群超过2000台节点规模
云上某业务实时写入压力高达1000w TPS
菜鸟网络某数据业务极度复杂分析场景，查询QPS 100+

导入导出

灵活的数据导入导出能力对一个实时数仓来说至关重要，AnalyticDB当前既支持通过阿里云数据传输服务DTS、DataWorks数据集成从各种外部数据源导入入库，同时也在不断完善自身的数据导入能力。整体导入导出能力如下图（其中导入部分数据源当前已支持，部分在开发中，即将发布）。

640?wx_fmt=png

★ 数据导入

首先，由于AnalyticDB兼容MySQL5.x系列，支持通过MySQL JDBC方式把数据insert入库。为了获得最佳写入性能，AnalyticDB提供了Client SDK，实现分区聚合写的优化，相比通过JDBC单条insert，写入性能有10倍以上提升。对于应用端业务逻辑需要直接写入AnalyticDB的场景，推荐使用AnalyticDB Client SDK。

同时，对于快速上传本地结构化的文本文件，可以使用基于AnalyticDB Client SDK开发的Uploader工具。对于特别大的文件，可以拆分后使用uploader工具进行并行导入。

另外，对于OSS，MaxCompute这样的外部数据源，AnalyticDB通过分布式的Connector Service数据导入服务并发读取并写入到相应DB中。Connector Service还将支持订阅模式，从Kafka，MQ，RDS等动态数据源把数据导入到相应DB中。AnalyticDB对大数据生态的Logstash，Fluentd，Flume等日志收集端、ETL工具等通过相应插件支持，能够快速把数据写入相应DB。

今天在阿里巴巴集团内，每天有数万张表从MaxCompute导入到AnalyticDB中进行在线分析，其中大量导入任务单表数据大小在TB级、数据量近千亿。

★ 数据导出

AnalyticDB目前支持数据导出到OSS和MaxCompute，业务场景主要是把相应查询结果在外部存储进行保存归档，实现原理类似insert from select操作。insert from select是把查询结果写入到内部表，而导出操作则是写入外部存储, 通过改进实现机制，可以方便地支持更多的导出数据源。

核心技术

高性能SQL Parser

AnalyticDB经过数年的发展，语法解析器也经历了多次更新迭代。曾经使用过业界主流的 Antlr（http://www.antlr.org），JavaCC(https://javacc.org)等Parser生成器作为SQL 语法解析器，但是两者在长期、大规模、复杂查询场景下，Parser的性能、语法兼容、API设计等方面不满足要求，于是我们引入了自研的SQL Parser组件FastSQL。

★ 领先业界的Parser性能

AnalyticDB主打的场景是高并发、低延时的在线化分析，对SQL Parser性能要求很高，批量实时写入等场景要求更加苛刻。FastSQL通过多种技术优化提升Parser性能，例如：

快速对比：使用64位hash算法加速关键字匹配，使用fnv_1a_64 hash算法，在读取identifier的同时计算好hash值，并利用hash64低碰撞概率的特点，使用64位hash code直接比较，比常规Lexer先读取identifier，在查找SymbolTable速度更快。
高性能的数值Parser：Java自带的Integer.parseInt()/Float.parseFloat()需要构造字符串再做parse，FastSQL改进后可以直接在原文本上边读取边计算数值。
分支预测：在insert values中，出现常量字面值的概率比出现其他的token要高得多，通过分支预测可以减少判断提升性能。

以TPC-DS99个Query对比来看，FastSQL比Antlr Parser（使用Antlr生成）平均快20倍，比JSQLParser（使用JavaCC生成）平均快30倍，在批量Insert场景、多列查询场景下，使用FastSQL后速度提升30~50倍。

640?wx_fmt=png