数据架构概述

什么是数据？

一个企业的数字化核心是数据，数据化的价值依赖于数据的标准和质量，数据对一个企业来说至关重要，它也是整个信息化建设及企业架构的核心。数据具有多样性，有结构化的、非结构化的，与业务相关的、与系统相关的，企业内部的、企业外部的等。

从数据的价值来看，可分为数据本身的和由数据分析产生的。数据本身并没有太多价值，重要的是数据进一步带给我们什么。我们可以从数据中提炼出信息，总结出知识，并可以进一步通过技术来更智能地分析这些数据的深层次价值。这需要数据思维，一种重视事实、追求数据本质的思维模式。

什么是数据架构

数据架构作为企业架构的重要组成部分，是连接业务架构与应用架构的纽带，是企业架构的核心，主要描述企业架构的数据模型、数据分布、数据资产之间的结构和关系。

数据架构涉及数据模型，相关的实体、属性、关系等，以及相关的数据分布和治理。

数据架构的目的:

• 建立一个标准、统一、通用、共享的公共数据平台
  • 既能够满足业务处理需要
  • 也能够为上层应用提供一个共享、开放的数据访问环境，
• 在此基础上充分分析和挖掘数据的价值，有效地支撑企业数据经营决策

从企业架构的视角来看，数据架构扮演着重要的作用。

比如，在Zachman企业架构理论框架:

• 第一列是数据
  • 第二行是概念数据模型
  • 第三行是逻辑数据模型
  • 第四行是物理数据模型
  • 第五行是数据库定义

图例：数据架构在企业架构中的位置

从上图可以看出，数据架构需要对接整个企业架构的数据要求，对应业务架构中业务能力、业务流程、业务活动的数据支撑，以及对应应用架构中领域模型、领域服务和应用功能的数据映射，同时通过技术架构的数据存储、数据库、云原生等技术能力进行数据存储。

数据架构将领域模型和相应的服务抽象映射到对应的数据模型，并对数据模型中数据项、数据项中的属性、数据项之间的关系进行清晰的定义，构建数据项与应用系统之间的关系，从而实现从业务、应用到数据之间的平稳过渡和紧密关联。

数据架构需要基于业务架构、应用架构和技术架构，保持数据的完整性和一致性。同时，数据架构需要考虑相关的数据技术。

数据架构的价值

数据架构的价值主要体现在以下几个方面。

1.数据架构可以有效地支持企业战略目标和业务架构的落地，发掘企业对数据的诉求。

2.数据架构设计会使业务流程应用系统变得更加流畅，更加易于理解和维护。

3.数据架构描述企业核心的数据资产，进行数据的沉淀。

4.提供数字化转型系统在数字层面的参考，提供相关原则和规范。

5.通过数据思维，为企业各方面利益干系人提供数据管理方法。

6.提供标准、一致、通用、共享的公共数据平台，为不同业务和应用提供友好的共享数据访问能力。

数据架构的设计框架

数据架构注重从总体上规划企业的数据资源，比如数据架构规划、数据架构设计方法、数据架构设计步骤、数据架构技术及数据架构原则和规范。

图例：数据架构的设计框架

数据架构规划：对企业数据资产进行梳理，形成数据资产目录，同时对业务流程和领域模型等进行数据映射，通过顶层的数据分层规划，实现与其他架构的松耦合和数据共享、复用。

数据架构设计方法：包含数据模型、数据分布和数据治理，构建统一的数据体系。

数据架构设计步骤：进行具体、可实操的数据准备、数据采集、数据建模、数据处理及数据分析，并且应按步骤进行。

数据存储技术：包含数据存储的相关技术选型，比如数据库、存储、云原生数据库、相关产品工具等，本质上属于技术架构体系，由于与数据架构紧密相关，因此也放在数据架构的设计框架中。

数据架构原则和规范：比如存储选择、数据库设计、数据开发治理规范、参考行业模型等，提供指导和约束。

数据架构规划

数据架构规划是从企业整体角度出发，基于战略目标、业务架构及应用架构的规划输入，进行数据架构规划的过程。

数据架构规划主要包括数据资产目录和数据分层两部分。

数据资产目录

通过对企业各部门及各业务的数据资产的梳理，初步构建企业的数据资产目录，对数据进行分类和定义，建立数据模型，在数据资产目录的梳理过程中，可以结合业务活动及领域模型，构建出基于数据的主题域。其中包括：

形成数据资产目录雏形。

数据分层

我们可以进一步根据企业的特点，对数据资产进行分层，合理的分层对于数据架构十分重要。一些常见的数据分层思路如下所示。

结构化数据与非结构化数据。结构化数据是有固定格式和有限长度的数据，是企业应用系统管理的核心数据资源，一般由数据库来管理；非结构化数据是不定长、无固定格式的数据，比如企业管理的制度规范、技术文档等，一般OA或者知识管理类系统，以及半结构化数据，如CSV、日志、XML、JSON等格式的数据。

企业级数据与应用系统级数据。从数据建模角度看，企业级数据主要作为企业的数据标准，包括概念数据模型和逻辑数据模型两大类，定义核心业务实体、实体之间的关联关系、相关的业务规则；应用系统级数据是在某些应用或系统中相对具体的数据。

元数据和过程数据。元数据又称主数据，是企业业务中相对静态、不变的实体信息描述，是业务运行所必需的关键信息；过程数据通常指的是在业务流程中产生的记录业务变化的数据，进一步还可以分为OLTP（在线交易类型，如交易订单状态）和OLAP（在线分析类型，如用户购买行为的分析）等类型。

下面我们来看看一些常用的数据分层参考。

从数据处理过程角度进行分层

从数据的处理过程角度，可以分为不同的层次。

数据采集层：把数据从各种数据源中采集和存储到数据存储器上，过程中涉及转移、交换、选择、过滤和清洗等手段，包括数据分片、路由、结果集处理、数据同步等。

存储分析层：包括OLAP、OLTP、实时计算、离线计算、大数据平台、数据仓库、数据集成、数据挖掘、流计算，涉及结构化数据存储、非结构化数据存储、大数据存储等。

数据共享层：涉及数据共享、数据传输、数据交换、数据集成等。

数据应用层：涉及应用系统、产品功能、领域模型、实时查询、数据接口等。

从云计算角度进行分层

从云计算的微服务角度，数据可以分为IaaS、PaaS、SaaS等类型。

IaaS：提供基础设施服务能力，比如数据库、存储、网络、物理硬件等，更加考虑成本性能、稳定性、易维护性、准确性等。

PaaS：提供基础应用平台，比如数据一致性事务框架，微服务调度管理、消息收发，以及共享服务的能力提供，更加考虑稳定性、通用性、完整性等。

SaaS：负责对外部提供业务服务，比如基于共享服务的编排组合，对外API透出，更加考虑用户角度的灵活性、易用性、适用性等。

数据架构设计方法

数据架构的目的是将企业的数据资产进行有序管理，从而充分发挥数据的价值。在实践中，数据架构需要做好三个方面的工作，即数据模型、数据分布和数据治理。

数据模型

数据模型是描述数据与数据之间关系的模型，包括数据概念模型、数据逻辑模型、数据物理模型。数据模型需要遵循数据标准，数据标准包括元数据标准和对应的数据模型标准。其中，定义良好的元数据和数据模型是实现数据共享、一致性、完整性与准确性的基础。

元数据定义

元数据是描述数据的数据，描述数据之间的定义和属性，比如数据库的元数据有表、列、行、字段等，定义企业最重要的内部基础数据类型。

元数据可以帮助我们定义数据的模型标准，包括业务元数据、技术元数据、管理元数据等。

元数据管理是为了厘清元数据之间的关系，元数据管理可以进一步分为对元数据的获取、存储、维护、分析、质量管理等。

元数据在业界有很多研究，比如FEAF中就对元数据的参考模型给出了定义，同时在低代码领域，基于元数据的编程也是非常重要的话题。

这里我们先看看FEAF中对元数据定义的一种标准参考，其将元数据分为三个标准领域。

数据描述（Data Description）：对数据的统一描述，支持数据的发现和共享；核心的元数据包括实体、关系、属性、数据类型、数据资产等。

数据上下文（Data Context）：对数据进行归类，便于数据的发现，支撑数据资产定义；核心的元数据包括主题、数据资产、分类法、数据资源等。

数据共享（Data Sharing）：支持数据的访问和交换；核心的元数据包括提供者、使用者、交换包、数据定义等。

数据模型定义

数据模型是数据架构的核心，针对组织、人员、客户、供应商、财务等元数据确定业务定义和规则、编码规范、数据类型、数据格式，保证最重要的数据准确、完整和一致。企业应集中进行数据的清洗，并以服务方式把元数据传送给对应的应用系统。数据模型可以通过E-R实体关系图来进行建模，实现对数据及其关系的表述，可以指导IT的开发，是从应用架构的领域模型到系统数据层面转化的基础。

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

概念数据模型：根据实体及实体之间的关系，从宏观角度分析和设计的企业的核心数据结构。

逻辑数据模型：根据逻辑数据实体及实体之间的关系，准确描述业务规则和领域模型的逻辑关系，定义相应的数据来源及相关维度关联。

物理数据模型：按照一定规则和方法，将逻辑数据模型中定义的逻辑数据实体、属性、属性约束、关系等内容，转换为数据库可识别的实体关系。

数据模型在定义过程中要注意以下几点。

数据模型与领域模型有对应关系，但并不是一一对应的。数据模型主要从数据的角度出发。

数据实体不能脱离业务或者应用独立存在，特别是概念数据模型和逻辑数据模型。

数据实体设计尽量遵循第三范式。每个数据实体的属性不要重复定义，不应包含其他数据实体中的非关键字类型的属性，特殊场景除外。

多层数据要进行一体化设计，元数据管理和数据模型管理融合，数据同时需要不断地持续迭代。

数据分布

数据在业务应用的数据流全景视图中，重点关注数据的分布关系，比如典型的数据源分布、信息流、数据流，以及业务流程和应用能力是如何通过数据进行联动的。

一方面，企业需要分析数据对应的业务，即分析数据在业务各环节的创建、引用、修改和删除的关系

另一方面，企业需要关注数据在单一应用中的数据结构与各功能模块之间的引用关系。

在数据分布中，一个比较重要的话题是数据存储。企业数据有不同的类型，需要不同的数据存储、一致性事务要求、数据库查询操作能力等。

比如，结构化数据采用关系型数据，非结构化数据采用NoSQL类型，同时还有文档类型、图数据库、列式数据库、分析型数据库、搜索引擎数据库、时序数据库等多种类型，同时随着云原生的兴起，云原生数据库也是一种趋势。

数据治理

数据治理是IT架构治理的组成部分，承担着明确数据治理主题和责任机制、建立数据治理标准，并通过管理制度和流程控制加强对数据生命周期全过程管理的职责。数据治理主要包括以下几个方面。

数据标准管理

建立一套符合自身实际，涵盖数据定义、业务操作、应用功能多层次数据的标准化体系。数据标准可以分为以下三类。

基础类数据标准：在日常业务开展过程中产生的具有共同业务特性的标准。

指标类数据标准：满足内部管理及外部监管的要求，在基础数据基础上按统计、分析规则加工后的可定量化的数据标准。

专有类数据标准：在细分业务经营及管理分析中涉及的特有数据。

一个结构化且全面的数据管理方法可以促进对数据的有效使用，过程中需要关注元数据及相关的应用组件是否被清楚地定义，重要的业务活动和应用组件是否都构建了数据标准，应用之间信息交换和数据转化的复杂程度是否可以覆盖等。 此外，标准需要涵盖对质量的管理，具体包括以下几个方面。

准确性：在接入、转换、分析、存储、传输、应用流程中不存在错误。

完整性：数据库应用或所有记录、字段都完整存在。

一致性：在整个数据库的定义和维护方面，确保数据在整个过程中是一致的。

时效性：数据与真实业务应用同步在时间容忍度（数据的更新频度）内。

可靠性：提供数据的数据源必须可靠、稳定。

数据生命周期

数据需要考虑完整的生命周期，并根据相应的标准规划进行细化，相关的生命周期需要重点考虑以下阶段。

数据生成及传输阶段：按照标准生成数据，保证数据的准确性和完整性。数据传输过程中要考虑保密性和合规性，防止数据泄露或被篡改。

数据存储阶段：关注保密性、完整性、可用性和一致性，操作要由数据的Owner（所有者）部门来执行。

数据处理和应用阶段：分析、处理数据，以挖掘有价值的信息，保证数据的安全，只输出分析后的结果。

数据迁移阶段：制订合理的迁移计划，提供有关数据转换和清洗等方面的指标，同时需要考虑新系统上线的数据割接应急方案。

数据销毁阶段：主要涉及数据的保密性，此过程需要采用必要的工具，要有完整的记录。

数据服务管理

数据服务是为了更准确地向边界提供数据访问和分析能力，从而用企业内部多年的数据沉淀反哺应用业务系统。 这需要企业对数据进行深度加工，包括通过各种报表、工具来分析数据，通过建立统一的数据服务平台来满足跨部门的数据流转，提高处理效率。

在此过程中，企业需要重点关注数据对外呈现的接口规范，比如数据统计维度的规范、数据展示统一框架、数据发布与共享模式等。这种数据接入方式可以防止数据重复录入和冲突，并且通过数据同步、数据维护、备份恢复、数据上传方式的机制保证了数据的准确性和可靠性，同时提供访问控制策略和数据共享策略，对数据与外部系统的交换进行规范和控制。

数据安全管理

数据安全至关重要，进行数据安全管理可以保障企业的核心数据资产不被泄漏。 企业在进行数据安全管理时需要关注以下方面：

数据使用的安全性，比如数据访问的操作权限，应用通知权限、数据水印、数据印章等；

数据隐私问题，比如敏感信息的脱敏

数据操作入口统一，比如单点登录

数据安全合规，比如数据审计、数据合规

建立安全管理制度，比如数据安全管理规范、隐私管理办法、管理决策审计

......

数据架构设计步骤

数据架构的设计是一个持续迭代、优化的过程，设计步骤如图所示。

数据准备

准备阶段聚焦在企业的数据输入，比如数据架构规划、数据资产目录、业务架构与应用架构输入，以及业务数据层面的需求，并确定相应的数据流程；

聚焦于数据流向，需要梳理数据全景图。

此外，数据准备阶段需要确定核心的数据有哪些维度，对应的数据管理者、生产者和使用者，与数据相关的业务和应用边界。

同时，通过数据标准，明确数据层面的数据标准，比如数据接入和生命周期管理规范，定义业务和应用对应的数据术语和统一语言，建议企业内部需要共同遵守的数据规则。

数据采集

在数据准备之后，就需要进行数据采集了。

数据采集包括数据源的准备、接入和传输，相关数据的定义，确定元数据及相应的数据含义，确定数据的统计口径；

确定数据的来源；

明确数据的更新频率，是实时更新还是按时更新；数据的更新方式，同时梳理数据相应的主要实体和关键指标，明确数据的范围边界，确保各方使用的数据口径统一。

同时，企业需要考虑技术角度的数据采集效率、准确率和日志记录等方面。数据采集阶段非常重要，它会直接影响数据建模的质量。

数据建模

此步骤进行数据模型的建立，包括概念建模、逻辑建模和物理建模，E-R图是比较常用的建模方式，描述数据实体、属性和关联关系。首先，进行概念建模，这个过程主要是自上而下地创建数据模型，从数据全景出发，不局限在具体的主键和字段，注重数据主题域的关系及与领域模型的映射。

其次，进行逻辑建模，详细定义概念模型的业务主键和逻辑主键，对实体属性进行规范。需要注意的是，设计需要遵循第三范式，达到最小的数据冗余。

最后，进行物理建模，通过对数据库的规范，将逻辑数据模型实例化为物理数据模型，根据数据存储介质的不同，需要对物理数据模型进行相应的优化，并对数据进行具体的数据存储设置。

数据处理

通过数据建模，我们对数据进行了标准、规范的定义，接下来需要对数据进行处理，一般涉及以下几个步骤。

首先，进行数据抽取，在传统的数据处理中，有ETL（Extract、Transform、Load）等处理方法，过程中需要关注数据操作的幂等性。

然后，进行数据清洗和过滤，数据采集和数据建模的过程一般是不规整的，需要对其中的缺失值、重复、关联等进行清洗，并对过程中发现的异常进行统计和处理，以提高数据的质量。

最后，需要对数据的日志进行分析，比如日志分级、日志标记和告警、日志备份和去重等。

数据分析

经过数据采集、数据建模和数据处理后，接下来需要进行数据分析，过程中需要结合行业知识，并对数据进行相应的整合，比如通过相关的数据报表分析、多维分析，建立相应的数据可视化能力，并提高数据的敏捷性，可根据不同视角展示数据的内容，逐步达到可控、可视，提供决策支撑环境，使得数据有效地支持企业决策。

另外，数据分析还与数据挖掘和人工智能相关，企业可以通过大数据算法发现数据的深层次价值。数据分析可以按照独立的数据分析项目来推进，并通过模型和方法的迭代进行优化。同时，数据分析可以借助不同的商业智能（BI）工具进行，同时需要专业人才（如数据分析师）。

数据架构技术

数据架构的核心技术与数据库和存储技术相关，近年来随着技术的发展，越来越多的数据存储技术可以支持多种数据类型。即使使用同一类型的数据存储技术，不同技术的功能及适用的场景也不尽相同。大部分数据存储的引擎都内置存储、查询、处理数据的基础功能，也有部分数据存储的处理和存储功能分离，提供的对外API能力也不相同。下面我们分别来看看数据库技术和存储技术。

数据库的发展历史

数据库已经发展了几十年，下面简要回顾一下数据库的发展历史。

1980—1990年，数据库属于商业起步阶段，此时Oracle、IBM DB2、Sybase，以及SQL Server和Informix等OLTP（Online Transaction Processing）数据库开始出现。

1990—2000年，开源数据库兴起，出现了MySQL、PostgreSQL等；同时出现了一些OLAP（Online Analytical Processing）数据库，来应对大量的数据分析诉求，如Teradata、Sybase IQ、Greenplum等。

2000—2010年，以Google为代表的互联网公司逐渐推出了NoSQL数据库，比如GFS（Google File System）、Google Bigtable、Google MapReduce“三大件”。GFS解决了分布式文件系统问题，Google Bigtable解决了分布式KV（Key-Value）存储的问题，Google MapReduce解决了在分布式文件系统和分布式KV存储进行分布式计算和分析的问题；三大件的核心是通过分布式技术对数据的强一致性需求进行弱化，通过集群的水平扩展来处理，进而衍生了NoSQL数据库来应对非结构化和半结构化的海量数据处理，比如现在的一些典型NoSQL代表如文档数据MongoDB、缓存Redis等。

在2010年以后，出现了AWS Aurora、Redshift、Azure SQL Database、Google Spanner、阿里云的PolarDB和AnalyticDB，它们的特点是具有云服务、云原生、一体化分布式、多模和HTAP能力。

总体来说，数据库的演进经历了从结构化数据在线处理到海量数据分析，从关系型数据库到数据仓库，再到如今异构、多源云原生的发展历程，在此过程中，License传统方式逐步淡出舞台，数据库开源及云上数据库逐步成为主流方式。

数据库的分类

数据库主要分为四类，即OLTP数据库、NoSQL数据库、OLAP数据库及数据库服务和管理类工具，这也是云数据库厂商发力的四个方向。

OLTP数据库：传统的关系型数据库，用于事务处理的结构化数据库，典型例子是银行的转账记账、订单下单、商品库存管理等。其面临的核心挑战是高并发、高可用及高性能下的数据正确性和一致性。典型的云数据库代表是AWS RDS、Azure SQL Database、阿里云的RDS和PolarDB。

NoSQL数据库：存储和处理非结构化或半结构化数据（如文档、图、时序、时空、KV），不强调数据的一致性，以此换来系统水平拓展、吞吐能力的提升。典型的云数据库代表是AWS DynamoDB、AWS ElasticCache、Azure Cosmos DB，以及阿里云的MongoDB、Redis等。

OLAP数据库：应用场景是海量的在线实时分析数据、数据类型复杂及分析条件复杂的情况，能够支持深度智能化分析。其面临的挑战主要是高性能、分析深度、与TP数据库的联动及与NoSQL数据库的联动。典型的云数据库代表是AWS的Redshift、阿里云的AnalyticDB等。

数据库服务和管理类工具：比如数据传输、数据备份、数据管理、管控平台等，以简单的形式提供给DBA及数据库开发者。典型的云数据库代表有AWS和Azure的Database Migration Service，阿里云的数据传输服务（Data Transmission Service，DTS）。

接下来，我们分析一下典型的数据库类型。

关系型数据库

关系型数据库即传统的OLTP，全称是Relational Database Management System（RDMS）。大部分RDMS都提供结构化查询语言（SQL）用于检索和管理数据。一个或者一系列数据库的操作可以构成一个事务（Transaction）。RDMS的数据结构（Schema）通常需要提前定义，所有的读写操作都要遵循Schema。

关系型数据库可以被分成三个基本的模块，包括:

关系模型，即表格、索引、外键、范式等；

事务处理（ACID），即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）；

查询优化，即SQL的解析、改写、优化、执行等。

关系型数据库的典型代表是MySQL、PostgreSQL，以及阿里云的RDS、PorlarDB等。

关系型数据库适用于频繁创建和更新记录，对数据结构需要强制约束，需要高度规范化的数据，不过单个数据条目数据量不大；数据具有高度完整性，追求最终一致性；索引和关系可以被准确地维护。

关系型数据库适用于库存管理、交易管理、报表管理、财务管理等。

Key-Value数据库

Key-Value（KV）数据库是NoSQL的一种，键作为唯一标识符，键和值可以是任何内容，我们可以将任意数据存储为一组键值，并通过键来检索存储值。在大多数情况下，键值存储仅支持简单的查询、插入和删除操作，读取或写入单个值都是原子性操作。键值存储模型对简单查找操作进行了深度优化，查询非常快速。因为键值存储可以在多个节点之间轻松分配数据，所以具有非常强的可伸缩性。如果需要修改某个值，无论是修改部分还是修改全部，应用程序都必须覆盖重写这个值的所有数据，因此键值存储更新效率较低。

常见的KV数据库有以下几种。

Redis：最流行的键值对存储数据库，是一个使用ANSIC编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。

Cassandra：开源分布式NoSQL数据库系统，集Google BigTable的数据模型与Amazon Dynamo的完全分布式架构于一身，是一种流行的分布式结构化数据存储方案。

LevelDB：由Google所研发的KV嵌入式数据库管理系统编程库，以开源的BSD许可证发布。

KV数据库非常适合不涉及过多数据关系和业务关系的数据，同时能有效地减少读写磁盘的次数，比关系型数据库存储拥有更高的读写性能，不过数据的特点是非结构化和不可预知的。

以Redis为例，KV数据库的优点主要体现在：

性能极高（Redis支持每秒10万次以上的事务数）；

丰富的数据类型（Redis支持String、Hash、List、Set、Sorted Set、Bitmap和Hyperloglog）；

丰富的特性（Redis支持Publish/Subscribe、通知、Key过期等）。

KV数据库Redis的缺点也比较明显，主要是不支持强一致性，Redis不能完全保证原子性，发生故障时不可以进行回滚，

所以在使用Redis时，需要根据业务场景进行设计，因为并不是所有场景都需要强ACID原则，比如视频直播、电商秒杀等场景。

文档数据库

文档数据库通常使用类似JSON或XML的格式存储文档，每个文档都包括命名字段和数据。数据既可以是简单的值，也可以是列表、子集合这样的复杂元素，通过唯一的键来进行查询。通常，文档中包含单个实体的数据，如一名用户或者一个订单的数据。一个文档中含有的数据，在RDMS中可能分布在不同的表中，可以解决关系型数据库数据结构扩展不方便的问题。

典型的文档数据库是MongoDB，这是一种面向文档的数据库管理系统，由C++ 撰写而成，以此来解决应用程序开发社区中的大量现实问题。2007年，MongoDB由10gen团队所发展，并于2009年正式对外推出。

文档数据库的优点是可以频繁进行插入和更新操作，数据不需要规范化，新增字段简单，可以兼容历史数据，容易存储复杂数据；文档数据库的缺点和KV数据库类似，对事务的支持较弱，也不支持复杂查询（如Join查询）。文档数据库适用于对读写分离的应用、社交网络、游戏等高频访问业务，以及对数据结构要求不高的业务。

图形数据库

图形数据库是一种NoSQL数据库，基于图论来存储实体之间的关系信息。图形数据库由两种元素组成：节点和关系。每个节点可以代表一个实体（如人、地点、事物），关系则用于描述节点之间是如何关联起来的。图形数据库可以非常高效地查询社交网络等一系列互相具备关系的节点数据，并分析节点之间的关系。

常见图形数据库如下所示。

Neo4j：是由Neo4j公司开发的，具有原生图存储和处理数据的符合ACID的事务数据库。根据DB-Engines排名，Neo4j是最流行的图形数据库。

ArangoDB：是由triAGENS GmbH开发的原生多模型数据库系统。该数据库系统支持三个重要的数据模型（键/值、文档、图形），其中包含一个数据库核心和统一查询语言。

Titan：是一个可扩展的图形数据库，用于存储和查询包含分布在多机群集中的数百亿个顶点和边缘的图形，并且支持事务。

图形数据库适用于具有多种复杂关系且动态随时间变化的数据类型，具有基于图论的设计灵活性、开发敏捷性，并且支持事务。图形数据库的缺点是节点等有数据的限制，并且对拆分不太支持。其适应的场景包括社交网络、推荐引擎、知识图谱和IT运营等。

列式数据库

在列式数据库中，数据是按列而非行存储的。列式是经常需要一起访问的相关数据分组，而行把许多列数据与本行的行键（Row Key）关联起来。同一个列式的数据会存储在一起，同一个属性的所有值会被存储在一起。当查询时可以仅对需要查询的列进行处理，这样可以大幅降低I/O，提升性能，支持大量并发用户查询，其适用于海量数据查询场景。另外，列式中任意给定对象的行都可以动态变化。

常见的列式数据库如下所示。

HBase：Apache的Hadoop生态中的一员，运行于HDFS文件系统之上，为Hadoop提供类似于BigTable规模的服务。同时，MapReduce这个计算框架在HBase之上提供了高性能的计算能力，以处理海量数据。HBase的基本概念包括Rowkey（行键）、Column Family（列族）、Column（列）、Version Number（版本号）、Cell（单元格）。

BigTable：是一种压缩的、高性能的、高可扩展性的，基于Google文件系统（GFS）的数据存储系统，用于存储大规模结构化数据，适用于云端计算。

列式数据库主要适用于批量数据处理和即时查询，有高效的存储空间利用率，普通的行式数据库一般压缩率在3∶1至5∶1，而列式数据库的压缩率一般在8∶1至30∶1，同时查询效率高。列式数据库的缺点是不适合扫描小量数据，不适合随机更新，不适合执行含有删除和更新的实时操作，不支持事务的正常回滚。

列式数据库的适用场景为大数据量且有快速随机访问的需求，写密集型且对性能和可靠性要求非常高的应用，不需要复杂查询条件来查询数据的应用，比如大数据场景、广告营销场景等。

分析型数据库

分析型数据库是面向在线统计分析、即席查询等发掘信息数据价值的数据库。数据分布在多个服务器上，最大限度地提升可伸缩性和可扩展性。分析型数据库可以轻松处理CSV、parquet、ORC等格式的文件。分析型数据库的优势在于超强的实时数据分析能力、高可用和可扩展性、广泛的生态。

OLAP数据库的典型代表是阿里云的AnalyticDB，可以支持海量数据实时高并发在线分析，具备行列混存引擎，能够支持高吞吐写入和高并发查询，并且支持海量数据处理，支持多表、中文及复杂分析；利用向量化技术，支持结构化数据和非结构化数据的融合处理。 分析型数据库适用于企业BI任务，以及高并发实时数据分析任务。分析型数据库适用的场景包括数据仓库服务、大数据分析及ETL离线数据处理、数据湖分析、在线高性能查询、多模数据分析及异构数据源联合分析等。

搜索引擎数据库

搜索引擎数据库可以让应用程序搜索到保存在外部数据存储中的数据，支持为体量巨大的数据创建索引，并提供对这些索引的实时访问。这些索引是基于多个维度的，用于支持对超大文本数据的自由搜索。

搜索引擎数据库的典型代表如下所示。

Elasticsearch：是一个基于Lucene的搜索引擎。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful Web接口，能够实现实时搜索，稳定、可靠、快速、安装方便。

Solr：是Apache Lucene项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成及富文本处理。

搜索引擎数据库适用于基于多个数据源和服务构建的数据索引，并且查询效率高，可扩展。

搜索引擎数据库的缺点是对事务型支持不足，不支持事务的正常回滚，更新性能较低，内存占用大。搜索引擎数据库适用的场景包括分布式的搜索引擎、数据分析引擎、全文检索、结构化检索、复杂的即席查询、对海量数据进行近实时的处理。

服务和管理类工具

这里主要介绍一些通用的服务和管理类工具。

常用的数据分类方法有决策树法、KNN法、SVM法、Bayes法和神经网络。

通用的数据建模工具有E-R图、CASE工具、UML、Oracle Designer等。

对于数据传输的迁移，可以采用阿里云的DTS，它支持多种数据源间的数据传输，支持集数据迁移、数据订阅及数据实时同步，并支持公共云、混合云场景，可以解决远距离、毫秒级异步数据传输难题。

另外，在云数据库类型中，各大云服务厂商也提供了其他工具能力，如数据库备份、数据库管控平台、数据库SQL监控和分析等。

存储技术

除数据库之外，数据架构还要考虑数据的存储问题，这里主要介绍以下几个方面。

对象存储：主要用于存储离散单元（对象）。每个对象都在一个被称作存储桶的扁平地址空间的同一级别里，一个对象不会从属于另一个对象。对象存储适合存储和检索较大的二进制对象，如图像、视频、音频、大型文档，以及CSV、Parquet和ORC等格式的常用于大数据场景的文件。对象存储可以用于管理和存放海量非结构化数据。

典型的云存储服务有AWS的S3、Azure的Blob Storage、阿里云的OSS。

块存储：可以像使用物理硬盘一样格式化及建立文件系统，具有高性能和低时延的特点，支持随机读写。

典型的云存储服务有AWS的EBS、Azure的Managed Disks、阿里云的块存储。

共享文件：可共享访问、弹性扩展、具有高可靠性及高性能的分布式文件系统，提供共享访问。

典型的云存储服务有AWS的Elastic File System、Azure的Files、阿里云的文件存储。

归档和备份：存储和归档不常访问且长期存在的数据，以及备份和恢复云上文件。

典型的云存储服务有AWS的S3 Glacier、Azure的Storage Archive Access Tier、阿里云OSS的归档存储。

批量离线数据传输：PB级别端到端的离线数据迁移服务，能够使用安全设备将大量数据传入或传出云端。

典型的云存储服务有AWS的Snoball Edge、Azure的Data Box、阿里云的闪电立方。

数据架构原则和规范

数据架构中需要制定相应的原则和规范，指导数据架构的规划和设计。这里就与数据架构相关的数据架构总体原则、数据治理规范、数据存储开发规范进行介绍，这些原则和规范是笔者根据自身经验总结出来的，大家可以作为参考，但不能生搬硬套，在实践中需要灵活应用。

数据架构总体原则

整体性原则：数据架构必须根据总体方案统一规划，进而多级实施。

基于业务原则：数据是为业务服务的，承载着相应的业务能力和应用功能，与领域模型相对应。

标准化原则：统一规划数据服务标准、数据交换标准，以及提供数据读写访问功能、基本数据处理逻辑。

隔离原则：数据与应用分离原则、数据异构原则、数据读写分离原则。

数据一致性原则：数据必须一致，每个数据系统内限制获取次数，各部门需要遵循整个公司的数据定义，并尽量共享已有数据。

数据安全原则：保证业务和应用的信息安全和运行安全，同时关注数据质量，确保数据的可用性、准确性及完整性。

数据治理规范

数据按对象进行管理，明确数据对应的组织（Owner），每个数据都只能有唯一的Owner。

从企业架构层面、业务和应用全局视角来定义数据治理相关规范，并紧密结合其他企业架构。

数据治理各项标准需要长期迭代，并在企业层面制定相应的奖惩措施。

为了降低数据之间的耦合度，可以通过设置主副数据的方式进行数据解耦。

当业务数据量过大时，单一数据响应吃力，可以考虑分库分表、多级数据缓存等方式。

数据治理的目的是数据共享，通过数据的优化治理，实现数据准确、完整、一致、可靠。

数据存储开发规范

下图为数据存储设计的一些注意事项，包括数据标准体系、数据资产共享、数据模型和元数据的关键信息，同时包括数据存储开发规范，这里就以下几个方面进行展开。

图例：数据存储设计的一些注意事项

数据存储类型选择

我们在选择数据库时，需要以需求为导向，权衡多种因素，如数据量、并发量、实时性、一致性、读写分布、安全性及运维成本等。具体地，我们可以参考以下原则。

根据不同存储需求进行选择：企业架构数据类型多样，单一的数据存储很可能满足不了所有需求，我们可以采用针对不同存储需求组合数据库的方式。

将业务交易数据存储在关系型数据库中

将JSON文件存储在MongoDB中

将应用程序日志存储在Elasticsearch中

将Blob对象存储在对象存储空间中

根据应用场景进行选择：不同类型的应用系统可使用不同类型的数据库。

比如内部的管理型系统，数据量和并发量都不大，可选择关系型数据库；

大流量的电商系统或者活动促销型系统可选择NoSQL数据库；

日志或者搜索类应用选择日志搜索型数据库；

实时交易事务型应用（如OMS）可采取关系型、NoSQL和一致性事务组合方式；

离线分析报表系统可选择列式或分析型数据库。

优先考虑可用性：根据CAP原则，我们需要根据业务需求进行权衡，选择合适的数据库。

使用分布式系统时，需要在可用性和一致性间进行权衡

在面向互联网应用中，建议优先考虑可用性，通过最终一致性来实现更高的可用性

考虑团队能力：在选择数据库时，我们需要考虑开发队伍的技术能力。新的技术可能需要开发人员了解新的使用模式、查询优化、性能调整等。

考虑事务处理能力：在选择数据库时还需要考虑事务处理能力，特别是在多种数据库场景下，单个事务可能将数据写入多个数据存储中，需要设计补偿事务来撤销已完成的数据处理操作。

数据存储评估

虽然我们确定了数据库类型，但各种类型的数据库还有很多开源或商业化的技术产品，我们可以从以下几个维度来考虑。

功能点：比如数据格式、数据大小、规模和结构、数据关系、一致性、Schema灵活性、数据迁移能力、数据生命周期。

性能效率：服务连接数、响应时间、吞吐量、可扩展性、实时性。

可维护性：监控报警、日志查询、协议许可、售后服务、DevOps适配性。

可靠性：SLA、复制或备份、容灾能力等。

可移植性：托管服务、地域可用性、数据本地/外部/云上迁移能力等。

安全性：加密和验证、审计、网络安全等保合规、数据脱敏、防泄漏、全链路的数据校验。

成本：总成本、ROI等。

数据库设计原则

针对数据库本身的设计，有以下通用的设计原则。

原始单据与实体之间的关系一般是一对一关系，也可以是一对多或者多对多关系。一般而言，一个实体不能既无主键又无外键。

表及字段之间的关系，尽量符合第三范式。有时为了提高运行效率，可以降低范式标准，适当增加冗余。

尽量减少多对多的实体关系设计，可以增加第三个实体。

E-R图尽量结构清晰，关联简洁，实体和属性分配合理，没有低级冗余。

尽量减少数据库中的表、组合主键、表中的字段，防止数据库频繁打补丁。

可以通过优化SQL、分批分表、增加缓冲区、适当增加冗余等方法提高数据库运行效率。

数据结构和存储方案建议经过评审并沉淀成文档，做好版本管理。

MySQL规范

表的命名最好加上“业务名称_表的作用”，表名不使用复数名词。

表名、字段名应使用小写字母或数字，数字不要在开头。

表必备三字段：id、gmt_create、gmt_modified。

每张表必须设置一个主键ID，且这个主键ID使用自增主键。

主键索引名为pk_字段名；唯一索引名为uk_字段名；普通索引名为idx_字段名。

单表列数目必须小于30，若超过则应该考虑将表拆分；单表行数超过500万行或者单表容量超过2GB，才建议进行分库分表。

合适的字符存储长度，不但可以节约数据库表空间、节约索引存储，而且可以提升检索速度。

如果存储的字符串长度几乎相等，则使用Char定长字符串类型，减少空间碎片。

禁用保留字，如DESC、Range、March等，参考MySQL中的保留字。

索引规范

业务上具有唯一特性的字段，即使多个字段的组合，也应建成唯一索引。

超过三个表禁止Join。需要Join的字段，数据类型必须绝对一致；当多表关联查询时，保证被关联的字段有索引。

当建立联合索引时，必须将区分度更高的字段放在左边。

利用覆盖索引（只需要通过索引即可拿到所需数据）来进行查询操作，避免回表查询。

在较长Varchar字段，例如在Varchar（100）上建立索引时，应指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。

如果有ORDER BY的场景，则请注意利用索引的有序性。

SQL规范

为了充分利用缓存，不允许使用自定义函数、存储函数、用户变量。

在查询中指定所需的列，而不是直接使用“*”返回所有的列。

禁止使用外键与级联，一切外键概念必须在应用层解决。

应尽量避免在Where子句中使用“or”作为连接条件。

不允许使用“%”开头的模糊查询。

如果有国际化需要，那么所有的字符存储与表示，均以UTF-8编码。

事务中需要锁多个行，要把最可能造成锁冲突、影响并发度的锁往后放。

减少死锁的主要方向，就是控制访问相同资源的并发事务量。

无Where条件下的性能排序：count(字段)<count(主键ID)<count(1)≈count (*)。

避免使用Select *，在查询中，不要使用“*”作为字段列表。

避免大字段存储传输，优化子查询，尽量避免在·以内。

分库分表原则

下面介绍一下分库分表。分库分表有以下几种形态。

水平分库：以字段为依据，将一个库中的数据拆分到多个库中。每个库的结构都一样；每个库的数据都不一样，没有交集；所有库的并集是全量数据。水平分库适用于总并发高且难以根据业务归属垂直分库的场景。

水平分表：以字段为依据，将一个表中的数据拆分到多个表中。每个表的结构都一样；每个表的数据都不一样，没有交集；所有表的并集是全量数据。水平分表适用于单表的数据量过高的场景。

垂直分库：以表为依据，将不同的表拆分到不同的库中。每个库的结构都不一样；每个库的数据都不一样，没有交集；所有库的并集是全量数据。垂直分库适用于总并发高，可以根据业务归属切分的场景。

垂直分表：以字段为依据，将表中字段拆分到不同的表中。每个表的结构和数据都不一样；所有表的并集是全量数据；一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据。垂直分表适用于单表的字段过多，并且热点数据和非热点数据在一起的场景。

分库分表的步骤建议

分库分表有一些工具支持，比如阿里云的DRDS。不过，不管是使用工具还是自己实现，都需要遵循一些原则。

评估当前数据库的瓶颈，确定是否一定要分库分表；

如确定，则选择切分方式，分库还是分表、水平还是垂直；

根据当前容量和增长量评估分库或分表个数；

选Partition Key，注意要拆分均匀，同时考虑其他关键字段的查询；

制定分表规则，如Hash或Range等；

执行，比如采用双写的方式；

考虑扩容问题，并尽量减少数据的移动。

数据架构参考实践

通用数据架构

这里给出一个通用的数据架构以供参考，如图6-6所示，通过分层的视角列出了一些相对核心的层次，每个层次的内容并不固定，我们需要根据具体的业务和数据需求进行调整。

图例：通用数据架构

数据服务：构建数据服务层，通过接口服务化方式对外提供数据服务。比如对应的数据目录、数据标签、数据分析、算法模型（如智能补货算法、信用风险模型、商品推荐模型、客户留存模型、转化漏斗算法），并结合相应的数据应用、数据产品和分析模型，提供对应的公共数据服务能力。

数据计算：数据只有被整合、计算才能被用于洞察规律、挖掘潜在信息，实现数据价值，可以包括批量离线、内存计算、在线流式、机器学习等。

数据存储：支撑数据的数据库及存储技术，包括关系型、NoSQL、分析型、其他存储方式，具体的分类和选型可以参考本章相关内容。

数据采集：一套标准的数据采集体系，包括结构化、非结构化、半结构化数据的采集，还要做好数据传输。

工具平台：需要搭建一些工具或平台，

智能研发平台（从数据开发流程上辅助开发人员进行数据研发，如构建数据模型、算法开发、数据服务等）

智能分析平台（针对数据进行灵活、快速的分析，支持多数据源、多维分析、多图表组件、多用户权限、多屏等）

智能标签平台（进行标签的定义、可视化及相应的管理）

智能运维平台（对工具平台的服务组件及集群节点的健康状态进行监控）

大数据分析平台（构建大数据处理分析能力，包括相应的组件）

结合应用架构

在应用架构中，我们介绍了一些基于DDD的通用应用中心，核心是对应的领域模型。在数据架构中，可以很好地承接这些领域模型到数据模型，并逐步形成相应的数据和存储规划。

这里需要强调的是，领域模型和数据模型并不一定是一对一的关系，前者面向DDD的领域实体，后者面向数据规划层面，比如一个会员积分领域模型，可能对应数据库中的会员积分表、积分明细表、积分快照等多张表。

这个过程也需要结合数据架构设计方法和步骤，对整体数据进行分析，这里推荐结合应用架构进行数据架构。

图例：结合应用架构进行数据架构

数据规划：总体规划，根据企业战略计划、业务架构和应用架构相应输入（如业务流程和应用场景），明确需要建设的数据主题域、相关的资源配置、技术选型等。

数据采集：对接相应的数据源，根据对应数据进行基础的采集、清洗和结构化处理。

数据建模：明确对应的主题，同时确定相应的聚合粒度、对应的数据指标、总体规范定义等。

数据萃取：根据数据进行萃取管理，识别统一ID，建立标签画像，进行相应数据服务的开发。

数据资产管理：整合数据服务能力，构建数据地图，并结合资产应用和指标管理体系，沉淀数据模型等关键数据资产。

数据治理：将数据服务进一步标准化、可视化，并经过多维分析和运维治理，对数据的生命周期进行治理。

结合数据仓库

数据仓库（Data Warehouse）是数据处理、分析的有效手段，有着几十年的发展历史，可以有效地助力数据架构的设计和建设，可以说数据架构的很多理念来源于数据仓库。数据仓库是一个面向主题的、集成的、反映历史变化的数据集合，用于支持管理决策和信息的全局共享。

数据仓库的主要功能是将OLTP所累积的大量资料，通过数据仓库理论所特有的方法进行分析整理，并提供给OLAP、大数据等技术。

在数据仓库中，数据按照功能和量级主要分为四层，通过不同层次的架构过程实现从数据资产向信息资产的转化，并且对整个过程进行有效的元数据管理及数据质量处理。

操作性数据层（Operational Data Store，ODS）：面向主题的、集成的、不断变化的数据，是可选部分，具备OLTP的特征。

明细数据层（Data Warehouse Detail，DWD）：将来自不同系统的同类数据源按照某种维度进行聚合，形成统一聚合数据，比如将不同电商平台的订单数据聚合，形成宽表。

汇总数据层（Data Warehouse Summary，DWS）：加强指标维度退化，提炼粗粒度常用维度、常用指标的汇总模型；同时根据某一时间内实体的事件轨迹，形成公共主题宽表，比如根据客户属性、购物经历、偏好等形成全面客户洞察。

应用数据层（Application Data Store，ADS）：增加个性化的标签衍生，并基于应用进行数据组装，比如大宽表、趋势指标等应用型数据。

结合大数据

数据架构与大数据密切相关，随着大数据技术的发展，大数据分析能力逐步成为数据架构核心能力。

大数据本质上是以一种分治思维把复杂的计算任务分发出去并进行汇总，主要的流程有：

搭建大数据平台需要考虑解决数据采集的组件、数据处理的计算引擎、各种数据存储组件，以及数据作业调度、权限、安全管理组件等。同时，企业需要对数据规模进行评估，包括数据总体量、数据日增长量、数据存储周期等。

目前，大数据相关技术选择面很广，其中Hadoop生态占主流，比如:

数据采集可选择Flume、Kafka、Logstash、RocketMQ等

数据存储可选择HBase、Ignite、HDFS、TiDB、Parquet等

数据计算引擎可选择MapReduce、Hive、Spark、Flink、TensorFlow、Kubernetes等

数据作业调度可选择Azkaban、Oozie、Airflow等

数据权限可选择Ranger、Kerberos等

当然除了这些开源组件，还有很多成熟的商业化大数据产品，在计算性能、运行稳定、技术支撑等方面有很多优势，比如AWS的Redshift，阿里云的MaxCompute、DataWorks等。

同时，大数据对外提供的服务层也有一些工具支持，比如定制报表、智能缓存、事件分析、数据挖掘、智能算法等。比如，可视化BI工具有AWS的QuickSight、Azure的Power BI及阿里云的Quick BI。

大数据平台本质上是数据架构及应用数据仓库的延伸，目的是构建企业全统通的数据综合体系，向下承接云计算能力，线上提供数据智能化应用服务。它通过数据架构技术，对海量数据进行采集、计算、存储、加工，之后形成标准数据，形成大数据资产，最终形成数据API，为企业和客户提供各种高效的数据服务。

大数据平台建设的基础是数据仓库和数据中心，并结合大数据技术，更加关注提供给业务的分析型数据服务，如个性化推荐、千人千面等。通过大数据平台的赋能，企业可在全渠道、上下游生态链中用数据指导运营，实现一切业务数据化、一切数据业务化，助力零售数字化建设，比如沉淀消费者画像、精准广告投放、进行品牌数字化，以及利用会员历史数据，分析会员生命周期，实现会员管理数字化。

另外，数据湖（Data Lake）也属于广义的大数据范畴，数据湖是以自然格式存储的数据的系统或存储库，通常是对象Blob或文件。数据湖通常是企业所有数据的单一存储，包括源系统数据的原始副本，以及用于报告、可视化、分析和机器学习等任务的转换数据，经过数据抽取、数据解析、数据处理等对外提供数据API能力。

数据湖比较关键的模块有分布式存储引擎、流数据处理引擎、分布式计算引擎。目前，Hadoop是十分常用的数据湖技术，另外商业化的有AWS的Kinesis Analytics、Azure的Data Lake Analytics、阿里云的数据湖分析（DLA），它们可以支持多种大数据源。

在提到大数据时，也会常常提到人工智能等，结合人工智能可以提供更丰富的数据智能服务和应用，业界比较典型的有机器学习类AWS的SageMaker、Azure的Machine Learning、阿里云的机器学习PAI；自然语言处理类AWS的Lex、Azure的Speech Services和LUIS、阿里云的机器学习智能语音交互和NLP；人脸图像识别类AWS的Rekognition、Azure的Cognitive Services、阿里云的人脸识别和图像识别服务等。