导语：
随着越来越多的企业认识到数据作为生产要素的价值 ，加快了企业数字化转型 ，把完善企业级的数据治理体系作为企业数字化转型的一个目标。Z6官网人生就是博科技在大数据领域始终保持足够的技术敏锐度 ，并积累了丰富的经验与资产。为此 ，我们组织了一个系列专文 ，分期发表 ，与您一起探索更适合当下行业发展的数据观 ，欢迎大家持续关注。
作者｜Z6官网人生就是博科技大数据研究院 内容｜本篇共4694字 ，预计阅读时间18分钟
企业数据管理包含数据架构、数据集成、元数据、数据质量、数据建模、主数据与参考数据等多个管理职能领域 ，数据架构是管理数据的基础。站在企业架构的高度 ，数据架构与企业应用架构、技术架构有紧密的关系 ，最终影响数据资产的质量。长期以来 ，一些组织没有把数据当作产品来开发 ，没有把数据当作资产来管理。几乎每个组织的每个数据管理职能领域以及应用架构 ，都存在提升空间 ，但不要企图短期内得到全面提升 ，应该梳理整个组织的数据管理生态系统 ，找出合适的某些领域先行优化 ，即使少量的投入 ，也可能很快产出价值。 01 盘点数据资产 数据的多样性与数据量爆炸式增长使数据的管理日益复杂 ，数据需求的激增使数据服务的提供部门穷于应付 ，迫切需要尽早盘点存量数据资产。 l 盘点库存资产及资产使用状况 盘点组织范围有哪些数据以及数据状况 ，数据所代表的准确定义 ，有什么用途 ，梳理清楚数据资产起源于何处 ，如何在组织中移动 ，形成清晰的库存资产目录与资产分布地图与血缘。 盘点跟踪数据资产被不同用户、不同需求使用的情况 ，包括使用的广度、深度与频度等 ，评估使用产生的价值 ，从而发现可重用的高价值数资产据 ，并质疑不被使用的数据资产的存在意义。 l 提高高价值资产的使用效率与重用率 盘点数据资产 ，发现有价值的数据资产 ，形成数据资产目录 ，提高数据服务的质量、使用效率。在盘点过程中可能发现不同人员开发了相似或相同的数据资产 ，在没有数据资产目录的情况下 ，重复开发的现象是必然存在的？獯嬷械氖葑什 ，无论多少份重复的数据 ，只能算同一资产 ，除了备份之外 ，其它都是多余的 ，不仅占用存储空间成本 ，还要付出管理维护成本。数据资产目录可以提升资产重用率 ，从而避免资产无序增长。 l 数据资产目录 ，应该包含问题资产目录 盘点数据资产 ，目的不仅仅是为了得到一份可供使用的数据资产清单 ，还要为问题资产管理提供输入。如果不是简单地为了输出资产目录 ，在定义数据资产与以及数据资产之间关系的过程中必然会发现许多问题 ，诸如各种数据质量问题、数据流转与分布不合理、信息孤岛、烟囱式应用、使用了不合适的数据源（没有使用权威数据 ，减少负资产的使用与影响）、数据使用不合规等等。 数据资产的“目录”概念 ，弱化了数据资产的内在意义 ，代替不了数据架构的职能。数据资产的含义要比一般图书目录、商品目录丰富得多 ，数据资产之间是有关系的 ，可以带来更多潜在的衍生价值。 02 完善基础元数据 盘点数据资产需要可靠的元数据对数据资产进行定义、归类 ，建立数据之间关系与血缘关系。组织的运营取决于共享信息的能力 ，在大多数组织中 ，元数据管理方面的历史欠账太多。 l 缺乏元数据 启动盘点数据资产工作 ，面临的第一个问题是缺乏数据资产的元数据。许多业务系统只能从生产库上导出没有业务逻辑的物理库表结构。银行业务数据不是凭空产生的 ，应该先有数据的元数据后才能产生数据 ，不是先有鸡还是先有蛋的问题。现实是一些业务系统设计时并没有考虑到数据的使用 ，数据被当作业务系统的副产品 ，尤其是快速迭代的互联网系统产生的各种大数据 ，一般没有把元数据作为最终产品交付件。 l 元数据不可靠 即使在系统建设初期维护了部分元数据 ，也没有纳入配置管理中 ，投产之后更新不及时或再也没有更新 ，不能保持一致且最新 ，不同文档之间内容不一致。元数据发布也不到位 ，常常遗漏下游用户 ，不同人员的版本不一样。数据仓库中的基础数据元数据也不齐全 ，衍生数据的元数据也很少维护 ，所谓的统一指标 ，不是建立在统一的基础之上的；炻业脑莶钜欤ㄊ萁峁埂⒏袷胶椭档氖褂貌钜欤┍燃虻サ氖荽砦笥跋煅现氐枚。 数据生命周期前期阶段工作的不负责任 ，没有交付可靠的元数据 ，下游用户无法比较与关联数据 ，也就不能准确使用这些数据 ，更无法将数据作为资产进行管理 ，增加了数据使用成本与风险 ，拖延了数据项目实施周期 ，后期需要付出更大的补救代价。 因为元数据管理不善 ，也因此衍生出大量不一致的元数据。如一些银行数十万数据项 ，足以说明其数据与元数据管理的混乱。 需要及早梳理、补充完善基础元数据 ，如最基本的数据库设计说明书、每项数据资产的业务含义 ，关键数据元的定义与规则等等 ，无论代价多大 ，都无法回避这些工作；≡莸耐晟埔话阌ο扔谑葑什痰慊蜃魑葑什痰阆钅康那捌诠ぷ魍瓿。 03 优化数据架构 很多数据资产问题可能因数据架构的缺陷导致的。企业数据架构描述数据应该如何组织与管理数据 ，作为企业架构的一部分 ，是管理数据资产的蓝图。数据架构的设计贯穿于数据全生命周期 ，没有数据架构也就没有数据管理的基础 ，导致数据管理各种成本的大幅增加。 许多组织没有设计数据架构 ，架构部门的职责范围不包含对数据架构的管理 ，可能仅限于管理技术架构或部分应用架构 ，架构设计与管理的能力弱 ，也不具备对供应商方案的把控管理能力 ，整个组织概念混乱 ，数据分布与数据流转混乱。 只有少量组织建立了数据架构 ，庞大的数据架构需要足量的高端架构师进行持续管控维护。架构本应该长期相对稳定的 ，某些组织却每五年甚至两到三年大幅度修改架构。一些从业人员试图用业务领域来分类数据 ，把业务分类与数据分类混为一谈。 某些组织意图对某些主数据进行集中管理 ，但没有配套的管理组织、人员、流程与措施 ，比如开发部署了ECIF系统 ，但仅能保证客户三要素或四要素是企业一致的 ，保证键的唯一 ，不对主数据本质属性管理 ，这些数据还是混乱的 ，产生不了客户单一视图。 与过去数据模型仅存在于数据仓库的认知一样 ，不少数据专业人员对数据架构的认知仅限于数据仓库的分层。虽然对数据仓库的分层仍有不同的理解 ，在数据仓库实施过程中 ，确实倒逼了企业数据架构与应用架构的建设、提升优化。 随着业务与产品的创新 ，业务与技术试图突破已有的各种管理限制 ，使数据的管理日益混乱 ，成本日益增加。组织需要具备良好管理的数据架构 ，尽快形成企业的数据分类 ，开发概念数据模型 ，从对基本概念达成一致的认识开始 ，指导盘点资产、数据的产生与使用、数据标准等工作 ，及早实现数据资产管理的价值。 04 优化应用架构 应用架构是对实现业务能力、支撑业务发展的应用功能的结构化描述。应用架构重点回答业务功能在哪里实现的问题 ，数据架构重点回答数据在哪里产生又在哪里使用的问题。许多组织整体上缺少对业务、业务流程与信息数据的理解 ，没有很好规划应用架构。 一些应用系统由历史演变而来 ，可能包罗原始所有的业务 ，设计扩展性差 ，已经不能适应不断变化的业务需求 ，没有一个大而全的应用系统能支撑大型组织所有的业务。应该从应用架构与技术架构上进行拆分。 有些业务应用系统的功能过于单一 ，开发不同的业务系统处理相同或相似的业务功能 ，除了导致概念不统一（如对私、个人、零售三个名称不同但内涵相同的概念 ，“个人贷款借据表”中的业务主键的名称是“零售贷款借据编号” ，给使用者造成业务主键与表分别表达了不同业务的误解） ，每个系统必须具备完整的业务操作与处理流程 ，无论设计开发 ，还是系统配置、运维人员配置 ，都造成资源浪费 ，导致昂贵的成本？梢韵胂笠幌 ，当两个业务功能相似的系统整合为一个系统的时候 ，会带来哪些收益。 流程关系紧密的业务功能分散在多个应用系统中实现被拆分为多个系统 ，如贷款业务申请、客户评级、授信、担保、押品、合同放款、贷后、核销等所谓对公信贷全流程 ，业务功能分别在多个系统实现 ，从一个或2个集中的系统被过度拆分 ，数据集成与交互的复杂性指数级增加 ，同样的数据在多个系统中存放 ，必然导致数据的不一致性 ，同时产生了混乱的概念 ，如贷款申请流程中没有业务意义的技术主键 ，流转到授信、合同放款等系统中时 ，被转义为贷款申请编号 ，而用企业抽象通用的业务编号表示真正的贷款申请编号 ，还产生了贷款借据、贷款支用、贷款账户等概念。 应用架构影响数据架构与数据的集成。不合理的、混乱的应用架构编织了复杂的蜘蛛网 ，不但制造了混乱的概念 ，还造成数据集成的困难甚至集成了错误的数据 ，给业务管理与数据管理带来困惑 ，增加数据管理成本与风险。 需要从企业视角优化整合各条线、部门应用 ，解决功能过于分散、功能交叉重叠与分工不清晰的问题。良好的数据资产管理 ，离不开业务架构、应用架构、数据架构以及技术架构顶层设计来降低数据资产总拥有成本 ，给业务提供高质量的数据。架构方面一项小的优化措施 ，可能带来大的价值提升。 05 有效实施数据标准 一些组织已经实施了十多年数据标准 ，制定了包含数千或超万的数据标准信息项 ，但是十多年过去 ，落地实施的标准并不多 ，即使最基本的数据项也大多没有落地。比如某行建立了币种、币种代码、币种编码、币种码、货币种类代码、币种类型代码、币种种类编码、币种种类代码、货币代码、币种代码值、币种信息等近千名称不同、数据类型不同的币种代码相关数据项。 数据标准本身定义不准确或不严谨 ，数据标准的内涵理解存在比较大的差异 ，合标要求不明确或不严谨 ，或多或少都存在一些问题 ，流于形式与表象 ，没有抓住本质。比如： 分类是管理数据很关键的一项工作 ，有些数据标准 ，除了按照主题域分类外 ，没有进一步的分类 ，比如产品分类、协议分类、事件分类 ，数据设计人员有了随意发挥的空间。 l 有些标准术语/数据项甚至没有定义 ，标准维护人员在没有准确了解现存标准的情况下不断新增标准术语与数据项 ，导致不断膨胀。 l 属性名称只落标中文名 ，虽然建立了词根中英文名称对照 ，但是没有通过工具强制执行 ，造成物理名称与逻辑名称的不一致。在物理建表时 ，即使提供了字段的中文说明 ，但Hive不支持将字段中文注释显示为查询结果的标题 ，这种情况下的落标没有起到作用。 l 客户名称的技术属性标准 ，如定义为VARCHAR（80） ，标准的解释为只要长度不超过80位即是合标的 ，但是如果某些业务系统的定义没有遵循标准 ，在数据仓落标时常常被截断。对于这些关键属性 ，严谨的标准还应该限制最小长度 ，以确保数据质量。 l 没有管理代码类数据项的枚举值 ，或数据项的码值没有经过严谨设计 ，仅是简单的罗列 ，如设计了生命周期状态数据项 ，用于各数据主题域相关实体的生命周期的状态 ，包含数千个码值 ，中文名称为“正常”的码值超过20多个 ，从而失去了使用价值。 数据标准应该是严谨的 ，标准应少而精 ，易于理解掌握 ，逐步推进工作。把实施宽泛的大而全的数据标准作为数据治理的切入点或启动项目不是一个有效的选择。数据标准所能表达的意义有限 ，数据标准仅是衡量数据质量的参考依据之一 ，并不能代替数据架构来管理数据。 06 及时解决数据质量问题 任何组织的数据都可能存在质量问题 ，包含大量冗余与垃圾数据。数据质量问题一经发现 ，应找到问题的根本原因及早解决 ，因为分析问题与解决问题都要付出成本 ，质量分析人员每天都需要分析质量问题 ，需要占用资源 ，成本随着拖延的时间不断增加。 尽量在上游解决数据质量问题 ，避免问题发散。因为同一个问题从源头被传到数据湖与数据仓库 ，再进一步传导到各个下游应用 ，相关人员都需要重复分析与解决问题 ，代价指数级增长 ，解决方案也可能不同 ，最终用户看到的可能不一致。 数据质量问题内涵复杂 ，涉及跨部门、跨专业合作 ，对于数据质量问题的识别与处理往往依赖于质量分析人员的能力与组织执行力 ，应把质量问题的产生、解决时间与成本价值联系起来 ，建立数据质量问题认责与考核机制 ，避免扯皮推卸责任现象。对于已经积累多年的陈年旧债 ，要分析分类 ，从架构出发 ，解决根本问题。 一些组织的治理和信息资产项目由合规性驱动 ，是被动型项目 ，而不是由数据作为资产所衍生的潜在价值驱动。由于各种历史原因 ，各企业的数据管理存在很大的提升空间 ，基于成本收益基准 ，从优化现有的数据及数据管理生态开始 ，不懈地关注架构、标准、质量和流程等 ，打好数据价值基础。
