分享一个银行数据集成架构的启示【荷兰银行】

数据集成架构属于一个常见问题领域。本文讨论不针对特定行业。主要对数据感兴趣的人：数据架构师、数据工程师、解决方案设计师、数据专业人员等。

大约两年前，荷兰银行面临着改造当前数据仓库架构的挑战。它必须满足最新和未来的商业智能和分析要求，并以敏捷的方式支持数据驱动的文化。但同时它也必须尊重严格的数据管理原则：治理、法律义务和内部政策。这些要求通常会对流数据、非结构化和外部数据的使用、操作流程中的分析嵌入、API使用等施加限制。

现代架构必须满足所有这些不同的要求，但同时它还必须与金融科技、外部数据提供商和数据消费者建立一个生态系统。“生态系统架构”是在数据集成领域取得成功的关键。荷兰银行未来的数据是分布式的，特别是当迁移到云并与外部各方进行越来越多的交互和协作时。未来很可能会达到这样一个阶段：使用的大部分数据本质上都是“外部”数据。为了控制数据分布和使用，需要一个“大规模数据分布的架构”。

一 现状

荷兰银行现有的架构类似于大多数企业所拥有的架构，可以通过下面的概念图来最好地说明：

除了有机会利用最新的大数据和分析技术趋势之外，还必须能够控制它。数据沿袭是一个重要目标。每当数据模式发生变化时，都需要能够跟踪数据和变化。判断数据的真实性和质量也非常重要。典型的企业数据仓库设计基于90年代的原则，将所有数据集中在一起，然后集成所有内容。使用这种方法不可能考虑大量外部和非结构化数据。数据治理的观点也是一个问题。荷兰银行希望对所有权有清晰的了解，并允许数据提供者控制其数据的分发和使用。最重要的是，希望通过减少共享依赖来提高敏捷性。

以下讨论基于“每个应用程序都有一个数据库”的假设：

第一个假设是每个创建数据的应用程序（至少在银行应用程序的上下文中）都有一个“数据库”（应用程序数据的有组织的集合）。从这个角度来看，即使是创建数据的无状态应用程序也有“数据库”。在这些类型的场景中，数据通常位于RAM或临时文件中。根据这个假设，当有两个应用程序、有两个数据库时是合乎逻辑的。

第二个假设是数据集成总是迫在眉睫。当这两个应用程序之间发生互操作性时，期望数据从一个应用程序移动到另一个应用程序。

二 对集成的共同理解

这个问题会涉及上下文和模式转换。这是因为应用程序数据库模式是为了满足特定的业务需求而设计的。由于要求不同；应用也不同。因此，模式预计会有所不同，并且在移动数据时始终需要数据集成。

无论是进行ETL（提取、转换和加载）还是ELT（提取、加载和转换）、虚拟还是物理、批量还是实时，都无法摆脱数据集成困境。数据互操作性和集成将构建新的架构。

数据提供者和数据消费者

对于集成架构，荷兰银行采用并调整了“面向服务”的理念和TOGAF的集成信息基础设施参考模型(III-RM)。应用程序或系统要么是数据提供者（数据的生产者），要么是消费者（数据的消费者）。因为荷兰银行是更大生态系统的一部分，所以我们希望数据提供者和数据消费者也成为外部各方。

根据数据提供者和数据消费者的基本概念，定义了一组原则：

• 清晰的应用程序和数据所有权

• 数据质量在源头得到维护，这是数据提供者的责任。

• 可理解的数据，这意味着定义、标签和适当的元数据是可用的。

• 没有无目的的数据消耗。

• 不需要时不要进行集成。

• 如果不需要与其他来源的数据集成，请自行解决问题。

• 数据消费者在分发数据时可以成为数据提供者。如果是这样，他们必须遵守相同的原则。此外，请勿分发不属于您的数据。

• 集成对数据消费者是关闭的。他们负责数据转换，因为他们设定了要求。

三 “数字集成和访问层”架构蓝图

有了数据提供者和数据消费者的概念，集成和互操作如何进行？中间的“解决方案”称之为数字集成和访问层（DIAL）。让我们来看看其中的一些方面。

访问：理想情况下，数据消费者想要一个单一的位置（一层），在那里他们可以随时以任何速度以一致的方式“探索”、访问和查询所有数据。数据消费者不必担心可用性。数据是否必须物理存在于该层取决于非功能性需求。

集成：架构的一个关键部分是关于转换/集成。在DIAL架构中设定了一个硬性要求，即数据提供者和数据消费者之间的数据转换只能完成一次。因此，最初没有转变为企业模式。在这种方法中，数据要么位于提供者的上下文中，要么位于消费者的上下文中。消费者设定要求，我们接受数据的协调，并且如果数据严重重叠，可能需要采取额外的步骤。但在新模型中，仅允许在域级别创建附加层。通过这样做，敏捷性将显着提高。通过放开企业模式，数据提供者和消费者可以按照自己的速度进行改变。同时一切都是解耦的。

元数据：如果不使用企业模型，数据消费者如何理解数据的含义？这就是元数据发挥作用的地方。元数据是关键的粘合剂。为了实现“可理解的数据”原则，荷兰银行要求提供者和消费者集中交付业务元数据。对于集成和转换，需要沿袭元数据。通过使数据集成架构成为元数据驱动的，它支持一种通过提供洞察将数据“重用”给其他消费应用程序的方法。从逻辑上讲，这意味着所有数据使用者都可以访问企业元数据目录，从中可以看到可用数据、模式、定义、沿袭、所有权、质量、源列表等。

数据安全：该架构使用数据提供者和数据消费者之间的数据交付协议。数据根据元数据协议和标签进行路由。这使得数据提供者能够控制分发，因为每当元数据标签和分类发生变化时，路由就会发生变化。

数字化：荷兰银行通过机器学习和人工智能实现元数据要求的方式。最终，架构成为一个自学习的语义层，允许各方与其交互。该层还将包括分类服务，用于查看数据的真正潜力和价值，包括其与业务能力模型、技术模型等的关系。

1 使用架构构建块来设计架构

让我们继续看看一些工程方面的内容。为了分发和移动数据，我们区分以下功能和模式：

（1）读取数据存储架构

读取数据存储充当“只读缓存”，可以从中获取数据。将其视为操作系统的“命令查询职责分离”扩展。因为不进行任何前期转换，所以格式是“域数据”，这意味着上下文是从域继承的（基于架构指南）。对于“域数据”，还意味着不能创建新数据并且不能更改数据的上下文。为了添加新的业务逻辑，希望数据消费者首先提取和转换。因此需要新的数据所有权。

数据读取存储的好处是开发人员可以重构他们的操作系统，而无需更改他们的数据读取存储。针对数据读取存储的查询不会增加操作系统的负载。数据读取存储必须保持最新，这可以通过批量、变更数据捕获(CDC)、微批、复制或同步等摄取技术来完成。

对于数据治理实践来说，让数据提供者拥有并控制数据读取存储中的数据非常重要。这还包括数据访问：确定谁或哪个应用程序有权访问。这里使用数据交付协议的概念。例如，如果消费者与其中一个数据读取存储中的表建立依赖关系，则会创建一个合约，并且数据提供者知道存在依赖关系。提供商仍然可以设计或重构其操作系统，但必须保证向后兼容性。

荷兰银行设想针对不同用例的多个数据读取存储，并且不同的数据读取存储也可以共享相同的技术平台。读取数据存储与技术无关，这意味着数据读取存储可以是一个关系系统，也可以是一个基于数据结构的文档存储。Cassandra、Hadoop(HIVE2)、MongoDB、RedShift等等都是有效的平台。数据提供者可以将自身扩展到这些环境中的一个或多个。这使得数据读取存储成为消费者的完美场所，因为需要消耗数据的方式存在差异：例如，大容量与小容量的高速数据。在多个数据读取存储位于同一环境中的场景中，将主数据和参考数据引入此类共享环境也是合乎逻辑的。元数据再次是关键的粘合剂，它负责伪装事务，主数据和参考数据。具有多个数据读取存储的环境也是可以执行跨系统的一致性和完整性检查的地方。正如预期的那样，这将对数据质量产生积极影响。

（2）面向服务的架构

对于实时应用程序到应用程序通信或可以直接从应用程序或系统中取出的数据量，荷兰银行使用轻量级集成组件：“面向服务”。请求-响应是最著名的模式。通过在应用程序之间放置通信总线或集成组件（例如使用企业服务总线或API网关）来实现解耦和集成，实时架构中的元数据再次被集中收集。所有服务都必须在中央服务注册表中注册。它们始终归数据提供者所有。对于正在使用的API，荷兰银行使用相同的数据交付协议理念。

（3）事件驱动架构

最后一种模式是事件流数据。每当状态发生变化时，就会创建一个事件或触发器。这些数据被转发到流媒体平台之一，从那里可以开始向数据消费者分发数据。数据还可以保留更长时间。在DIAL架构中，这些“状态存储”也称为“读取数据存储”。对于流媒体也遵循相同的原则。主题和订阅始终通过元数据进行控制。

2 组合不同的模式

这些模式之间可能略有重叠，但是将它们组合起来时，集成架构如下所示：

DIAL中的模式也是互补的。事件可以被摄取到读取数据存储中。命令和查询可以通过API网关相互分离。我们还为每一层制定了通用的消费模式。例如，对于读取数据存储，消费模式可以是ETL、ODBC访问、轮询后拉取、文件推送订阅或通过商业智能解决方案直接访问。

（1）域数据存储

在DIAL架构的右侧，可以看到数据消费者的解决方案以及“域数据存储”或“集成数据存储”的概念。在荷兰银行未来的架构中，所有未来的应用程序仅依赖于单个应用程序数据库。必须避免使用为多个应用程序存储数据的数据库。

DDS是多种不同用例的象征，例如商业智能、分析、运营应用程序等。应用程序数据库是专门为满足和解决特定业务需求而设置的。因此，数据模型预计将非常具体。数据模型可以从高度标准化到维度化。此外，集成步骤也可能有所不同，从单个集成步骤到需要额外步骤（数据清理、额外协调等）的情况。

所有这些直接使用、转换和存储数据的新型应用程序称为集成数据存储。由于数据模式发生了变化，荷兰银行期望新的所有权并将新数据视为新的“黄金”数据。所有这些新应用程序都需要在元数据存储库中注册，这称之为黄金源列表(LoGS)。荷兰银行还为过渡/运营系统制定了这一注册原则。

DIAL架构放弃了企业数据模型，转而追求更高的敏捷性。这也符合‘连接生态系统’的思维。荷兰银行架构中的企业数据模型已经为元数据管理、主数据管理、数据治理和数据质量等学科提供了位置。通过实施数据管理，荷兰银行确保监督数据分发并促进数据可重用性。

（2）跨链数据移动

对于DIAL参考架构右侧有一个箭头，它一直回到数字集成和访问层。这是因为数据消费者在再次分发数据时也可以成为数据提供者。因此，当应用程序想要与其他应用程序共享/分发数据时，必须再次使用DIAL架构的模式。为了说明应用程序之间的数据互操作性，请参见下图：

应用程序之间的互操作性始终通过DIAL架构进行。由于该架构依赖于元数据，因此无论使用什么模式，都可以跟踪数据。架构指南对“有界上下文”内的数据分发做出了例外：共享相同业务问题的应用程序边界。但当上下文或职责发生变化时，就需要使用DIAL进行解耦。

（1）元数据组件

元数据流的详细信息如下图所示。

所有数据读取存储都需要将其所有元数据架构信息同步到中央元数据存储库。DIAL架构具有“集中管理”的ETL功能，可以自动将血缘写入元数据存储库，但数据消费者也可以选择自己的模式。在这些情况下，将手动交付元数据沿袭。

（2）与微服务有什么关系

您可能想知道：微服务和DIAL架构之间有什么关系？微服务架构是一个应用程序架构，而DIAL架构是一个应用程序之间的集成架构。微服务是一个可独立部署的单元，是应用程序的一部分。许多微服务一起形成一个应用程序。有界上下文是我们划线的地方。在应用的范围内，开发者有一定的自由度，但跨应用时，需要使用DIAL模式进行解耦。

四 小结

数字集成和访问层是荷兰银行架构师、开发人员、工程师和解决方案设计师的架构，因此他们知道如何为业务提供最高价值。总结一下，主要优点是：

• 清晰洞察数据供应链。

• 数据提供者和消费者对数据消费以及消费者的要求和责任的洞察。

• 更高的敏捷性，因为删除了当前架构中所需的额外集成步骤并消除了与其他域的依赖关系。

• 更容易访问和查找数据。

• 洞察数据、质量和所有权的含义。

• 更好的安全性，因为在属性级别上有标签，可以强制执行基于属性的访问。

• 有机会更快地利用最新趋势和发展。

往期推荐