编者按：
随着数字化转型、数据要素市场化、高质量发展等宏观导向 ，数据价值愈发得到重视。从最基础的数据架构到上层的数据应用 ，无论是金融机构还是金融科技厂商 ，都有着各自的理解与实践。K8凯发科技在大数据领域始终保持足够的技术敏锐度 ，将以本篇关于“数据架构”的探讨为始 ，后续推出系列文章 ，与您一起探索更适合当下行业发展的数据观 ，欢迎大家持续关注。
作者｜K8凯发科技大数据研究院
内容｜本篇共3170字 ，预计阅读时间10分钟
很久以来 ，数据架构一词的影响一直局限于很狭小的专业领域范围之内 ，国内的数据治理工作基本都围绕着数据标准开展。2021年2月9日人民银行发布《金融业数据能力建设指引》 ，对数据架构的认识正式提升到了行业高度 ，而把数据标准改为数据规范 ，也算是各归其位了。
数据架构是什么
按照ISO/IEC/IEEE 42010:2011的架构定义：系统的基本组织 ，体现在其组件、它们之间的关系和环境 ，以及管理其设计和演变的原则。
架构一词来源于建筑行业。如果说杜甫当年盖茅屋不需要设计 ，那么建造现代广厦不可能没有设计图就开工了。
管理数据也需要架构。数据架构定义管理数据资产的蓝图 ，描述应该如何组织与管理数据 ，内容包括数据模型、数据定义、数据映射规范、数据流、结构化数据应用接口规范（DAMA DMBOK2）。数据架构需要持续动态地维护 ，并不比建筑架构设计简单。
国家标准GB/T36073—2018《DCMM数据管理能力成熟度评估模型》关于数据架构的描述为：通过组织级数据模型定义数据需求 ，指导对数据资产的分布控制和整合 ，部署数据的共享和应用环境 ，以及元数据管理的规范。
那么如何解读数据架构 ？有哪些组件 ？组件之间的关系是什么 ？与哪些环境有关系 ？
数据架构有哪些组件
企业数据架构设计包括企业数据模型设计以及数据流设计（DAMA DMBOK2） ，这也是数据架构比较经典的内容。从零开始设计企业数据架构需要很长的时间、很大的资金投入 ，并存在潜在的失败风险。在企业数据架构实践中 ，业界已有一些成熟的行业数据模型可以参考 ， 因此 ，一般情况下 ，最详细的数据架构设计文件是一个正式的企业数据模型。物理数据模型也是数据架构文件 ，但物理数据模型是数据建模和设计的产物 ，而不是数据架构。
DCMM的数据架构能力域包括数据模型、数据分布、元数据管理、数据集成与共享能力项 ，DCMM把在DAMA数据管理知识体系中独立的元数据管理、数据集成两个领域也包含进去了。DCMM标准已被广泛认可 ，一些领先的机构获得了数据管理能力成熟度四级或五级认证。
如何理解DCMM定义的数据架构组件关系
数据架构的核心组件是数据模型 ，指导数据分布与数据集成。
数据分布也是数据集成的必要输入。为提升数据集成与交互的效率 ，数据集成反过来对数据分布提出要求。
企业的数据模型、数据分布以及数据集成的设计文档都是元数据 ，如果没有这些元数据 ，组件之间的关系无法展现 ，用户就无法使用数据。
数据架构与应用架构、技术架构的关系
数据架构不能独立存在 ，站在企业架构的高度 ，与企业应用架构、技术架构有紧密的环境关系。
应用架构是数据架构的输入。数据的分布是数据在业务应用与数据应用系统中的分布 ，这些系统的业务功能决定了将产生哪些数据以及需要哪些数据 ，因此 ，应用架构设计决定了数据的分布 ，指导数据架构中数据定义、数据集成与交互等规划和管控工作。数据架构设计对应用架构的输入不应照单全收 ，应用系统中的数据模型设计应遵循企业数据架构 ，数据分布与集成的原则要求影响应用系统的功能分布。
数据架构是技术架构的输入。数据的集成交互与存储规划的需求是对技术架构提出的要求。技术架构是数据架构的落实基础支撑 ，基于可靠性、性能·、实施的复杂性、成本等考虑的数据库软件、数据存储等技术选型可能反过来制约应用架构与数据架构。
数据管理领域的反思
自金标委成立三十多年以来 ，在推动金融数据标准化方面取得了巨大成就 ，金融行业的数据管理水平一直处于领先地位；毓耸莨芾砹煊蚓咛迨导 ，仍有一些问题值得反思。
数据架构管理简单粗放
因为有便宜的存储设备可以选择 ，过度强调应采尽采（甚至有些企业主张实时采集全域数据 ，数据采集无差别“大而全” ） ，过度强调非结构化数据的价值 ，没有对数据进行精细化区别管理 ，没考虑过其中大部分数据可能没有任何价值 ，没有考虑TCO与ROI ，放任数据的膨胀。
数据管理与治理没有建立在企业数据架构基础之上
有些企业数据架构的管理不包括数据模型 ，仅限于数据分析平台（数据仓库或数据中台）的分布流转 ，数据集成仅限于从数据采集开始到数据应用。
在数据模型设计与数据集成过程中 ，忽视了企业数据分布（应用架构）的输入 ，可能导致所用数据并非权威数据源 ，甚至可能使用了错误的数据 ，无法保证数据质量。
数据治理体系化与深度有待提升
有些企业数据的治理停留在建章立制方面 ，有些企业建立了数据标准但没有落地 ，意识到“同义不同名、同名不同义” ，要统一术语概念 ，但没有上升到数据架构体系层面 ，很难取得实质性进展。
许多企业花大力气打通数据应用“最后一公里” ，而不关注数据生产“最前十公里”。如果忽视数据问题产生的源头 ，事倍功半 ，最后一公里的应用很难有高质量的数据基础。
强调可用性 ，质量被忽略
有些金融企业在引入互联网解决方案时忽视了行业差异 ，为了提高可用性 ，不断提高数据不一致性等质量问题容错率；チ幸敌矶嘁滴癯【岸允葜柿康囊蟛桓 ，从统计角度只要满足一定程度的相似性。而金融行业财务报表、合规监管等需求对数据质量的要求远高于互联网行业。
应该怎么做：
以企业级的架构视角来管理与使用数据
许多企业有数据 ，无数据架构。数据架构处于无感的被动地位 ，技术选型后才谈数据架构 ，应用系统不考虑数据架构基本要求。当技术平台穷于应付 ，不能给客户带来好的体验时 ，不从数据架构、应用架构方面进行反思。
架构设计的本质是企业级顶层视角与体系化设计
清晰理解企业数据架构的本质 ，无论是数据治理或数据资产管理 ，还是数据仓库、数据中台或数字化转型 ，都应该站在企业级顶层视角 ，进行架构层面的体系化设计。
数据生命周期每个阶段的生产者、加工者都应该对自己设计的数据产品负责 ，对自己的用户负责。设计者的眼光不但要向前看 ，还要注意到左右的应用架构与技术架构 ，还要向后看 ，认识到自己的设计工作是非常重要的环节。
稳定的架构来自抽象思维
架构应该是稳定的。解决“同义不同名、同名不同义”的问题只是数据架构管理万里长征的第一步。即使数据模型的设计遵循数据标准 ，仍解决不了本质问题 ，只有采用抽象的思维 ，剥离数据的噪声 ，抽象出业务的本体 ，才能产生稳定的框架 ，并以结构化、体系化来表达或展现。
与数据治理协同
数据治理是数据架构的另一关键环境因素。数据架构的目标最终需要通过与数据治理的协调一致才能实现 ，数据架构负责正确地做事 ，数据治理确保（按照数据架构）做正确的事。
把企业数据模型作为数据治理工作的产出物
从建立企业概念数据模型入手 ，让各干系人认识到企业数据模型的重要性 ，在数据建模中体系化治理数据 ，在数据治理中逐步完善形成企业数据模型 ，指导数据在企业各系统的分布与集成 ，支持应用系统的数据重用与敏捷开发。
管理数据资产的全生命周期
建立数据即资产的数据资产观 ，在日常工作中建立成本与收益意识 ，从数据的产生开始管理 ，使数据的设计者、生产者、加工者与管理者都认识到在数据的全生命周期中都投入了成本 ，优化数据管理生态 ，实现企业级的数据集成 ，驱动数据资产价值的最大化。
建立数据分析生态体系
结构化与非结构化数据有不同的价值密度 ，需要不同的处理技术与流程。数据不同的生命周期 ，价值密度也不一样。需要建立完善的数据分析生态体系 ，有效管理各种不同形态、不同生命周期的数据 ，为不同用户提供高质量的数据以及友好的体验。
结语
企业数据的管理是一项持续的工作 ，不可能毕其功于一役。业务在发展变化中 ，数据架构也要同步更新。许多企业实施数据中台并没有带来数据管理能力的提升 ，也没能给用户提供高质量的数据 ，如果不站在企业的架构视角 ，数据治理与数据架构脱钩 ，各行其是 ，再换个马甲也无用。
