关于数据:基于-MaxCompute-的实时数据处理实践

简介：MaxCompute 通过流式数据高性能写入和秒级别查问能力(查问减速)，提供 EB 级云原生数仓近实时剖析能力；高效的实现对变动中的数据进行疾速剖析及决策辅助。以后 Demo 基于近实时交互式 BI 剖析 / 决策辅助场景，实现指标卡近实时 BI 剖析、近实时市场监测、近实时趋势剖析、近实时销量拆分性能。

本文作者 隆志强 阿里云智能 高级产品专家

一、产品性能介绍

基于查问减速的数仓架构

以后比拟流行的实时数仓，根本都是基于 Flink 来做的。明天分享的内容不是把 MaxCompute 定义为一个实时数仓，咱们讲的是基于以后数据的实时处理流程，在 MaxCompute 中是怎么去做反对的，怎么在 MaxCompute 中做实时数据的接入、查问、利用。开源的实时数仓是基于 Flink 来做的，Flink 实质是实时计算，反对流批一体，所以比拟实时的场景都是基于 Flink+Kafka+ 存储来做的。本次分享次要不是讲计算环节，本次次要解说基于 BinLog、Flink、Spark Streaming 的实时流数据是怎么写入到 MaxCompute 中的。

通过实时流通道，实时写入 MaxCompute，写入即可见，这是 MaxCompute 的产品特点。目前市场的数仓产品写入查问绝大多数都有延时存在，MaxCompute 是做到了高 QPS 的实时写入，写入即可查。能够通过查问减速 (MCQA) 实时查问写入进 MaxCompute 的数据。对接到 BI 工具，即席查问能够实时拜访到实时写入的数据。

Binlog 写到到 MaxCompute，是通过 DataX，反对增删改查的合并，后续在产品性能迭代中，MaxCompute 会反对 upsert，反对业务数据库数据的新增、批改、删除。Flink 数据计算完之后写入到 MaxCompute 时，间接应用 Streaming Tunnel 插件写入 MaxCompute 中，这个过程不须要做代码开发，Kafka 也反对了插件。

实时写入目前没有做写入数据的计算解决环节，只是疾速的把当初流式数据包含音讯服务的数据，间接通过 Streaming Tunnel 服务写入到 MaxCompute 中。以后 Streaming Tunnel 反对了支流音讯服务，如 Kafka、Flink，做了插件反对。以及 Streaming Tunnel SDK，以后只反对 Java SDK。能够通过 Streaming Tunnel SDK 做一些利用读取之后的逻辑解决，再调取 Streaming Tunnel SDK 写入到 MaxCompute 中。写入 MaxCompute 之后，目前次要的解决环节是针对写入的数据，进行直读查问，也能够把写入的数据关联到 MaxCompute 中的离线数据，做联结查问剖析。在查的过程中，如果是通过 SDK 或者 JDBC 接入时，能够关上查问减速（MCQA)性能。如果是通过 web console 或 DataWorks，是默认开启查问减速（MCQA）性能。以后次要是 BI 剖析工具和第三方应用层剖析工具，通过 SDK 或 JDBC 链接 MaxCompute 时，是能够关上查问减速（MCQA）性能，这样能够做到靠近秒级查问实时写入的数据。

整体来看，当初的场景次要是数据的实时流式写入，写入之后能够联合离线数据，做联结剖析查问，通过查问减速（MCQA）性能。在数据进入 MaxCompute 后，是没有做计算的，只是做查问服务。这是目前基于 MaxCompute 实时数据处理场景。

流式数据写入性能介绍

以后流式数据写入性能曾经在中国区商业化公布。以后此性能是收费应用。

性能特定

• 反对高并发、高 QPS（Queries-per-second）场景下流式数据写入，写入即可见。
• 提供流式语义 API：通过流式服务的 API 能够不便的开发出分布式数据同步服务。
• 反对主动创立分区：解决数据同步服务并发创立分区导致的并发抢锁问题。
• 反对增量数据异步聚合（Merge）：晋升数据存储效率。
• 反对增量数据异步 zorder by 排序功能，zorder by 详情请参见插入或覆写数据（INSERT INTO | INSERT OVERWRITE）。

性能劣势

• 更优化的数据存储构造，解决高 QPS 写入导致的碎片文件问题。
• 数据链路与元数据拜访齐全隔离，解决高并发写入场景下元数据拜访导致的抢锁提早和报错问题。
• 提供了增量数据异步解决机制，能够在应用过程中无感知状况下对新写入的增量数据做进一步解决，曾经反对的性能包含：
• 数据聚合（Merge）：晋升存储效率。
• zorder by 排序：晋升存储、查问效率。

流式数据写入 - 技术架构

Stream API 无状态并发数据实时可见

技术架构分为三个局部：数据通道、流计算数据同步、自研利用。

以后数据通道反对的有 Datahub、Kafka、TT、SLS

流计算数据同步反对的有 Blink、Spark、DTS、DataX、kepler/DD

数据写入 MaxCompute 中，在计算集群前会有 Tunnel 集群存在，提供 Stream Tnnel 服务来实现从客户端到 Tunnel 服务端数据的写入。写入过程是一个文件最佳的过程，最初会有一个文件的合并。这个过程是耗费了数据通道过程中的计算资源服务，但这一耗费是收费的。

查问减速性能介绍

实现数据实时写入与基于查问减速的交互式剖析

目前查问减速性能能够反对日常查问 80%-90% 的场景。查问减速性能的语法与 MaxCompute 内置语法完全一致。

MaxCompute 查问减速 – 针对实时性要求高的查问作业，全链路放慢 MaxCompute 查问执行速度

• 应用 MaxComputeSQL 语法和引擎，针对近实时场景进行优化
• 零碎主动进行查问优化抉择，同时反对用户抉择延时优先还是吞吐优先的执行形式
• 针对近实时场景应用不同的资源调度策略：latencybased
• 针对低延时要求的场景进行全链路优化：独立执行资源池；多层次的数据和 metaCaching；交互协定优化

收益

• 简化架构，查问减速与海量剖析自适应的一体化计划
• 比照一般离线模式快几倍甚至数十倍
• 联合 MaxCompute 流式上传能力，反对近实时剖析
• 反对多种接入形式，易集成
• 反对自动识别离线工作中的短查问，后付费模式是默认开启。预付费以后反对为应用包年包月资源的实例下 SQL 扫描量在 10 GB 以内的查问作业提供收费查问减速服务。
• 低成本，免运维，高弹性

查问减速 - 技术架构

自适应执行引擎、多层次缓存机制

当 SQL 提交到 MaxCompute 计算引擎时，会分为两个模式，离线作业(吞吐量优化）和短查问(提早优化）。两个模式从技术底层来说，查问减速作业做了执行打算的缩减和优化，计算资源是预拉起资源，是向量化执行，会基于内存 / 网络 shuffle 以及多层次的缓存机制。相比于离线作业的代码生产到磁盘 shuffle，再进行资源排队申请。查问减速会进行辨认作业，如果符合条件，则间接进入预拉起资源。在数据缓存局部，基于 Pangu 分布式文件系统，对表跟字段会有一个缓存机制。

查问减速 - 性能比对

TPCDS 测试集与某业界当先竞品的性能比拟

• 100GB 超越 30% 以上
• 1TB 规模性能并驾齐驱

二、利用场景

流式数据写入 - 利用场景

查问减速 - 利用场景

固定报表疾速查问

• 数据 ETL 解决为面向生产的聚合数据
• 满足固定报表 / 在线数据服务需要，秒级查问
• 弹性并发 / 数据缓存 / 易集成

通过数据利用工具或者是 BI 剖析工具通过 JDBC/SDK 接入到 MaxCompute，能够直读到 MaxCompute 内的表数据。

Ad-hoc 数据摸索剖析

• 自动识别作业特色，依据数据规模、计算复杂度抉择不同的执行模式，简略查问跑的快、简单查问算得动
• 配合存储层建模优化，如分区、HashClustering 等进一步优化查问性能

• 近实时经营剖析
• 反对批量和流式数据接入
• 历史数据和近实时数据交融剖析
• 产品级别集成音讯服务：
• Datahub- 日志 / 音讯
• DTS- 数据库日志
• SLS- 行为日志
• Kafka- 物联网 / 日志接入

三、工具及接入

流式数据写入 - 接入

音讯 & 服务

• 音讯队列 Kafka（插件反对）
• Logstash 的输入插件（插件反对）
• Flink 版内置插件
• DataHub 实时数据通道(外部插件）

SDK 类新接口 -Java

• 简略上传示例
• 多线程上传示例
• 异步化 IO 多线程上传示例

参考上述示例能够本人封装相应的业务逻辑。

查问减速 - 接入

工具类

• DataWorks（默认开启）
• ODPS CMD（须要配置）
• MaxCompute Studio（须要配置）

SDK 类接口

• ODPS JavaSDK
• ODPS PythonSDK
• JDBC

老接口兼容

• 自动识别模式

四、Demo& 总结

基于 MaxCompute 的实时数据处理实际

实现对变动中的数据进行疾速高性能剖析及决策辅助，10 亿条数据查问秒级获取。

本次 Demo 实际是通过 MaxCompute+QuickBI 实现。QuickBI 当初已反对直连的 MaxCompute 查问减速模式，QuickBI 自身已有减速引擎，如 DLA、CK 等。以后最优的模式，直连 MaxCompute 走查问减速模式是最快的。

实际总结

长处

• Streaming Tunnel: 实时写入可见, 解决了高 QPS 写入导致的碎片文件问题；
• 查问减速：低提早 - 多级缓存 & 疾速资源调度、易用 - 一套 SQL 语法、弹性 - 存储计算拆散

晋升

• 目前上游利用生产 / 汇总时每次只能全量查问，无奈做进一步实时流计算解决；实时入库不反对批改、删除；
• 后续 MC 提供流式 SQL 引擎运行实时流作业，做到流批一体

原文链接
本文为阿里云原创内容，未经容许不得转载。