ofo在MaxCompute的大数据开发之路

摘要：2017年，ofo向市场投入了一千多万辆单车，这些单车的投放、运营和调度须要大量数据的支持。本文将从ofo选择MaxCompute的理由以及数据完整性、任务调度、Proxy服务三个方面的实战应用，分享ofo 在MaxCompute的大数据开发之路。

演讲嘉宾简介：龙利民，ofo大数据，大数据副总监。

 

PPT材料下载地址：http://click.aliyun.com/m/1000003067/

视频地址：http://click.aliyun.com/m/1000003068/

产品地址：http://click.aliyun.com/m/1000003065/

本次分享主要包括如下内容：

1、ofo为何选择MaxCompute 

2、实战应用

   1. 数据完整性

   2. 任务调度

   3. Proxy服务

 

1、         ofo为何选择MaxCompute

首先，回顾一下2016年。当时，ofo的数据分析师还在使用Excel+MySQL这样原始的方式来制做报表。在这样的背景下，要求一名研发人员利用两周的时间开发出数据平台。

那么，如何完成这个任务呢？首先，分析一个数据平台主要包括哪些部分。其中，首要问题是集群（大数据下仅利用MySQL常常出现查挂的状况）。有了集群以后，须要进行数据的装载，这就涉及到ETL。对外界来讲，他们更关心的是数据自己，所以还须要BI平台，这部分也是须要大量投入的。有了BI平台以后，就能够在平台上制做报表，且涉及到报表的调度。 

其中，最首要的问题仍是集群，是自建集群仍是使用云服务？在进行这一选择时，主要从如下六个维度进行考量。

· 存储：事实上，存储也决定了性能。阿里云中就使用了ORC，它是一种列式存储。而MaxCompute使用的也是列式存储。

· 计算：计算性能的要求就是减小耗时。好比，一句SQL语句执行二三十分钟，这样的计算性能显然是不可接受的。

· 费用：费用这一因素一般是不须要考虑的。对于通常小公司而言，MaxCompute按量后付费是最好的选择。

· 稳定性：稳定性须要长期使用才能得以体现，所以这里不作过度强调。

· UDF：共享单车的特性决定了在计算中涉及大量“点”的计算。这里必须用到UDF函数，所以，若是不支持UDF，则不归入选择范围。

· 文档：MaxCompute的文档写的很是的详细。

 

综合了多方面的因素，咱们最终选择了MaxCompute。那么，在使用了一年半后，其结果怎么样呢？下面简单介绍几个事例。

· 实锤一：某同事在ofo工做一年写的SQL，超过前5年的总和；

· 实锤二：对比自建EMR集群和MaxCompute：集群成本 2 vs 1，运维成本 6 vs 1；

· 实锤三：新孵化项目，业务运转良好的前提下，日费用不到50元。

 

2、 实战应用

上面介绍的是选择MaxCompute的缘由，下面介绍一些在使用过程当中的经验。

1. 数据完整性：数据不许的问题是数据分析师最担忧的问题。但更使人担忧的是，看到数据时没法得知它到底准不许！形成这个问题的一个重要缘由就是数据不完整。好比，昨天共产生了100万条数据，但只上传了99万条。所以，必定要保证数据的完整性。

· 数据完整性的定义：程序计算的时候确保T+1天的数据是完整的，非割裂的，即原子的；

· 不注重数据完整性的作法：经过时间来约定计算，数据间的计算依赖也是基于时间；

不注重数据完整性的后果：很难发现数据的错误，须要人力来排查问题；若是不在逻辑上解决掉，会重复出现。

指望中的数据完整性只存在两种状况，要么有数据，且必定是对的，要么就没有数据。

在实际应用中，如何解决数据完整性的问题呢？解决方案主要包括如下几点。

· 用命令的 tunnel upload上传数据，不用SDK；（利用tunnel upload上传数据时，对文件来讲，它是具备原子性的，不会存在文件只上传了一半的状况。而SDK是行级上传的。）

· 维护数据标记。（当数据被上传到MaxCompute以后要对数据进行标记，好比当天的数据是否传完，后续的计算也会基于这一标记进行，不会对未ready的数据进行计算。）

作到这几点后，在实际应用中起到了很是显著的效果：没有出现一块儿，由于数据不完整致使的数据不许的状况。

在程序上保证了数据完整性后，还要思考另外一个问题：自发查询的数据完整性如何解决。好比在HUE中查询时，用户不知道数据是不是完整的。关于解决方案，这里先埋个伏笔，后面会进行详细介绍。

2. 任务调度：天天有近千张报表须要调度计算，报表间的关系会存在相互依赖的问题。如何有效的协做，是任务调度须要解决的问题。

任务调度主要分为下面三种。

中间表、宽表：咱们将最原始的数据表称为原表，好比天天产生的订单表、优惠券表等。但在实际查询中须要将这些表进行关联。好比，想要查询某个订单中的优惠券信息，若是不创建宽表则每次查询都须要写join语句。

计算报表：计算后用于统计的表。

结果宽表：计算报表会存入数据库，这样就会致使数据库中存在很是大量的表。创建结果宽表以便于分析师找到想要分析的指标。

下图展现了对任务调度的指望。

第一，并发，多机多进程，以减小进程挂掉服务器挂掉带来的影响。

第二，协做，要求能创建依赖关系。好比先计算完某张表后再计算依赖它的表。

第三，可监控，当出现故障时能及时报警。

第四，可扩展性，在任务调度中写的语句不只是SQL，也有多是python脚本或shell等。第五，资源隔离，在资源调度中要注意，不能让大的SQL把资源所有占用，一旦资源被所有占用，整个计算都会卡住。

下面介绍在实际应用中使用的任务调度技术框架。数据库中存储了天天要计算的任务，生产者从数据库中取数据，并核实数据完整性和依赖关系，核实状态是否为ready，核实完成后进入队列，状态变为waiting，消费者从队列中获取数据并将状态改成running，最后将状态写回数据库。在这一过程当中，每一个任务都须要将其心跳的状态同步到数据库中，好比某个生产者挂掉以后，若是没有心跳机制，那么它获取的任务将有可能永远在waiting状态。

任务调度资源优化和隔离

MaxCompute主要包括两种使用方式：预付费和后付费。预付费，有一个单独的资源池，其中的资源可以使用但有上限，而且已经提早付费。后付费，有一个共享的资源池，你们须要抢占资源。

在实际应用中包括如下规则：

· 大任务使用后付费

· 优先级高任务使用预付费

· 优先把预付费填满

· 预付费队列满了，使用后付费

 

3. Proxy服务

下图展现了Proxy endpoint能够解决的问题。

· 解决重复执行：好比两我的重复执行了同样的SQL语句，且数据没有更新。那么第二次执行的时候，会直接返回上一次的结果。这样，第二次查询的过程不会占用MaxCompute的资源。这样，就能够减小执行耗时，提高体验。同时，下降资源开销，节约成本。

· 安全控制：再也不对外暴露key，构建业务自由帐号，不一样的人会拥有不一样的帐号。同时，构建内网的IP白名单。MaxCompute的白名单是针对外网的，而在内网中也会有不少台机器，若是全部内网机器都拥有访问权限，也是不安全的。

· 方便统计：SQL开销统计到人，而且也能够方便地按部分来计费。

那么，在实际应用中应该如何作呢？整体来说分为下图两种方案。

方案一：代理转发。收到数据后转发到MaxCompute而后再经过response返回。

方案二：服务端在调用SDK。利用MaxCompute SDK，每次得到请求后，解析请求中的参数，再返回给SDK。

因为方案二的工做量较大，咱们选择了方案一，它具备如下优势。

· 开发工做量小

· Pyodps升级也不影响

· 对于潜在的API接口具备兼容性

· 只实现咱们自由帐号体系

· ip白名单控制

 

下图展现了其核心代码。

下面简单介绍其中的部分代码。

对全部url进行规则判断，正则表达式中写的越多就会越优先命中。

主要是用于解决SQL代码重复执行的问题。

主要解决命令行的问题。MaxCompute主要分为两个入口，一个是SDK，另外一个是命令行。SDK是比较易于实现的。而命令行中会本身生成taskname，每一次请求都会check其taskname。

 

另外，构建安全控制时，必定要有本身的签名。不能使用客户端上传的签名，咱们只能使用客户端上传的SSID的前缀。

上面的代码中实现了整体的流程，但具体实现过程当中还存在一些问题。

难点1：如何确保优化后结果和实际执行结果一致？

· 从SQL中提取表信息和分区信息

· 在必定延时内，获取表数据的更新信息

解决方案：

· 构建SQL语法树，提取出表，目前还没解决分区

· 另起新进程，捕获表和分区的最后一次修改时间

难点2：命令行返回的适配，为何呢？

· task name 由客户端生成，例如：console_query_task_152696399361

· taskstatus和instanceprogress都会去校对服务端返回的信息中的task name, 一旦和客户端的task name不一致，会出现：FAILED: task status unknown

解决方案：客户端会从server的全部task name中查找到和本身同样的task name。

· 保存历史全部请求的task name

· 返回全部的task name

经过Proxy服务，取得了不错的效果：

· 提高了体验，具体例子：第一次sql执行耗时的70秒，再次执行不仅须要0.9秒；

· 减低了费用，总体费用减低了一半；

· 提高了安全的可控性，不暴露sercret_key给同事；

· 每一个业务分配1个帐号，能方便统计费用；

· 解决了前面提到的数据完整性问题。

目前，ofo使用的ODPS Proxy，任务调度和数据处理核心代码都已经开源。

原文连接

本文为云栖社区原创内容，未经容许不得转载。