运营商大规模数据集群治理实践指南

Q1：军哥，你们运营商行业的大规模集群，都有啥特点啊？

A：我们集群主要是承载B域、信令和互联网日志等去标识化数据，简单的说，有三个特点：

• 集群规模较大：数千节点规模，近百PB数据量，日新增处理数据百TB以上；

• 组织干系人多：数据平台开发运维过程涉及到数百人以上的不同团队组织协同；

• 数据合规要求高：数据租户服务涉及到数据安全、用户隐私保护的合规要求高。

Q2：好吧，听起来，要搞定这样的集群，有难度呀！那何时要关注集群的治理呢？

A：好问题！一般来说，当数据质量问题、数据交付及时性、数据安全问题需要耗费极高的应对成本，或者说，当你经常会碰到以下类似的问题时，就该考虑做系统化的集群治理工作了。

Q3：看起来，集群治理好像需要做很多配套的工作，实际上会有多大的产出效果呢？

A：说出来，你可能不太信，就拿针对某集群治理的效果为例：

• 在处理数据量翻倍的情况下，集群资源负载降低30%以上，综合计算节省数百台节点，每年节省投入上千万元；

• 减少垃圾数据、测试数据、中间数据、过程数据，占总存储15%以上；

• 核心产品模型运行时长，缩短30%-80%。

一、集群治理的定位

Q4：我以前听说过数据治理，你这里说大规模数据集群的治理，有什么具体差异吗？

A：好问题！不过要搞清楚这块，得先了解一下我们数据资产管理体系建设的实施路径——主要分三个子工程，同步开展实施推进：

工程一

搭建核心业务数据治理框架，包括基础平台的建设、治理规范的制定，元数据管理、数据血缘和数据质量工具开发和应用实践，构建上层数据产品体系和数据能力开放平台，让数据多用活用，形成符合公司业务和组织协作特点的治理文化。

工程二

实现全域数据计算集群的深度治理，完成全域数据治理元数据的自动化采集、存储和分析，构建数据能力开放平台多租户专项治理机制，沉淀数据治理中台能力，基于大数据集群底层核心组件（如YARN、HDFS）的深入洞察，孵化出数据集群治理的应用。

工程三

完善治理机制体制建设，构建数据资产管理体系，并利用该系统的运营逐步重塑优化业务流程，实现可支撑全业务流程的成本评估机制，让数据价值持续攀升。

回到你刚才的提问，数据治理基本上可以理解为工程一的核心目标；大规模集群的治理对应工程二，它需要长期支撑工程一的具体建设任务，并为数据资产管理体系的运营夯实基础。

二、集群治理的背景

Q5：你刚才说的好像很有道理，但是我还是不太明白，为何不是在数据治理工程中扩展一个子任务去做，而是要另起炉灶，搞一个新的大工程来做数据集群的专项治理？

A：好问题！恭喜你！你快要触摸到数据集群治理问题的核心了。我们不妨再捋一下数据集群治理的背景，主要是遇到的历史部分集群无序建设的种种问题：

这些问题可进一步分为几类，简单分析完你就自然明白了：

• 管理类：集群接口机权限管控、数据表不合理创建和删除、垃圾数据表过多问题。这类问题，可以通过数据治理工程进行持续改进，但是解决时间周期以年为单位。

• 集群类：集群整体加工慢、稳定性欠佳、队列资源争抢、资源得不到合理分配的问题。这类问题，基本上要集群底层视角进行深入分析，在业务层做数据治理几乎无解。

• 洞察类：冗余计算浪费资源问题、智能实时预警、完整血缘和数据价值分析问题。这类问题只能通过大数据技术手段对Hadoop底层核心组件做深入洞察来解决。

三、集群治理的目标

Q6：听你这么说，针对大规模数据集群的治理工程还是很有必要的！

A：是的，“大规模”带来的问题，肯定不止上面这几类。

实际上会远超你的想象，传统的数据治理工具（如元数据、数据质量、数据血缘分析）可能就不灵了，必须要根据集群规模、数据仓库新型技术方案选型以及业务流程进行重构，才可能得到预期的治理效果。

再强调一句，大规模数据是长在集群之上，而集群里面的很多关键组件不是传统的商业关系型数据库，而是开源社区的通用版本，其可维护性、稳定性和功能局限性等方面都存在较大的挑战，性能这块也需要深入到源码层进行重构调优处理，你得做好准备。

所以，我们做大规模集群治理的核心目标聚焦在：

• 确保集群稳定，充分保障集群资源算力；

• 以效果为导向，有效驱动平台数据治理。

1、充分保障集群资源算力

毫无疑问，在大规模集群计算环境，保障集群资源算力是首要任务。

如果这一块稍有闪失，数据采集、数据存储、数据加工、数据建模分析、数据测试、数据稽核、数据迁移、数据同步、数据计算、数据作业重跑等流程可能都要崩溃。

因为这些环节背后都涉及到大量的数据作业任务调度执行，其成功与否取决于分布式系统组件整体的通信、资源的申请、以及任务实例的执行结果。

因此除了足够的物理资源池之外，还需要特别保障集群Master进程类服务的性能表现和稳定性。

2、有效驱动平台数据治理

开展集群治理的工作，最重要的目标就是有效支撑数据治理工程的建设。

数据治理是一个系统工程，通常是按照类似下面的框架做：

其关键是组织、流程、平台工具、评价考核机制的全面协同。

首先是从数据采集加工流程中梳理出数据治理体系最需关注的各环节建设内容和目标：

然后构建元数据管理、数据质量稽核、数据血缘分析、数据地图等工具集：

• 元数据管理：数据库表、模型脚本等元数据信息庞大复杂，可通过全文检索功能迅速查找和关键字匹配的权限范围内的元数据信息，为海量数据分析提供更快、更正确的查询处理、更好的数据质量、更易使用的操作接口等。

• 数据血缘分析：元数据管理重要应用之一，展示表、视图、过程之间的关系，表和指标间的关系。采用NET模式或FLOW模式进行信息呈现。血缘关系的数据来源支持通过解析数据加工SQL脚本、存储过程注释的方式；可支持通过ETL流程自动生成的方式，亦可支持通过配置表的方式。

• 数据地图：元数据信息的全景视图，描述所有元数据对象的血缘关系，所处层级覆盖范围由ODS->DWA->DWD->DM层，全面呈现了数据仓库中数据之间的关系。

如果你的数据集群规模不大，比如百节点以内，有非常完备的治理组织架构，按照传统的工具流程和方法论去做数据治理，一般问题不大。

但是，如果是在运营商大规模集群环境，随着业务的发展，遇到新的问题时，光靠一些老套路是行不通的，或者说整体治理成本是极大的。

在这样的大规模集群环境下，数据治理的本质其实就是：解决人与人的对抗、人与机器的对抗、人与工具的对抗、人与数的对抗问题。

实践经验发现，只是靠堆人的方式，或者只在数据治理文化层面强调人机数的全面协同，要做好大规模集群的数据治理是不太现实的。

更务实的做法是基于公司业务和组织架构特点，不断驱动和协同优化，还要借助大数据技术手段，精益推动数据集群侧的持续治理，形成数据治理+集群治理+资产管理的整体协同效应。

简而言之，集群治理支撑数据治理，数据治理驱动数据资产管理。

数据中心的资产包括数据、程序、流程、服务及资源5大类，通过集群治理和资产的有效管理，对于促进数据价值持续发现、数据能力持续开放、数据的持续变现有巨大的促进作用，从而逐步推动数据治理体系向资产管理体系演进。

四、集群治理的实施路径

Q7：军哥，说了半天，你好像还没有告诉我，到底如何开展集群的治理工作呀？

A：不急，只要你明白了集群治理的定位、背景、目标，其实搞大规模数据集群的治理工作就没有那么难，按照以下8个步骤做就行：

• 第一步：理清大规模数据集群的现状和治理需求点

• 第二步：明确治理的组织架构、方法论、技术框架

• 第三步：构建针对大数据集群的智能运维技术平台

• 第四步：实现YARN作业&HDFS画像、小文件洞察

• 第五步：实现NN RPC画像、关键Master服务预警

• 第六步：实现冗余计算挖掘，以目录维度评估冗余度

• 第七步：重构数据血缘、元数据、数据资产管理应用

• 第八步：智能分析集群用户行为画像，检测预测异常

下文中将对以上八个步骤进行具体解读。

五、集群治理的案例实践

第一步：理清大规模数据集群的现状和治理需求点

• 现状：Hadoop集群的计算能力已达到数千节点，平台部分集群初期由外部厂商进行建设，为了支撑业务快速上线，并没有统一规划，无序建设引发的问题逐渐暴露出来，权限混乱、计算能力下降、资源冗余计算、资源浪费等问题频发，针对该部分集群的稳定性和资源利用优化治理工作挑战巨大。

• 需求点：数据治理项目实施的整体难点主要集中在运营商多源头数据质量持续改进、日万亿级大规模数据加工处理、数据平台资源弹性交付与产品化快速响应支撑能力、数据能力开放平台租户高效运营、数据平台智能运维体系建设、数据安全合规保障等六个方面。其中跟集群本身治理特别相关的是：集群智能运维平台搭建、Hadoop组件洞察应用、冗余计算挖掘、集群用户行为智能分析、数据血缘与元数据管理系统重构等五个方面。

第二步：明确治理的组织架构、方法论、技术框架

1）治理组织架构

• 集群治理组：负责集群治理平台应用和优化评测工具研发、治理方案的制定、组织治理周例会和专项优化虚拟小组联合讨论会、定期跟踪巡检治理效果，像牵引器一样驱动大家协同完成工作。

• 数据治理组：除了负责数据质量和常规治理工作以外，还要配合集群治理组的方案，评估涉及到业务数据域基础模型采集加工过程中的改进优化需求点，然后负责具体实施，当然还包括相关产品支撑模型的重构、融合模型的整合优化工作。

• 租户运营组：配合数据治理组、数据建模组和集群治理组完成租户场景集群治理专项方案的实施。

• 平台维护组：配合产品应用部、数据治理组、租户运营组、数据建模组、集群治理组完成集群治理专项优化方案的实施。

• 数据建模组：配合数据治理组、集群治理组完成集群治理平台AI类模型的开发。

• 产品应用部：配合数据治理组和集群治理组完成集群治理专项优化方案的实施。

2）治理方法论

这里的核心就是建立自下而上、自发协同、精益推进式的数据治理文化。

3）治理技术框架

Q8：这个技术框架理解起来太抽象了，要解决的问题可以再解释一下吗？

A：其实没有那么难以理解，主要是公司业务高速发展过程中数据业务需求越来越复杂，所需算力也越来越大，进一步导致某些集群的规模越来越大，承载的产品也越来越多，部分集群面临资源负载过高、资源抢占严重、RPC请求负载过高等问题。

存储系统也面临空文件、垃圾文件、小文件过多，平均文件大小过小、文件数持续增长等问题，存储系统稳定性面临很大隐患。

作业又面临执行耗时过长、耗资源大、数据倾斜严重等问题，直接导致数据加工异常率过高、数据具备时间有延迟风险、产品交付面临风险。

基于以上面临的各种困境构建巡山大数据集群治理平台，以资源、存储、作业三大角度，从资源画像、作业画像、存储画像、冗余计算挖掘、数据血缘画像、RPC画像六大维度，几十个小维度进行集群交叉治理并协同各相关组织进行全域治理，使集群全面向良性健康方向发展。

第三步：构建针对大数据集群的智能运维技术平台

Q9：军哥，搞大规模数据集群的治理怎么扯到智能运维平台上面去了呢？必须要建这个平台吗？

A：好问题！前面说过，集群治理的首要目标就是充分保证集群资源算力，实际上就是要保障集群关键服务运行和数据作业资源调度的稳定性，以及相对不错的性能表现。

这里的稳定性和性能就是IT运维领域的事情，从业界发展来看，主要经历了四个阶段：

• 运维1.0：主要关注网管软件和ITSM工单系统，讲究业务协同和运维流程化。

• 运维2.0：主要关注CMDB和SOP标准运维，一般都会强调自动化工具在运维场景的应用，重点解决一些靠堆人方式解不了的问题。

• 运维3.0：主要关注DevOps、微服务、容器化的融合，比如基于容器云的DevOps一体化平台，打通项目管理、需求、研发、测试、上线、变更处理全流程。

• 运维4.0：主要关注AIOps，实现智能化的健康可用性分析、资源占用预测统计、异常检测、故障预警、智能扩缩容、日志根因分析应用等，其实就是用大数据的技术手段来搞定AIOps模型数据的采集、存储和分析处理。

一般来说，企业IT建设的头几年，会逐步上线CMDB、ITSM、Job自动化作业、SOP等子系统，然后开始考虑DevOps、容器云、AIOps等方向的建设。

对于大规模数据集群来说，我们必须先构建好这个基础的智能运维技术平台。

1）总体架构

• ITSM：IT流程服务管理系统，支持跨部门业务工作协同；

• CMDB：配置管理平台，IT资产应用统一配置化动态管理；

• Job：自动化作业平台，运维场景的作业批量自动化调度执行；

• SOP：标准运维平台，可视化拖拽模板化的运维流程定义和调度执行；

• DevOps：开发运维一体化平台，公司平台级开发运维一体化管理模式；

• 大数据集群治理平台应用：基于Hadoop内核组件深度分析，实现各类运维数据综合采集和统一整合，基于运维业务场景构建智能调度模型，提升平台数据处理作业性能，有效节省集群资源占用，实现平台集群资源利用率最大化；

• Monitor统一监控：先支持基础设施和平台集群监控应用，然后完成数据治理及上层产品层对接，逐步形成更全面的端到端统一监控平台。

2）数据生产检测可视化大屏

具体实施过程中，前期需重点关注平台优化和跨部门业务协同子系统的运营成效。

第四步：实现YARN作业&HDFS画像、小文件洞察

1）联合治理

以底层技术为核心，从资源、存储、计算三大维度进行联合治理，深度监控各业务资源队列使用状态、存储系统文件分布、作业运行事件和配置，建立可视化工具体系，驱动日常优化和运营。

①从资源角度：

对线上集群的资源队列状态进行秒级数据采集，包含队列最大容量、队列配置容量、队列已使用容量多维度的数据采集，实时监控不同业务线、不同周期资源使用状态，以达到动态调整资源规划、加工周期保障产线加工正常进行。

②从计算角度：

通过采集全域作业信息，解析出数十项核心指标和千个作业配置，计算出作业耗时TOP、耗内存TOP、耗CPU TOP、数据倾斜TOP、高IO TOP以及从不同业务、不同周期、不同账户洞察待优化作业，针对不同异常类型给出相应优化方案，降低作业资源负载、降低输出文件数、提升输出文件大小，从而减低整个集群资源负载和提升存储系统稳定性。

③从存储角度：

采集分布式存储系统的元数据镜像和元数据操作日志，洞察分布式存储系统文件数趋势、文件分布统计、平均文件大小趋势统计、空文件分布、垃圾文件分布。

2）技术实现方案

第五步：实现NN RPC画像、关键Master服务预警

大数据集群有很多关键服务，这些服务的健康异常状态，需要重点监控，且尽可能做到实时处理效果，这样在故障发生后可以组合多种监控和日志信息，从多个维度交叉定位问题，提升解决问题效率。

1）技术实现方案

第六步：实现冗余计算挖掘，以目录维度评估冗余度

冗余计算意味着同一份数据被多个加工流程加工，主要是由于前期为了支撑业务快速上线、没有统一规划、无序建设过程中所引发的问题。

在运营商海量数据背景下，数据重复加工意味着对内存、CPU、存储容量、IO、文件数量、RPC负载有着全面且巨大的影响。

在全域数十万加工作业中如何全面且精准定位冗余计算成为不小的挑战，基于此持续优化线上加工流程更是一个缓慢的过程，需要详细梳理业务需求，制定数据标准，明确数据口径。

洞察冗余计算主要思路是解析全域数十万个作业并从每个作业千个配置项中解析出输入目录，每个作业会有多个输入目录，最多的有上百个甚至上千个，且目录中含有省份、账期、基站等各种分区类型。

我们需要对目录进行通用化处理，以目录为维度统计对应的加工流程以及每个加工流程对应的作业实例，从每个作业实例中计算内存消耗、CPU消耗、存储消耗、IO负载、文件数增长、RPC负载以评估冗余计算带来的成本、优化后达到的效果、执行周期内对其他数据加工产生的影响，以精细化数据为基础协调各组织进行持续治理。

1）技术实现方案

第七步：重构数据血缘、元数据、数据资产管理应用

1）面临挑战

• 在某集群长期的无序建设中，由于对数据缺少平台级的运营手段，比如缺少数据库、数据表以及数据列统一的信息维护平台和整体的物理视图，导致底层数据存在过多垃圾表，且缺少对底层数据的认知；

• 对元数据的变更无监控无跟踪，缺少全域加工数据血缘关系，不能追溯数据加工流向，导致故障发生后不能明确影响范围，数据成本与价值也难以衡量，在安全合规为第一红线的背景下，对敏感数据也没有效跟踪；

• 缺少数据资产管理，没有展示数据应有的支撑能力，造成组织架构内数据服务信息不对称。

基于以上痛点，着手重构了企业级全域元数据平台，提供全域物理视图、业务视图、元数据变更跟踪监控、全域数据血缘关系图等核心功能。

物理视图提升对数据的认知，业务视图展示数据支撑能力，元数据变更跟踪实时了解产线环境异常修改，数据血缘可提供数据追溯、数据成本价值洞察、敏感数据流向。

元数据平台视图

元数据平台应用

全域数据血缘关系图

2）技术实现方案

第八步：智能分析集群用户行为画像，检测预测异常

产线环境难免存在数据被误删除的情况，故障发生后，一般要通过较复杂的综合定位过程才能发现根因。

此时产线加工可能受阻、数据具备时间延迟，进一步影响到产品质量和用户体验。

由于此类故障从根本上难以彻底消除，为尽可能的降低负面影响，可建立用户行为异常操作智能检测机制，对不正常的用户操作及时预警，在一定程度上提前发现问题、规避故障。

1）技术实现方案

根据产线环境千万级的作业信息，结合当下的资源状态进行特征抽取，建立实时的机器学习模型，对当前以及未来一段时间窗口的资源占用进行预测，将检测到的异常状态波动进行告警。

六、结语

在运营商大规模集群治理的实践过程中，有几点感悟：

• 领导的支持力度非常关键。公司领导对数据资产管理建设的价值认可，能够在核心数据质量持续优化过程中提供组织协调支持，有效推动集团和各省分公司配合改进，保障端到端质量优化效果。

• 数据治理文化建设是核心。建立专业的数据治理团队，优化数据资产管理组织架构，以自底向上的完整血缘分析、核心数据质量为入口，建立自下而上、自发协同、精益推进的数据治理文化。

• 数据资产管理架构和配套工具是基础。在业务发展过程中，逐步打造体系化的数据治理实施能力，安全合规标准规范先行，建立持续优化的治理体制。

• 数据能力开放平台是优势。通过面向外部租户自助建模平台的综合运营，可大幅提升内部数据治理工程跨组织的协同效率，数据用多了，自然会激发治理的原动力。

• 基础平台团队要拥抱并吃透开源技术。能够从大数据平台核心组件源码层进行重构与性能调优，充分保障集群的稳定性和算力要求，在大规模集群故障预测、异常检测、故障恢复、资源调度优化、跨集群协同计算等方向全面探索和应用AIOps技术解决难题。

作者：尹正军、穆纯进

来源：中国联通大数据订阅号（ID：unibigdata）

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn

更多关于数据治理的话题

来DAMS看看还有哪些成功实践为你适用

↓↓扫码可了解更多详情及报名↓↓

2019 DAMS中国数据智能管理峰会-上海站