“简单是终极的复杂”— 莱昂纳多·达·芬奇

“大多数信息都是无关紧要的，大多数努力都是浪费的，只有专家才知道该忽略什么”—詹姆斯·克利尔，《原子习惯》

您拥有一个包含许多不同系统的复杂数据管道。从表面上看，它看起来非常复杂，但在幕后却是一团乱麻。它可能需要大量的管道工作来连接不同的部分，可能需要持续监控，可能需要一个大型团队，拥有独特的专业知识来运行、调试和管理它。更不用说，您使用的系统越多，您重复数据的地方就越多，数据不同步或过时的可能性就越大。此外，由于这些子系统中的每一个都是由不同的公司独立开发的，它们的升级或错误修复可能会破坏您的管道和数据层。 

如果您不小心，最终可能会遇到以下情况，如三分钟视频所示。我强烈建议您在继续之前观看它。

复杂性之所以出现，是因为尽管每个系统在表面上看起来可能很简单，但它们实际上将以下变量引入您的管道，并可能增加大量复杂性

1. 协议 - 系统如何传输数据？(HTTP、TCP、REST、GraphQL、FTP、JDBC)
2. 数据格式 - 系统支持什么格式？(二进制、CSV、JSON、Avro)
3. 数据模式和演变 - 数据如何存储？(表、流、图、文档)
4. SDK 和 API - 系统是否提供必要的 SDK 和 API？
5. ACID 和 BASE - 它是否提供 ACID 或 BASE 一致性？
6. 迁移 - 系统是否提供了一种简单的方法来将所有数据迁移到系统中或从系统中迁移出来？
7. 持久性 - 系统对持久性有何保证？
8. 可用性 - 系统对可用性有何保证？(99.9%、99.999%)
9. 可扩展性 - 它如何扩展？
10. 安全性 - 系统有多安全？
11. 性能 - 系统处理数据的速度有多快？
12. 托管选项 - 它是否仅托管或本地部署，或者两者兼而有之？
13. 云 - 它是否在我的云、区域等上运行？
14. 其他系统 - 它是否需要其他系统？(例如，Kafka 的 Zookeeper)

数据格式、模式和协议等变量加起来被称为“转换开销”。性能、持久性和可扩展性等其他变量加起来被称为“管道开销”。总的来说，这些分类共同构成了所谓的“阻抗不匹配”。如果我们能够衡量它，我们就可以计算复杂性并使用它来简化我们的系统。我们很快就会谈到这一点。

现在，您可能会争辩说，您的系统虽然看起来可能很复杂，但实际上是满足您需求的最简单系统。但是您如何证明这一点呢？

换句话说，您如何真正衡量并确定您的数据层是真正简单还是复杂？其次，您如何估计您的系统在添加更多功能时是否会保持简单？也就是说，如果您在路线图中添加更多功能，您是否还需要添加更多系统？

这就是“阻抗不匹配测试”发挥作用的地方。但让我们首先了解阻抗不匹配是什么，然后我们将进行测试本身。

什么是阻抗不匹配？

这个术语起源于电子工程，用于解释电阻抗不匹配，导致能量从点 A 传输到点 B 时能量损失。

简单来说，这意味着您拥有的东西与您需要的东西不匹配。要使用它，您需要取用您当前拥有的东西，将其转换为您需要的东西，然后使用它。因此，存在不匹配以及与修复不匹配相关的开销。 

在我们的案例中，您以某种形式或数量拥有数据，并且您需要在使用它之前对其进行转换。转换可能发生多次，甚至可能在中间使用多个系统。

在数据库世界中，阻抗不匹配发生的原因有两个

1. 转换开销：系统处理或存储数据的方式与数据实际外观或您对数据的看法不同。例如：在您的服务器中，您可以灵活地将数据存储在多种数据结构中，例如集合、流、列表、集合、数组等等。它可以帮助您自然地建模您的数据。但是，您需要将这些数据映射到 RDBMS 或 JSON 文档存储中的表中，以便存储它们。然后进行相反的操作以读取数据。请注意，面向对象语言模型和关系表模型之间特定的不匹配被称为“对象关系阻抗不匹配”。
2. 管道开销：您在服务器中处理的数据量和数据类型与您的数据库可以处理的数据量和数据类型不同。例如：如果您正在处理来自移动设备的数百万个事件，则典型的 RDBMS 或文档存储可能无法存储这些事件，也无法提供 API 来轻松聚合或计算这些事件。因此，您需要特殊的流处理系统，例如 Kafka 或 Redis Streams 来处理它们，并且可能还需要数据仓库来存储它们。

阻抗不匹配测试

测试的目的是衡量整个平台的复杂性，以及在未来添加更多功能时复杂性是增加还是减少。 

测试的工作原理是简单地使用“阻抗不匹配分数”(IMS) 来计算“转换开销”和“管道开销”。这将告诉您您的系统相对于其他系统而言是否已经很复杂，以及随着时间的推移，随着您添加更多功能，这种复杂性是否会增加。

以下是计算 IMS 的公式

该公式简单地将两种类型的开销相加，然后除以特征数量。这样，您将获得总开销/特征（即复杂性分数）。 

为了更好地理解这一点，让我们比较四个不同的简单数据管道并计算它们的得分。其次，让我们也想象一下，我们正在两个阶段构建一个简单的应用程序，这样我们就可以看到 IMS 分数随着时间的推移如何随着我们添加更多功能而变化。

阶段 1：构建实时仪表板

假设您正在从移动设备获取数百万个按钮点击事件，并且您需要在出现任何下降或峰值时发出警报。此外，您将整件事视为更大应用程序的一个功能。 

案例 1：假设您只是使用 RDBMS 来存储这些事件，尽管表格可能不适合。

1. 转换开销 = 1
   1. 您需要将事件流转换为表格。
2. 管道开销 = 1
   1. 您的管道中只有一个数据库。
3. 功能数量 = 1

案例 2：假设您使用 Kafka 来处理这些事件，然后将它们存储到 RDBMS 中。

1. 转换开销 = 1
   1. Kafka 可以轻松处理点击流；但是，从 Kafka 到 RDBMS 是一个开销。
2. 管道开销 = 2
   1. 您有两个系统（RDBMS 和 Kafka）。请注意，我们忽略了 Zookeeper。
3. 功能数量 = 1

案例 3：假设您使用 Kafka 来处理这些事件，然后将它们存储到 KsqlDB 中。

1. 转换开销 = 0
   1. Kafka 可以轻松处理点击流
2. 管道开销 = 1
   1. 您只有一个系统（Kafka + KSqlDB）。请注意，我们忽略了 Zookeeper。
3. 功能数量 = 1

案例 4：假设您使用 Redis Streams 来处理这些事件，然后将它们存储到 RedisTimeseries 中（两者都是 Redis 的一部分，并与 Redis 原生配合使用）。

1. 转换开销 = 0
   1. Redis Streams 可以轻松处理点击流
2. 管道开销 = 1
   1. 您只有一个系统（Redis Streams + RedisTimeSeries）
3. 功能数量 = 1

阶段 1 后的结论： 

我们在本示例中比较了四个系统，发现“案例 3”或“案例 4”最简单，IMS 为 1。在这一点上，它们都相同，但是当我们添加更多功能时，它们会保持相同吗？

让我们向我们的系统添加更多功能，看看 IMS 如何保持。

阶段 2：构建具有 IP 白名单的实时仪表板

假设您正在构建相同的应用程序，但希望确保它们仅来自白名单中的 IP 地址。现在您正在添加一个新功能。

案例 1：假设您只是使用 RDBMS 来存储这些事件，尽管表格可能不适合，并且它们使用 Redis 或 MemCached 用于 IP 白名单。 

1. 转换开销 = 1
   1. 对于 IP 白名单，您不需要进行任何转换。但是，您需要将事件流转换为表格
2. 管道开销 = 2
   1. 您有 Redis + RDBMS
3. 功能数量 = 2

案例 2：假设您正在使用 Redis + Kafka + RDBMS。 

1. 转换开销 = 1
   1. 对于 IP 白名单，您不需要进行任何转换。此外，Kafka 可以轻松处理流。
2. 管道开销 = 3
   1. 您拥有 Redis + Kafka + RDBMS。注意：我们忽略了 Kafka 也需要 Zookeeper。如果您添加了它，数字将进一步下降。
3. 功能数量 = 2

案例 3：假设您正在使用 Redis + Kafka + KsqlDB。

1. 转换开销 = 0
   1. 对于 IP 白名单，您不需要任何转换。此外，Kafka 和 KsqlDB 可以轻松处理流。
2. 管道开销 = 2
   1. 您有 Redis + (Kafka + KsqlDB)。注意：在这种情况下，我们将 Kafka + KsqlDB 视为同一系统的一部分。
3. 功能数量 = 2

案例 4：假设您正在使用 Redis + Redis Streams + RedisTimeSeries。

1. 转换开销 = 0
   1. 对于 IP 白名单，您不需要任何转换。此外，Redis Streams 和 RedisTimeseries 可以轻松处理流和警报。
2. 管道开销 = 1
   1. 您有 Redis + Redis Streams + Redis TimeSeries。注意：在这种情况下，这三个都是同一个系统的一部分。
3. 功能数量 = 2

第二阶段结论：

当我们添加一项新功能时，

• 案例 1 在第一阶段为 2，降至 1.5。
• 案例 2 在第一阶段为 3，降至 2。
• 案例 3 在第一阶段为 1，保持在 1。
• 案例 4 在第一阶段为 1，降至 0.5（最佳）。

因此，在我们的示例中，案例 4 的 IMS 得分最初为 1，是最低的之一，但随着我们添加新功能，它实际上变得更好，最终降至 0.5。

请注意：如果您添加更多或不同的功能，案例 4 可能不会保持最简单。但这就是 IMS 得分的理念。只需列出所有功能，比较不同的架构，然后查看哪一个最适合您的用例。

为了让使用更加简单，我们为您提供了一个计算器，您可以在简单的电子表格中实现它来计算 IMS 得分。

IMS 计算器

使用方法

1. 对于每个数据层或数据管道，只需列出
   1. 您目前拥有的功能。
   2. 路线图中的功能。这很重要，因为您需要确保您的数据层能够在没有任何额外开销的情况下继续支持即将推出的功能。
2. 然后映射每个功能的转换开销和管道开销。
3. 最后，将所有开销的总和除以功能数量。
4. 对具有不同系统的管道重复步骤 2 和 3，以便进行比较和对比。

数据管道 1

数据管道 2

摘要

很容易沉迷于构建复杂的数据层，而不考虑后果。IMS 得分是为了帮助您意识到自己的决策。

您可以使用 IMS 得分轻松比较和对比多个系统的用例，并查看哪个系统真正最适合您的功能集。您还可以验证您的系统是否能够承受功能扩展并继续保持尽可能的简单。

永远记住

“简单是终极的复杂”——莱昂纳多·达·芬奇

“大多数信息都是不相关的，大多数努力都是浪费的，但只有专家才知道该忽略什么”——詹姆斯·克利尔，《原子习惯》