大数据资产管理平台实践（下）：设计、研发、运营

背景介绍

随着信息经济发展，以大数据为代表的信息资源正在朝着生产要素的形态演进：

中共中央、国务院近日发布的 《关于构建更加完善的要素市场化配置体制机制的意见》，将数据纳入生产要素范围，明确加快培育数据要素市场；

今年的政府工作报告中也明确指出，需要培育技术和数据市场，激活各类要素潜能；

数据成为生产要素，是对其价值的充分肯定，对于数字经济的发展起到导向作用。但现阶段我国数据要素市场化配置尚处于起步阶段，仍需加强探索与完善。作为值得信赖的数据智能科技服务专家，联通大数据公司在数据要素市场化、数据资产管理等领域有了较丰富的沉淀，基于此，我们在今天的推送中，将公司在数据资产管理平台的设计、研发与运营方面的实践经验进行梳理，欢迎大家共同探讨、指正。

本文作者：尹正军，联通大数据公司高级架构师

上一期传送门 →

硬核科普 | 大数据资产管理平台实践（上）：定义、目标、挑战

五

数据资产管理平台的功能设计

(一) 整体架构设计: 一站式端到端数据治理管控

Q：这个平台有这么多功能模块啊！如何理解这些模块的定位和价值呢？

A：简单的说，我们的数据资产管理平台=数据治理平台+数据服务平台，其中数据服务平台的核心是能力开放平台，包括租户建模分析平台、数据查询分析、数据资源共享交换、数据能力商店、API服务中心等典型应用。

再举一个小例子，当你想在数据仓库中建一张表（模型），首先就是借助于数据开发平台的数据模型管理模块，进行逻辑模型设计，这里涉及到表命名和字段schema结构的定义与配置；表命名可以参考数据标准模块的相关规范要求来定义，字段设计可选择直接导入ER图，或者参考数据标准管理模块中的标准(历史相似)模型对应的数据元（属性）、代码集（字典）、数据集（属性集合）等条目信息进行设计，逻辑模型设计之后选择相应数据源进行物化处理，从而生成产线环境中的物理模型，这里的数据源是基于平台中数据源管控功能进行配置管理。当模型上线后，我们可能会基于数据集成平台的数据采集交换模块，从其他数据源系统导入相应的表数据，同时会触发元数据管理模块中的元数据采集及变更管控稽核功能，确保模型的所有变更状态能够及时通知数据组织相关人员；然后是基于数据加工过程管理模块，围绕新建的表进行加工过程（通常是SQL或Shell脚本）的标准化管理，这里的标准化是指根据加工的基础模板自动生成相应加工脚本处理模型，并一键完成该处理模型的仿真测试和上线；在仿真测试阶段和正式上线后，都会涉及到数据集成平台的工作流调度；上线一段时间后，可能会遇到数据质量问题，则可采用数据质量平台对模型中的数据进行数据质量稽核，还可能会遇到表数据具备问题，比如每天凌晨批处理过程执行前，数据没有按时具备，以至于对后续处理产生影响，这时就可以借助元数据管理模块的血缘分析和数据地图功能，大致评估出影响范围；同时，根据数据集群治理平台的底层洞察功能，找到该数据模型相关大数据作业处理背后的底层存储和计算瓶颈，然后进行数据治理优化动作的实施；数据质量问题和集群治理问题解决之后，可以通过数据服务平台开放共享给内外部租户，刚才提到的数据采集交换、元数据稽核、数据质量稽核等任务，都会交给数据集成平台的工作流模块进行调度处理，另外，涉及到该模型后续的使用消费、变更删除等操作，会由数据开发平台生命周期模块全局管控。

(二) 数据集成平台：解决数据采集交换与调度问题

定位与目标：

把政府、企业内外部数据快速整合到一起，通常会包含数据采集交换和工作流调度系统，如果还要支撑DataOps数据开发运维运营一体化平台功能落地的话，需提供大数据平台与生产应用系统的双向通信能力，方便构建数据开发、运维、治理、运营闭环系统。

核心模块列表：

数据采集交换平台、数据工作流调度系统、数据应用代理系统。

主要功能列表：

数据源原理：RDBMS、MPP、hadoop、txtFile、ftp等

映射管理：映射新增、映射设计、映射导入、目录编辑与迁移

流程管理：流程汇总、导入/添加工作流、流程编排、流程实例管理（日志查看、重跑、暂停、失败恢复）、目录编辑与迁移

运行监控：资源监控、异常监控（调度和宕机）、历史流程实例查看与清理

配置管理：工作流消息配置、自定义插件维护、计划调度管理、作业组管理、计算资源管理、流程模板管理、自定义函数管理

参考设计：

(三) 数据开发平台：解决数据开发标准化问题

定位与目标：

支撑数据模型设计、数据加工脚本标准化，实现开发、测试、上线过程自动化，保障数据模型与生命周期管理标准落地。

核心模块列表：

数据模型管理、数据脚本过程管理、数据生命周期管理。

主要功能列表：

开发模板管理：开发模板查询、导入、版本控制、删除、状态管控

开发内容管理：内容目录管理、开发过程管理（新建、测试、审批、部署、下线）

开发内容审批：开发内容详情、资源消耗消息、开发内容审批

执行日志管理：执行日志生产、执行日志查询

Agent组管理：组详情、组编辑和创建

Agent管理：服务器管理、主机用户过滤设置、组同步、状态变更

参考设计：

(四) 元数据管理平台：解决数据资产盘点问题

定位与目标：

基于技术元数据、业务元数据和管理元数据的采集与分析，实现数据血缘、影响分析和全链分析，解决内部数据资产统一盘点和运营问题。

核心模块列表：

元数据采集、元数据存储、元数据分析、元数据应用。

主要功能列表：

元模型管理：元模型属性定义、分类权限管控、异构元数据支撑、元模型与元数据关系映射管理

元数据采集管理：元数据采集方式、元数据解析、元数据入库

元数据稽核：元数据版本稽核管控、元数据标准稽核

元数据应用

血缘分析：血缘数据采集、血缘全链解析

影响分析：血缘数据采集、下游生成实体分析

资产目录：业务视图分类管理、技术元数据管理

资产地图：系统/域层次关联配置、数据仓库分层绑定、数据模型血缘绑定

参考设计：

(五) 数据质量管理平台：解决数据质量改进问题

定位与目标：

针对数据进行稽核来确保数据的质量，覆盖及时性、完整性、准确性、一致性、唯一性及合理性等，及各系统之间数据的统一性。建立标准化度量系统，方便系统性改进数据质量问题。

核心模块列表：

数据源、数据对象、元数据分类管理；数据质量检测模型、方案、规则管理；数据质检任务调度、报告、流程管理。

主要功能列表：

数据源管理：元数据目录管理、数据对象管理

质量模型管理：模型分类管理、质检方案绑定

质检方案管理：方案基础配置、质检对象选择、质检规则配置与自定义、调度策略与告警配置

质检调度与报告管理：任务调度日志、质检报告管理、质检改进流程

配置管理：集群配置、质检资源配置、质量模板配置

参考设计：

(六) 数据标准管理平台：解决数据管理规范问题

定位与目标：

数据标准是大数据治理生态中重要的一环，与数据过程管理、元数据管理、质量管理等模块进行协作，组成完整工具集，促进公司、组织内数据处理、交换相关流程、功能的标准化，有效提高数仓平台建设和数据管理的质量和效率，加速数据流转，从而促进业务创新。

核心模块列表：

数据元、代码集、标准术语、指标标准管理；数据标准分类检索、实施流程管理；数仓建模管理 (逻辑模型设计与物化）。

主要功能列表：

数据元管理：属性描述符、属性约束

数据标准分类：国家标准、行业标准、企业标准（数据主题、业务渠道）

数据标准存储与检索：全文检索、文件存储、数据库存储

数据标准实施流程管理：标准规划、标准制定、标准发布、标准执行、标准维护

数仓建模支撑：基于标准导入、逻辑模型设计、逻辑模型物化、分层分域约束与映射、模型稽核

参考设计：

(七) 数据集群治理平台：解决集群洞察优化问题

定位与目标：

基于Hadoop集群底层组件运行机制和大数据开发运维等组织活动进行多维交叉洞察，以降本增效为中心，向下保障大规模Hadoop集群算力，向上指导数据治理动作实施和业务连续性。

核心模块列表：

集群治理数据采集；集群治理分析引擎；集群治理平台应用。

主要功能列表：

资源画像：集群整体CPU/内存等资源使用；分队列CPU/内存等资源使用

存储画像：集群文件数、空文件数、文件夹数、文件数增量；10M/50M小文件账户分布；数据库、表、分区小文件以及增长

作业画像：作业耗资源TOP、作业IO TOP、作业耗时TOP、作业数据倾斜TOP

数据血缘画像：全链路分析、前溯分析、后溯分析、故障影响评估

元数据画像：垃圾表洞察报告、垃圾分区洞察报告

RPC调用画像：RPC账户、业务分析；RPC分时统计、RPC下钻作业分析

冗余计算画像：计算目录被扫描次数、目录管理作业、冗余计算资源评估

用户行为告警：库、表变更实时告警；库、表目录变更实时告警

参考设计：

(八) 数据服务平台：解决数据能力开放共享问题

定位与目标：

以生产环境的运营支撑和应用开发为主要IT诉求，构建IaaS、PaaS、SaaS三层私有云体系，提供可复用、可隔离的存储计算资源、数据资源、开发组件资源，同时保证多租户安全隔离，落地安全多方计算技术，方便数据资源开放共享和数据资产运营。

核心模块列表：

云计算资源池；数据能力商店；多租户控制台；安全多方计算。

主要功能列表：

云计算资源池：Hadoop平台、容器云平台、虚拟化平台

数据能力商店：数据产品套餐、数据API服务、数据推送服务、数据总线服务

多租户控制台：工单管理、订单列表、能力套餐、系统总览

计费管理：基础信息维护、商品报价维护、租户费用报表

可视化分析建模：可视化建模、BI报表构建

数据管控套件：元数据管理、数据集成平台、数据质量管理、数据模型与生命周期管理

安全多方计算：计算基础能力、编译及计算功能、数据流通管理

参考设计：

六

数据资产管理平台的研发运营实践

(一) 整体研发与运营：始终坚持合适的才是最好的

Q:在数据资产管理平台的整体研发实践方面，有什么心得可以分享吗？

A:OK，整体来看，我这边主要有四点：

第一，研发策略方面：要处理好完全自主研发和部分模块外采之间的矛盾。

比如像数据采集交换这个基础模块，真的有必要完全从头开始自行研发吗？不见得。目前开源社区就提交了一些很好的项目，大部分场景需求基本能够覆盖到。即使开源社区的项目不太满足架构和安全性等个性化要求，也可以尝试外采部分基础模块，没必要全部都完全自研。

第二，产品定义方面：要处理好产品经理、技术架构师与开发工程师的矛盾。

产品经理想的是满足内外部客户，尽快完成研发任务，技术架构师或技术经理，经常会聚焦到后期架构扩展和性能问题。在产品需求讨论和定义阶段，经常会发生冲突。先比如说，DataOps数据开发运维一体化模块的问题，产品经理认为这个非常酷炫的功能，一定对外输出，最好能通用适配几乎所有的行业。技术经理和工程师的内心想法是，这个东西完全是按照公司内部的产线系统结构和组织特点来设计的，对外输出的价值很低，兼顾所有行业的话，技术上很难落地。再比如说，元数据管理系统中的数据血缘分析问题，产品经理认为这个是系统的核心亮点，必须要端到端做好，是最大卖点。技术经理和工程师的真实想法是，关键是看血缘基础数据采集范围，是否能够覆盖到全业务线全渠道全产品全模型全系统范围，甚至包括内外部不同开发团队提交数据处理作业的不同方式，要端到端做好，其实不是很现实，即使真正做到内部实用了，发现又并不通用，看起来漂亮的血缘分析展现效果，实际上在其他公司并不会有多大的实用价值。

第三，团队管理方面：要处理好公司团队价值产出目标与个人成长目标的矛盾。

这个问题也是所有中台产品研发管理者必须会面对的一个难题，公司和团队，会看重一定周期内的产出是否符合内外部客户需求，不是那么在意背后是否有足够的技术挑战。而团队组员会更看重自己的个人成长，希望能有一定的技术挑战和比较充裕的研究时间周期、方便自己亲历攻坚克难的整个过程，不喜欢做搬砖、挖煤、填坑的事情。怎么办？个人经验是，在研发过程中，必须两条线并行，一条满足项目最低交付目标，一条满足团队成员个人成长目标（OKR）。

第四，研发实践方面：要处理好内部定制化产品研发与外部通用交付型产品研发的矛盾。

其实刚才提到了，内部产品研发，经常要实用，要针对组织背景解决实际问题，而外部产品，更追求行业通用，能够大规模标准化交付。如何平衡好，需要提前做很多的功课。及时跟进开源社区的项目进展，还有广泛学习业界巨头和有行业特色的ISV团队们的商业化产品的经验。

(二) 数据集成平台：你可能只需要一个集成平台？

实践心得：

• 高度分散的数据源
  

数据大量分散在政府、企业的不同业务系统、数据库、甚至第三方系统中; 数据源类型、结构、模式不尽相同，须经过采集、清洗与标准化才能进入数据仓库。

• 开发脚本的复杂性
  

数据加工过程一般通过执行复杂冗长晦涩的脚本来完成，要求开发人员必须有较高的专业技能；数据加工过程的逻辑错误、语法错误也不容易捕捉；集群作业提交参数的合理性问题。

• 流程维护与可复用
  

数据处理的流程大量依赖各种脚本程序，难以理解与修改维护；数据处理流程经常无法复用，缺乏统一管理；因为数据断传、漏传、补传造成数据重跑问题突出。

• 飞速增长的数据量和非结构化数据类型
  

随着5G+物联网场景超大规模数据的输入；数据持续不断的到达，数据集成应当具备PB级实时或准实时数据处理能力；需要支持结构化、半结构化、非结构化等不同数据类型。

(三) 数据开发平台：数据仓库开发最佳实践是什么？

实践心得：

• 数据开发平台与数据治理体系
  

数据开发平台支撑数据治理文化落地，数据治理过程强调组织、文化、工具、流程的全方位协同，数据开发平台仅仅是数据治理工具体系的一部分。

• 产线环境安全与便捷实用性的博弈
  

为了保障产线环境下数据加工脚本执行的安全性，平台需要覆盖脚本模板配置、脚本创建、审核、测试、部署上线的完整流程，整体使用复杂度相对提升，需要配套的运营流程。

• IT墙与数据部门组织墙问题
  

数据开发平台研发背景往往跟生产环境实际痛点相关，涉及组织较多，在向其他部门或项目组推广时，因不同组织绩效目标差异，通常会遇到不同程度的IT墙和部门组织墙问题。

• 从脚本标准化自动化到在线IDE
  

企业各开发团队的技术栈和开发习惯差异较大；平台脚本模板很难兼容所有团队的灵活需求；在线IDE需兼顾数据治理标准落地和个性化需求开发的要求。

(四) 元数据管理平台：数据血缘应该怎么做才实用？

实践心得：

• 多种元数据采集方案的抉择
  

针对不同数据源/集群的采集有多种方案，站在交付目标、无侵入性的角度考虑，综合权衡好安全性、性能和扩展性要求。

• 元数据管理应用是推广抓手
  

从数据资产目录、数据视图、元数据检索、元数据稽核、数据地图、数据血缘、影响分析、全链分析、活性分析、数据价值图谱等应用方向寻找内部推广应用的突破口。

• 数据血缘分析准确性与完整性
  

由于企业数仓存储介质、加工方式、调度手段多样，在采集多种元数据后，整合血缘分析的困难度较高，建议定向对指定场景进行血缘分析。

• 元数据稽核与数据标准、数据质量协同
  

元模型管理、元数据属性填充率、贯标落地统计、生产环境最新版本与资产管理平台、测试环境双向稽核。

(五) 数据质量管理平台：质量是一个老大难问题？

实践心得：

• 数据质量稽核的投入产出比
  

当关键业务域数据体量太大(如每日新增超过百TB）、集群规模较大(无法建立对等测试环境)，总体质量稽核成本过高。

• 数据稽核对象和策略的选择
  

针对省分不同账期不同主题域数据，如何根据业务要求和实时流代码埋点处理流程进行抽样，选择性做质量稽核？优先解决采集链路质量监控、数据断传补传漏传、波动性监测等基础层稽核问题。然后解决业务层稽核问题。

• 数据质量报告的问题
  

常态化的质量稽核统计报表，无法给非技术口领导层直观的呈现，需要结合业务领域知识和组织结构做进一步封装。

• 与元数据、数据标准、调度系统协同
  

数据源目录分类和质检对象来源于元数据系统，数据表模型质检要求来自于数据标准系统，数据质量任务执行通常要跟工作流调度系统对接。

(六) 数据标准管理平台：企业标准如何制定和落地？

实践心得：

• 数据标准分类管理问题
  

国家标准、行业标准、企业标准同时管理成本较大，其实践层面的指导意义待深入探索研究和试错。

• 数据标准制定相关的业务梳理工作
  

数据标准的制定往往依赖于领域业务能手、IT架构专家等组织团队的通力协作，相关的业务梳理工作工程量很大。

• 数据标准的内部推广应用问题
  

数据标准管理工具在内部推广应用的实际困难往往会超出预期，需要持续迭代，离不开一把手的支持和长期的努力。

• 基于数据标准做数仓全局规划和落地
  

主要是从逻辑模型设计和物化入手，逐渐完善数据仓库分层分域、数据指标标准等数据架构规范的落地。

(七) 数据集群治理平台：大规模平台数据治理突破口

实践心得：

• HDFS文件存储洞察
  

开发NameNode元数据持久化文件Fsimage和元数据操作文件记录文件EditLog的反序列化解析项目，无侵入性洞察全集群，冷温热存储状态，至少要实现千万级目录精细画像。

• YARN Job数据作业洞察
  

实现资源监控与异常作业多维度洞察、高效协同优化。综合几十个小维度进行集群交叉治理并协同各相关组织进行全域治理，使集群逐步向良性健康方向发展。

• 数据冗余计算挖掘分析
  

针对HDFS JOB BINARY FILE进行分析，定位疑似冗余计算作业，与组织架构复杂度无关、不依赖上层业务的大量输入，其核心提取出具有相同输入路径的作业，以目录维度视角挖掘作业。

(八) 数据服务平台：从数据能力商店到数据开放平台

实践心得：

• 提供丰富的大数据计算框架
  

平台数据框架层需要提供丰富、多样的大数据计算框架，满足海量数据批量计算、复杂逻辑关联、流式数据处理、高并发低延迟海量数据查询、消息分发等多种场景。

• 脱敏样例数据
  

平台可从大数据生产平台上提取脱敏后的样例数据（产品表和标签） 来提供给租户进行相关的训练模型,除此之外租户还可以根据自己业务需求来制定专属样例数据。

• 生产工具和服务
  

平台要为租户提供丰富的生产工具和服务，支撑租户完成生产建设与应用开发和扩展；随着能力建设的深入以及租户业务场景的扩展，未来会有更多的工具和插件集成到能力开放平台中开放服务。

• 多渠道运营管理
  

平台要支持多租户方式进行平台管理运营，各租户之间数据资源共享，硬件、网络、计算资源互不影响，保证各合作伙伴资源使用稳定及其模型资产安全。

结语

Q: 最后能否再简要概括一下，企业搞数据资产管理平台研发运营，以及推动数据治理体系和数据中台落地等，这一些数智化转型系统工程建设的典型步骤，或者关键挑战？

A:你刚才说的数据智能相关的系统工程，往往都是知易行难。从实操经验来看，企业数智化转型失败，通常有以下5个主要原因：

1. 在认知层面，并未真正上升到数据战略层面，没有一把手牵头去规划和执行，在中途放弃了很多目标。

2. 在组织层面，没有建立起高效的数据组织协同机制，没有全局观念，互相推诿扯皮，组织墙问题突出。

3. 在文化层面，未能真正形成相应的数据驱动文化，大量历史习惯阻碍了文化的落地，无法突破舒适圈。

4. 在人才层面，没有配套的数据人才支撑体系，团队的成长较缓慢，跟不上行业和企业快速发展的节奏。

5. 在技术层面，无法驾驭以云计算、大数据、人工智能、物联网、区块链为代表的数字科技先进生产力。

所以，下面这一点，我还想再强调一遍，目前行业通用型工具体系建设仅仅是数据治理体系和数据资产管理框架很小的一部分，更多的是，要不断提升数据驱动文化认知，充分依赖于组织、标准、流程的全方位协同。其中数据资产管理的期望是能达到点石成金的效果，覆盖从数据集成、数据分析挖掘到数据资产共享和流通的全过程，实现数据的深度融合、创新应用、资产化运营；数据资产管理的平台演进要遵循渐进主义，始终坚持‘合适的才是最好的’指导原则；数据资产管理相配套的治理应用落地，尽量要寻找到精益数据管控服务的最佳实践，始终坚持以业务价值产出和系统性降本增效为导向。最后，说到企业数智化转型工程，我通常喜欢用12345678910这10个点来总结：