spark两个节点2.2GB数据的orderby算子测试（上）

我们的任务就是分析orderby算子的流程，并用数据验证，最终总结优化方法。

 

spark的orderby算法，有点像桶排序，有三个阶段：

1. 抽样确定bound（水塘抽样算法，随机从n个元素中选择k个，但抽样过程中无法知道n）

2. 根据bound进行shuffle write

3. shuffle read 并在内存中排序

 

2.2GB数据集共5百万条记录保存在master1上，两台物理机主机名为master1和slave5，都是4核心，4GB内存，但是每台机器只给work分配1GB内存（spark实际用于计算的默认内存因子为0.6，实际上内存是动态管理的），要不2GB数据集就显得太小了，

 

我们先分析spark的ui记录，再根据ganglia的数据做进一步的分析。

jobs如下：有3个job共运行大约15分钟（当时还不懂得截图，将就一下吧(●ˇ∀ˇ●)）

 

job0由master1读取了一个128m的数据，初始化获取元信息，类型推断

job1是全表扫描并进行抽样的过程，tasks如下：

因为数据存储在master1上，网络io严重拖慢了速度，负载极不均衡。

 

job2有两个stage：

stage1根据抽样结果将数据写到bound间（shuffle write）， 每台主机的tasks为由job1获得的数据，所以master1和job1一样，14个tasks，而slave为4个tasks，也就是说这个stage主机间不交换数据。18个task运行完大约2min，是master1运行完14个task的时间，由于job1的分配不均衡导致slave5的cpu资源浪费

stage2是shuffle read过程，抽样了200个bound，所以共200个分区，任务分配较均衡，指标总览图已经能很好说明问题，如下：

这个stage主机间是会交换数据的，可以简单看出slave5处理完本地的512M在从master1上获取（实际上是会根据分区从本地和maters上同时获取分区数据的），所以共1024MB，和实际数据919.8MB还是挺吻合的

 

接下来分析ganglia的报告，做一个简单的分析，主要的图：

master1：

slave5：

spark应用提交时间在10：05，可能因为实验环境不纯净，存在一些数据无法解释，就简单分析一下。

先分析slave5： 

slave5先在master1读取大约512M数据，可以看到网络io大约4MB/s 第一个io高峰大约150s，cpu也比较平稳

io和cpu处理是异步的

接下来是shuffle write：时间在10：08到10：11

疑惑点：根据前面的分析，这个阶段是不会交换数据的，否则slave5就不会只花了20几秒运行4个tasks，无法解释这一时段的网络io

然后再看看master1：  

运行的东西多，内存比较紧，有些数据被调到了swap上，系统缓存只剩下默认大小了

还有下篇~