ODPS 功能之概述篇

用户项目空间-Project
Project是用户使用ODPS时最先接触的概念，它类似Oracle的schema或者Mysql中的database。Project 也是ODPS中最基本的资源隔离单位，每个用户数据及计算任务都隶属于一个Project。 各Project 之间也可以通过授权建立共享通道，进行数据交换。Project 也是ODPS中的计量单元，收费也是以一个Project为基本单位的。
用户在使用ODPS之前，需要申请创建一个Project，有了Project之后，用户就可以上传数据做数据分析了。
数据处理流程
一般的大数据处理流程分为三部分，如下图所示：

1. 数据主要来源于在线系统，如业务数据库Mysql、Oracle，网站的日志文件。 这些数据都可以通过ODPS提供的数据通道功能导入到ODPS中；
2. 数据导入后，可以使用SQL、MR做数据分析，也可以使用流计算对数据进行聚合等操作，还可以使用机器学习算法对数据建模、预测。ODPS提供的是“All in One ”服务，只要数据导入到ODPS后，各种高大尚分析挖掘工具都可以直接拿过来使用，用户只需要关注在自己的数据业务，根本不需要关于底层是如何工作的；
3. 数据处理完毕后，如果是算法模型，可以使用ODPS的在线预测服务，将模型Push到在线预测系统中进行在线的数据预测。如果是分析结果，可以通过数据通道导回到Mysql 、Oracle中，与业务应用系统对接；
围绕这样的一个数据处理流程，ODPS在各个阶段提供了不同的功能。
数据存储
用户的数据上传到ODPS后，默认会以结构化的方式存储到ODPS的表。表隶属于Project，可以进行分区，有自己的数据类型，如Bigint, Boolean, Double, Datetime, String, Decimal。 数据上传后，以列压缩的方式存储到盘古上。这种压缩方式的好处就是对于文本类型的数据，一般都能取得较好的压缩比，一般是4：1，即10G的数据，在ODPS上的size为2.5G。每个文件默认会保存三份。
数据通道
根据数据分析的性质， ODPS提供两种数据通道-批量数据上传及实时数据上传两种。
批量数据上传适合大量数据的上传，批量上传通道限制每个写入ODPS的数据块最大为100G。每次上传完成后，调用Commit方法，数据即可保存到表中；
实时上传适合数据流处理的场景，如流计算，每次上传数据的packet为2M。通过实时通道上传的数据可以直接使用ODPS Stream SQL 进行流计算，也可以使用数据订阅接口将数据转发到第三方的流计算应用中，这个功能就类似于AWS的Kinesis。 通过实时上传的数据，默认会保存一份到ODPS表中，所以也可以通过实时通道向ODPS实时导入数据；
批量通道提供了上传和下载的接口，实时通道只提供了上传的接口，但同时也提供了订阅接口，允许数据被其它应用所订阅。
使用可以使用CLT中的数据上传命令将本地的文本文件上传至ODPS，也可以使用Java、Python SDK通过编程上传数据。 同时ODPS也引入了两个开源社区中日志数据上传的两大利器：Flume和Fluentd。用户可以使用这两个工具将各种源的数据上传到ODPS中。今天ODPS的用户大部分都在通过这两款工具将Web 日志实时导入到ODPS中做数据分析。
SQL
用户最熟悉使用SQL对数据分析了。ODPS也支持SQL查询操作，而且语法类似于Hive 的HQL。SQL操作的主要对象是表，数据量可在T级到P级。SQL中提供的功能有：
DLL：表、列、分区、视图、生命周期等操作 ；
DML：数据更新、多路输出以及动态分区输出 ；
Join：多表关联分析，支持 inner , left , right full join 以及mapjoin;
窗口函数：支持常见的窗口函数如avg,count 也支持滑动窗口；
UDF： 支持通过Java、Python编写UDF、UDAF和UDTF；
Stream SQL
通过实时通道上传的数据，可以直接使用Stream SQL做流计算。 ODPS 的流计算是一种创新的流计算方式，可以通过类SQL的语法就能定义流计算的作业，如：
创建一个流计算的任务，该任务引用stream_in表作为数据源，并且将结果写入stream_out表中
create streamjob streamjob1 as
insert into stream_out
select count(*)
from stream_in ;
end streamjob;
随着数据的上传，在ODPS客户端窗口中执行若干次
select * from stream_out;
会发现有一系列逐渐累积增长的汇总数据。
Stream SQL 支持单流计算、多流Join、同时还支持流与维表的Join，并提供了聚合、排序及子查询的功能。
MapReduce
ODPS提供了MapReduce的编程接口。用户在处理数据时，如果SQL满足不了要求，可以使用MapReduce。
MapReduce处理数据过程主要分成2个阶段：Map阶段和Reduce阶段。首先执行Map阶段，再执行Reduce阶段。Map和Reduce的处理逻辑由用户自定义实现， 但要符合MapReduce框架的约定。
· 在正式执行Map前，需要将输入数据进行”分片”。所谓分片，就是将输入数据切分为大小相等的数据块，每一块作为单个Map Worker的输入被处理， 以便于多个Map Worker同时工作。
· 分片完毕后，多个Map Worker就可以同时工作了。每个Map Worker在读入各自的数据后，进行计算处理，最终输出给Reduce。Map Worker在输出数据时， 需要为每一条输出数据指定一个Key。这个Key值决定了这条数据将会被发送给哪一个Reduce Worker。Key值和Reduce Worker是多对一的关系， 具有相同Key的数据会被发送给同一个Reduce Worker，单个Reduce Worker有可能会接收到多个Key值的数据。
· 在进入Reduce阶段之前，MapReduce框架会对数据按照Key值排序，使得具有相同Key的数据彼此相邻。如果用户指定了”合并操作”(Combiner)， 框架会调用Combiner，将具有相同Key的数据进行聚合。Combiner的逻辑可以由用户自定义实现。与经典的MapReduce框架协议不同，在ODPS中， Combiner的输入、输出的参数必须与Reduce保持一致。这部分的处理通常也叫做”洗牌”(Shuffle)。
· 接下来进入Reduce阶段。相同的Key的数据会到达同一个Reduce Worker。同一个Reduce Worker会接收来自多个Map Worker的数据。 每个Reduce Worker会对Key相同的多个数据进行Reduce操作。最后，一个Key的多条数据经过Reduce的作用后，将变成了一个值。
由于目前ODPS MR只能处理ODPS中表里的数据，与Hadoop MR相比，不同的地方就在Map和Reduce 的声明上，如下：

ODPS MR的输入数据是表的Record，可以通过Record对象来获取每列的值，如：

ODPS对用户提供了JAVA的MR编程接口，同时还可以使用开源的Eclipse 开源插件在本地编写、调度MR程序，成功后再部署到ODPS上运行。
图模型-Graph
ODPS 提供了类似Google Pregel的图编程模型。 用户可以用来编写满足聚类、Pagerank以及求最短路径这样场景的算法。
ODPS GRAPH能够处理的图必须是是一个由点(Vertex)和边(Edge)组成的有向图。由于ODPS仅提供二维表的存储结构， 因此需要用户自行将图数据分解为二维表格式存储在ODPS中，在进行图计算分析时， 使用自定义的GraphLoader将二维表数据转换为ODPS Graph引擎中的点和边。
点的结构可以简单表示为 < ID, Value, Halted, Edges >，分别表示点标识符(ID)，权值(Value)，状态(Halted, 表示是否要停止迭代)， 出边集合(Edges，以该点为起始点的所有边列表)。边的结构可以简单表示为<DestVertexID, Value >，分别表示目标点(DestVertexID)和权值(Value)。如下图所示：

典型的Graph 程序逻辑包括三步：
1. 加载图：通过自定义的GraphLoader将数据解析为点或边，并对数据分片，分配到相应的Worker上；
2. 迭代计算：遍历所有非结束状态的点或收到消息的点，并调用其Compute方法进行计算；
3. 迭代终止：所有点处于结束或达到最大迭代次数后，程序终止；
机器学习平台 DT PAI
DT PAI是阿里巴巴推出的基于云计算的机器学习平台。在这个平台上，用户可以使用多种算法及在线预测服务。
DT PAI的功能包括