数据架构杂谈

数据架构杂谈
（来源：毕马威大数据挖掘微信公众号，2017-09-30）
我们通常所说的“数据架构”与“应用架构”和“技术架构”并列，三者共同组成IT架构。

IT架构由业务架构驱动，从业务架构出发分析业务流程、定义数据架构，流程和数据结合定义应用架构，根据数据架构和应用架构设计技术架构。

值得注意的是：业务架构和应用架构均包含数据架构的内容，业务架构中数据架构即数据概念模型，分析重点是数据领域、主数据和核心业务对象。

业务运营的两条重要线索是流程和数据，业务流程离不开数据流转，业务运营状况通过数据反映，基于业务架构的端到端流程建模过程中会衍生出对应的业务数据对象，需要与数据架构的数据模型对接。

流程模型和数据模型对接后落实到应用（系统）层面，就形成了应用架构。

应用架构将业务对象转换为数据对象或具体的数据库表对象，数据模型进一步转换到具体应用（系统）的逻辑模型和
物理模型，在此基础上分析数据对象和应用（系统）功能之间的创建、引用、修改或删除CRUD关系，以明确功能边界划分，对应数据架构中最终的数据分布。

可以将数据架构简单分解为数据分布、数据模型、数据标准和数据治理。

数据架构为数据资产的管理和应用奠定基础，支撑数据的存储、访问、整合和分析，包含相对静态部分如元数据、业务对象数据模型、主数据、共享数据，也包含相对动态部分如数据流转、ETL、整合、访问应用和数据全生命周期管控治理。

数据是企业的关键业务资产，通过有效的组织、存储、分发和管理实现在不同业务条线之间的共享。

狭义的数据架构可以用来特指数据分布，包括数据业务分布与数据应用（系统）分布。

数据业务分布指数据在业务各环节的CRUD关系，数据应用（系统）分布指单一应用（系统）中数据架构与应用（系统）各功能模块间的引用关系，以及数据在多个应用（系统）间的引用关系，数据业务分布是数据应用（系统）分布的基础和驱动。

数据架构层面通过数据分类、分层部署等手段，从非功能性视角将数据合理布局。

通过整体架构管控和设计，支持业务操作类和管理分析类应用（系统），满足业务发展及IT转型对数据的需求，架构的扩展性和适应性能够提升数据分析应用的及时性、灵活性和准确性。

最简洁的分类方法可将数据分为基础数据和衍生数据，基础数据一般为业务操作过程中采集和加工的数据。

衍生数据将业务基础数据按照不同维度加工计算，形成统计指标供管理分析使用。

可以按照数据的生命周期、功能及其流转范围进一步把基础数据分为4类，并在此基础上进行分布设计：
参数数据：保证应用（系统）运行的控制信息，包括业务类控制信息如国家、行政区划、币种、利率等，也包括技术类
控制信息如时间阀值、流量阀值、页面配置等
•业务结果数据：记录业务活动最终结果的信息，是企事业实体关注的核心数据。

如客户、员工、渠道等数据，常需流转
到另外一个应用（系统）
•业务过程数据：某单个工作任务流为完成其功能所需要的中间过程信息，该信息不需要传输到另外一个工作任务处理，
即不需要跨任务处理的过程数据，常在单个应用（系统）内
部
•操作痕迹数据：记录操作人员对应用（系统）进行操作的信息。

包括业务操作痕迹数据如授权记录、业务操作记录等，
和技术痕迹数据如系统日志等。

该类数据在操作人员实际操
作过程中产生，常用于风险控制、内部审计和行为分析。

通常可以认为基础数据主要分布于操作型业务应用（系统）中，衍生数据/指标主要分布于数据仓库、数据集市和管理分析应用（系统）中。

现实业务场景中某些业务流程与管理相关，也需要基于大量的衍生数据/指标进行后续业务操作，典型的如客户关系管理系统CRM 基于客户粒度加工衍生数据再进行业务操作，由此可将其拆解为分析型ACRM和操作型OCRM，基于数据架构决策中计算与访问分离的优化思路，业界领先实践将分析加工计算部分剥离到数据集市，操作型应用（系统）读取访问已加工衍生数据进行后续业务操作。

对于拥有众多分支机构的大型企事业单位或者横跨多行业的大型企业集团，数据物理存放的集中和分散是数据分布设计中的重要内容。

从地域角度看，数据分布有数据集中存放和数据分布存放两种模式。

数据集中存放是指数据集中存放于总部数据中心，其分支机构或下属子公司不放置和维护数据，数据分布式存放是指数据分布存放于总部、分支机构或下属子公司，分支机构或下属子公司需要维护管理
自己的数据。

这两种数据分布模式各有其优缺点，需要综合考虑自身需求，确定具体数据分布策略。

一般的数据分布常采用操作型业务系统数据库DB+操作型数据存储库ODS（+数据仓库DW）+数据集市DM的方式。

业界领先实践考虑结合面向服务架构SOA、商业智能BI技术和数据虚拟化技术，利用数据整合平台将数据仓库中的数据转变为被其他应用（系统）所访问的数据服务，为那些需要满足BI需求、访问数据仓库数据的应用（系统）提供访问路径。

关于数据仓库，可参考我司资深专家结合数据分析挖掘的讨论《如何利用数据仓库优化数据分析？》和《一个数据仓库转型者眼中的数据挖掘》；关于数据集市，则可参考我司资深专家构建示例《如何从基础构建银行信用风险数据集市？》。

数据架构层面的管控包括数据架构原则、设计指南和数据规范，用以指导数据架构规划和数据模型设计，支撑数据架构决策。

具体应用（系统）设计时需遵守数据方面的要求和规范，以保障数据架构原则的落地实施。

基于数据分布的应用设计主要通过数据架构视图，从功能方面整体规划布局数据类应用及数据整合关系。

数据规范包括业务规范和技术规范，指导应用的设计开发和实施。

架构决策是在众多可行的方案中选择较优的方案，对实施中存在的问题进行决策。

数据模型包括概念模型、逻辑模型和物理模型。

数据模型设计要充分考虑性能、可用性和可维护性等，与业务流程模型对接，形成面向操作型应用的基础数据模型，与管理分析需求对接，形成面向分析型应用的统计数据模型。

定义良好的数据模型可以反映业务模式的本质，确保数据架构为业务需求提供全面、一致、完整的高质量数据，且为划分应用系统边界，明确数据引用关系，定义应用系统间的集成接口，提供分析依据。

良好的数据建模与数据标准的制定是实现数据共享，保证一致性、完整性与准确性，提高数据质量的基础。

关于数
据模型和数据质量，可参考我司资深专家文章《数据模型——数据仓库的灵魂》和《如何提高数据质量？》。

数据标准可作为数据在不同业务领域流转应遵循的标准，相关概念可参考我司高层专家的文章《聊聊有关数据的一些基本概念和常见误区（上）》和《聊聊有关数据的一些基本概念和常见误区（下）》。

数据治理指的是在数据全生命周期进行管控和治理，可划分两个层面的数据生命周期，一个是单业务对象数据生命周期，一般在应用（系统）内部，或与流程建模中的单个工作流相关；一个是跨多个业务对象的数据生命周期，可能跨越多个应用（系统），体现的是多个业务对象数据之间的转换和映射，往往是和端到端的业务流程相关。

数据治理顶层设计、管控流程机制以及措施和手段可参考我司高层专家的文章《从抗日武装的发展谈到数据治理》。

大数据时代，数据湖Data Lake的理念指出，数据可以无需加工整合，直接堆积在平台上，由最终使用者按照自己的需要进行数据处理。

而传统数据仓库建设强调的是整合、面向主题、分层次等思路。

数据湖建设思路对传统数据架构形成了重大挑战，同时也涉及应用模式等多方面的问题。

概念提出者James Dixon比喻“如果把数据集市看做一瓶饮用水，数据湖则是未经处理和包装的原生状态水库。

不同源头的水体源源不断流入数据湖，带来各种分析、探索的可能性。

”未知结构堆积数据再应用的方式为Schema On Read，即在数据访问时，由数据使用者来解析和确定数据的格式，按需进行数据探索和处理，原始数据写入者不关心其是否有一致、统一的数据格式，不预设表结构以接入数据（对应Schema On Write）。

这就对最终使用者的经验和能力提出了很高的要求。

数据湖理念的优势在于：
✎降低数据保存的成本，无需建模定义数据结构即可保存
✎降低数据产生和使用之间的延迟
✎给予最终用户最大的灵活度来处理数据，不同用户可能有不同理解
✎允许用户保存非结构化、半结构化的数据
✎对于现在不需要处理或者无法处理的数据，保留原始数据供未来使用
数据湖理念的劣势在于：
✎用户在使用时，不得不先花时间去解析数据的格式，不同用户多次解析数据造成计算资源浪费
✎有些数据如果不在写入的时候遵循一定的格式，在使用时不一定能够解析其格式，若解析错误，使用数据的结果将与其预期南辕北辙
数据湖理念契合机器学习和人工智能的发展趋势，具备广阔的应用前景。

数据架构规划需要应对数据湖理念带来的挑战。

参考文献：
张新宇《大数据时代的数据架构设计》，《中国金融电脑》2015.8 《数据架构是IT架构的核心》/ea/84980.html
人月神话《再谈数据架构》/s/blog_493a84550101gvrg.html Martin James 《战略数据规划方法学》，北京：清华大学出版社1994。