关于Spark UI中的Event Timeline
关于Event Timeline
下面举个简单的例子，例如下图：
现在这很有趣。 我们看到基本都是红色和蓝色，也就是大部分时间花在了Scheduler Delay和Task Deserialization Time上 而我们真正想要看到的是很多绿色 —— Executor Computing Time的比例，就是executor真正执行工作所花的时间。
Scheduler Delay(蓝色部分)是等待的时间，即Executor正在等待某些东西 —— 通常这是等待驱动程序来控制和协调作业。
而红色是任务反序列化时间Task Deserialization Time，一般来说它不应该这占用如此大的比例。
所以我们知道我们的任务需要很长时间来反序列化，但为什么呢？ 在这一点上，原因仍然不明确，但可以看出来程序中的数据被序列化并发送到每个Executor进行处理消耗了很长时间，因此很大可能是因为每个executor所分配的数据量太大了，可以考虑减小任务的大小，即将输入的数据进行更多的分区。
另外，由于任务与数据分区是一对一的，这确实有助于我们回答这个问题：我们应该拥有多少个分区？
更确切地说：如果分区（和任务）太少，这个图表会是什么样子？
在最极端的情况下，我们可能会看到任务数比executor具有核心数的少 —— 也许我们的集群中有20个核心，但只能看到16个任务。 这通常不是我们想要的，而且很容易识别和改变。
但是，更巧妙的是，如果我们拥有比我们拥有的内核数更多的任务数，但若要获得最佳性能仍然太少。 我们如何认识到这种情况呢？
一般来说，我们可以查看图形的右边缘，找到要完成的最后一个或两个任务。 这些任务本质上限制了工作的进度，因为如果它们不完成则我们无法进行到下一步。 查看时间刻度，并查看这些任务的结束时间与前几个任务的结束时间之间的跨度是否显着(例如，数百毫秒或更多)。 我们正在关注的是群集核心未充分利用阶段结束时的时期。 如果这是实质性的，则表示分区/任务太少，或者数据大小，计算时间或两者都存在偏差。
如果我们有太多的分区，导致任务太多。 这种情况会怎样？ —— 很多非常短的任务，浙江导致在非计算活动中花费更多的时间。
任务中的绿色表示“执行器计算时间”，理想情况下，我们希望这至少占任务花费的70％。如果你看到许多任务填充了其他颜色，表示非计算活动，例如“任务反序列化”，并且只有一小部分绿色“计算时间”，则表明你可能有太多任务/分区。
请注意关于这些时间线图的两个问题：
- 虽然任务栏被安排来显示开始时间和长度，但“泳道”只是单独的执行者。执行者泳道内的一个“行”不代表特定的核心或线程，并且在同一线程上安排的任务不以任何方式显示该事实。
- 通常，执行器“泳道”内的条形图的垂直布局纯粹是试图在页面上的有限空间内显示许多任务的工件。多个任务的垂直定位，重叠等没有意义。
参考资料
Tuning Apache Spark Jobs the Easy Way: Web UI Stage Detail View