【参考数据架构】创建参考数据架构…

我想在创建参考数据架构的同时分享我的思考过程。希望它能帮助你定义你的，我们通过提供反馈来帮助我改进我的。

我认为参考架构是一个需要努力的目标，而不是简单地反映当前的状态。在我看来，参考架构应该与供应商无关，但要强调重要/强制性的技术功能。参考架构可能（也应该）包括当前未使用的组件，以便从我们当前的位置有更广泛的视角。

我的参考架构是基于多年来在各种公司和技术中积累的实践经验。我将我的实践经验与阅读社区出版物的时间结合在一起。这个参考架构也构成了我在Simplics工作的基础，我已经开始在Medium上描述它，从我的帖子开始。。。

为什么我觉得有必要发布这篇描述我的参考数据架构的帖子？

好吧，这是我描述我的信仰以及简单主义是如何构成的一种方式。我还没有真正找到很多类似的（公共）著作，它们将数据架构作为所有数据消耗学科的通用架构，强调没有供应商标志的需求和功能…

此外，从供应商的产品开始并以此为基础进行构建真的很难，所以这确实会有所帮助。

The 2023 MAD, brought to you by Matt Turck,

要获得高分辨率，请访问以下任何链接。

MAD 2023-版本1.0（matttturck.com）

2023年MAD（机器学习、人工智能和数据）前景-Matt Turck

简单地看一眼数据技术地图就会得出一些结论。

• 任何人如何评估和选择适合这份工作的工具？不用花很多时间评估！评估和评估每种产品所需的各个方面实际需要多长时间？
• 我们不能满足于使用一些工具来完成任务，这会导致团队的学习曲线陡峭。。。
• 我们需要构建一些可以改变和采用/替换工具的东西，因为一切都在发展，我们可能还没有完成任务的最佳工具，但…

那么，我们可以从社区共享的东西开始吗？

我决定花几个小时浏览其他人是如何定义和描述他们的数据架构的？我把一堆图表复制到下面的幻灯片中。

https://youtu.be/Lb55-tVdEz0

Lots and lots of data architecture diagrams grabbed from the Internet

My reference data architecture

我们现在有了一个充满学科和能力的图表，作为一种多层次的方法绘制。使用您记录在案的需求，并详细说明每一个重要的学科，既作为需求，也作为对您需求的回答…

好的，那么我们如何看待这张照片呢？

从左到右，穿过中间，然后向上。处于较高位置的部件比处于较低位置的部件更重要。然而，对于一个装备精良的“生态系统”来说，所有组件都是有效且重要的（每个图标所代表的内容将在本文中进一步描述）。

在最左边，我们有各种类型的来源，所有这些来源都有特定的特征需要考虑。这些通常是；内部遗留系统、ERP、SAAS、定制、微服务、数据库、日志、设备和社交媒体等。。

为了将数据传输到中间，我们需要以拉、推和流的形式进行某种形式的源摄取。数据被接收并存储在着陆区，然后被组织到一个原始的“无缓冲”存储器中，以便进行审计和再处理。

从那里，我们将数据调整为选定的格式和上下文，并使其可访问。我们进一步将数据集成到实体和扩展上下文中，使其更易于访问。稍后将数据公开为特定业务用例所需的格式，以便进行简单准确的访问。并非所有数据都必须“穿越”所有五个丰富层。根据我们的实际需求，消费可以从后面三个层（对齐、集成和业务）中的任何一个进行。

从源接收到业务调整，我们创建需要编排和调度的程序和/或数据流。我们强调内部流程的自动化，因此它涵盖了所有层，在我们的图表中具有更高的重要性。

我们的第二要务是数据质量，这是一个贯穿我们所有层面的实践。另一方面，我们的最高优先级是我们的最终用途；我们的消费和运营。我们应该专注于我们的最终用途，让它驱动其他一切。我们的内部数据操作（或数据治理或数据操作）与任何其他用户或应用程序一样重要。这导致元数据成为一个关键组件，它必须捕获有关所有模式、模型、定义、数据、流程、事件和用法的数据。

如果你对每个图标所代表的每个功能感兴趣，请继续阅读，否则请随意到此为止…也许你没有找到“基于图标的”图表，所以如果你愿意，这里有一个文本替代方案…

My reference architecture

这是相同的架构，但没有图标，绘制有点不同。它由与前面的图表完全相同的层和功能组成。以下部分与我的流程有关，描述了我用作参考架构基础的功能和需求…

步骤1：收集、列出并描述你想要的能力。

这些应该包括已知驱动用例的特定功能，以及未来未知用例的更通用的功能。我通常将这些能力分组，并将描述保持在高水平，但驾驶计划除外。让我使用下面的详细列表进行说明。

数据采集

data acquisition capabilities

• 我们需要一种推送数据模式来允许系统发送数据。
• 我们需要一种从系统中获取数据的拉取数据模式。
• 我们需要一种流式数据模式，以便能够即时、连续地访问数据。
• 我们需要一个到达数据的占位符、一个交付区域或上传区域。
• 我们需要一个长期的档案，用于可追溯性、再处理和审计。

数据可观测性

capabilities for data observability

• 我们需要能够观察和测试我们的数据质量；完整性、一致性、有效性和新鲜性。
• 我们需要收集并显示所有数据点/产品的踪迹。起源，它是如何生成的，如何随着时间的推移进行处理和转换，以及它为哪些用户/应用程序提供服务。
• 我们需要确保数据不会被滥用或歪曲，并且只提供给那些可能担心的人。

数据集成

data integration capabilities

• 我们需要具备转换能力，以便实现如下所述的新状态和新形式的数据。
• 我们需要统一我们的数据，以便简化访问并使其成为可能。
• 我们需要整合数据，以整合数据，提供更广泛的视角，创造相似性，并定义可以共享的概念和定义。
• 我们需要将数据调整为适合其应用的形式。
• 我们需要定义一个包含定义、术语和概念的术语表

编程访问

• 我们需要启用公司代码管理标准，如git或类似标准
• 到目前为止，人们和技术人员最常用的数据处理和操作语言是SQL。因此，目前启用SQL对数据的访问至关重要。
• 我们需要为各种工具开放数据访问，并通过为我们的数据创建SDK或为各种编程语言提供模板来避免技术锁定。
• 对于需要在不同技术设置之间保存、跟踪和移动的任何代码，纳入CI/CD流程非常重要，以提高代码质量、共享和开发速度。

日常运营

day to day operation capabilities

• 我们需要尽可能地实现流程自动化。
• 我们需要能够通过排序、扇入和扇出功能来协调我们的数据流/管道。
• 我们需要安排某些数据流和任务。
• 我们需要能够监控我们的技术环境、数据管道、资源消耗、财务支出和数据质量。
• 我们需要能够针对关键事件创建警报。
• 我们需要设置一系列控制措施，以确保我们的数据环境持续发展，并为最终用户和消费应用程序维护高质量的服务。
• 我们需要能够审计数据是如何被访问的，被谁以及何时修改的。

数据消费

data consumption capabilities

• 我们需要运营情报能力，以便将数据转化为可操作的见解，帮助我们的组织优化运营并提高底线。
• 我们需要BI和报告，以便以描述和报告业务进展的方式呈现数据，并帮助我们的组织做出更好的决策，改进运营，实现竞争优势。
• 我们需要仪表板功能，以便使数据具有相关性，并将正确的信息呈现给正确的利益相关者。
• 我们需要某种笔记本电脑功能，以便我们的高级用户能够在彼此之间精心设计、开发、处理、呈现和共享数据和程序。
• 我们需要一套工具和流程来对我们的数据运行人工智能和ML计划。模型培训、评估、验证、审计和出版，也许还有一些特定的商业图书馆
• 我们需要为数据应用程序开放我们的数据环境。使用数据并为另一个目的生成“新的”丰富数据的应用程序。
• 我们需要为用户提供一种使用搜索方法发现数据的方法。
• 我们需要允许我们的用户在彼此之间共享数据和代码。

这很可能是您将详细介绍自己能力的领域。对于具体的需求，请详细说明，否则请接受我的高级定义。例如，您可能需要针对用例的NLP功能，可能还需要一些用于并行处理的基础设施，以及针对ML功能的某种注册表和编排。

第2步：了解您的要求

许多数据架构要求都很一般，但考虑起来非常重要。

我最近写了一篇关于底层总体需求的文章，这些需求应该影响整个架构，并体现在所有组件和功能中。我觉得这些很重要！

Requirements for data architectures

当然，链接帖子中列出的要求还不够，你还会有其他更实用的要求，比如延迟、外观、资金限制、员工技能、绩效、分配、法律和政策等等。

第3步：总结和定义

总结所有需求和功能，并定义您的参考架构。我们有一系列的能力，需要结合实际情况进行组织。我们有一套总体要求需要考虑。我们的需求有助于我们将我们的能力置于上下文中，相互限制或启用。很可能你最终会创建一个类似于我的多层架构。

我的参考架构既可以用于经典的集中式实现#datawarehouse，也可以用作现代的去中心化实现#datamesh。

Classic Centralized Data Warehouse Architecture

我们的经典集中式数据仓库在这种架构中可以完美地工作。例如，我们可以将数据收集到云存储桶中，配置云数据仓库来访问存储桶并自动加载数据。我们努力定义一个集中的数据模型，并创建加载自动化和数据可观察性的功能。我们在星形模式、表格和多维多维数据集中创建基于用例的数据集。我们为适当的数据集配置消费工具，并集中我们的安全性、完整性和访问功能。一切都由一个中央跨职能团队负责。集成和重用能力是这些设置的重点。

Decentralization using streamline architecture, hybrid mesh :)

在这个架构中，我们希望实现去中心化，以便团队提高生产力，并将复杂性保持在领域边界内。然而，我们仍然希望实现在各个实现中遵循相同的指导方针、框架和方法。在这些场景中，我们从精心规划的架构和策略中受益匪浅。成功的关键在于；流程、结构、流程和元数据的自动化。有了这些东西，我们可以很容易地启用中央数据目录，并使用户能够找到和访问他们所需的数据，也许可以使用虚拟化工具。在我上面的参考图中，我们有相同的架构布局（和组件），但有几个实例。我们集中数据访问、发布和发现。

Data mesh and my reference architecture

拥有自主团队的去中心化也可以受益于精心规划的架构和政策。这一次，我们将架构表现为一种通用的数据基础设施即服务，具有数据发布、可观察性、完整性、发现和访问的自动化过程。每个域都将能够独立地处理它们的工作负载，并使用任何东西来解决它们的需求。然而，如果一个域想要发布数据集或产品，他们必须使用我们的通用数据基础结构服务来发布。因此，基本上，我们的通用数据参考架构只提供用于共享的数据，这被认为是伟大的数据发现服务的理想选择…

我的参考架构的每一个变体都可以而且应该用伟大的技术进行实例化。以下步骤可以指导您进行选择。

第四步：与技术产品相匹配。

因此，即使我说这是技术不可知论，这也是我们试图将每个功能图标与一些技术进行映射的时候。例如。

1. 我们拉…
2. 我们推送使用…
3. 对于流式数据，我们使用…
4. 我们在…将数据写入并组织到存储桶中…。
5. 我们将数据整合到实体中，并将其发布为…in…
6. 将数据集成到…中…。在…上…。
7. 创建…并在…中发布…。
8. 使用…编排流/程序…。
9. 我们使用…。作为我们的日程安排工具
10. 对于数据验证，我们使用…
11. 所有数据质量控制都是使用…创建和监控的…
12. 我们将我们的数据谱系记录在…
13. 让我们将定义和术语表存储在…
14. 我们使用…存储和发布元数据…
15. 我们用…监控我们的系统…。
16. 我们使用…创建警报和警告…
17. 对于资源和消费计划，我们使用…
18. 为了运行和监控我们的操作，我们使用…
19. 我们喜欢的笔记本是…
20. 我们使用…进行SQL访问
21. 我们使用…进行编程访问
22. 对于数据发现，我们使用…
23. 我们使用创建仪表板…
24. 我们使用…构建和发布报告…
25. 我们使用…将数据集成到…中…
26. 我们精心安排了我们的模特训练…
27. 我们在…中发布我们的模型…
28. 我们与…共享数据…
29. 我们使用…集成MA…
30. 我们的工具和数据访问由…控制…

因此，30步后，我们有了一堆技术和他们的责任/目的。我们现在可以开始连接并构建我们的精细数据环境了！