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%以上非常准的血缘关系，而且跟人无关了。 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
