过滤掉非生产需要的特性和噪音；

对每个(entity_id、target_id)对进行聚合；

将表分为 N 个分片，并对每个切分通过自定义 UDF 生成一个用于在线查询的自定义索引文件。

使得 PipedRDD 容忍节点重启（SPARK-13793）：PipedRDD 之前在处理节点重启设计不够健壮，当它获取数据失败时，这个作业就会失败。我们重新设计了 PipedRDD，使得它能够友好的处理这种异常，并且从这种类型的异常中恢复。

最大的获取失败次数可配置（ SPARK-13369 ）：对于长期运行的作业而言，由于计算机重动而导致获取失败的可能性大大增加。在 Spark 中每个阶段允许的最大获取失败次数是写死的，因此，当达到最大失败次数时，作业通常会失败。我们做了一个更改，使其变得可配置，并将这个参数的值从 4 增加到 20，使得作业对于 fetch 失败更加健壮。

Less disruptive cluster restart：长时间运行的作业应该能够在集群重启后继续运行，这样我们就不会浪费到目前为止完成的所有处理。Spark 的可重启 shuffle service 让我们在节点重启后保留 shuffle 文件。最重要的是，我们在 Spark driver 中实现了能够暂停任务调度的功能，这样作业就不会因为集群重启而导致任务失败。

Unresponsive driver（SPARK-13279）：Spark driver 添加任务会进行一项时间复杂度为 O(N2) 的操作，这可能会导致其被卡住，最终导致作业被 killed。我们删除这个不必要的 O(N2) 操作来解决这个问题。

Excessive driver speculation：我们发现，Spark driver 在管理大量任务时，会花费了大量时间进行推测（speculation）。在短期内，在运行这个作业时我们禁止了 speculation。我们目前正在对 Spark Driver 进行修改，以减少 speculation 的时间。

TimSort issue due to integer overflow for large buffer（ SPARK-13850 ）：我们发现 Spark 的 unsafe 内存操作有一个 bug，这会导致 TimSort 中的内存出现问题。不过 Databricks 的工作人员已经修复了这个问题，使我们能够在大型内存缓冲区上进行操作。

Tune the shuffle service to handle large number of connections：在 shuffle 阶段，我们看到许多 executors 在试图连接 shuffle service 时超时。通过增加 Netty 服务线程（spark.shuffle.io.serverThreads）和 backlog （spark.shuffle.io.backLog）的数量解决了这个问题。

Fix Spark executor OOM（ SPARK-13958 ）：一开始在每个节点上运行四个以上的 reduce 任务是很有挑战性的。Spark executors 的内存不足，因为 sorter 中存在一个 bug，该 bug 会导致指针数组无限增长。我们通过在指针数组没有更多可用内存时强制将数据溢写到磁盘来修复这个问题。因此，现在我们可以在一个节点上运行 24个任务而不会导致内存不足。

Spark UI Metrics：Spark UI 可以很好地洞察特定阶段的时间花在哪里。每个任务的执行时间被划分为子阶段，以便更容易地找到作业中的瓶颈。

Jstack：Spark UI 中还提供 executor 进程的 jstack 功能，这个可以帮助我们找到代码中的热点问题。

Spark Linux Perf/Flame Graph support：尽管上面的两个工具非常方便，但它们并没有提供同时运行在数百台机器上作业的 CPU 概要的聚合视图。在每个作业的基础上，我们增加了对性能分析的支持，并且可以定制采样的持续时间/频率。

Fix memory leak in the sorter（SPARK-14363）性能提升 30%：我们发现当任务释放所有内存页，但指针数组没有被释放。结果，大量内存未被使用，导致频繁溢出和 executor OOMs。现在，我们修复了这个问题，这个功能使得 CPU 性能提高了30%；

Snappy optimization （ SPARK-14277 ）性能提升 10%：对于每一行的读/写，都会调用 JNI 方法（Snappy.ArrayCopy）。我们发现了这个问题，并且将这个调用修改成非 JNI 的System.ArrayCopy调用，修改完之后 CPU 性能提高了10%；

Reduce shuffle write latency（SPARK-5581）性能提升近 50%：在 map 端，当将 shuffle 数据写入磁盘时，map 任务的每个分区打开和关闭相同的文件。我们修复了这个问题，以避免不必要的打开/关闭，修改完之后 CPU 性能提高近 50%；

Fix duplicate task run issue due to fetch failure （SPARK-14649）：当获取失败（fetch failure）发生时，Spark driver 会重新提交已经运行的任务，这会导致性能低下。我们通过避免重新运行正在运行的任务修复了这个问题，并且我们发现当发生获取操作失败时，作业也更加稳定；

Configurable buffer size for PipedRDD（SPARK-14542）性能提升近 10%：在使用 PipedRDD 时，我们发现用于将数据从排序器（sorter）传输到管道处理的默认缓冲区大小太小，我们的作业花费了超过 10% 的时间来复制数据。我们使这个缓冲区大小变得可配置，以避免这个瓶颈；

Cache index files for shuffle fetch speed-up（SPARK-15074）：我们发现，shuffle service 经常成为瓶颈，reduce 端花费 10% 到 15% 的时间来等待获取 map 端的数据。通过更深入的研究这个问题，我们发现 shuffle service 为每次 shuffle fetch 都需要打开/关闭 shuffle index 文件。我们通过缓存索引信息，这样我们就可以避免重复打开/关闭文件，这一变化减少了50%的 shuffle fetch 时间；

Reduce update frequency of shuffle bytes written metrics（SPARK-15569）性能提升近 20%：使用 Spark Linux Perf 集成，我们发现大约 20% 的 CPU 时间花在探测和更新随机字节写的指标上。

Configurable initial buffer size for Sorter（ SPARK-15958 ）性能提升近 5%：Sorter 的默认初始缓冲区大小太小(4 KB)，对于大的工作负载来说这个值太小了，因此我们浪费了大量的时间来复制内容。我们将这个缓冲区大小变得可配置（过往记忆大数据备注：spark.shuffle.sort.initialBufferSize）， 当将这个参数设置为 64 MB 时，可以避免大量的数据复制，使得性能提升近 5%；

Configuring number of tasks：由于我们输入的数据大小为 60 T，每个 HDFS 块大小为 256 M，因此我们要生成超过250,000个任务。尽管我们能够运行具有如此多任务的 Spark 作业，但我们发现，当任务数量过高时，性能会显著下降。我们引入了一个配置参数，使 map 输入大小可配置，我们通过将输入的 split 大小设置为 2 GB ，使得 task 的数据减少了八倍。