简介： 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引擎运行实时流作业，做到流批一体

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