Spark：为大数据处理点亮一盏明灯(3)

监控与运维

每一款驱动程序都拥有自己的一套Web UI，通常为端口4040，其中显示所有实用性信息——包括当前运行任务、调度程度、执行器、阶段、内存与存储使用率、RDD等等。这套UI主要充当信息交付工具，而非针对Spark应用程序或者集群的管理方案。当然，这也是调试以及性能调整之前的基础性工具——我们需要了解的、与应用程序运行密切相关的几乎所有信息都能在这里找到。

虽然算是个不错的开始，但这套Web UI在细节方面仍然显得比较粗糙。举例来说，要想查看任务历史记录、我们需要导航到一台独立的历史服务器，除非大家所使用的是处于独立模式下的集群管理器。不过最大的缺点在于，这套Web UI缺少对于运维信息的管理与控制能力。启动与中止节点运行、查看节点运行状况以及其它一些集群层面的统计信息在这里一概无法实现。总体而言，Spark集群的运行仍然停留在命令行操作时代。

Spark的Web UI提供了与当前运行任务相关的丰富信息，但所有指向集群的管理操作则需要完全通过命令行来实现。

Spark对决Tez

事实上，Spark与Tez都采用有向无环图（简称DAG）执行方式，这两套框架之间的关系就如苹果与桔子般不分轩轾，而最大的差别在于其受众以及设计思路。即使如此，我发现很多IT部门仍然没能分清这两款框架间的差异所在。

Tez是一款应用程序框架，设计目的在于帮助开发人员编写出更为高效的多级MapReduce任务。举例来说，在Hive 0.13版本当中，HQL（即Hive查询语言）由语言编译器负责解析并作为Tez DAG进行渲染，即将数据流映射至处理节点处以实现高效执行。Tez DAG由应用程序以边缘到边缘、顶点到顶点的方式进行构建。用户则完全不需要了解Tez DAG的构建方式，甚至感受不到它的存在。

Spark与Tez之间的真正差异在于二者实现方式的不同。在Spark应用程序当中，同样的工作节点通过跨迭代实现重新使用，这就消除了JVM启动所带来的资源成本。Spark工作节点还能够对变量进行缓存处理，从而消除对数值进行跨迭代重新读取与重新计算的需要。正是借鉴着以上几大特征，Spark才能够在迭代编程当中如鱼得水、充分发力。而由此带来的缺点是，Spark应用程序会消耗大量集群资源、特别是在缓存过期的情况下。我们很难在集群运行着Spark的时候对资源进行优化。

尽管支持多级任务执行机制，Tez仍然不具备任何形式的缓存处理能力。虽然变量能够在一定程度上得到缓存处理，从而保证规划器在可能的情况下保证调度任务从同节点中的上一级处获取必要数值，但Tez当中仍然未能提供任何一种经过妥善规划的跨迭代或者变量广播机制。除此之外，Tez任务还需要反复启动JVM，而这会带来额外的资源开销。因此，Tez更适合处理那些规模极为庞大的数据集，在这种情况下启动时间只占整体任务处理周期的一小部分、几乎可以忽略不计。

在大多数情况下，Hadoop社区对此都拥有很好的移花接木式解决方案，而且其中最出色的部分机制已经能够作用于其它项目。举例来说，YARN-1197将允许Spark执行器以动态方式进行规模调整，这样它们就能够在合适的条件下将资源返还给集群。与之相似，Stinger.next将为Hive等传统Hadoop应用程序带来由跨查询缓存提供的巨大优势。