【数据架构需求】数据架构要求

好吧，所以这篇文章不会真正提供任何关于预定义数据体系结构的细节，但它确实强调了构建数据体系结构时的一些首要任务。如果您对需求和高级思想感兴趣，请继续阅读，否则请等待下一篇文章：）

因此，为了构建一个功能良好的数据环境，我们必须定义一些基本需求。我们应该努力建立一个适应性强、可持续的数据环境，能够满足您的所有数据需求，包括ML/AI、分析、数据应用程序或其他任何东西。一些数据平台供应商会说，你只需注册，你想要的一切都已经得到了考虑，但事实远非如此。数据架构由许多模块组成，这些模块必须相互交互和“馈送”，就像任何生态系统一样…

根据我的说法，这些是数据架构最重要的要求。是的，无论您喜欢的方法是集中式数据仓库、数据仓库、数据库、数据结构、数据网格还是孤立的ML/AI项目，这些要求都是一样的。

让我们将需求分组到几个桶中。交付、数据信任、适应性、成本、技术和可移植性等等！

General data architecture requirements

1.交付(Delivery)

能够以尽可能低的延迟交付数据。这适用于新的需求，但也适用于持续的增强。别忘了，我们需要我们的数据提供给可能关心的人，而且只提供给他们，但要简单地查找、访问和理解

It’s all about the ability to deliver value… fast!

实现价值的时间短

• 原因：简单地说，就是快速满足新需求的能力。
• 如何：在所有事情上引入“自动化优先”的方法。努力实现那些可以自动化的部件的自动化。它不仅加快了开发速度，还将提高您的整体质量，并实现非常纤薄的维护。不符合可用自动化模式的东西应该分开。

以下是我们可以实现自动化以提高生产力和质量的领域列表。

• 代码生成
• 流式处理和批处理自动化
• 测试自动化
• 自动数据验证和筛选
• 自动化部署
• 自动访问控制
• 自动化数据词汇表

如果我们学会了如何激活可用的元数据，这并不难。

访问数据

• 为什么：我们必须允许数据发现和简化访问，同时确保隐私和数据完整性！
• 如何：以景观为目标，我们可以搜索数据，了解数据并请求访问。当被授予（希望是自动化的）时，我们应该能够使用我们选择的工具集访问数据，只需单一登录，没有（低）代码。访问权限应该易于授予和撤销。我们的数据环境的所有部分都应该包括在内，并且访问政策适用于所有地方。重要的是，您的数据架构支持通用访问安全层，这样就可以实现单一的管理点。启用支持轻松访问所需数据的框架，消除数据格式和连接库等障碍。

2.数据信任

第二个最重要的需求是数据信任。基本上，这是围绕着可追溯性展开的。我们在使用什么，数据是如何被更改的，为什么被更改，由谁更改，何时更改？还有谁在使用数据集？数据集的新鲜度和准确性如何？这些都是任何数据消费者都应该问的问题，因此答案应该掌握在掌握范围内。

How do we achieve data trust?

可追溯性

• 为什么：数据的一个非常重要的方面是数据来源、谁或什么处理了数据以及如何处理。数据出现在什么上下文（模型）中？谁消费它，谁拥有它？（如果可能…）
• 如何：所有流程都应该生成和使用元数据。从一个特定数据产品的初始发布开始，经过任何中间过程，直到最终消费。如果我们调整流程以使用元数据作为规范，并自动发现已发布的结果。根据定义，我们将激活元数据，使其准确并更新。因此，我们的元数据将具有更高的质量，并且绝对正确。

审计能力

• 原因：数据信任的另一个重要方面是能够看到谁、什么、什么时候发生了什么以及为什么发生。
• 如何：跟踪所有内容的更改。在跟踪更改时不要引入选择。应跟踪所有数据、所有代码和所有描述性信息的更改。这是确保100%审计跟踪的唯一方法。不允许手动编辑代码、模型或数据，并引入临时数据。

数据（质量）可观测性

• 为什么：我们必须能够信任我们消费的数据。努力不是为了拥有完美的数据质量，而是为了在数据不是最优的时候突出显示。努力获取数据，当数据不符合时发出警告。请记住，数据质量也是非常主观的，对一个消费者来说，糟糕的数据质量可能对另一个消费者是好的数据质量。。。
• 如何：当数据偏离预期结果时，我们应该能够创建警报、警告和/或通知。例如；
  • 当流程没有按照应有的方式进行预成型时。
  • 当数据丢失和/或暂停时。
  • 当一个数据集与另一个数据集中没有“相加”时
  • 出现缺失值时
  • 出现新值时
  • 当数据出现异常时

正如在组织内定义KPI一样自然，也应该定义“质量绩效指标”。

持久性和非易失性

• 原因：通过日复一日地提供稳定和可预测的结果，实现数据信任。
• 如何：确保我们根据已知的数据管理最佳实践对数据进行建模和结构化。
  • 保持历史记录并使数据在一段时间内具有可比性。
  • 添加新数据时，不应删除以前的数据。
  • 应保留历史数据，以便进行比较、趋势和分析。
  • 使用物理数据建模实践，使我们能够保留以前的数据并附加新的数据。
  • 如果可能的话，争取只插入模式，并将数据与现在的数据结合起来呈现。
  • 至少引入一种双时态方法。

合并和集成

• 为什么：围绕键和概念集成数据可以实现简单和可扩展的使用，而不会引入手动错误。将数据整合到单个来源点可以最大限度地减少数据的滥用。
• 如何：将数据建模为清晰简洁的数据模型。使用数据建模实践，使您能够适应和扩展新的属性、对象和上下文。事实上，我们的数据环境应该允许多个上下文/模型，而不会丢失对来源的跟踪。找到需要整合和集成的概念，并在建模任务上花费时间。暂停或丢弃当前纯粹隔离（或面向单个域）的用例的数据，直到出现跨域使用的用例。这使我们能够专注于重要的任务，并为那些具有高业务影响的事情整合对象、属性、上下文和度量。

3.适应性

一切都在变化…我们的业务、竞争对手、技术、源系统、数据消费模式、需求和人员。事实是，当我们的数据环境增长时，会引入更多的变化。对于我们与之互动的每一个系统，其发展速度都会发生变化。随着我们消费和分析越来越多的数据，我们将需要更多的数据。因此，它甚至不是变化的线性增长，而是变化的指数增长。因此，我们的数据环境必须以适应性为首要任务。

有适应能力的（Adaptable）

• 原因：变化会发生，也降会发生。
• 怎样：
  • 启用源代码一致的数据合同/产品，确保我们的交付流程具有稳定性。
  • 通过从元数据构建通用流程或生成的流程，我们可以简单地更改映射的目标或源方面。
  • 允许数据驱动的分类和业务规则，并将其推送给下游运营者。
  • 将分类和业务规则视为源数据。
  • 使用喜欢变化的整体建模方法。
  • 引入时间数据结构。
  • 努力在所有选定的工具中使用数据结构的动态分配。

数据建模

• 原因：任何信息都是无用的，除非以用户可以使用的格式传递。数据建模有助于将用户的需求转化为可用于支持业务流程和规模分析的数据模型。
• 如何：没有上下文和集成的数据很快就会失去价值。一个好的数据模型将在不破坏质量的情况下引入数据的扩展使用和探索。
  • 使用集合数据模型，花时间集成和规范术语和对象。
  • 为具有特定格式的特定用例在集成数据模型之上创建语义模型。

（去）集中

• 原因：同样的集中式流程，无论是否与数据有关，总是比同样的去集中式方法慢，因为从定义上讲，它无法扩展。然而，去中心化的方法更难协调一致。
• 如何：使用通用方法和基础架构实现去中心化。精简通用模式和定义可以帮助并行化数据处理，而不会失去控制。基于元数据发现的自动化通用过程将允许模式重新分解，而无需重新构建现有功能。集中数据环境中在去集中化时能够实现最佳效果的部分。一次又一次地重复该策略。

4.成本

毫无疑问，在我的经验中，成本是进行任何形式转换最常见的用例。关注成本变得越来越重要，因为成本可能不像以前那么清楚……今天，许多成本都是基于消费的。因此，硬件和人员配置不像以前那样可预测。一个糟糕实现的功能可能无法扩展，因此随着时间的推移，成本会越来越高。一个糟糕的工具选择可能需要我们的开发人员花更多的时间来掌握。性能较低的平台可能需要较长的等待时间，这些时间可能会花在其他任务上。所有这些例子都是浪费成本，可以通过政策和信任来避免。

Balance COST vs. PERFORMANCE on both tech and staff

简单

• 为什么：不那么复杂的系统成本更低
• 如何：尽量将复杂性隐藏在简单的工具、任务和结构中。制定可重复的模式，并从任何维护任务中收集知识。努力用简化的流程取代复杂的流程。

易于学习，易于掌握

• 为什么：将新的个人引入数据环境应该是一个短暂而顺利的过程。花在引进上而不是生产上的每一天都是沉没成本。
• 怎样：
  • 在数据环境的所有部分使用简单而高效的接口。
  • 避免编写脚本和键入命令，而是在UI中嵌入功能。
  • 对每个数据点具有完整的可追溯性。理想的情况是，只需单击一下，就可以看到原始数据的来源以及所有/任何转换。
  • 如果开发模式相同，那么理解和产生新功能将更加顺利。
  • 每一次技术故障都应该能够一次又一次地运行，而不会产生新的结果。这可以防止由于打嗝和糟糕的操作而导致的错误，还有一个额外的好处，即关于故障处理的决策将更容易做出。
  • 最后，一个干净的架构使它能够透明地了解发生什么、为什么发生以及在哪里发生，从而更快地进行故障排除。

低拥有成本

• 为什么：支付所需的计算费用，而不是更多，按需扩展，并简化维护任务。
• 怎样：
  • 标准化流程（开发和运营）。
  • 优化我们的接入点并利用可扩展的平台。
  • 明智地使用缩放，将不良模式转换为更具成本效益的模式。
  • 确保所有运行代码的标准和原则一致。
  • 尝试使用可以上下扩展的平台，希望不要将计算与存储捆绑在一起。

可预测的

• 原因：使用基于消费的价格模型有时会感到不确定和可怕。SaaS和云产品的价格可能会突然发生变化，这与我们想要的正好相反。技术的正确选择实际上是成本/性能的平衡。
• 如何：考虑分析、直接访问或基于内存的过程。什么最适合我们的用例。也许两者兼而有之？
  • 构建尽可能精简的管道，只使用更改的数据，或者至少使用可预测的数据块。
  • 根据自身和备选方案分析和比较成本。
  • 使数据环境中的组件可移植，并且不在特定技术上投入太多，防止技术锁定。谁知道呢，我们首选的SaaS可能会突然改变他们的价格模式，并危及整个设置。

5.技术

数据环境应被视为其自身的应用程序，并与源系统分离。这种明显而简单的方法使我们能够为用例优化工作负载，并使我们能够根据业务需求和未来场景对数据进行建模，而不与源系统绑定。

分离的（Separated）

• 为什么：将数据环境与源系统分离。针对用例进行优化，并针对未来进行构建。
• 如何：分离的平台、基于用例的数据模型、数据接收管道或发布模式。

并行且可缩放

• 为什么：我们的工作负载必须能够并行执行，并能够纵向和横向扩展，从而实现更多的流程和更多的消费者。
• 如何：首先保护一个或多个允许同时使用和并行读/写的数据平台。其次，流式数据与批处理数据相结合的安全模式。最后，将数据建模到物理模型中，以实现独立加载。

可变数据格式

• 为什么：一个好的数据环境可以支持所有格式的数据，无论它是结构化的、半结构化的还是非结构化的。
• 如何：通过允许数据以本机格式上传、自动分析并在数据发现目录中发布，简化数据发布过程。将数据复制为“单一”符合要求的数据格式，以便于访问和使用。

可访问性

• 原因：开放的数据环境使我们的数据消费者能够使用他们熟悉和熟悉的工具，从而提高生产产品的质量。
• 如何：让我们的数据环境变得灵活，因为新的工具和用户可以很容易地从调色板中添加或删除。然而，数据访问限制了可能性。这使我们能够更加数据驱动和灵活地处理数据，同时能够完全控制数据的完整性。相反，将消费锁定在用户甚至可能没有能力使用的选定工具集上，从而危及生产产品的质量。

6.可移植性

我们今天选择的技术在几年内可能不会那么突出。价格模型可能会改变，技术可能无法满足当前的工作量。也许我们的合作已经与另一家供应商达成了战略协议。无论如何，在可预见的时间内，有很多可能性，很难做出最佳的技术选择。

可移植的

• 原因：新技术以惊人的速度发展，云计算成本也在不断变化。新的用例出现，个人技能不断发展。为了避免我们的数据环境出现“遗留”品牌，我们必须将技术和成本与我们的用例和技能集相一致。
• 如何：接受我们的架构并不完美的事实。充分利用它。让每个组件尽可能少地负责，并尽可能多地自动化流程。使元数据处于活动状态，这意味着使用元数据作为我们自动化流程的中心组件。从元数据中生成代码、结构和配置，并尝试使用广泛接受的语言来处理数据，如SQL、python等。

总结

设置为适应而构建的数据环境。任何代码、模块和/或组件都应可移植到另一个平台、技术堆栈和/或服务。

接受我们的数据架构永远不会完美的事实，接受缺陷，但要构建自动化流程。代码和结构应该是生成的，或者是通用的，并且基于元数据。当我们面临必须更换某些东西的事实时，这样可以更容易地进行迁移。

确保我们在可重复任务上花费尽可能少的时间，在数据建模和定义上花费越来越多的时间。使用具有时间-时间概念的集成建模。这将使我们的系统更加稳定，并承受核心业务系统/流程的重大变化/重构。

始终专注于简化访问、数据发现、访问模式、结构简化和改进。