ODPS大讲堂之SQL更新于4月28日凌晨

今天总算闲了一些，给同学们介绍些ODPS的基本知识吧。先从SQL开始说起。
一些基本的语法我就不介绍了，同学们可以参考SQL部分的文档：
ddl: create table/view, drop table/view, alter table/view,
dml: insert overwrite/into, multi insert, dynamic partition, select(sort by, distribute by, order by, group by, limit),  union, join(mapjoin)

这个贴子里说些电视台不让播的：
1. ODPS SQL 不支持update和delete，为什么？
     这个和分布式的使用场景及技术实现相关。在使用场景上，ODPS的设计目的是为了处理大规模（PB级别）数据，对于这样大的数据，只更一条数据的update操作的场景是不常见的。从技术实现上，update操作也会极大影响系统性能。主流的分布式系统中，都没有支持这两个操作。


2. ODPS支持的数据类型包括：Boolean, String, Bigint, Double, Datetime。


3. sort by 和order by的区别。
    本来想搞一个截图，但今天太累了。大家将就着看吧。
    由于odps是分布式的，因此排序也分两种。sort by 是 局部排序，order by是全局排序。
    比如启动了10个worker，如果是sort by排序，那么每个worker内部处理的数据是有序的。但用户从外部看，总体上是无序的。因此，sort by需要和distribute by连用。因为distribute by是将数据按照某一列的值以某种hash算法分配给后续的task中的所有worker的。先使用distribute by分配数据，再使用 sort by对每个worker内的数据进行排序。理论上，distribute by 容易产生所谓的数据倾斜，因为如果系统使用的hash算法不能将用户的数据平均分配给后续作业的所有worker，有可能出现的额一种情况是：某个worker承担了大量数据的处理，但其他worker处理的数据量很小。如果这种情况产生，有些worker会很快结束，但有些会运行很长时间。判断数据是否倾斜要依赖同学们的使用经验，没有统一的标准来判断。悲催的是，我们目前也没有提供给大家太多用来查看数据倾斜的手段。console提供了log命令，大家可以尝试使用下。
    第二种排序如果是order by，所有数据全局有序。同样10个worker处理所有数据的排序，现在内部进行局部排序。最后还需要额外一个worker对所有数据进行全局排序，即收集上面10个worker的结果，进行统一排序。从这个过程中，大家可以看到，order by的处理方法实际上是反分布式的。因为为了达到全局排序，一定需要一个worker处理所有数据。因此，这就是为什么odps需要限制order by的使用，后面必须加limit。limit的作用是为了限制order by的全局排序数量，例如只排序前10000条数据。
    额外说一句，由于order by及distribute by的语义有矛盾，因此这两种操作也不能出现在同一个select语句中。因为distribute by是为了分发数据。而order by是为了合并排序数据。一个是分发，一个是合并，一山不容二虎，除非一公和一母。


4. distribute by + sort by与group by的区别。
    从表面上看来，distribute by + sort by的记过和group by是比较相近的。但如果对Hadoop比较熟悉的同学应该了解Compare和groupcompare。有兴趣的同学可以查查Hadoop文档。
   从使用功能上来看，聚合函数可以和group by连用，但不能和distribute by sort by连用。
   我有点困了，先更新到这里。


5. 什么是窗口函数


6. 什么是聚合函数

对分布式SQL有兴趣的同学也可以到网上找找相关资料，有一个叫Hive的东西，呵呵。

文档陆续更新中....