大数据计算程序的优化工作，需要结合岗位，提升认知，经过深度思考后再着手进行会更好

大数据计算程序的优化工作，需要结合岗位，提升认知，经过深度思考后再着手进行会更好。

“天下武功，唯快不破”，呵呵，走神儿了，忽然间想起1998年世界杯英阿大战中，阿兰希勒和巴蒂斯图塔互射点球时的情景，一个字：“快”，记得好像接近190KM/H，守门员只能眼睁睁看到皮球入网。差点忘了，现在又到了2018年世界杯，祝大家观球愉快！

事情就是这个样子，作为大数据计算程序的开发者，谁又不希望自己开发的程序像这样的点球射门一样，既准确，运行又快速呢。

但是如何做好大数据计算程序的优化工作，是不是需要建立一个清晰的认知：优化是一个体系的概念，涉及集群硬件、管理软件、调度、程序脚本等环节；优化工作的输出实际上又是在两个象限进行：1、计算程序的执行时长优化；2、计算程序的资源消耗优化。

一个是缩短程序运行时长或做到单位时长内完成更多的程序任务，达到缩短整体时长的效果；一个是降低单个程序的资源消耗，从而做到固定的资源池内完成更多的任务，提升集群的利用率，由于可以释放出更多的资源，因此也可以推进缩短总体程序队列的运行时长。

当然，大数据工作者所处岗位职责不同，优化工作的着手点也不同，但是要做到提升整体的程序队列运行效率、提升资源利用效率，是离不开各环节、各岗位的相互协作的。

绝不是在某个程序脚本中加个参数，修改修改语句而已，如果优化个别计算程序脚本，这些已经差不多就够了，但是如果面对的是成千上万个程序队列，这些还是远远不够的。

以hadoop集群及hive场景下计算程序的开发者视角为例：在计算程序准确的前提下，程序执行时长是一个显性的优化目标，但是程序的资源消耗优化也至关重要。

在实际场景中，集群环境分配给各个计算程序执行时的资源是动态变化的，由于计算海量数据的部分脚本执行时资源消耗过高，如果执行时间点重叠，就会与其他计算程序造成资源争抢，形成资源等待时间，这个时间长度是不可预见的，从而会导致整个计算程序队列的总体运行时长拉长，即便对其中的几个进行了语句级优化，但整体运行时长也不会轻易达到效果。

就像两个胖胖过一扇门，虽然行动慢一点，只要时间点不重叠，都可以顺利通过，但是如果一起过，就会卡在门那里，谁也过不去，浪费的只有时间。

如果是这样的话，那么又如何解决呢：

方案一：要么两人拼速度吧，快的通过后，慢的也就通过了，都用不了太多的时间；如果两个人速度一样快，那就只能呵呵了。这相当于优化单个计算程序的执行时长；

方案二：要么把这扇门改大吧，门大了，两个人也就通过了，但是主人会同意么？会不会影响建筑安全呢？就是改的话，施工也需要很多时间，能等的起么？虽然是个方案，但是不可控。这相当于申请更换硬件设备。

方案三：听调度哥的，两人排好队，定好优先级，按秩序一前一后过，结果呢？ok，很短的时间内顺利通过。这相当于申请调度支持协作。

方案四：要么咱哥俩儿减减肥吧，锻炼身体，说不定还可以去踢世界杯呢，瘦身后，如果有调度哥给咱俩排队更好，即便没有，无论何时，就算并行一起过，咱俩也都可以一闪而过么。这相当于不仅进行了单个计算程序的执行时长优化，又同时进行了程序的资源消耗优化。

如果我们可以选择一种方案的话，该如何选呢？

方案四会更好一些。当然在实际场景中，还是不要过于教条，灵活的运用会更好。

诚然，在大数据生态圈内，更多的同行们是从事科技成果转化的大数据分析、大数据计算等的程序开发工作者，站在这个视角着手计算程序的优化工作，结合岗位职责，提升认知，经过深度思考后再着手进行会更好。无论怎样，终极目标都是要提升工作效率，在规定的时间内得到准确的数据分析和加工结果。

感谢！