2019大数据产业峰会|联通大数据李大中：联通大规模数据集群治理实践

1、 HDFS&YARN作业深度监控。核心问题是小文件过多、文件量过大。大家知道在hadoop3.0以后才进行namenode，执行作业计划的时候耗时会多，根因就是HDFS文件数过高。左上图可以看到我们每天资源的负载情况，资源负载情况几乎是全天打满，一千多个需求，任务数有三万多个。我们研发了一套元数据管理平台，对namenode里面的数据，fsimage数据和editlog数据进行解析，但是效率根本没有办法满足海量日志快速搜集和序列化。

从这种状态无侵入性的观察整个集群，通过fsimage数据和editlog数据两个数据进行加工以后，开始对开始对千万级数据目录进行统一的画像，画像以后找点，所有的都找某个点某个原因。这是因为集群出现问题不是光计算资源、存储资源出现问题，可能包含模型、规范、输入输出、切片合不合理，也可能是一系列东西出现问题——雪崩的时候没有一片雪花是不出现问题的。我们把这些点完整的策划出来，告诉大家这个点应该优化，这样的话效率会更高。通过一系列的优化以后，整个集群文件数由八千万下降到三千万，这种下降直接使计算效率提升了很多，整个集群负载下降了20%，单集群下降的更多最大幅度30%。实际上是我并没有扩集群，没有增加任何算力，只是简单优化了一下。

2、RPC请求和关键服务预警。再一个是RPC的关键指标，有一段时间我们发现集群在空闲的时候任务提交不上去，提交会等待非常多的时间，但是集群资源都是空的，最后定位发现根源在RPC请求。RPC请求是非常关键的指标，一旦RPC出现过载，整个集群全部出现等待。现在我们针对RPC这块采用了很多数据，比如JMX指标等，和作业进行关联，定位到作业上就能找到作业的组织、作业的负责人进行优化。否则十几万的工作量，通过这种方式实时获取也能精准定位出来，确实发现某个业务直接造成RPC峰值迅速上升，毫秒级一下达到秒级，这一块是重大的关联点。根据这个把全部的拎出来以后全部优化，优化出来集群RPC请求负载断崖式下降，可以提供更多产线加工数据请求服务

3、重复加工/冗余计算挖掘。由于团队太庞大了，有产品团队、数据治理团队、研发团队、基础设施团队还有各个组的团队，这些团队协作的时候对于数据的理解或者信息不共享，或者无法共享等，使得数据多次重复加工、冗余计算。可能你们组加工的模型和我们组加工的模型只有轻微的差异，但是我并不知道那块已经加工出来了我可以用，我就还是会从原始数据开始进行加工，这个时候一定有非常高的疑似性做重复加工。这两个可能只是轻微的差别可以合并，我们以作业输入输出为维度结合分布式存储画像，勾勒出来整个加工作业的流程取向，定位它是不是冗余作业。这个是从最底层日志抽取的，和本身生产组织没有关系，优化效果非常大的，系统里面发现大量的疑似冗余加工，替代出来以后交各个相关负责组里面优化，使集群各维度资源全面降低10%以上。

4、重构元数据管理、血缘分析应用。另外我认为在血缘重构、元数据管理方面，也是大型治理需要注意的点。往往一张表发生问题的时候，上下游关系不清晰，不能定位整个故障面和影响面。另外有对外合作的要求，外部模型也在用我的数据，这时候对于敏感信息的流向是不清晰的，需要通过血缘分析进行管理。另外对于元数据要无侵入，一旦把人工加进去以后，元数据基本不可用了，这一块我们也通过自己构建元数据平台提供全域物理视图、业务视图、元数据的变更来实现构建关系。下图是通过图计算的方式把整个元数据的东西展示出来，这一块更多是在hadoop里头通过hadoop里的引擎处理。如果spark接入元数据构建程序的话也会和spark合并起来，如果spark是单独一块的话会以输入输出目录为主，这样由于系统里面大量的spark，这两个处理完以后里面的血缘是95%以上非常准的血缘关系，而且跟人无关了。

通过这个图看，左上角肯定是疑似冗余加工的现象了，由一个点形成若干个目录输出，这些输出的东西可能有差异和区别，但可以合并到一块，对我们来说就是算力巨大的减少，没有治理的话这种东西是看不到的。

5、智能分析集群用户画像与行为预测。这一块我们也做了尝试，采用ALS的理念，使用小波的分析方法，我们认为每天操作它的特征工程会绘制出来一个阴影面积，这个阴影面积有高有低，如果每天的采样点通过计算落在阴影面积内就认为是健康的，如果超出阴影面积而且长期超出的话，一定有很多在这个时间段内不应该做的或者特别敏感的特征做出来了。比方说我们也有数据清理，凌晨2点要进行大量过期日志的清理，这时候可能有大量的RM动作在里头。这个动作如果发生在10点钟，日志里面捞出来大量RM操作的话，那这一定是严重的问题。我们尝试根据这些特征构建一个自动化的东西，建立用户行为异常操作监测机制，发现问题规避故障。

我们的数据治理架构，里面包含的就是namnode的日志还有资源队列等等，还有hab的审计日志等等全部都采集上来进行解析，解析完以后，上面的引擎大家很熟悉了，都是通用的处理引擎，对外构建了两套东西，一个是数据治理构架，SaaS的画像，用户画像、用户异常行为画像、冗余计算画像、右面是元数据，基于自动采集内容进行的元数据管理的这些东西。从体系上来讲，刚才所说的内容是放到这块了，又加入了大数据资产管理的应用，大数据能力开发平台，底层又和ITSM CMDB和devops打通以后构成整体资产管理，是由底层自动化运维的东西和变现的东西有机打为一体，这样就持续保证系统进行稳定运行可供的状态。

三、大规模数据集群治理的效果收益

分享一下治理的成果。前面两个成果是业务支撑能力和租户运营治理，对内支撑正常的业务调度，对外将系统跟外部进行合作建模，这一个东西给公司带来的直接收入每年超过两千万。第三个成果是集群深度治理成果，对于算力和集群精细化的运营和加工，保守数字每年节省的固定资产投入上千万，

最后想谈一下大数据集群治理的实践总结。首先是高层支持力度非常关键，因为这是一项贯穿从采集到最终数据服务全链条，所有干系组织都要参与的工作，不是某个人每个组可以干成的。其次数据治理文化建设是核心，这种文化一定是自下而上自发协同的，不能以KPI的方式管理，因为我们也不知道治理最后要达到怎样的数值。只能采用OKR的方式，关注过程和结果，不断调整目标。第三这个项目治理是一个持久的工作，容易反复，要做好打持久战的准备。最后要拥抱并吃透开源技术，里面好多东西没有产品支撑，自己要深挖，需要有开创性的思维。

以上就是我的一些心得。谢谢大家！

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!