RDD可以很好地适用于支持数据并行的批量分析应用，包括数据挖掘，机器学习，图算法等，因为这些程序通常都会在很多记录上执行相同的操作。RDD不太适合那些异步更新共享状态的应用，例如并行web爬行器。因此，我们的目标是为大多数分析型应用提供有效的编程模型，而其他类型的应用交给专门的系统。

关于RDD详见：

弹性分布式数据集：一种基于内存的集群计算的容（二）：弹性分布式数据集（RDD）

硬件环境：

开发机器是 3台 Intel(R) Xeon(R) CPU E5440 @ 2.83GHz双核 2.8G 4G内存

操作系统：

Red Hat Enterprise Linux Server release 5.7 (Tikanga)

Spark配置：

三节点，每个节点2G内存，14 个维度，100个类别，10次迭代，使用不同大小样例文件分析。

结论1：定义0.8（数据量/2048/3）作为三节点的阈值，当运行数据在阈值内时性能成单调递增，当超过该阈值时，性能急剧下降，当超过阈值2%时性能下降53.11937%，当超过34.01326%，性能下降70.80896%

以下是测试数据：

性能趋势图：

Spark配置：

一节点， 2G内存，14 个维度，100个类别，10次迭代。

结论2：定义0.9（数据量/2048）作为三节点的阈值，当运行数据在阈值内时性能成单调递增，当超过该阈值时，性能急剧下降，当超过阈值8.3334961%时性能下降57.61797318%，当超过18.18167291%，性能下降66.4701143%

当超过36.36441116%，性能下降94.14757913%

性能趋势图：

总论：在执行Spark程序的时候需预估所需的内存，当超过一定阈值后，性能将急剧下降。

版权声明：原创作品，转载请保持文章完整性，转载时请务必以超链接形式标明文章原始出版、作者信息和本声明。否则将追究法律责任。

博客地址：http://www.ninqing.net/

微博地址：http://weibo.com/ninqing

Storm是twitter开源的一套实时数据处理框架，基于该框架你可以通过简单的编程来实现对数据流的实时处理变换。

Storm的配置文件一般存放在$STORM_HOME/conf下，通常名为storm.yaml，它符合yaml格式要求。

配置项详解:

以下是从storm的backtype.storm.Config类中搜集的所有storm支持的配置项(Based storm 0.6.0):

1数据倾斜的原因

1.1操作：

1.2原因：

1)、key分布不均匀

2)、业务数据本身的特性

3)、建表时考虑不周

4)、某些SQL语句本身就有数据倾斜

1.3表现：

任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。

单一reduce的记录数与平均记录数差异过大，通常可能达到3倍甚至更多。 最长时长远大于平均时长。

2数据倾斜的解决方案

2.1参数调节：

hive.map.aggr = true

Map 端部分聚合，相当于Combiner

hive.groupby.skewindata=true

有数据倾斜的时候进行负载均衡，当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。

2.2 SQL语句调节：

如何Join：

关于驱动表的选取，选用join key分布最均匀的表作为驱动表

做好列裁剪和filter操作，以达到两表做join的时候，数据量相对变小的效果。

大小表Join：

使用map join让小的维度表（1000条以下的记录条数） 先进内存。在map端完成reduce.

大表Join大表：

把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果。

count distinct大量相同特殊值

count distinct时，将值为空的情况单独处理，如果是计算count distinct，可以不用处理，直接过滤，在最后结果中加1。如果还有其他计算，需要进行group by，可以先将值为空的记录单独处理，再和其他计算结果进行union。

group by维度过小：

采用sum() group by的方式来替换count(distinct)完成计算。

特殊情况特殊处理：

在业务逻辑优化效果的不大情况下，有些时候是可以将倾斜的数据单独拿出来处理。最后union回去。

3典型的业务场景

3.1空值产生的数据倾斜

场景：如日志中，常会有信息丢失的问题，比如日志中的 user_id，如果取其中的 user_id 和 用户表中的user_id 关联，会碰到数据倾斜的问题。

解决方法1： user_id为空的不参与关联（红色字体为修改后）

select * from log a

  join users b

  on a.user_id is not null

  and a.user_id = b.user_id

union all

select * from log a

  where a.user_id is null;

解决方法2 ：赋与空值分新的key值

select *

  from log a

  left outer join users b

  on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;

结论：方法2比方法1效率更好，不但io少了，而且作业数也少了。解决方法1中 log读取两次，jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数，就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。

3.2不同数据类型关联产生数据倾斜

场景：用户表中user_id字段为int，log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时，默认的Hash操作会按int型的id来进行分配，这样会导致所有string类型id的记录都分配到一个Reducer中。

解决方法：把数字类型转换成字符串类型

select * from users a

  left outer join logs b

  on a.usr_id = cast(b.user_id as string)

3.3小表不小不大，怎么用 map join 解决倾斜问题

使用 map join 解决小表(记录数少)关联大表的数据倾斜问题，这个方法使用的频率非常高，但如果小表很大，大到map join会出现bug或异常，这时就需要特别的处理。 以下例子:

select * from log a

  left outer join users b

  on a.user_id = b.user_id;

users 表有 600w+ 的记录，把 users 分发到所有的 map 上也是个不小的开销，而且 map join 不支持这么大的小表。如果用普通的 join，又会碰到数据倾斜的问题。

解决方法：

select /*+mapjoin(x)*/* from log a

  left outer join (

    select  /*+mapjoin(c)*/d.*

      from ( select distinct user_id from log ) c

      join users d

      on c.user_id = d.user_id

    ) x

  on a.user_id = b.user_id;

假如，log里user_id有上百万个，这就又回到原来map join问题。所幸，每日的会员uv不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。

4总结

使map的输出数据更均匀的分布到reduce中去，是我们的最终目标。由于Hash算法的局限性，按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤：

1、采样log表，哪些user_id比较倾斜，得到一个结果表tmp1。由于对计算框架来说，所有的数据过来，他都是不知道数据分布情况的，所以采样是并不可少的。

2、数据的分布符合社会学统计规则，贫富不均。倾斜的key不会太多，就像一个社会的富人不多，奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。

3、map读入users和log，假如记录来自log,则检查user_id是否在tmp2里，如果是，输出到本地文件a,否则生成<user_id,value>的key,value对，假如记录来自member,生成<user_id,value>的key,value对，进入reduce阶段。

4、最终把a文件，把Stage3 reduce阶段输出的文件合并起写到hdfs。

如果确认业务需要这样倾斜的逻辑，考虑以下的优化方案：

1、对于join，在判断小表不大于1G的情况下，使用map join

2、对于group by或distinct，设定 hive.groupby.skewindata=true

3、尽量使用上述的SQL语句调节进行优化

AOP

AOP是Btrace, jip¹等众多监测工具的核心思想, 用一段代码最容易说明:

public void say(String words){
  Trace.enter();
  System.out.println(words);
  Trace.exit();
}

如上, Trace.enter() 和 Trace.exit() 将say(words)内的代码环抱起来, 对方法进出的进行切面的处理, 便可获取运行时的上下文, 如:

• 调用栈
• 当前线程
• 时间消耗
• 参数与返回值
• 当前实例状态

实现的选择

实现切面的方式, 我知道的有以下几种:

代理(装饰器)模式

设计模式中装饰器模式和代理模式, 尽管解决的问题域不同, 代码实现是非常相似, 均可以实现切面处理, 这里视为等价. 依旧用代码说明:

interface Person {
  void say(String words);
}

class Officer implements Person {
  public void say(String words) { lie(words); }
  private void lie(String words) {...}
}

class Proxy implements Person {
  private final Officer officer;
  public Proxy(Officer officer) { this.officer = officer; }
  public void say(String words) {
    enter();
    officer.say(words);
    exit();
  }
  private void enter() { ... }
  private void exit() { ... }
}

Person p = new Proxy(new Officer());

很明显, 上述enter() 和exit()是实现切面的地方, 通过获取Officer的Proxy实例, 便可对Officer实例的行为进行跟踪. 这种方式实现起来最简单, 也最直接.

Java Proxy

Java Proxy是JDK内置的代理API, 借助反射机制实现. 用它来是完成切面则会是:

class ProxyInvocationHandler implements InvocationHandler {
  private final Object target;
  public ProxyInvocationHandler(Object target) { this.target = target;}
  public Object handle(Object proxy, Method method, Object[] args) {
    enter();
    method.invoke(target, args);
    exit();
  }
  private void enter() { ... }
  private void exit() { ... }
}
ClassLoader loader = ...
Class<?>[]  interfaces = {Person.class};
Person p = (Person)Proxy.newInstance(loader, interfaces, new ProxyInvocationHandler(new Officer()));

相比较上一中方法, 这种不太易读, 但更为通用, 对具体实现依赖很少.

AspectJ

AspectJ³是基于字节码操作的AOP实现, 相比较Java proxy, 它会显得对调用更”透明”, 编写更简明(类似DSL), 性能更好. 如下代码:

pointcut say(): execute(* say(..))
before(): say() { ... }
after() : say() { ... }

Aspectj实现切面的时机有两种: 静态编译和类加载期编织(load-time weaving). 并且它对IDE的支持很丰富.

CGlib

与AspectJ一样CGlib⁴也是操作字节码来实现AOP的, 使用上与Java Proxy非常相似, 只是不像Java Proxy对接口有依赖, 我们熟知的Spring, Guice之类的IoC容器实现AOP都是使用它来完成的.

class Callback implements MethodInterceptor {
  public Object intercept(Object obj, java.lang.reflect.Method method, Object[] args, MethodProxy proxy) throws Throwable {
    enter();
    proxy.invokeSuper(obj, args);
    exit();
  }
  private void enter() { ... }
  private void exit() { ... }
}
Enhancer e = new Enhancer();
e.setSuperclass(Officer.class);
e.setCallback(new Callback());
Person p = e.create();

字节码操纵

上面四种方法各有适用的场景, 但唯独对运行着的Java进程进行动态的跟踪支持不了, 当然也许是我了解的不够深入, 若有基于上述方案的办法还请不吝赐教.

还是回到Btrace⁵的思路上来, 在理解了它借助java.lang.Instrumentation进行字节码注入的实现原理⁶后, 实现动态变化跟踪方式或目标应该没有问题.

借下来的问题, 如何操作(注入)字节码实现切面的处理. 可喜的是, “构建自己的监测工具”⁷一文给我提供了一个很好的切入点. 在此基础上, 经过一些对ASM⁸的深入研究, 可以实现:

• 方法调用进入时, 获取当前实例(this) 和 参数值列表;
• 方法调用出去时, 获取返回值;
• 方法异常抛出时, 触发回调并获取异常实例.

其切面实现的核心代码如下:

 private static class ProbeMethodAdapter extends AdviceAdapter {

    protected ProbeMethodAdapter(MethodVisitor mv, int access, String name, String desc, String className) {
      super(mv, access, name, desc);
      start = new Label();
      end = new Label();
      methodName = name;
      this.className = className;
    }

    @Override
    public void visitMaxs(int maxStack, int maxLocals) {
      mark(end);
      catchException(start, end, Type.getType(Throwable.class));
      dup();
      push(className);
      push(methodName);
      push(methodDesc);
      loadThis();
      invokeStatic(Probe.TYPE, Probe.EXIT);
      visitInsn(ATHROW);
      super.visitMaxs(maxStack, maxLocals);
    }

    @Override
    protected void onMethodEnter() {
      push(className);
      push(methodName);
      push(methodDesc);
      loadThis();
      loadArgArray();
      invokeStatic(Probe.TYPE, Probe.ENTRY);
      mark(start);
    }

    @Override
    protected void onMethodExit(int opcode) {
      if (opcode == ATHROW) return; // do nothing, @see visitMax
      prepareResultBy(opcode);
      push(className);
      push(methodName);
      push(methodDesc);
      loadThis();
      invokeStatic(Probe.TYPE, Probe.EXIT);
    }

    private void prepareResultBy(int opcode) {
      if (opcode == RETURN) { // void
        push((Type) null);
      } else if (opcode == ARETURN) { // object
        dup();
      } else {
        if (opcode == LRETURN || opcode == DRETURN) { // long or double
          dup2();
        } else {
          dup();
        }
        box(Type.getReturnType(methodDesc));
      }
    }

    private final String className;
    private final String methodName;
    private final Label start;
    private final Label end;
}

更多参考请见这里的 Demo , 它是javaagent, 在伴随宿主进程启动后, 提供MBean可用jconsole进行动态跟踪的管理.

后续的方向

1. 提供基于Web的远程交互界面;
2. 提供基于Shell的本地命令行接口;
3. 提供Profile统计和趋势输出;
4. 提供跟踪日志定位与分析.

参考

1. The Java Interactive Profiler
2. Proxy Javadoc
3. Aspectj
4. CGlib
5. BTrace User’s Guide
6. java动态跟踪分析工具BTrace实现原理
7. 构建自己的监测工具
8. ASM Guide
9. 常用 Java Profiling 工具的分析与比较
10. AOP@Work: Performance monitoring with AspectJ
11. The JavaTM Virtual Machine Specification
12. 来自rednaxelafx的JVM分享, 他的 Blog
13. BCEL

一、MapR是什么？

MapR是MapR Technologies, Inc的一个产品，号称下一代Hadoop，使Hadoop变为一个速度更快、可靠性更高、更易于管理、使用更加方便的分布式计算服务和存储平台，同时性能也不断提高。它将极大的扩大了Hadoop的使用范围和方式。它包含了开源社区的许多流行的工具和功能，例如Hbase、Hive。它还100%和Apache Hadoop的API兼容。它能够为客户节约一半的硬件资源消耗，使更多的组织能够利用海量数据分析的力量提高竞争优势。目前有两个版本，M3和M5，其中M3是免费的，M5为收费版，有试用期。具体功能差别见：http://www.mapr.com/products/mapr-editions.html。

1、MapR的整体结构：

二、为什么要MapR？

MapR比之其他Hadoop发行版具有三大优越性：EASY、DEPENDABLE、FAST。

Easy：

• 有强大的管理工具：MapR Control System，方便的查看集群的状态，作业执行情况，各项配置等；
• Mount Hadoop with Direct Access NFS™ . This allows users to mount the entire Hadoop cluster as an NFS volume . Users can simply browse files, automatically open associated applications with a mouse click, or drag-and-drop files and directories into and out of the cluster. Additionally, standard command-line tools and UNIX applications and utilities (such as Grep, Tar, Sort, or Tail) can be used directly on data in the cluster. With other Hadoop distributions, the user must copy the data out of the cluster in order to use standard tools . 不同于HDFS的一次写入，MapR允许修改、重写文件，可并发读写任一文件。
• 安装配置简单，完整发布版包括：HBase, Pig, Hive, Mahout, HBase, Cascading, ZooKeeper等。（但其实M3没有默认安装HBase, Pig, Hive, Mahout，需要自己另行安装）
• 和Hadoop – MapReduce, HDFS ,HBase 100% API兼容。

Dependable:

• 分布式的NameNode，避免单点失败；（M5才有）
• 镜像，MapR的镜像让你可以根据你的Recovery Time objectives设定策略，自动镜像你集群内、集群间或者站点间的数据，（M5才有）
• 快照，采用redirect-on-write技术，速度快，可以设定快照计划或者随机使用快照，操作简单。（M5才有）
• 使多个作业安全地共享集群资源，MapR可以给用户设定资源配额，跟踪容量的使用情况。

Fast：

• 比其他的发行版快，而且节约一半的硬件资源；
• Higher MapReduce and HBase throughput (2X – 5X)
• Optimized shuffle
• Higher random I/O (5X to 100X)
• 自动、透明的压缩节省了网络和磁盘开销；
• Lockless architecture scales linearly with number of cores and nodes

在MapR的官方网站http://www.mapr.com/products/why-mapr.html上有更详细的介绍，有兴趣可以进一步了解。

三、如何使用MapR

MapR 可以像hadoop那样支持单点安装伪集群，但在集群环境下才能真正体现它的威力。我这里在四台服务器上安装MapR Edition 3 ，主要介绍M3-RHEL or CentOS安装。

Hardware Requirements

每个节点必须满足下表所列的要求：

Disk

• At least one free unmounted drive or partition, 50 GB or more（参见安装前准备－>disksetup）
• At least 10 GB of free space on the operating system partition

Software

确保在所有的节点上安装的是６４位的操作系统，目前ＭａｐＲ仅支持以下操作系统：

• CentOS 5.x
• Red Hat Enterprise Linux 5.x or 6.0
• Ubuntu 9.04 or above

主机名唯一（使用虚拟机的需注意这一点）

每个节点安装JDK：

• Sun Java JDK 6（一定要是sun的，系统已安装了openjdk的要注意设置ｓｕｎ的为默认jdk）

安装前准备

最好用root用户执行整个过程，我之前用其他用户碰到了一些问题。这里统一默认使用root用户。

规划：

确定集群规模，以及在每台机器上安装的服务。详见：

http://www.mapr.com/doc/display/MapR/Planning+Roles

我这里是：

Node1：CLDB，FileServer，JobTracker，NFS，TaskTracker，WebServer，ZooKeeer。

Node2：FileServer，TaskTracker，ZooKeeer。

Node3：FileServer，TaskTracker，ZooKeeer。

Node4：FileServer，TaskTracker。

disksetup：

setting up disks for MapR是一个重要步骤，查看机器是否有这样一块磁盘空间：具体参考：http://www.mapr.com/doc/display/MapR/Setting+Up+Disks+for+MapR。

在每台机器上创建文件/tmp/disks.txt，列出本机所有可被MapR使用的磁盘。

由于我的机器上没有符合要求的磁盘空间，我的做法是：（这种方法不能很好发挥MapR威力，仅用来测试）

/sbin/modprobe loop

mkdir /disk1/mapr-disks

dd if=/dev/zero of=/disk1/mapr-disks/loop0 bs=1G count=20

/sbin/losetup -f

/sbin/losetup /dev/loop0 /disk1/mapr-disks/loop0

echo /dev/loop0 > /tmp/disks.txt

SSH keyless：

确保服务器之间SSH无密码访问，也很简单，就是在每台服务器执行“ssh-keygen -t rsa”，回车不输入密码，生成密钥和公钥，在某台机器上的／root／.ssh目录下新建authorized_keys文件，将所有机器的公钥内容添加到authorized_keys，再将authorized_keys复制到其他机器的／root／.ssh目录下。在每台机器上SSH登录所有机器（包括自己），第一次会要求输入密码，并记录为已知主机，下次就不用再输了。

安装

1、在所有节点的/etc/yum.repos.d/下创建maprtech.repo文件, 内容为：（注意baseurl中的archive，官方网站上的文档有错）

[maprtech]

name=MapR Technologies

baseurl=http://archive.mapr.com/redhat

enabled=1

gpgcheck=0

protect=1

2、在 node 1, 执行命令：

yum install mapr-cldb mapr-fileserver mapr-jobtracker mapr-nfs mapr-tasktracker mapr-webserver mapr-zookeeper

在 node 2和node 3, 执行命令:

yum install mapr-fileserver mapr-tasktracker mapr-zookeeper

在nodes 4, 执行命令:

yum install mapr-fileserver mapr-tasktracker

3、配置和磁盘格式化，在所有节点执行:

/opt/mapr/server/configure.sh -C <node1IP> -Z <node1IP>,<node2IP>,<node3IP>

/opt/mapr/server/disksetup -F /tmp/disks.txt

4、启动zookeeper，在node1, node2,node3,执行命令：

/etc/init.d/mapr-zookeeper start

注意：MapR中用的是zookeeper3.3.2，有个bug，启动不成功之后再次启动会报错，详见：https://issues.apache.org/jira/browse/ZOOKEEPER-1061。

5、在node1执行：

/etc/init.d/mapr-warden start

在node1用以下命令给用户授权：

/opt/mapr/bin/maprcli acl edit -type cluster -user root:fc

6、许可证书：

在安装证书之前NFS是不可用的，所以在日志中会看到很多ERROR，有两种方法安装证书：通过可视化页面MapR Control System或者命令行。

MapR Control System方法参考：

http://www.mapr.com/doc/display/MapR/M3+-+RHEL+or+CentOS的第11步。

命令行：先在http://mapr.com/register/login.html注册用户，然后注册一个集群，Cluster ID可以在node1上执行：maprcli license showid得到，注册完后得到证书，在node1上新建文件lice保存证书内容，执行：

maprcli license add -is_file true –license lice

证书安装成功，可通过maprcli license list查看。

7、启动NFS，在node1执行：

/opt/mapr/bin/maprcli node services -nodes node1IP -nfs start

8、在node2、node3、node4执行：

etc/init.d/mapr-warden start

9、通过https://node1IP:8443，登录MapR Control System，Enjoy it ！

10、在终端进入hadoop下bin目录，输入hadoop mfs -ls / ,查看文件系统；

11、在终端执行

hadoop jar /opt/mapr/hadoop/hadoop-0.20.2/hadoop-0.20.2-dev-examples.jar pi 2 50

更多信息参考：http://www.mapr.com/doc/display/MapR/Home

淘宝网拥有国内最具商业价值的海量数据。截至当前，每天有超过30亿的店铺、商品浏览记录，10亿在线商品数，上千万的成交、收藏和评价数据。如何从这些数据中挖掘出真正的商业价值，进而帮助淘宝、商家进行企业的数据化运营，帮助消费者进行理性的购物决策，是淘宝数据平台与产品部的使命。

为此，我们进行了一系列数据产品的研发，比如为大家所熟知的量子统计、数据魔方和淘宝指数等。尽管从业务层面来讲，数据产品的研发难度并不高；但在“海量”的限定下，数据产品的计算、存储和检索难度陡然上升。本文将以数据魔方为例，向大家介绍淘宝在海量数据产品技术架构方面的探索。

淘宝海量数据产品技术架构

数据产品的一个最大特点是数据的非实时写入，正因为如此，我们可以认为，在一定的时间段内，整个系统的数据是只读的。这为我们设计缓存奠定了非常重要的基础。

图1 淘宝海量数据产品技术架构

按照数据的流向来划分，我们把淘宝数据产品的技术架构分为五层（如图1所示），分别是数据源、计算层、存储层、查询层和产品层。位于架构顶端的是我们的数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。这一系列的数据是数据产品最原始的生命力所在。

在数据源层实时产生的数据，通过淘宝自主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到一个有1500个节点的Hadoop集群上，这个集群我们称之为“云梯”，是计算层的主要组成部分。在“云梯”上，我们每天有大约40000个作业对1.5PB的原始数据按照产品需求进行不同的MapReduce计算。这一计算过程通常都能在凌晨两点之前完成。相对于前端产品看到的数据，这里的计算结果很可能是一个处于中间状态的结果，这往往是在数据冗余与前端计算之间做了适当平衡的结果。

不得不提的是，一些对实效性要求很高的数据，例如针对搜索词的统计数据，我们希望能尽快推送到数据产品前端。这种需求再采用“云梯”来计算效率将是比较低的，为此我们做了流式数据的实时计算平台，称之为“银河”。“银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。

容易理解，“云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。这是因为，对于“云梯”来说，它的定位只是做离线计算的，无法支持较高的性能和并发需求；而对于“银河”而言，尽管所有的代码都掌握在我们手中，但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中，避免不了分层，最终仍然落到了目前的架构上。

为此，我们针对前端产品设计了专门的存储层。在这一层，我们有基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom，在后面的文字中，我将重点介绍这两个集群的实现原理。除此之外，其他第三方的模块也被我们纳入存储层的范畴。

存储层异构模块的增多，对前端产品的使用带来了挑战。为此，我们设计了通用的数据中间层——glider——来屏蔽这个影响。glider以HTTP协议对外提供restful方式的接口。数据产品可以通过一个唯一的URL获取到它想要的数据。

以上是淘宝海量数据产品在技术架构方面的一个概括性的介绍，接下来我将重点从四个方面阐述数据魔方设计上的特点。

关系型数据库仍然是王道

关系型数据库（RDBMS）自20世纪70年代提出以来，在工业生产中得到了广泛的使用。经过三十多年的长足发展，诞生了一批优秀的数据库软件，例如Oracle、MySQL、DB2、Sybase和SQL Server等。

图2 MyFOX中的数据增长曲线

尽管相对于非关系型数据库而言，关系型数据库在分区容忍性（Tolerance to Network Partitions）方面存在劣势，但由于它强大的语义表达能力以及数据之间的关系表达能力，在数据产品中仍然占据着不可替代的作用。

淘宝数据产品选择MySQL的MyISAM引擎作为底层的数据存储引擎。在此基础上，为了应对海量数据，我们设计了分布式MySQL集群的查询代理层——MyFOX，使得分区对前端应用透明。

图3 MyFOX的数据查询过程

目前，存储在MyFOX中的统计结果数据已经达到10TB，占据着数据魔方总数据量的95%以上，并且正在以每天超过6亿的增量增长着（如图2所示）。这些数据被我们近似均匀地分布到20个MySQL节点上，在查询时，经由MyFOX透明地对外服务（如图3所示）。

图4 MyFOX节点结构

值得一提的是，在MyFOX现有的20个节点中，并不是所有节点都是“平等”的。一般而言，数据产品的用户更多地只关心“最近几天”的数据，越早的数据，越容易被冷落。为此，出于硬件成本考虑，我们在这20个节点中分出了“热节点”和“冷节点”（如图4所示）。

顾名思义，“热节点”存放最新的、被访问频率较高的数据。对于这部分数据，我们希望能给用户提供尽可能快的查询速度，所以在硬盘方面，我们选择了每分钟15000转的SAS硬盘，按照一个节点两台机器来计算，单位数据的存储成本约为4.5W/TB。相对应地，“冷数据”我们选择了每分钟7500转的SATA硬盘，单碟上能够存放更多的数据，存储成本约为1.6W/TB。

将冷热数据进行分离的另外一个好处是可以有效降低提高内存磁盘比。从图4可以看出，“热节点”上单机只有24GB内存，而磁盘装满大约有1.8TB（300 * 12 * 0.5 / 1024），内存磁盘比约为4:300，远远低于MySQL服务器的一个合理值。内存磁盘比过低导致的后果是，总有一天，即使所有内存用完也存不下数据的索引了——这个时候，大量的查询请求都需要从磁盘中读取索引，效率大打折扣。

NoSQL是SQL的有益补充

在MyFOX出现之后，一切都看起来那么完美，开发人员甚至不会意识到MyFOX的存在，一条不用任何特殊修饰的SQL语句就可以满足需求。这个状态持续了很长一段时间，直到有一天，我们碰到了传统的关系型数据库无法解决的问题——全属性选择器（如图5所示）。

图5 全属性选择器

这是一个非常典型的例子。为了说明问题，我们仍然以关系型数据库的思路来描述。对于笔记本电脑这个类目，用户某一次查询所选择的过滤条件可能包括“笔记本尺寸”、“笔记本定位”、“硬盘容量”等一系列属性（字段），并且在每个可能用在过滤条件的属性上，属性值的分布是极不均匀的。在图5中我们可以看到，笔记本电脑的尺寸这一属性有着10个枚举值，而“蓝牙功能”这个属性值是个布尔值，数据的筛选性非常差。

在用户所选择的过滤条件不确定的情况下，解决全属性问题的思路有两个：一个是穷举所有可能的过滤条件组合，在“云梯”上进行预先计算，存入数据库供查询；另一个是存储原始数据，在用户查询时根据过滤条件筛选出相应的记录进行现场计算。很明显，由于过滤条件的排列组合几乎是无法穷举的，第一种方案在现实中是不可取的；而第二种方案中，原始数据存储在什么地方？如果仍然用关系型数据库，那么你打算怎样为这个表建立索引？

这一系列问题把我们引到了“创建定制化的存储、现场计算并提供查询服务的引擎”的思路上来，这就是Prometheus（如图6所示）。

图6 Prom的存储结构

从图6可以看出，我们选择了HBase作为Prom的底层存储引擎。之所以选择HBase，主要是因为它是建立在HDFS之上的，并且对于MapReduce有良好的编程接口。尽管Prom是一个通用的、解决共性问题的服务框架，但在这里，我们仍然以全属性选择为例，来说明Prom的工作原理。这里的原始数据是前一天在淘宝上的交易明细，在HBase集群中，我们以属性对（属性与属性值的组合）作为row-key进行存储。而row-key对应的值，我们设计了两个column-family，即存放交易ID列表的index字段和原始交易明细的data字段。在存储的时候，我们有意识地让每个字段中的每一个元素都是定长的，这是为了支持通过偏移量快速地找到相应记录，避免复杂的查找算法和磁盘的大量随机读取请求。

图7 Prom查询过程

图7用一个典型的例子描述的Prom在提供查询服务时的工作原理，限于篇幅，这里不做详细描述。值得一提的是，Prom支持的计算并不仅限于求和SUM运算，统计意义上的常用计算都是支持的。在现场计算方面，我们对Hbase进行了扩展，Prom要求每个节点返回的数据是已经经过“本地计算”的局部最优解，最终的全局最优解只是各个节点返回的局部最优解的一个简单汇总。很显然，这样的设计思路是要充分利用各个节点的并行计算能力，并且避免大量明细数据的网络传输开销。

用中间层隔离前后端

上文提到过，MyFOX和Prom为数据产品的不同需求提供了数据存储和底层查询的解决方案，但随之而来的问题是，各种异构的存储模块给前端产品的使用带来了很大的挑战。并且，前端产品的一个请求所需要的数据往往不可能只从一个模块获取。

举个例子，我们要在数据魔方中看昨天做热销的商品，首先从MyFOX中拿到一个热销排行榜的数据，但这里的“商品”只是一个ID，并没有ID所对应的商品描述、图片等数据。这个时候我们要从淘宝主站提供的接口中去获取这些数据，然后一一对应到热销排行榜中，最终呈现给用户。

图8 glider的技术架构

有经验的读者一定可以想到，从本质上来讲，这就是广义上的异构“表”之间的JOIN操作。那么，谁来负责这个事情呢？很容易想到，在存储层与前端产品之间增加一个中间层，它负责各个异构“表”之间的数据JOIN和UNION等计算，并且隔离前端产品和后端存储，提供统一的数据查询服务。这个中间层就是glider（如图8所示）。

缓存是系统化的工程

除了起到隔离前后端以及异构“表”之间的数据整合的作用之外，glider的另外一个不容忽视的作用便是缓存管理。上文提到过，在特定的时间段内，我们认为数据产品中的数据是只读的，这是利用缓存来提高性能的理论基础。

在图8中我们看到，glider中存在两层缓存，分别是基于各个异构“表”（datasource）的二级缓存和整合之后基于独立请求的一级缓存。除此之外，各个异构“表”内部可能还存在自己的缓存机制。细心的读者一定注意到了图3中MyFOX的缓存设计，我们没有选择对汇总计算后的最终结果进行缓存，而是针对每个分片进行缓存，其目的在于提高缓存的命中率，并且降低数据的冗余度。

大量使用缓存的最大问题就是数据一致性问题。如何保证底层数据的变化在尽可能短的时间内体现给最终用户呢？这一定是一个系统化的工程，尤其对于分层较多的系统来说。

图9 缓存控制体系

图9向我们展示了数据魔方在缓存控制方面的设计思路。用户的请求中一定是带了缓存控制的“命令”的，这包括URL中的query string，和HTTP头中的“If-None-Match”信息。并且，这个缓存控制“命令”一定会经过层层传递，最终传递到底层存储的异构“表”模块。各异构“表”除了返回各自的数据之外，还会返回各自的数据缓存过期时间（ttl），而glider最终输出的过期时间是各个异构“表”过期时间的最小值。这一过期时间也一定是从底层存储层层传递，最终通过HTTP头返回给用户浏览器的。

缓存系统不得不考虑的另一个问题是缓存穿透与失效时的雪崩效应。缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。在数据魔方里，我们采用了一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存失效时的雪崩效应对底层系统的冲击非常可怕。遗憾的是，这个问题目前并没有很完美的解决方案。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。在数据魔方中，我们设计的缓存过期机制理论上能够将各个客户端的数据失效时间均匀地分布在时间轴上，一定程度上能够避免缓存同时失效带来的雪崩效应。

结束语

正是基于本文所描述的架构特点，数据魔方目前已经能够提供压缩前80TB的数据存储空间，数据中间层glider支持每天4000万的查询请求，平均响应时间在28毫秒（6月1日数据），足以满足未来一段时间内的业务增长需求。

尽管如此，整个系统中仍然存在很多不完善的地方。一个典型的例子莫过于各个分层之间使用短连接模式的HTTP协议进行通信。这样的策略直接导致在流量高峰期单机的TCP连接数非常高。所以说，一个良好的架构固然能够在很大程度上降低开发和维护的成本，但它自身一定是随着数据量和流量的变化而不断变化的。我相信，过不了几年，淘宝数据产品的技术架构一定会是另外的样子。

举例而言, 在一个管理用户信息的业务场景中通常都会有:

01 class User {
02   Long id;
03   String name;
04   Integer age;
05 }
06 
07 interface UserRepository {
08   void add(User user);
09   void delete(User user);
10   User findBy(long id);
11   void update(User user);
12 }

01 CREATE TABLE `user_t` (
02   `id` int(10) unsigned NOT NULL,
03   `name` varchar(50) DEFAULT NULL,
04   `age` int(3) DEFAULT NULL,
05   PRIMARY KEY (`id`),
06   KEY `NAME` (`name`),
07   KEY `AGE` (`age`)
08 ) ENGINE=InnoDB

若直接使用HS4J提供的API, 代码会如HS4J Getting Started的示例一样, 模式化的重复. 对象结构简单还不是问题, 一旦对象字段十多个, 而且还老是要变化, 可想而知噩梦才刚刚开始.

使用Kit提供的注解来声明的话, 一切HS4J的调用操作全部将透明化:

01 @Repository(database="test", table="user_t")
02 interface UserRepository {
03   @HandlerSocket(INSERT)
04   @EntityClass(User.class)
05   void add(User user);
06   ...
07 }

接下来要写的代码就是:

01 HSClient hsClient = new HSClientImpl(new InetSocketAddress(9999));
02 ProxyFactory proxyFactory = new HandlerSocketProxyFactory(hsClient);
03 UserRepository proxy = proxyFactory.newProxyOf(UserRepository.class);
04 
05 proxy.add(new User(1L, "killme2008", 18));
06 
07 hsClient.shutdown();

抛开必要的初始化和销毁的代码, 除了一行必须的业务代码没有任何多余的.

这里没有配置表的列(Columns), 而是通过EntityClass来告诉Kit默认使用User的所有字段映射为表的所有列, 前提是User的字段名与表列名一致.

若列名与字段名无法一致的时候, 可以ColumnName来声明:

01 class User {
02   @ColumnName("uid")
03   Long id;
04   ...
05 }

查询方法怎么声明呢?

01 @HandlerSocket(FIND)
02 @EntityClass(User.class)
03 ResultIterator<User> findBy(@Operator(EQ) long id);

业务代码会是:

01 ResultIterator<User> itr = proxy.findBy(1L);
02 while (itr.next()) {
03   User user = itr.get();
04   ...
05 }

缺省情况下, 使用表的主键作为Index的key. 与add不同的是:

1. 使用ResultIterator<User>作为返回值类型, 其实目的是为了简单的封装ResultSet;
2. 使用Operator对参数id进行了注解, 告诉HS4J对id使用EQ操作.

查询场景通常会有分页的需求, 这就会使用到Offset和Limit两个注解:

01 @HandlerSocket(FIND)
02 @Index("AGE")
03 @EntityClass(User.class)
04 ResultIterator<User> findUserAgeGreaterThan(@Operator(GT) int age, @Offset int offset, @Limit int limit);

上面都是全字段写入或读取, 在部分修改的场景中如何注解呢?

01 @HandlerSocket(UPDATE)
02 @Columns("age")
03 @Index("NAME")
04 void updateUserAge(@Operator(EQ) String name, int age);

通过Colunms告诉HS4J打开的Index仅对age进行操作, 并以name为key, 是用age参数作为value.

修改多值的情况下, 请保证参数声明的顺序和Columns定义的顺序一致:

01 @HandlerSocket(UPDATE)
02 @Columns({"name", "age"})
03 void updateUserNameAndAge(@Operator(EQ)long id, String name, int age);

主要的用法介绍到此, 还其他的用法就不再累述了, 请参看单元测试代码举一反三吧!

年轻代又分成3个部分，一个eden区和两个相同的survior区。刚开始创建的对象都是放置在eden区的。分成这样3个部分，主要是为了生命周期短的对象尽量留在年轻带。当eden区申请不到空间的时候，进行minorGC，把存活的对象拷贝到survior。年老代主要存放生命周期比较长的对象，比如缓存对象。具体jvm内存回收过程描述如下（可以结合上图）：

1、对象在Eden区完成内存分配
2、当Eden区满了，再创建对象，会因为申请不到空间，触发minorGC，进行young(eden+1survivor)区的垃圾回收
3、minorGC时，Eden不能被回收的对象被放入到空的survivor（Eden肯定会被清空），另一个survivor里不能被GC回收的对象也会被放入这个survivor，始终保证一个survivor是空的
4、当做第3步的时候，如果发现survivor满了，则这些对象被copy到old区，或者survivor并没有满，但是有些对象已经足够Old，也被放入Old区 XX:MaxTenuringThreshold
5、当Old区被放满的之后，进行fullGC

在知道垃圾回收机制以后，大家可以在对jvm中堆的各个参数进行优化设置，来提高性能。

最近一直做系统优化，但从建模的角度今天有个小优化，原理比较简单，效果可能不是很大，但很有意思。

这种优化的好处是不用改变sql代码，对用户是透明的。

所以分享下。

-

由于hive在文件基础上，而会全部扫一个分区里面的内容。

hive表的概念是基于hadoop的文件系统hdfs，表其实是分布式文件里面的一个文件目录。

再加上没有索引，如果要取的表里面的某些字段就必须全部扫描该表对应的文件目录

-

如：建表way1：

create table if not exists t_hm_0501_test_01

(

uid string,

nick string

)

PARTITIONED BY (pt STRING , bc_seller string )

row format delimited

fields terminated by ‘\t’

lines terminated by ‘\n’

stored as textfile;

-

在hadoop的hdfs中其实是这样的目录

–

t_hm_0501_test_01表对应hdfs里的如下文件目录。

/t_hm_0501_test_01

—-

一级分区

/t_hm_0501_test_01/pt=20110501000000

/t_hm_0501_test_01/pt=20110502000000

–

二级分区

/t_hm_0501_test_01/pt=20110501000000/bc_seller=0

/t_hm_0501_test_01/pt=20110501000000/bc_seller=1

最后那个分区目录后面放的是真正的数据文件

—

如果有语句 select ,.. from t_hm_0501_test_01  where pt’=20110501000000’ and bc_seller=0

Hadoop只读取/t_hm_0501_test_01/pt=20110501000000/bc_seller=0 下面的数据，不用处理bc_seller = 1 的数据。

–

如果这个表where条件中的值不是分区字段，则会全部扫里面的内容。

如果我们把部分常用字段枚举成分区字段，则会减少扫的内容（条数）。

！！

Way2：

如果这样建表：

create table if not exists t_hm_0501_test_01

(

uid string,

nick string

)

PARTITIONED BY (pt STRING )

row format delimited

fields terminated by ‘\t’

lines terminated by ‘\n’

stored as textfile;

-

一级分区

/t_hm_0501_test_01/pt=20110501000000

/t_hm_0501_test_01/pt=20110502000000

同样的sql 语句：

select ,.. from t_hm_0501_test_01  where pt’=20110501000000’ and bc_seller=0

-

其实是扫的是：

/t_hm_0501_test_01/pt=20110501000000 所有东西，包括下面bc_seller=1的数据，增加了脏数据。

浪费了一些map 及其他资源。

-

这其实是一个树形结构，如果做得好就是个tree算法，可以最少的读取文件。

而且这种优化的好处是不用改变sql代码，对用户是透明的。

那么如何设定partition 及如何确定其分区值

就成了关键。

1. 还可以凭借一些业务经验去确定，更科学的是通过系统自动的解决该问题。

这里通过对hive sql 元数据解析，写一下算法进行分析，得到更好的提出更优的分区

具体如何选择需要，需要改字段满足一些特性。

1. 比较容易枚举
2. 字段指相对固定
3. 频率最高的过滤字段

————

如下例子：

如果你在数据分析的过程中，

你的用户表操作的性别过滤很多，可以以性别作为分区。

———-

如果你经常分析成交数据

大量分析计算30天的交易成交，其次是60天的成交。

你也可以时段进行分区，这样可以节省你很多成本。

———————————————————————

微博：www.weibo.com/xiaodongdata

QQ ： 448683559

Hive语法解析器是根据<上次分享的 词法分析 > 生成的语法树为基础，进行语法解析。根据语法token的情况实现了五个具体的语法解析器。

+

在你生成语法器的时候， SemanticAnalyzerFactory分别针对不同的情况生成对应的某个语法器,如下

SemanticAnalyzerFactory类：

+

现在有五个语法解析器 analyzer继承了BaseSemanticAnalyzer。

五个SemanticAnalyzer的简单介绍：

ExplainSemanticAnalyzer

对语法树、执行计划 做了一个打印操作，其他的基本上都是按照SemanticAnalyzer执行的，最重要的差别，就是在整个解析过程中它没有让context在构建文件真正的临时文件所需的文件及文件路径等。

FunctionSemanticAnalyzer ：

主要操作是创建和消除一个的function的元信息。

如：

CREATE TEMPORARY FUNCTION str_to_date AS ‘com.taobao.hive.udf.UDFStrToDate’;

sql可以调用该自定义的function。

DDL SemanticAnalyzer：

主要是对表、view、partition的级别增删改查的操作。

如：show tables;

Load SemanticAnalyzer:

Load操作。

SemanticAnalyzer：

对于我们最重要关注的是SemanticAnalyzer：对应sql语句进行解析，这也是最核心最复杂的组件。

=

BeseSemanticAnalyze 中语法解析开始于下面：

public void analyze(ASTNode ast, Context ctx) throws SemanticException {

this.ctx = ctx;

analyzeInternal(ast);

}

=

五个解析器都继承于它，并实现analyzeInternal（），不同的analyzer不同的实现过程，我们关注的是普通sql（select from ）的解析，所以在这里直接看SemanticAnalyzer。

= （注： ctx 是 context 类，很重要，在下面会提到）

+

所以解析过程的就从这里开始。 我们只说正常sql （select … from）的解析。

这就是hive源码里面的SemanticAnalyzer类（超大的一个类）。

因为很重要直接代码如下：

SemanticAnalyzer的analyzeInternal（）

public void analyzeInternal(ASTNode ast) throws SemanticException {

reset();

QB qb = new QB(null, null, false);

this.qb = qb;

this.ast = ast;

ASTNode child = ast;

LOG.info(“Starting Semantic Analysis”);

System.out.print(“Starting Semantic Analysis”);

// analyze create table command

//

//建表或view 前处理 ,如： create table .. as select .. from

if (ast.getToken().getType() == HiveParser.TOK_CREATETABLE) {

// if it is not CTAS, we don’t need to go further and just return

if ((child = analyzeCreateTable(ast, qb)) == null) {

return;

}

}

// analyze create view command

if (ast.getToken().getType() == HiveParser.TOK_CREATEVIEW) {

child = analyzeCreateView(ast, qb);

if (child == null) {

return;

}

viewSelect = child;

}

//

// continue analyzing from the child ASTNode.

doPhase1(child, qb, initPhase1Ctx());//获取subSql,table 等对应别名

LOG.info(“Completed phase 1 of Semantic Analysis”);

getMetaData(qb);//get 元数据

LOG.info(“Completed getting MetaData in Semantic Analysis”);

// Save the result schema derived from the sink operator produced

// by genPlan. This has the correct column names, which clients

// such as JDBC would prefer instead of the c0, c1 we’ll end

// up with later.

Operator sinkOp = genPlan(qb);//这个层次才开始column names，生产operator

resultSchema =

convertRowSchemaToViewSchema(opParseCtx.get(sinkOp).getRR());

if (createVwDesc != null) {//四面

saveViewDefinition();

// Since we’re only creating a view (not executing it), we

// don’t need to optimize or translate the plan (and in fact, those

// procedures can interfere with the view creation). So

// skip the rest of this method.

ctx.setResDir(null);

ctx.setResFile(null);

return;

}

ParseContext pCtx = new ParseContext(conf, qb, child, opToPartPruner,

topOps, topSelOps, opParseCtx, joinContext, topToTable,

loadTableWork, loadFileWork, ctx, idToTableNameMap, destTableId, uCtx,

listMapJoinOpsNoReducer, groupOpToInputTables, prunedPartitions,

opToSamplePruner);

//进入优化器，生成更好的operator tree

Optimizer optm = new Optimizer();

optm.setPctx(pCtx);

optm.initialize(conf);

pCtx = optm.optimize();

init(pCtx);

qb = pCtx.getQB();

// At this point we have the complete operator tree

// from which we want to find the reduce operator

genMapRedTasks(qb);

LOG.info(“Completed plan generation”);

return;

}

关键方法：

doPhase1（）

这个方法相当于把tree的大枝叶先过滤了一遍，解决了一些别名问题和对应为问题，

包括：表和subsql的对应的别名，

Tree 的string 与 ast 对应等，只是没有涉及到字段级别。

1次解析

public void doPhase1(ASTNode ast, QB qb, Phase1Ctx ctx_1)

以下是官方注释。

/**

* Phase 1: (including, but not limited to):

*

* 1. Gets all the aliases for all the tables / subqueries and makes the appropriate mapping in aliasToTabs, aliasToSubq

* 2. Gets the location of the destination and names the clase “inclause“ + i

* 3. Creates a map from a string representation of an aggregation tree to the actual aggregation AST

* 4. Creates a mapping from the clause name to the select expression AST in destToSelExpr

* 5. Creates a mapping from a table alias to the lateral view

* AST’s in aliasToLateralViews

这里是递归的遍历这颗树，

代码示例，如面对 TOK_FROM

case HiveParser.TOK_FROM:

int child_count = ast.getChildCount();//

if (child_count != 1) {

throw new SemanticException(“Multiple Children “ + child_count);

}

// Check if this is a subquery / lateral view

// 正对不同情况，给出不同解决方法

ASTNode frm = (ASTNode) ast.getChild(0);

if (frm.getToken().getType() == HiveParser.TOK_TABREF) {

processTable(qb, frm);

} else if (frm.getToken().getType() == HiveParser.TOK_SUBQUERY) {

processSubQuery(qb, frm);

} else if (frm.getToken().getType() == HiveParser.TOK_LATERAL_VIEW) {

processLateralView(qb, frm);

} else if (isJoinToken(frm)) {

processJoin(qb, frm);

qbp.setJoinExpr(frm);

}

break;

把摘下来的信息放在QB、QBParseInfo等几个容器里面。如：如果是select 就把信息记录到QBParseInfo 中。

skipRecursion 标示递归是否结束。

其中涉及了几个容器：

QBParseInfo 是辅助analyzer语法解析的一个容器，

而qb放的是sql block基本单元，包括表名别名问题。

这里我们可以拿到很多我们想要的东西。

QBParseInfo

Implementation of the parse information related to a query block.

各种对应关系，如： select , groupby , groupby 等的string –Map– astNode

private final boolean isSubQ;

private final String alias;

private ASTNode joinExpr;

private ASTNode hints;

private final HashMap<String, ASTNode> aliasToSrc;

private final HashMap<String, ASTNode> nameToDest;

private final HashMap<String, TableSample> nameToSample;

private final Map<String, ASTNode> destToSelExpr;

private final HashMap<String, ASTNode> destToWhereExpr;

private final HashMap<String, ASTNode> destToGroupby;

==

Context 类在这里很重要

Context : 是query的一个context

主要功能：

1 标示explain: 如果是explain语句， explain为ture都不会实际的建立这些文件。

2可以建立tmp-file （在query执行过程中所需要的tmp-file 文件和路径 ），生成和清除中间临时文件及路径。

所以我们可以再这里获取整个过程中的临时文件，用于优化使用。

private Path makeMRScratchDir(HiveConf conf, boolean mkdir)

==

未完待续！

微博：www.weibo.com/xiaodongdata

QQ ： 448683559