网站建设服务器 几核,成都网站建设服务密需湖南岚鸿案例,网站建设的目的和意义,环保类网站模板前言#xff1a;
对于任何使用大数据技术的公司来说#xff0c;大数据平台特别是Hive来说#xff0c;维护其高效快速的运行#xff0c;对整个公司的运作来说至关重要。比如说#xff1a;某个调度任务失败了造成业务部门的某些报表无法正常产出#xff1b;hive平台最近速…前言
对于任何使用大数据技术的公司来说大数据平台特别是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的时代我们要利用好深表的数据凡事尽可能的拿数据说话而不是拍脑门做决定。
