编者按：
随着数字化转型、数据要素市场化、高质量发展等宏观导向，数据价值愈发得到重视。从最基础的数据架构到上层的数据应用，无论是金融机构还是金融科技厂商，都有着各自的理解与实践。长亮科技在大数据领域始终保持足够的技术敏锐度，将以本篇关于“数据架构”的探讨为始，后续推出系列文章，与您一起探索更适合当下行业发展的数据观，欢迎大家持续关注。
作者｜长亮科技大数据研究院
内容｜本篇共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，放任数据的膨胀。
数据管理与治理没有建立在企业数据架构基础之上
有些企业数据架构的管理不包括数据模型，仅限于数据分析平台（数据仓库或数据中台）的分布流转，数据集成仅限于从数据采集开始到数据应用。
在数据模型设计与数据集成过程中，忽视了企业数据分布（应用架构）的输入，可能导致所用数据并非权威数据源，甚至可能使用了错误的数据，无法保证数据质量。
数据治理体系化与深度有待提升
有些企业数据的治理停留在建章立制方面，有些企业建立了数据标准但没有落地，意识到“同义不同名、同名不同义”，要统一术语概念，但没有上升到数据架构体系层面，很难取得实质性进展。
许多企业花大力气打通数据应用“最后一公里”，而不关注数据生产“最前十公里”。如果忽视数据问题产生的源头，事倍功半，最后一公里的应用很难有高质量的数据基础。
强调可用性，质量被忽略
有些金融企业在引入互联网解决方案时忽视了行业差异，为了提高可用性，不断提高数据不一致性等质量问题容错率。互联网行业许多业务场景对数据质量的要求不高，从统计角度只要满足一定程度的相似性。而金融行业财务报表、合规监管等需求对数据质量的要求远高于互联网行业。
应该怎么做：
以企业级的架构视角来管理与使用数据
许多企业有数据，无数据架构。数据架构处于无感的被动地位，技术选型后才谈数据架构，应用系统不考虑数据架构基本要求。当技术平台穷于应付，不能给客户带来好的体验时，不从数据架构、应用架构方面进行反思。
架构设计的本质是企业级顶层视角与体系化设计
清晰理解企业数据架构的本质，无论是数据治理或数据资产管理，还是数据仓库、数据中台或数字化转型，都应该站在企业级顶层视角，进行架构层面的体系化设计。
数据生命周期每个阶段的生产者、加工者都应该对自己设计的数据产品负责，对自己的用户负责。设计者的眼光不但要向前看，还要注意到左右的应用架构与技术架构，还要向后看，认识到自己的设计工作是非常重要的环节。
稳定的架构来自抽象思维
架构应该是稳定的。解决“同义不同名、同名不同义”的问题只是数据架构管理万里长征的第一步。即使数据模型的设计遵循数据标准，仍解决不了本质问题，只有采用抽象的思维，剥离数据的噪声，抽象出业务的本体，才能产生稳定的框架，并以结构化、体系化来表达或展现。
与数据治理协同
数据治理是数据架构的另一关键环境因素。数据架构的目标最终需要通过与数据治理的协调一致才能实现，数据架构负责正确地做事，数据治理确保（按照数据架构）做正确的事。
把企业数据模型作为数据治理工作的产出物
从建立企业概念数据模型入手，让各干系人认识到企业数据模型的重要性，在数据建模中体系化治理数据，在数据治理中逐步完善形成企业数据模型，指导数据在企业各系统的分布与集成，支持应用系统的数据重用与敏捷开发。
管理数据资产的全生命周期
建立数据即资产的数据资产观，在日常工作中建立成本与收益意识，从数据的产生开始管理，使数据的设计者、生产者、加工者与管理者都认识到在数据的全生命周期中都投入了成本，优化数据管理生态，实现企业级的数据集成，驱动数据资产价值的最大化。
建立数据分析生态体系
结构化与非结构化数据有不同的价值密度，需要不同的处理技术与流程。数据不同的生命周期，价值密度也不一样。需要建立完善的数据分析生态体系 ，有效管理各种不同形态、不同生命周期的数据，为不同用户提供高质量的数据以及友好的体验。
结语
企业数据的管理是一项持续的工作，不可能毕其功于一役。业务在发展变化中，数据架构也要同步更新。许多企业实施数据中台并没有带来数据管理能力的提升，也没能给用户提供高质量的数据，如果不站在企业的架构视角，数据治理与数据架构脱钩，各行其是，再换个马甲也无用。
