简介： 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，可能前面也不肯定会开发，因为这个场景显著是一个批量的语义。

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