简介：MaxCompute（原名 ODPS）是一种疾速、齐全托管的 EB 级数据仓库解决方案, 致力于批量结构化数据的存储和计算，为用户提供数据仓库的解决方案及剖析建模服务。Tunnel 是 MaxCompute 提供的数据传输服务，提供高并发的离线数据上传下载服务，适宜于全量数据或历史数据的批量导入, 并且在 MaxCompute 的客户端工具中，提供对应的命令实现本地文件与服务数据的互通。

本篇次要通过五个局部介绍 MaxCompute Tunnel

• MaxCompute Tunnel 技术原理
• MaxCompute Tunnel 丰盛的生态
• Tunnel 性能简介
• SDK 的应用形式
• 最佳实际

一、MaxCompute Tunnel 技术原理

在服务端，提供的服务能够大略分为 API 层和执行层。API 层有两个集群 Frontend 集群会负责控制流的染指，Tunnel 集群负责数据。在执行层分为管制集群和计算集群，管制集群会负责资源管控，meta 的治理，和权限治理这些性能，计算集群就负责理论的计算和存储。

能够看到，Tunnel 是属于 API 层的一个组件，专门负责数据的上传和下载。为什么这么做, 是因为这是一个大数据的零碎，所以在 MaxCompute 上跑一个 SQL 其实就发了一条控制指令。因为指标的场景是一个大数据量的查问，比如说十亿条这种量级的，这是一个规模比拟大的操作，如果在这个场景下想做数据的同步，就不能像 MySQL 传统输出一样通过 insert into，因为 insert into 走管制集群这个链路是十分浪费资源的，同时也会有一些限度。一次一行的效率特地低，因而设计了离开的控制流和数据流。

Tunnel 集群负责的性能是在 SDK 层提供了 Tunnel 的 API，让用户能够通过一个结构化的形式去拜访数据。另外，Tunnel 是对外放进去的惟一的数据接口，会对用户写进来的数据做格局检查和权限校验，控制数据平安。同时会保障用户通过 Tunnel 写进去的数据用 SQL 可读，不必放心比方 SQL 读不了写进来的数据，或者写的数据和 SQL 读出来的值有差别。

另外一点，Tunnel 是间接拜访存储层的，MaxCompute 在底层的存储是一个分布式文件系统，Tunnel 是间接拜访这个文件系统的，这样在性能上就有了保障。也就是说，Tunnel 在现实状况下是能够保障单并发达到 10 兆每秒的吞吐能力，通过假并发也是能够程度扩大整个吞吐能力。

二、MaxCompute Tunnel 丰盛的生态

MaxCompute 有十分丰盛的生态，举荐首先要看一下有什么工具，或者有哪些服务能够做，倡议优先应用一些成熟的服务，尽量不要本人先写代码。

官网的 SDK 有 Java SDK 和 Python SDK。

另外，官网还提供了三种工具。MaxCompute 客户端是一个命令行工具，在数据同步这方面反对用户把一个本地文件上传到 MaxCompute 外面，也能够通过下载一张表到一个本地文件上。MaxCompute Studio 是一个 idea 插件，它也反对文件上传下载这样的形式。MMA2.0 迁徙工具是最近推出的一个工具，能够帮忙用户把数据从现有的大数据系统里迁徙到 MaxCompute 上，这些工具都是基于 SDK 开发的，都是通过 SDK 传输。

除了工具以外，MaxCompute 在第三方服务上也是集成的，比方云上的数据通道图，SLS（阿里云的日志服务），DataHub（数据通道），他们都是原生就反对 MaxCompute 投递的，Kafka 也是有官网的插件。

流计算方面，Blink，Spark 也都是有 MaxCompute 同步插件的。数据同步服务方面，DataWorks 的数据同步，实时同步和离线同步，都是反对 MaxCompute 同步的。

总结一下，如果有数据同步的需要，最好先看一下现有的服务是不是能够满足需要。如果感觉都满足不了，想要本人开发的话，能够看一下 SDK 是能够有哪些性能，和应用上的一些注意事项。

三、Tunnel 性能简介

上图是 Tunnel 总体性能的表格。当初有两套 API，分批量数据通道和流式数据通道。

批量数据通道指标的场景单并发的吞吐量很大，这种现实的场景是传量大的数据，一次一批，QPS 和并发都不能特地高，然而单并发的吞吐量能够做得很大，这个在 API 上也有一些优化。

流式数据通道是新提供的一种服务，因为当初的上游服务大多数都是一些流式服务灌进来的，也就是说单并发可能流量没有那么大，然而都是比拟细碎的数据，这种状况如果用批量数据通道会遇到很多限度。最显著的就是小文件问题，用批量数据通道写特地碎的数据进来会产生大量的碎片文件，跑 SQL 查问就会十分慢，用 Tunnel 下载也会十分慢。针对这种场景平台提供了流式数据通道服务，通过流式数据上来能够写得特地碎，一行写一次也能够，不须要放心小文件的问题，也不必放心并发的问题，并发能够有限多。流式数据通道是不限并发的，然而批量是限并发的。

从表格中能够看到，通过 Tunnel 是能够拜访这几种资源的：一般表，Hash Clustered 表，Range Clustered 表和 Transactional 表，最初是查问后果，这些都是能够下载的；一般表两种上传都反对；Hash Clustered 表和 Range Clustered 表并不适宜 Tunnel 去写，因为数据在存储上须要做一个零碎，而且会排序，而 Tunnel 集群规模没有计算机集群那么大，没有这个能力去做排序。因而，这种表个别经典的用法就是先写一张一般表，而后通过 SQL 做一个 insert overwrite，生成一张 Hash Clustered 表或者 Range Clustered 表。

流式上传在架构上做了降级，有一个异步解决的机制，会把用户写进来的数据在后盾进行加工，所以前面会反对 Hash Clustered 表。

Transactional 表是说，MaxCompute 的一般表是不反对 update 或者 delete 的，零碎最近在 SQL 上反对了这个语法，就是用户能够 update，也能够 delete，也能够反对 transaction。批量上传的 API 当初是反对 Transactional 表，然而只反对 append，也称为 insert into，它是不能从 Tunnel 的 API 下来 update 的。流式的也正在布局中，后续可能会连 update 也一起实现。批量的可能不会做 update 这个性能，然而批量的当初就能够 append 这种 Transactional 表。

查问后果就是说，如果跑一个 SQL，在 odpscmd 客户端或者 DataWorks 上对查问后果有 1 万条的限度。然而这个查问后果能够通过 Tunnel 下载，就不受条数限度，能够下载残缺的查问后果到本地。

总而言之，如果应用 SDK 的话，就能够做到表格里的这些性能。

四、SDK 的应用形式

1）根本配置

如果想开发的话有哪些货色须要配置，不论上传、下载，还是流式上传，这些配置都是一样的。首先须要创立一个 ODPS 对象和一个 Table Tunnel 对象。如果想用 SDK 跑 SQL，要创立 ODPS；TableTunnel 是 Tunnel 入口的一个类，所有的性能都是从这个类发动的。

而后看具体的配置项，图中左侧列举的是比拟要害的几个。Access ID 和 Access Key 就是账号信息，阿里云通过这个来示意一个账号。

ODPS Endpoint 是服务的一个入口，当初在公共云上应该有 21 个 region，包含金融云和政务云，中国有 7 个，海内有 14 个。每个 region 的 endpoint 是不一样的，应用时须要找到本人购买的 region 服务，并正确填写 endpoint 进去。

Tunnel Endpoint 是可选的，如果不填，零碎会通过所填的 ODPS endpoint 主动路由到对应的 Tunnel endpoint 上。在公共云上的网络环境比较复杂，分公网域名和内网域名，内网域名还分经典网络和 VBC，兴许会有路由的 endpoint 网络不通这种场景，这个时候平台提供了一个接口，用户能够把能拜访的 Tunnel endpoint 填进来，这样就会优先用所填的 Tunnel endpoint 而不会用路由的，但 99% 的状况下是不必填。

Default project 这个参数是在弹内常常用的。MaxCompute 的权限治理十分丰盛，比方如果在公共云上有多个 project，想要控制数据在跨 project 流动的话，就能够通过这个参数来配置。ODPS 里设置的 Default Project 能够了解为是原 project，上面的 create Stream Session 外面又有一个 project，即要拜访数据所在的 project。如果这两个 project 不一样，零碎会查看这个权限，用户是否能够拜访指标 project 的数据。如果跑 SQL，它也会依据原 project 来管制资源的应用。如果只有一个，这两个填成一样的就能够。

一般来说，Access ID，Access Key, 和 ODPS Endpoint 是必选的，Tunnel Endpoint 可选，Default project 如果只有一个只填一个就行了。

2）具体的上传接口

接下来展现具体的上传接口。首先看批量上传。

【批量上传】

批量上传的流程是先创立一个 upload session (第 31 行), 而后 open writer，用 writer 去写数据，而后 close，再 upload session 加 commit。

Upload session 能够了解为是一个会话的对象，相似于 transaction 的概念。这次上传是以 upload session 为单位的，即最终 upload session commit 胜利了这些数据才是可见的。在一个 upload session 外部能够 open 多个 writer，并且多个 writer 能够并发上传，然而 writer 是有状态的，须要给它指定一个不反复的 block ID，防止产生笼罩。Upload session 也是有状态的，没有 commit 就不可见；如果 commit 胜利了，这个 session 就完结了，临时就不能再去 open writer。Writer 的实现原理是 open 一个 writer 申请，零碎会发一个 HTP 申请到服务端，而后放弃这个长链接，写数据时平台会实时地把数据写到服务端，writer 是写一个长期目录。依据这个机制能够看到，如果 writer 或者 close 失败了，就相当于这个长连贯断了。所以 writer 和 close 这两个接口是不能重试的，如果 writer 两头有任何阶段失败了，就须要从新写。

除了失常的 commit 之外，MaxCompute 还反对让用户检查数据正确性。比方用户 open 了五个 writer，commit 的时候能够把这五个 ID 当成例子上传确认。如果查看到服务端与这个例子不统一，commit 就会报错。

总结一下，根本的性能点有：

批量上传是有状态并发；

commit 胜利后数据才可见；

反对 insertOverwrite, 也反对 InsertInto 语义。

Insert overwrite 指 commit 的时候反对应用某个 upload session 的数据间接 overwrite 掉一整个分区或者一张表，相似 SQL 的 Insert 和 Overwrite 的性能。

这个性能也有应用限度。

第一，一个 upload session 不能超过 2 万个 Block。

第二，Block ID 会导致数据笼罩。

第三，upload session 24 小时过期，因为 writer 数据是写在存储的长期目录的，长期数据有回收周期，超过 24 小时，writer 写过的数据就有可能被回收掉，这个就限度了 upload session 的生命周期。

第四，如果 open 了一个 writer 然而不写数据，就相当于占了一个闲暇链接，服务端会把这个链接间接断掉。

【流式上传】

接下来看一下流式上传的接口。前文中有提到，流式上传是在 API 上做了简化，还去掉了并发的限度和工夫的限度。

接口是 CreateStreamUploadSession，写数据的从 writer 改成了 RecordPack。所谓的 pack 其实相当于一个内存里的 buffer，能够用 pack.append(record)，比方判断 size 只须要判断这个 buffer 足够大或者条数足够多，而后再 flush 就能够了（42 到 44 行）。Pack 并不是写网络的，而是写内存的。因而，不同于 writer，flush 是能够重试的，因为数据都在内存里。并且 Pack 也没有状态，不须要关怀 writer 的 Block ID 等等。另外，因为 flush 胜利后数据就可见了，所以 session 也没有 commit 这种状态。因而，如果要开发分布式服务，这个相比批量上传就简化很多，没有太多的限度，只须要确保本机内存是否够大就好了。

同时零碎还反对了内存的复用，即 flush 过当前的 pack 是能够复用的。零碎会把上次写满的内存留住，防止产生 GC。流式上传只反对 InsertInto，因为在 API 上没有另外的接口，所以 InsertOverwrite 语义当初是不反对的。另外，流式服务是反对异步数据处理的，也就是除了保障用户通过流式写上来的数据可读之外，服务端还有一个机制能辨认进去新写进来的数据和存量数据，能够对新写进去的数据做一些异步的解决，比方 zorder by 排序和墨纸。

ZorderBy 排序是指一种数据的组织形式，能够把存在 MaxCompute 的数据按某些规定从新组织一遍，这样查问的时候效率会十分高。墨纸是指反对把数据在后端从新写一遍，把一些很碎的数据从新组织成存储数据存储效率较高的数据文件。在这个根底上还能够做一些排序和其余的解决，后续会再加更多的性能。

流式上传也会有一些限度。首先在写的时候，零碎会对这个表加锁，流式写的时候其余的操作是不能写的，比方 InsertInto 和 Insert Overwrite 是会失败的，要把流式停掉之后能力失常写。另外，DDL 有一些提早，如果要 drop table 或者 rename table 的话，可能 drop 完还能胜利写几条数据，会有最多 60 秒的提早。如果有这种场景，倡议先把流式停掉再去 drop 或者 rename。

【批量下载】

接下来介绍批量下载的接口。

TableTunnel 创立了一个叫 downloadSession 的对象。能够失去 record Count，指一个分区或者一张表的总行数。上面是 open reader，能够和批量上传对应起来: reader 和 writer; uploadSession 和 downloadSession。Openreader 是按 record 来辨别的，比方有 1000 行，能够分十个 100 行并发下载。Download 反对列裁剪，也就是能够下载其中几列。下载查问后果就把 TableTunnel 入口类改成 InstanceTunnel，odps 也是一样，53 行就不是 project, table 了，是一个 InstanceID。

应用限度方面，和批量上传相似，DownloadSession 限度也是 24 小时，因为它也有临时文件。同样闲暇链接 120 秒超时，另外还有 Project 级别并发限流，性能受碎片文件影响。

五、最佳实际

如果并发很高，不举荐走批量接口，因为并发限流是 project 级别的，如果上传或者下载的限额打满，整个 project 的批量上传都会失败。

这种接口举荐把并发降下来，而后充分利用并发约 10 兆每秒的吞吐能力。流式因为架构上的起因，是不受并发限度的。QPS 不倡议批量上传，因为碎片文件的问题，不倡议用特地高的 QPS 来用批量的接口写数据。如果 QPS 和并发都不高，应用这三种形式都不会很受限制。

另外有几个场景，transaction 当初反对批量上传，流式上传后续会跟进。目前流式上传不反对 Insert Overwrite，可能前面也不肯定会开发，因为这个场景显著是一个批量的语义。

作者：慕明 阿里云智能 技术专家
原文链接
本文为阿里云原创内容，未经容许不得转载