Github大数据开源项目之OAP详解
前言
Apache Spark是用于大规模数据处理的统一分析引擎。Spark SQL是Apache Spark最受欢迎的组件，它被广泛用于处理数据中心的大规模结构化数据。但是，在具有超大规模数据的高度动态环境中，Spark SQL仍然面临稳定性和性能挑战。
OAP全称为：Optimized Analytics Package，是针对Spark的优化分析包。OAP用来解决某些用例的性能问题，旨在利用自定义索引和智能细粒度的内存数据缓存来提升Spark SQL性能。
OAP整体架构如下图所示：
能够很清楚地看到，OAP是对Spark的SQL模块进行优化。
应用场景
实际业务场景下，SparkSQL进行批处理的返回时间为几分钟到几小时不等。而交互式查询要求在几秒甚至几微妙的时间内返回结果，否则会因延迟过高而影响正常业务处理，这对于SparkSQL是一个艰巨的挑战。
例如，交互式查询尝试从庞大的事实表中过滤出非常小的结果集。交互式查询通常处理大量数据集，若针对特定条件返回一小部分过滤数据，再加之生产环境对返回时间的苛刻要求，此时SparkSQL便显得力不从心。
OAP通过为键列创建与存储完整的B+树索引，并使用智能细粒度内存数据缓存策略，可以将SparkSQL交互式查询的时间提高到秒级。
注：通过正确使用索引和缓存，可以将某些交互式查询的性能提高一个数量级。
2. 批处理作业
自动缓存热数据
自动缓存热表
批处理作业场景很好理解，就是利用OAP+AEP（持久化内存）的方案，将热数据或热表（即时的状态和行为数据）缓存至AEP内存中，而非传统缓存至硬盘中，从而提升批处理作业性能。
注：AEP内存的读写性能介于DRAM和SSD之间，属于硬件加速。纳尼？没钱买AEP内存？那还是老老实实去搞SparkSQL参数调优和逻辑调优吧！
OAP原理
OAP使用索引和缓存来提高即席查询和批处理作业的SparkSQL性能
索引
用户可以使用SQL DDL（创建/删除/刷新/检查/显示索引）来使用OAP索引。用户使用DDL创建索引后，将在特定目录中生成主要由索引数据和统计信息组成的索引文件。执行查询时，利用分析索引文件来提高性能对用户是透明的。
缓存
缓存是OAP的另一个核心功能。对用户也是透明的。OAP可以自动加载频繁查询（热）的数据，并在缓存已满时根据LRU策略自动逐出数据。OAP缓存具有以下特征：
堆外内存：OAP高速缓存使用堆外内存，并避免使用JVM GC。它还可以将AEP用作高性能、大容量、低成本的存储器。
缓存局部性：通过实现基于Spark驱动程序和执行器通信的缓存感知机制，OAP可以将计算任务调度到将所需数据保存在缓存中的执行器。
缓存粒度：面向的存储格式文件的一个ROWGroup中的一列被加载到基本缓存单元中，该基本缓存单元在OAP中称为“光纤”。
缓存逐出：OAP缓存逐出使用LRU策略，并自动对最终用户透明地缓存和逐出数据。
缓存配置表：OAP还通过实际情况配置项目来支持缓存特定表，这些表通常是热表。
注：LRU算法：全称为Least recently used，即最近最少使用算法，是一种缓存淘汰算法。LRU算法根据数据的历史访问记录来进行淘汰数据，其核心思想是：如果数据最近被访问过，那么将来被访问的几率也更高。原理如下：
结语
OAP作为Intel BigData开源项目之一，体现了软硬件一体的有机结合，优化了SparkSQL的性能，效果还不错(*^_^*)。但经过佩奇一段时间的使用，也发现了两点劣势：
稳定性差：在使用OAP后，会影响正常SparkSQL任务的提交，甚至是运行失败，概率还挺高。原因很明显，AEP硬件虽好，但OAP软件驱动的实现就逊色很多。望Intel加大研发投入呀(●ˇ∀ˇ●)
易用性差，从AEP硬件安装测试到软件库编译配置，对环境的依赖严苛（如仅Xeon 62和Xeon 82系列的CPU才支持AEP）。自我OAP做成SparkSQL的一个插件为好，一键化部署与配置，岂不美哉！