前言：

对于任何使用大数据技术的公司来说，大数据平台特别是Hive来说，维护其高效快速的运行，对整个公司的运作来说至关重要。比如说：某个调度任务失败了造成业务部门的某些报表无法正常产出；hive平台最近速度下降了，造成业务跑sql，跑半天不出结果，进而发起投诉等等。对于数据平台来说任何一个小的事故轻则造成公司的运行效率降低，重则使整个公司的业务运行异常（异常可能不会被立刻发现）等等，可以夸张点的说，数据将像电力资源一样对整个公司至关重要，而数据平台自然也是其中的“主角”。那我们要如何确保这个“主角”可以一直稳定的运行呢？废话少说，下面就结合博主的一些经历，简单聊下数据平台维稳的一些想法。特此声明，本人菜鸟一枚，以下想法纯属胡扯，如有说的不对的地方，望各位大佬多多指教，也欢迎各位评论交流。

如何维稳？

针对如何维护数据平台稳定的问题，我想拿一些问题从以下几个层面说下自己的一些想法：底层表，SQL，调度任务。
问题场景一：业务频繁反馈Hive平台运行查询慢。
针对以上问题，可能是由多方面的原因引起的，也可以有多种解决办法。但是首先我想抛出的一个问题是：“如何证实业务所说的话？”凡事讲究证据，特别是在这个DT的时代。所以首先我觉得应该有一些指标来量化Hive平台运行的快慢，比如我们可以统计下每天Hive平台执行SQL的平均时间。根据这些指标，我们知道Hive平台的确变慢了，那如何去优化呢？业务我们可以加资源（加机器，加内存，换硬件设备如固态硬盘，调整集群参数等等）。但是我想说的还是我们要做的任何的优化的操作的依据是什么？或者说如果我们不知道要进行那种优化的操作，那我们能不能用一些方法排除掉我们不需要进行哪些方法去优化？用一些什么样的方法呢？还是指标量化的方法，拿出有效的指标去论证你的观点，而不是通过拍脑门来决定，特别是针对已有大量数据积累的场景下。

我们经常为业务做各种报表来辅助决策，那为什么我们不能为包含各类数据的数据平台的来做一版“体检表”来定位各种问题，进而为解决各种问题做决策呢？所以这篇文章我想传达的一点是通过指标化，报表化的方法来帮助你做决策或者说定位问题，解决问题，也就是用数据分析的方法来维护数据平台。

针对上面抛出的怎么优化的问题，说实话，我也没有一套很好的策略说要怎么做怎么做。但是我结合下自己的工作经历说下其中的一些想法吧。

底层表的优化

问题场景：数据仓库长时间未进行过底层数据的整理，如果说在近期业务量未大幅增加的情况下，Hive平台慢会不会是由于底层数据的“异常”造成的？
为了印证想法，开始着手先对数仓的底层表进行统计分析，主要从以下几个维度去初步生成一份报表：“表名，表大小，小文件数，更新时间，分区数，近段时间表的查询次数”。有了这张表我就对数仓底层的表数据一目了然，这里针对上面的问题，我们可以从“表的查询次数”和“小文件数量”两个维度进行分析，通过观察最常用的一些表的小文件数的情况来判定是否是底层表小文件的原因造成Hive平台慢的问题。当然有了这张报表，后续我们可以高效的完成各种需求：比如要节省硬盘空间，可以通过“表大小”，“表更新时间”字段进行高效的操作，以最低的成本（处理少量的表，节省大量的空间）获取不错的成果。当然后续该报表可以衍生出其他的字段如“是否包含V表”，“是否是分区表”等等，也可以和其他的数据关联衍生出更多的新的字段，如根据表名是否可以和业务的sql_log表进行关联，这样你可以从公司，部门，个人三个层面得到对不同表的查询次数，知道这些会不会对我们数仓的搭建有帮助？再放开脑洞一点，如果知道sql中每条sql对应的引用的表和查询的用户，可否利用算法建模来做一个推荐系统，比如用户输入sql的过程中可以自动推荐出接下来需要关联的表；更甚者是否能从中提取出表和表之间的类似相关系数的指标去衡量各个表之间的关联？最终如果说能再细分到字段和字段之间的联系（比如我知道对于某个部门来说哪几个字段一起出现的概率很大），那么我们就真的达到了利用数据挖掘技术来倒推出业务知识（业务知识体现在某组一起出现字段，但是为什么这组字段会一起出现，背后的业务含义我们并不知道，但是这又有什么关系，至少有了这些信息对我们搭建数仓来说已经足够了。毕竟比如你让搞数仓的去熟知业务和搞业务的去熟知数仓表是同等难度（这也是技术和业务之间的代沟），如果有了上面的一些信息，那就相当于搞数仓的搞懂了业务，这不正是技术人员所需要的）。

SQL优化

针对SQL的优化，我们可否利用报表去定位问题？
比如有时候，对于已经上线的调度任务，由于各种原因会去优化相关的sql。但是如何筛选这些sql以及如何快速的优化这些sql呢？自己的一个想法：以sql_log为基础数据，首先筛选出目标类别的sql数据（调度任务的sql），之后可以以sql耗时为度量筛选簇耗时较多的sql进行优化，一条sql耗时慢可能和许多因素有关：如表相关的因素小文件数量、表大小等，sql语法的因素等。那么如何才能快速的确定到底是那些因素呢？正常的操作，也许我们需要将这条sql拿出来，然后一点点执行，一步步的分析问题原因。但是针对一些经验化，固定化的操作可否转化为相应的指标？比如针对优化调度任务sql的问题，如果我有一张报表里面包含以下字段“sql语句，sql耗时，sql中各表的大小，sql中各表的小文件数”等，那么我们是不是就可以直接排除小文件数量的问题，进而去验证其他的原因。当然这张报表绝不可能停留在这个阶段，后续根据排查问题的需要，你可以添加任何的指标字段（如针对Spark的任务能否将sql执行时你在SparkUI中看到的信息加进来等），来帮助排查问题，这样的话，你甚至不需要执行一条sql就能定位到问题！

调度任务的优化

调度任务如何才能科学合理的规划？也是一直再思考的问题。虽然市面上有各种调度任务框架如Azkaban等，他们有很好的功能来满足调度的需求，但是这对于整个调度任务更高效的运行来说好像还有点差距。比如最近要上个新的调度任务，我要把它放到那个时间段去执行？某些调度任务经常性失败的原因是什么？
嗯~~，我想表达的是无论是Azkaban也好还是其他的调度任务框架，我们能看到的只是单个的调度任务本身，并没有一个更高的维度来描述一群调度任务运行的情况。针对上面的问题同样可能的原因有很多中，那我们能否通过一些图表来排除一些原因呢？如果我们有一张描述调度任务的图表，横轴代表的时间，纵轴代表的是平台总的资源使用情况，如内存（如果能显示并行的任务名称更好）。那么我们就能知道任何的时间点，我们平台的任务并行度以及对应的资源使用情况，这样对我们新增的调度任务的添加或者说整个调度任务更科学的规划会不会有更好的帮助？如果能在图中的时间轴标注下每次发生的事故事件，那对我们分析事故会不会有一个更高层面的认识？有了更高维度的认识，也就会少犯很多错误，产生更少的事故。

总结：

以上只是自己脑洞大开的一些想法，比较乱，也是想到哪写到哪，如果能对各位有帮助更好。但是只想传递一点：就是如何将工作中一些经验性、重复性的工作给指标化，利用数据分析的思路来“高效”的工作，更好的去定位问题，解决问题，甚至预防问题的发生等。总之，在这个DT的时代，我们要利用好深表的数据，凡事尽可能的拿数据说话，而不是拍脑门做决定。