2019-06-05 10:25
首先十分荣幸受大会邀请做一个我们自己运营商的集群治理方面的分享。在此之前我想谈谈自己的感想，运营商的数据量确实非常大，实时性要求非常高，从采集、处理加工等每个环节都要投入大量的人力物力来做，这个过程当中产生了很多以前在中小型规模和集群上遇不到的问题。数据量大了以后，全都是问题。
我先简单介绍一下联通大数据公司，联通大数据是中国联通集团旗下的全资子公司，也是三大运营商里面唯一成立的专业化大数据公司。我们联通大数据公司有两个功能，第一负责经营和运营中国联通全量用户数据的大数据能力的建设——这是联通集团赋予我们大数据公司的职能。另外在大数据领域对外的投资和合作也是由联通大数据公司来负责，所以大家今后要有这方面的合作需求可以和联通大数据公司合作。联通大数据有几大战略：一是集中平台——因为整个联通数据是集中的，联通大数据每天在处理全国的实时数据；第二我们也提供数据合作，这是基于我们的海量数据；第三是资本合作。
联通大数据的产品线非常多，建立了基础、标准应用和平台及行业解决方案三层产品结构。在标准产品里，我们的风控做的特别好。除此之外产品还包括数赢洞察、智慧足迹、大数据平台等。我们对外提供行业解决方案有旅游方面的大数据产品，有游前洞察、游中监测、游后服务、全程大数据，产品SaaS化。此外还有政务大数据、公共安全大数据，是偏向于社会治理方向的。
看一下联通拥有的数据资产。联通大数据平台存储容量100PB，Hadoop集群超过6000个节点，日新增数据超过140TB，上网数据日处理10000亿条，处理的互联网数据量达到万亿级，这个数据量都是定时或者实时机制汇聚到我们这里。联通大数据模型有2000多个，数据库200多个，数据表1.6万，字段50万+，分区数2000万，文件数2亿+。看到这些数字，做大数据的人都会非常兴奋，我们也一样，但是在兴奋过后也有很多疑惑或者叫做走过很多坑，为什么？因为这么海量的数据肯定在数据治理上要付出巨大的代价。
一、大规模数据集群治理
我重新定义了一下符合大数据公司自己的资产管理体系。我们也参考了业界好多CMI的数据管理体系等，但是我觉得符合大数据公司的管理体系还是图中这个，这一体系经过实践取得了明显的效果。首先我们的数据资产管理体系建设是由三块组成的：左侧第一块是数据治理框架，我们起了个称呼叫“梳整促”；中间第二部分叫“巡山”，以集群治理为主，最右侧第三块是价值经营，这三块连起来就是联通大数据公司的数据资产管理体系建设。
中间这块为什么叫“巡山”？我们把一个个集群都看作摆在我们面前的一座座大山，山上面有峰顶有风景有溪水有河流什么都有，但是得进去把它梳理成符合你需要的样子，所以基于这块今天重点讲的是基于全域的数据集群治理。
如图这是我们在经过一段时间发展以后系统层面出现的问题，这种问题不是说突然出现的，是慢慢慢慢反映出来的，最直接的反映是在集群的处理能力和处理效率的下降。从底层洞察这块可以直观看到，集群的文件数量太多，小文件占比高，文件数量多到单集群1000节点，上面的文件数大概将近8000万文件。这些不是一下子大规模爆发，是慢慢慢慢地积累起来，越来越不舒服，最后造成的结果是集群RPC负载过高，集群垃圾文件过多，影响集群稳定。在算力层面，集群虽然用了一些调度策略来区隔资源分配，但是由于集群不稳定，集群处理的效率降低，整体负载高，耗资源大。还有冗余计算，异常作业的检测。
在对最上层数据管理进行直接深入剖析和分析后发现，我们的元数据不够自动化、不够实时化，过多的依赖于人的维护或者一个流程，如果有人不遵循这个流程，元素管理就失真了。我们打破了这个思路，不能靠管理或者自上而下的规定。再有就是没有完整全域数据血缘追溯——这个血缘追溯是自动化的，无法定义工作的范围或者一些面子。
然后我们制定了大规模数据集群治理的目标，首要任务是解决当前整个集群的“亚健康”状态，这种亚健康状态不是出现在某一个集群里面，而是所有的集群里面。长期的任务是什么？简单点说就是“保持健康”，大家知道治病容易但是如果要长期保持健康状态是很难，因此后面我们有一系列的措施保持这种健康的状态。
这是数据治理、集群治理推进的方法论。从这个方法论上我们追求两点：
1、 由小而美的精益发现价值。一开始不会做宏观的自上而下的策略，以述说集群怎么优化、业务怎么架构。我们的步骤是首先从问发现题开始，找到问题。比方说今天集群里面的某个产品的模型，任务比平常增加了50%或者60%，一些小头部的体量，找完点以后代面，这个集群执行的慢到底因为作业提交的时候有问题，还是调度的时候有问题，还是数据倾斜的时候有问题，还是别的地方有问题。然后制定解决策略问题，解决完这一点以后，一定要落一个相应监督的点，这个监督的点是在今后过程中实时监控的。
2、 敏捷交付价值。我们希望把这个东西最后包装成一个产品交付，交付过程中采用敏捷式的方式。因为这套体系贯穿的是整个公司的生产组织体系，从底层数据的采集一直到数据的加工，从产品线到研发线，整个参与所有项目的有300多人，这种模式没有办法用固定组织模式采用固定的方式交付，更多是一种虚拟的方式、协同的方式、敏捷的方式交付，更多是跨组织的协同。
二、大规模数据流程治理中遇到的问题
接下来把在我们治理过程中遇到的几个点跟大家简单介绍一下。
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的方式，关注过程和结果，不断调整目标。第三这个项目治理是一个持久的工作，容易反复，要做好打持久战的准备。最后要拥抱并吃透开源技术，里面好多东西没有产品支撑，自己要深挖，需要有开创性的思维。
以上就是我的一些心得。谢谢大家！