1。紧急修复故障。公司集群机器下线。一定有失败。第一要务当然是尽快排查集群机器下线的原因，然后给出针对性的解决方案。如果短时间内出现集群问题，没有办法解决，应该尽快升级leader，并说明对业务的影响。如果上级重视，可能会帮你协调更高端的技术资源。这叫对症下药，也是治本的方法。其他方法都是曲线救国。这一步到位了，如果时间真的很紧迫，那就进行下一步。2、由于资源的动态扩展是一个集群，所以有冗余资源是合理的。那么临时动态扩容就是最基本的方法了。这也是云计算的意义所在。如果这一步做不到，至少说明系统规划没做好，难不成数据仓库还是单机的？如果是这样的话，就要考虑数据仓库云化的方法了。现在Hadoop大数据平台架构已经很成熟了。如果做不到这一步，那就记下来，等会儿跟企划部门算账，再往前走。3.集群资源的使用也存在2/8的资源分配和调整现象。既然是核心任务，肯定有很多非核心任务，所以其他非核心任务的资源分配应该转移到核心任务上。调整队列快速增加资源的方法，当然前提是能够大致判断调整后对业务的影响，但是这种抢别人资源的方式比较简单粗暴。如果资源调整不可调，那就继续往下走。4.调整优先级。如果移动资源不现实，比如短时间内难以在资源层面进行精细化调度，则对所有任务的优先级进行排序，提高核心任务的调度优先级，降低其他任务。优先级，保证核心任务的生成时间满足要求。当然，前提是清楚了解所有任务的重要性、相互依赖性以及对业务的影响。这些努力超出了诗意，临时而草率地调整任务优先级可能会产生严重后果。如果任务数以万计，相互之间有着千丝万缕的联系，短时间内不具备梳理操作的条件，那就继续往前走。5.任务代码优化核心任务一般都比较复杂，消耗的资源也比较多，也就意味着优化的空间比较大。家里有余粮的时候，可能不太注意代码的质量和效率。现在他们要经过优化，就看开发者的能力了。技术专家往往在这个时候体现出自己的价值。之前我们用spark替换hive，达到了很好的提速效果。如果代码优化的空间仍然有限，继续。6.减少任务依赖。数据仓库建模可以通过模型复用，有效提升上层应用的整体支撑效率。但是返回到单个应用任务时，需要依赖仓库模型的生成，反而影响生成速度。这就是局部最优和全局最优的矛盾。通过剥离核心任务对数据仓库模型的依赖，为其量身定制一套数据处理逻辑，可以大幅提升效率。其后果是资源被浪费，加剧了数据仓库整体的资源短缺。也就是说，有时为了评估和保护，不得不这样做。如果这不起作用，请继续。7.核心任务容灾核心任务非常重要，单个集群不可信任，不能把所有的鸡蛋都放在一个篮子里。灾难恢复或紧急响应是一种常见的做法。比如为了保证某些操作是安全的，我们往往采用异地异构的方案（核心任务分别放在hadoop和MPP集群中），前提是核心任务的规模不大，否则投资成本将难以承受。由于数据量大，数据仓库一般不做容灾解决方案，虽然集群崩溃是极小概率事件，但是集群性能下降是大概率事件。比如Hadoop的一个参数调整，可能会大大降低数据处理的效率。这已经是不得已的办法了，还是说说管理方法吧。8、做好说明工作核心任务延误肯定会影响业务。面对这种情况，一方面要及时向上级沟通汇报，配合各方分析故障，给出可以实施的解决方案。如果下属能用这7个计划做决定，我会很满意。另一方面，要做好核心任务延迟对业务实际影响的评估，做到心中有数，同时向业务方说明。适当下调企业预期。能做到这一步，我觉得已经超越了大部分人，因为这不是一个简单的技术问题，对加工人员综合素质的要求是相当高的。9、转危为机失败对于数据仓库来说既是挑战也是机遇。没有问题的时候，业务是感受不到数据仓库的价值的。赢得一些资源是相当困难的。如果故障真的对业务产生了更大的影响，可能会引起企业重新审视数据仓库的价值。记得有一次IT系统宕机，造成了很大的社会影响。后来分析是容量不够的原因。然后公司给企划部、市场部、IT部的负责人发了50个板子，说企划部没有计划好产能，少花钱。据说是市场部乱提需求，没有做好业务策划。通过这次事件，IT得到了更多的关注，获得了更多的资源来保证生产和各种容灾。系统从地上升起，然后整个系统都没有挂掉。其实还有一点我没说，就是人终究是靠人，暂时抱佛脚是没有用的。希望对大家有所启发。
