关于数据上传阿里云MaxCompute调研

1.背景

当前的数据存储基于mysql库表存储形式，目前已经无法满足愈加增大的数据存储需求，新项目基于Maxcompute数据仓库架构，需要将统计日志上传Maxcompute，本文对Maxcompute系统数据上传进行调研，测试，包括基于LogStash收集的DataHub实时数据通道和批量数据通道SDK等。

2技术调研及测试

2.1数据通道SDK

2.1.1 UploadSession

2.1.1.1 说明

MaxCompute Tunnel是MaxCompute的数据通道，可通过提供接口上传数据；

接口定义如下：

public class UploadSession {

        UploadSession(Configuration conf, String projectName, String tableName,

            String partitionSpec) throws TunnelException;

        UploadSession(Configuration conf, String projectName, String tableName,

            String partitionSpec, String uploadId) throws TunnelException;

        public void commit(Long[] blocks);

        public Long[] getBlockList();

        public String getId();

        public TableSchema getSchema();

        public UploadSession.Status getStatus();

        public Record newRecord();

        public RecordWriter openRecordWriter(long blockId);

        public RecordWriter openRecordWriter(long blockId, boolean compress);

        public RecordWriter openBufferedWriter();

        public RecordWriter openBufferedWriter(boolean compress);

    }

接口说明如下：

生命周期：从创建Upload实例到结束上传。

创建Upload实例：通过调用构造方法和TableTunnel两种方式进行创建。

请求方式：同步。

Server端会为该Upload创建一个session， 生成唯一UploadId标识该Upload，客户端可以通过getId获取。

上传数据：

请求方式：同步。

调用openRecordWriter方法，生成RecordWriter实例，其中参数blockId用于标识此次上传的数据，也描述了数据在整个表中的位置，取值范围为[0,20000]，当数据上传失败，可以根据blockId重新上传。

查看上传：

请求方式：同步。

调用getStatus可以获取当前Upload状态。

调用getBlockList可以获取成功上传的blockid list，可以和上传的blockid list对比，对失败的blockId重新上传。

结束上传：

请求方式：同步。

调用commit（Long[] blocks）方法，参数blocks列表表示已经成功上传的block列表，Server端会对该列表进行验证。

该功能是加强对数据正确性的校验，如果提供的block列表与Server端存在的block列表不一致抛出异常。

Commit失败可以进行重试。

状态如下：

UNKNOWN：Server端刚创建一个Session时设置的初始值。

NORMAL：创建Upload对象成功。

CLOSING：当调用complete方法（结束上传）时，服务端会先把状态置为CLOSING。

CLOSED：完成结束上传（即把数据移动到结果表所在目录）后。

EXPIRED：上传超时。

CRITICAL：服务出错。

同一个Upload中Session的blockId不能重复。也就是说，对于同一个UploadSession，用一个blockId打开RecordWriter，写入一批数据后，调用close，然后再commit完成后，不可以重新再用该blockId打开另一个RecordWriter写入数据。

一个block大小上限100GB，建议大于64M的数据。

每个Session在服务端的生命周期为24小时。

上传数据时，Writer每写入8KB数据，便会触发一次网络动作，如果120秒内没有网络动作，服务端将主动关闭连接，此时Writer将不可用，重新打开一个新的Writer写入。

官方建议使用openBufferedWriter接口上传数据，屏蔽了blockId的细节，并且内部带有数据缓存区，会自动进行失败重试；

2.1.1.2示例代码

 public class UploadSample {

         private static String accessId = “******";

         private static String accessKey = "******";

         private static String odpsUrl = "http://service.odps.aliyun.com/api";

         private static String tunnelUrl = "http://dt.cn-shanghai.maxcompute.aliyun.com";

                         //设置tunnelUrl，若需要走内网时必须设置”aliyun-inc”，否则默认公网。

         private static String project = "BaseDatawarehouse";

         private static String table = "origin_data";

         private static String partition = "2018-07-02";

         public static void main(String args[]) {

                 Account account = new AliyunAccount(accessId, accessKey);

                 Odps odps = new Odps(account);

                 odps.setEndpoint(odpsUrl);

                 odps.setDefaultProject(project);

                 try {

                         TableTunnel tunnel = new TableTunnel(odps);

                         tunnel.setEndpoint(tunnelUrl);//tunnelUrl设置

                         PartitionSpec partitionSpec = new PartitionSpec(partition);

                         UploadSession uploadSession = tunnel.createUploadSession(project,

                                         table, partitionSpec);

                         TableSchema schema = uploadSession.getSchema();

                          // 准备数据后打开Writer开始写入数据，准备数据后写入一个Block

                         RecordWriter recordWriter = uploadSession.openRecordWriter(0);

                         Record record = uploadSession.newRecord();

                         for (int i = 0; i < schema.getColumns().size(); i++) {

                                 Column column = schema.getColumn(i);

                                 switch (column.getType()) {

                                 case BIGINT:

                                         record.setBigint(i, 1L);

                                         break;

                                 case BOOLEAN:

                                         record.setBoolean(i, true);

                                         break;

                                 case DATETIME:

                                         record.setDatetime(i, new Date());

                                         break;

                                 case DOUBLE:

                                         record.setDouble(i, 0.0);

                                         break;

                                 case STRING:

                                         record.setString(i, "sample");

                                         break;

                                 default:

                                         throw new RuntimeException("Unknown column type: "

                                                         + column.getType());

                                 }

                         }

                         for (int i = 0; i < 10; i++)

                                 recordWriter.write(record);

                         }

                         recordWriter.close();

                         uploadSession.commit(new Long[]{0L});

                         System.out.println("upload success!");

                 } catch (TunnelException e) {

                         e.printStackTrace();

                 } catch (IOException e) {

                         e.printStackTrace();

                 }

         }

 }

2.1.2 TunnelBufferedWriter

2.1.2.1 说明

TunnelBufferedWriter是官方推荐的接口，也是本次测试所用的接口；

一次完整的上传流程通常包括以下步骤：

1、先对数据进行划分。

2、为每个数据块指定block Id，即调用openRecordWriter(id)。

3、用一个或多个线程分别将这些block上传上去，并在某个block上传失败以后，需要对整个block进行重传。

4、在所有block都上传以后，向服务端提供上传成功的blockid list进行校验，即调用session.commit([1,2,3,…])。

5、由于服务端对block管理，连接超时等的一些限制，上传过程逻辑变得比较复杂，为了简化上传过程，SDK提供了更高级的一种RecordWriter—TunnelBufferWriter。

接口定义如下：

public class TunnelBufferedWriter implements RecordWriter {

        public TunnelBufferedWriter(TableTunnel.UploadSession session, CompressOption option) throws IOException;

        public long getTotalBytes();

        public void setBufferSize(long bufferSize);

        public void setRetryStrategy(RetryStrategy strategy);

        public void write(Record r) throws IOException;

        public void close() throws IOException;

}

TunnelBufferedWriter 对象：

生命周期：从创建RecordWriter到数据上传结束。

创建TunnelBufferedWriter实例：通过调用UploadSession的openBufferedWriter接口创建。

数据上传：调用Write接口，数据会先写入本地缓存区，缓存区满后会批量提交到服务端，避免了连接超时，同时，如果上传失败会自动进行重试。

结束上传：调用close接口，最后再调用UploadSession的commit接口，即可完成上传。

缓冲区控制：可以通过setBufferSize接口修改缓冲区占内存的字节数（bytes），建议设置64M以上的大小，避免服务端产生过多小文件，影响性能，一般无须设置，维持默认值即可。

重试策略设置：可以选择三种重试回避策略：指数回避（EXPONENTIAL_BACKOFF）、线性时间回避（LINEAR_BACKOFF）、常数时间回避（CONSTANT_BACKOFF）。例如：下面这段代码可以将Write的重试次数调整为6，每一次重试之前先分别回避4s、8s、16s、32s、64s和128s（从4开始的指数递增的序列），这个也是默认的行为，一般情况不建议调整。

2.1.2.2 测试代码

public class uplodsession {
    private static String accessId = "******";
    private static String accessKey = "******";
    private static String odpsUrl = "http://service.odps.aliyun.com/api";
    private static String tunnelUrl = "http://dt.cn-beijing.maxcompute.aliyun.com";
    //设置tunnelUrl，若需要走内网时必须设置，否则默认公网。
    private static String project = "******";
    private static String table = "******";


    public static void main(String[] args) {

        Account account = new AliyunAccount(accessId, accessKey);
        Odps odps = new Odps(account);
        odps.setEndpoint(odpsUrl);
        odps.setDefaultProject(project);

        TableTunnel tunnel = new TableTunnel(odps);
        tunnel.setEndpoint(tunnelUrl);//tunnelUrl
        TableTunnel.UploadSession uploadSession = null;
        //获取开始时间
        long startTime = System.currentTimeMillis();
        try {
            uploadSession = tunnel.createUploadSession(project,table);
            System.out.println("Session Status is : "
                    + uploadSession.getStatus().toString());
            RecordWriter recordWriter = uploadSession.openBufferedWriter();
            Record product = uploadSession.newRecord();
            String message = ""
            for (int i=0;i<1000000;i++){
                product.setString("log",message);
                recordWriter.write(product);
                count=count+1;
                if(count>=10000){
                    recordWriter.close();
                    uploadSession.commit();
                    System.out.println("開始提交");
                    break;
                }
            }

            System.out.println("upload success!");
            //获取结束时间
            long endTime = System.currentTimeMillis();
            System.out.println("程序运行时间：" + (endTime - startTime) + "ms");    //输出程序运行时间
        } catch (TunnelException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

 

2.1.3 消费kafka数据写入Maxcompute

2.1.3.1 示例代码 

public class up {
    public static void main(String[] args) throws IOException, TunnelException {
        ConsumerConnector consumer;
        // 连接的Zookeeper接口, 不同业务模块使用的数据是相同的
        String zookeeper = "10.172.217.86:2181,10.44.143.42:2181,10.252.0.171:2181";
        // Kafka消费者订阅的主题,临时测试主
        String topic = "testReceivelog";
        String groupId = "testConsumer";
        String accessId = "******";
        String accessKey = "******";
        String odpsUrl = "http://service.odps.aliyun.com/api";
        String tunnelUrl = "http://dt.cn-beijing.maxcompute.aliyun.com";
        //设置tunnelUrl，若需要走内网时必须设置，否则默认公网。此处给的是华东2经典网络Tunnel Endpoint，其他region可以参考文档《访问域名和数据中心》。
        String project = "BaseDatawarehouse";
        String table = "origin_data";
        Properties props = new Properties();
        props.put("zookeeper.connect", zookeeper);
        props.put("group.id", groupId);
        props.put("zookeeper.session.timeout.ms", "500");
        props.put("zookeeper.sync.time.ms", "250");
        props.put("auto.commit.interval.ms", "1000");
        consumer = Consumer.createJavaConsumerConnector(new ConsumerConfig(props));
        Account account = new AliyunAccount(accessId, accessKey);
        Odps odps = new Odps(account);
        odps.setEndpoint(odpsUrl);
        odps.setDefaultProject(project);

        TableTunnel tunnel = new TableTunnel(odps);
        tunnel.setEndpoint(tunnelUrl);//tunnelUrl
        TableTunnel.UploadSession uploadSession = null;
        RecordWriter recordWriter = null;
        try {
            uploadSession = tunnel.createUploadSession(project, table);
            System.out.println("Session Status is : "
                    + uploadSession.getStatus().toString());
            recordWriter = uploadSession.openBufferedWriter();
        } catch (TunnelException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
        Record product = uploadSession.newRecord();
        Map<String, Integer> topicCount = new HashMap<>();
        //3线程消费3partition数据
        topicCount.put(topic, 3);
        Map<String, List<KafkaStream<byte[], byte[]>>> consumerStreams = consumer.createMessageStreams(topicCount);
        List<KafkaStream<byte[], byte[]>> streams = consumerStreams.get(topic);
        for (final KafkaStream stream : streams) {
            ConsumerIterator<byte[], byte[]> it = stream.iterator();
            int count = 0;
            while (it.hasNext()) {
                String message = new String(it.next().message());
                //写入
                product.setString("log", message);
                recordWriter.write(product);
                count = count + 1;
                if (count >= 10000) {
                    recordWriter.close();
                    uploadSession.commit();
                    count = 0;
                    uploadSession = tunnel.createUploadSession(project, table);
                    recordWriter = uploadSession.openBufferedWriter();
                    product = uploadSession.newRecord();
                }
            }
            if (consumer != null) {
                consumer.shutdown();
            }
            if(recordWriter!=null){
                recordWriter.close();
            }
        }
    }

优点：

批量导入，效率高，数据无丢失；

缺点：

1、批量倒入，数据无法精确归档（根据统计需求，需要将日志按照天、小时归档，如果对每条数据处理则更不适合，需要实时处理）；

2、批量导入，上传效率依赖于消费kafka；

3、Kafka适合实时处理，不适合批量操作；

4、批量导入，数据归档有误差，每批次中含有除当前分区外的其他分区数据，造成统计指标失准；

2.2 DataHub实时数据通道

2.2.1 说明

产品优势：

1、高吞吐

最高支持单主题（Topic）每日T级别的数据量写入，每个分片（Shard）支持最高每日8000万Record级别的写入量。

2、实时性

通过DataHub ，您可以实时的收集各种方式生成的数据并进行实时的处理，对您的业务产生快速的响应。

3、易用性

DataHub提供丰富的SDK包，包括C++， JAVA， Pyhon， Ruby， Go等语言；DataHub服务也提供Restful API规范，您可以用自己的方式实现访问接口。除了SDK以外，DataHub还提供一些常用的客户端插件，包括：Fluentd，LogStash，Flume等，可以使用这些客户端工具往DataHub中写入流式数据。

DataHub同时支持强Schema的结构化数据和无类型的非结构化数据。

4、高可用

服务可用性不低于99.999%。

规模自动扩展，不影响对外服务。

数据持久性不低于99.999%。

数据自动多重冗余备份。

5、动态伸缩

每个主题（Topic）的数据流吞吐能力可以动态扩展和减少，最高可达到每主题256000 Records/s的吞吐量。

6、高安全性

提供企业级多层次安全防护，多用户资源隔离机制。

提供多种鉴权和授权机制及白名单、主子账号功能。

7、DataHub服务基于阿里云自研的飞天平台，具有高可用，低延迟，高可扩展，高吞吐的特点。DataHub与阿里云流计算引擎StreamCompute无缝连接，可以轻松使用SQL进行流数据分析。

DataHub服务也提供分发流式数据到各种云产品的功能，目前支持分发到MaxCompute（原ODPS），OSS等。

功能图：

2.2.1.1 流式数据同步DataConnector

DataHub DataConnector是把DataHub服务中的流式数据同步到其他云产品中的功能，目前支持将Topic中的数据实时/准实时同步到MaxCompute(ODPS)、OSS、ElasticSearch、RDS Mysql、ADS、TableStore中。用户只需要向DataHub中写入一次数据，并在DataHub服务中配置好同步功能，便可以在各个云产品中使用这份数据。数据同步支持at least once语义，在网络服务异常等小概率场景下可能会导致目的端的数据产生重复。

DataConnector支持系统

目标系统	时效性	描述
MaxCompute（Odps）	准实时，通常情况5分钟延迟	同步Topic中流式数据到离线MaxCompute表，字段类型名称需一一对应，且DataHub中必须包含一列（或多列）MaxCompute表中分区列对应的字段
OSS	实时	同步数据到对象存储OSS指定Bucket的文件中，将以csv格式保存
ElasticSearch	实时	同步数据到ElasticSearch指定Index中，Shard之间数据同步不保证时序，所以需将同样ID的数据写入相同的Shard中
Mysql	实时	同步数据到指定的Rds Mysql表中
ADS	实时	同步数据到指定的ADS表中
TableStore	实时	同步数据到指定的TableStore表中

如何创建

创建Connector主要需要如下前置条件：

准备对应的MaxCompute表，该表字段类型、名称、顺序必须与DataHub Topic字段完全一致，如果三个条件中的任意一个不满足，则归档Connector无法创建。字段类型对应表见后表。

访问MaxCompute账号的设置，该账号必须具备该MaxCompute的Project的CreateInstance权限和归档MaxCompute表的Desc、Alter、Update权限，建议使用一个特殊最小权限的账号。官方建议使用RAM用户账号。

DataHub Topic的Owner/Creator账号, 才有相应的权限操作Connector，包括创建，删除等。

只支持将TUPLE类型的DataHub Topic同步到MaxCompute表中

操作流程： Project列表->Project查看->Topic查看->点击归档MaxCompute->填写配置，点击创建 

配置说明:

名称	是否必须	描述
MaxCompute Project	yes	MaxComputeProject名称
MaxCompute Table	yes	MaxCompute表名称
AccessId	yes	访问MaxCompute的阿里云账号AccessId
AccessKey	yes	访问MaxCompute的阿里云账号AccessKey
分区选项	yes	SYSTEM_TIME、EVENT_TIME、USER_DEFINE三种模式，SystemTime模式会使用写入时间转化为字符串进行分区，EventTime模式会根据topic中固定的event_time字段时间进行分区（需要在创建Topic时增加一个TIMESTAMP类型名称为event_time的字段，并且写入数据时向这个字段写入其微秒时间）,UserDefine模式将会直接使用用户自定义的分区字段字符串分区
分区范围	yes	划分分区的时间间隔，在SYSTEM_TIME、EVENT_TIME两种模式下生效，最少为15分钟
分区格式定义	yes	目前仅支持固定格式，未来将会开放为自定义格式，目前格式下，若为15分钟的分区范围，则会产生ds=20170704,hh=01,mm=15这样的分区

注意:

支持MaxCompute分区表

分区选项选择SYSTEM_TIME模式，表结构对应如下：

MaxCompute表： table_test(f1 string, f2 string, f3 double) partitioned by (ds string, hh string, mm string)

对应Topic应为如下的Schema:

Topic: topic_test(f1 string, f2 string, f3 double)

数据同步时根据写入时间确定ds/hh/mm的值写入MaxCompute

分区选项选择EVENT_TIME模式，表结构对应如下：

MaxCompute表： table_test(f1 string, f2 string, f3 double) partitioned by (ds string, hh string,mm string)

对应Topic应为如下的Schema:

Topic: topic_test(f1 string, f2 string, f3 double, event_time timestamp)

数据同步时根据event_time字段时间戳确定ds/hh/mm的值写入MaxCompute

分区选项选择USER_DEFINE模式，表结构对应如下：

MaxCompute表： table_test(f1 string, f2 string, f3 double) partitioned by (ds string, pt string)

对应Topic应为如下的Schema:

Topic: topic_test(f1 string, f2 string, f3 double, ds string, pt string)

数据同步时根据ds、pt的数据值，写入对应分区

USER_DEFINE模式下MaxCompute分区字段内容必须非空UTF8字符串，否则归档任务将无法正常运行或数据无效被丢弃。

USER_DEFINE模式下MaxCompute的分区字段的值必须符合MaxCompute对分区字段值的范围要求，否则归档任务将无法正常运行。

分区选项为EventTime模式时，若event_time字段的数据值是null或非法，会降级使用数据写入DataHub的SystemTime写入对应分区。

数据归档的频率为每个Shard每5分钟或者Shard中新写入的数据量达到64MB，DataConnector服务会批量进行一次数据归档进入MaxCompute表的操作。所以数据写入DataHub Topic后至多5分钟后在MaxCompute可以被查询到。

DataHub与MaxCompute字段类型对应表:

MaxCompute表中的类型	DataHub Topic中的类型
STRING	STRING
DOUBLE	DOUBLE
BIGINT	BIGINT
DATETIME	TIMESTAMP
BOOLEAN	BOOLEAN
DECIMAL	DECIMAL
MAP	不支持
ARRAY	不支持

最高支持单主题（Topic）每日T级别的数据量写入，每个分片（Shard）支持最高每日8000万Record级别的写入量，每个主题（Topic）的数据流吞吐能力可以动态扩展和减少，最高可达到每主题256000 Records/s的吞吐量，目前1个分片就足以支撑我们的数据量。

3. 对比与结论

3.1数据通道SDK

数据通道SDK上传流程如图：图略

说明：

延续用已有的数据采集架构，新建groupid 消费kafka的统一topic，然后springboot后台实时消费kafka数据，每10000条上传一次Maxcompute。

优点：

可以不用log重新采集，使用数据通道SDK可以解决DataHub的使用成本（SDK上传MaxCOmpute目前只有杭州能走内网，华北2北京要走公网，会流量费用）

不足：

1、批量上传，数据归档存在问题，造成统计结果存在误差。

2、数据上传效率依赖卡夫卡吞吐，存在单点故障隐患。

3.2 DataHub实时数据通道

DataHub 上传数据流程图：图略

说明：

从新搭建数据采集，与原有采集系统隔离，通过logstash直接上传数据到DataHub,数据实时归档到MaxCompute

优点：

1、以后实时计算直接可在DataHub接StreamCompute复用性扩展性比较好。

2、数据可实时归档，保证统计结果正确。

3、链路较短易维护，同时使用DataHub零维护，可靠性好。

4、吞吐量大，完全支撑日益增长的数据量。

3.3 结论

对比表：

	DataHub	数据通道SDK
吞吐量	最高支持单主题（Topic）每日T级别的数据量写入，每个分片（Shard）支持最高每日8000万Record级别的写入量每个主题（Topic）的数据流吞吐能力可以动态扩展和减少，最高可达到每主题256000 Records/s的吞吐量。	单个block上传的数据限制为100G，最多可20000个block
实时性	实时数据通道数据直接由logstash收集不用读kafka数据实时写入，每topic数据量达64M，或者当前数据超过五分钟会自动写入Maxcompute归档，实时性好	因为需要实时读取kafka数据，每读64m的数据会提交一次，需要http访问，目前华北二只能走公网，所以延迟很大
可靠性	服务可用性不低于99.999% 规模自动扩展，不影响对外服务 数据持久性不低于99.999% 数据自动多重冗余备份	存在单点故障问题，无法保证续传
数据归档	通过创建DataHub Connector，指定相关配置，即可创建将Datahub中流式数据定期归档的同步任务，数据产生时间与归档时间误差极小，目前测试按照天，小时，分钟对数据进行归档，以便统计和存储	批量上传无法准确归档，如准确归档需要每一条数据处理一次，上传一次，那么吞吐十分低，满足不了我们日益增长的数据量
维护成本	云服务零维护成本	需要根据需求开发上传代码，监控任务以及上传的数据完整性，维护成本高
费用成本	因为数据最终存储MaxCompute，datahub作为其一组件不产生费用	共享已有服务器资源无费用

通过两种上传方式调研、测试，以及上传数据流程对比，DataHub实时数据通道，有更好的可扩展性，能准确的对数据进行归档，以及良好的可靠性和零维护，所以采用这种方式作为数据上传比较合适。