数据 Historian 与时序数据库

作者：Jason Myers / 开发者
2024 年 3 月 13 日

很容易将技术购买决策描绘成非黑即白，一方是应许之地，另一方是反乌托邦的荒原，公司和利润在那里走向灭亡。但这与现实不符。

相反，组织需要根据自身需求权衡技术上的利弊。因此，虽然站在“推倒重来”的山顶上，高呼你的新技术的优点很容易，但这并不是大多数组织愿意做的事情。

在工业和制造业领域，数据 historian 是工业 3.0 的关键要素，计算机在其中占据中心舞台。事实仍然是，从工业 3.0 到工业 4.0 的进步是渐进的。一些公司可能会从工业 3.0 发展到 3.5 再到 3.7，然后才最终达到工业 4.0。随着技术的发展和组织拥抱 工业 4.0，他们必须如何适应？对于每个组织来说，这些渐进式的变化看起来都不一样。

在做出任何重大决定之前，重要的是要了解游戏中的参与者。就本文而言，我们讨论的是 InfluxDB，一种专门构建的时序数据库，以及传统的数据 historian。

数据 Historian：优点

数据 historian 并非一无是处。如果技术不能很好地工作，就不会在一个特定领域（如数据 historian）变得普遍。

• 特定领域： 供应商为工业和产业应用构建数据 historian。这些系统专注于工业环境的独特特性和需求，并提供与 PLC、SCADA、各个机器等配合使用的工具。
• OT 集成： 数据 historian 与运营技术 (OT) 控制系统和标准紧密集成。
• 端到端：数据 historian 具有几乎工业运营商所需的所有功能。较新的数据 historian 甚至提供丰富的 UI 来可视化数据。数据 historian 更像是一种“全包”选项，在单个解决方案中提供广泛的功能和能力。它们可能不是交钥匙解决方案，但比 DIY 更接近。

数据 Historian：缺点

虽然这些优点听起来都不错（这就是它们是积极因素的原因），但我们必须记住，这种考虑的背景是向工业 4.0 的过渡。数据 historian 是出色的独立解决方案，但是当您想对数据做更多事情时会发生什么呢？

• 传统技术：封闭的软件系统创建了“围墙花园”，限制了组织适应、创新和发展的能力。数据 historian 是一种为一项工作而设计的工具。但是，如果多人需要将相同的数据用于不同的目的呢？这就引出了下一点……
• 供应商锁定： 围墙花园使得几乎不可能与现代数据生态系统集成。封闭的专有软件使得与供应商愿意支持的工具之外的工具集成变得困难，甚至不可能。随着其他系统的进步，新的协议和标准涌现，供应商优先考虑互操作性，封闭系统限制了您可以对数据执行的操作。
• 数据孤岛： 这些系统通常在本地运行，因此当您的数据 historian 无法连接到其他系统时，historian 中的数据就会变成孤岛。一些组织甚至可能在一个站点运行多个数据 historian。这些系统的封闭性质阻止用户跨系统整理数据和提取见解——这是限制您从数据中产生价值能力的另一个因素。如果其他系统无法访问您的数据，那么它们也无法从中受益。
• 成本：由于它们是非常小众的系统，数据 historian 往往很昂贵。自定义更改（如果可用）既昂贵又耗时，因为供应商致力于其专有标准并且开发资源有限。

InfluxDB：优点

• 开放技术： InfluxDB 构建于开放技术之上，在应用程序开发中具有很大的灵活性。利用现代技术和开放标准，用户可以访问一流的服务和工具。这些功能使团队能够更快地适应、发展、开发和迭代应用程序。访问更大的生态系统、API、连接器、广泛采用的工业协议和第三方工具，使开发人员可以选择他们喜欢的工具并将其与 InfluxDB 集成。可访问性和互操作性是工业 4.0 的关键组成部分，而这正是像 InfluxDB 这样的 TSDB 的优势所在。
• 查询语言： InfluxDB 支持 SQL 和类 SQL 的 InfluxQL 查询语言。SQL 基本上是数字时代的通用语言，缩短了许多用户的启动时间。拥有多种查询数据的方式为用户提供了另一种灵活性。InfluxDB 还支持多种语言的客户端库，以简化数据写入。
• 可扩展性： 有几个值得一提的可扩展性方面。首先是数据库资源和基础设施。作为一种云原生数据库，InfluxDB 可以作为完全托管的服务使用。驻留在主要的云环境中使 InfluxDB 能够根据用户的需求进行扩展和缩减。另一个方面是它扩展以满足不断增长的数据摄取需求的能力。InfluxDB 旨在处理大型时序数据集，而不会影响性能。
• 更低的存储成本：这对于希望利用预测分析和其他高级分析以及人工智能工具的工业组织尤其重要。这些组织需要高度精细的历史数据来馈送和持续训练 AI 和机器学习算法。存储这些数据可能很昂贵，这就是为什么 InfluxDB 分离了计算和存储并利用了多个存储层。冷存储 用于不经常访问的数据，位于低成本对象存储上，并且可以 将存储成本降低 90% 以上。
• 多种部署选项： InfluxDB 是云原生的，但也适用于那些想要或需要控制其基础设施的用户进行本地部署。用于边缘部署的单节点实例还允许组织将数据收集和处理更靠近数据源，然后可以 复制 这些数据返回到中心化实例（如果需要）。

InfluxDB：缺点

没有一种解决方案可以随时随地为所有人完成所有事情，数据库也不例外。这正是专业数据库存在的原因。

• 非特定领域： InfluxDB 不是专门为工业或制造应用构建的。它没有数据 historian 那样的内置功能，并且无法从一开始就准备就绪。添加这些东西需要额外的时间和精力。
• 构建与购买： 当您选择像 InfluxDB 这样的时序数据库时，您就知道您需要构建一些东西。这需要领域知识（或至少学习的时间/意愿）和开发人员资源。
• 需要堆栈： 与构建/购买的想法相关，因为 InfluxDB 不是特定领域的，构建端到端解决方案需要使用更广泛的生态系统才能获得与数据 historian 相当的功能。一些组织不想要或没有资源来学习或管理整个生态系统。

部署：爬行、步行、跑步选项

回到我们最初的想法，在选择数据 historian 和/或时序数据库时，您应该考虑您组织的需求以及最适合他们的解决方案。

以下示例只是示例。每个组织的需求都不同，需要的权衡也不同，但希望这些示例能为您思考数据 historian、您的需求以及时序数据库在其中的位置提供一个起点。

爬行

假设您的数据 historian 对您的组织运行良好，但您对数字化转型感到好奇。毫无疑问，您已经在您的 OT 堆栈上投入了多年和大量资金，因此您不会为了实验而到处拔插头。

您可能采取的一种方法是使用 Telegraf 来测试数据收集。本质上，您可以配置 Telegraf 以从与您的数据 historian 收集的相同来源收集数据。您需要从一个小数据集开始，以降低存储成本，因为您会将相同的数据写入两个不同的位置。

但这样做可以让您了解在 OT 堆栈中将 InfluxDB 放置在何处。并且它可以产生合法的生产数据进行实验，以了解您可以获得什么样的见解。

步行

让我们将此示例提升到一个新的水平。还记得我们提到一个工厂可能在同一地点运行多个孤立的 historian 吗？好吧，为每个 historian 复制上述实验（但将每个 Telegraf 实例的数据输出到一个 InfluxDB 实例）允许您组合这些数据流并打破这些孤岛。

使用像 Grafana 这样的可视化工具，您可以创建一个单一的管理平台来跟踪每个系统的单独性能以及它们的集体性能。

跑步

一旦您了解 InfluxDB 如何在较小程度上与您的数据 historian 一起工作，您就可以构建该集成。将更多系统和工具连接到 InfluxDB。研究其他生态系统工具，您可以使用这些工具来替换数据 historian 的功能。开放技术的一个好处是您可以自定义这些替换以满足您的特定需求。

如果您正在扩展运营，并且您的 TSDB 实验进展顺利，那么可能是时候采用 TSDB 而不是昂贵的传统数据 historian 了。但关键是您可以轻松地进入开放标准和时序数据库。它不必是完全的推倒重来。您要确保您使用的技术满足您的需求，因此您需要确保从数据 historian 到 TSDB 的权衡是有意义的。

也就是说，认真对待数字化转型的组织很可能很快就会处于需要开放标准的连接性、互操作性和可访问性的地位，以保持竞争力。传统技术之所以成为传统是有原因的。但幸运的是，对您的系统进行面向未来的改造不必在一夜之间完成。在工业 3.0 到 4.0 的转型频谱中，处于 3.6 也没关系。选择是存在的。您只需要确定您的组织可以接受哪些权衡，例如成本、功能、能力等，并据此制定计划。

要开始尝试这些想法和 InfluxDB，立即注册免费帐户。

其他资源

• 替换数据 Historian 的战略方法
• 升级您的 IoT/OT 技术堆栈：用 InfluxDB 替换传统数据 Historian