‘数据历史学家‘是工业物联网 （IIoT） 中的一个众所周知的概念。它有助于确保和提高整体设备效率 （OEE）。
数据历史学家与其他工业趋势（如数字孪生或数据湖）有许多共同之处：它模棱两可;有多个定义。”过程历史学家”或”操作史学家”是同义词。”企业历史学家”相似，但更多的是企业级（工厂或全球基础设施），而”运营历史学家”则更接近边缘。历史学家软件通常嵌入或与标准 DCS 和 PLC 控制系统结合使用。
以下文章灵感来自”什么是数据历史学家？ “Operational Historian vs. Enterprise Historian: What’s the Difference?”
这个博客文章探讨了数据历史学家和事件流之间的关系，以及为什么Apache Kafka可能成为数据历史学家4.0的一部分。如果数据历史学家 4.0 是操作的、企业级的还是两者兼而有之，这还需要进行讨论。可以想象，这个问题没有单一的答案…
卡夫卡作为数据历史学家 ！* 替换其他数据存储、数据库或数据湖
在我们开始之前，只需一个简短的说明：这个想法不是使用Kafka作为单一，全能数据库，并更换您最喜爱的数据存储！无后顾之忧 ：-）请查看以下博客文章，了解有关此讨论的更多想法：
工业物联网 （IIoT） 中数据历史学家的用例
数据历史学家在不同行业有许多用途。以下是自动结果文章的无耻复制和粘贴：
- 制造现场记录仪器读数
- 工艺（例如流速、阀位置、容器水平、温度、压力）
- 生产状态（例如机器上/下、停机原因跟踪）
- 性能监控（例如单位/小时、机器利用率与机器容量、计划内停机与计划外停机）
- 产品家谱（例如开始/结束时间、物料消耗量、批次 = 跟踪、产品设定点和实际值）
- 质量控制（例如，在实验室内联线或离线质量读数，以便符合规范）
- 制造成本核算（例如可分配给生产的机器和材料成本）
- 公用事业（例如
资源利用率、温度、风扇速度）、网络基础设施（例如路由器吞吐量、端口状态、带宽核算）和应用程序（例如运行状况、执行统计信息、资源消耗）。
在讨论数据历史学家的功能之前，让我们先考虑一下为什么存在这个概念…
整体设备效率（OEE）
整体设备效益 （OEE） “是衡量制造生产力的黄金标准。简单地说，它确定了真正高效的制造时间的百分比。OEE 分数为 100%，意味着您只生产好零件，尽可能快，没有停止时间。在 OEE 语言中，这意味着 100% 质量、100% 性能（尽可能快）和 100% 可用性（无停止时间）。“
OEE 计划的主要目标之一是减少和/或消除制造中基于设备的生产率损失的最常见原因（称为六大损失）：
数据历史学家如何帮助减少和/或消除 Sig 重大损失？
数据历史学家的功能
数据历史学家支持确保和改进 OEE：
数据历史学家包含以下关键组件，可帮助实现工厂自动化和过程自动化：
- 集成：从 PLC（可编程逻辑控制器）、DCS（分布式控制系统）、专有协议和其他系统收集数据。双向通信，将控制命令发送回机器的参与者。
- 存储：存储数据以进行高可用性、重新处理和分析。
- 处理：随时间关联数据。加入来自不同系统、传感器、应用和技术的信息。例如：一批原材料到另一种原材料，一种连续生产与另一种生产，日班与夜班或夜班，一个工厂对另一个工厂。
- 访问：监控传感器、机器、生产线、工厂或全球基础设施。实时警报、报告、批处理分析和机器学习/深度学习
但是，混合集成和边缘计算的组合在大多数用例中至关重要。
这些功能在传统数据历史学家中通常非常有限和专有。因此，卡夫卡可能是一个不错的选择，为部分;正如我们在这篇文章后面看到的。
在将这些要求映射到基于 Kafka 的基础结构之前，让我们先考虑 OT、IT 和工业 4.0 之间的关系和差异。我们需要理解为什么有这么多的需求，从传统的数据历史学家到现代，开放，可扩展的物联网架构…
IT-OT融合的演变
数十年来，自动化行业一直习惯于专有技术、单体、无或非常有限的网络连接，没有或非常有限的安全强制（即身份验证、授权和加密，并不意味着安全，这实际上已经到位，而且至关重要）。
IT（即软件和信息技术）和 OT（即工厂、机器和工业自动化）之间的融合的演变正在改变这一点：
让我们从简化的角度从更多细节中考虑这种融合：
OT => 发布时间
OT 的主要兴趣是时间。通常为 99.999°。运营团队对快速周转时间不感兴趣。他们的激励是保持生产线运行10年以上，没有变化或停机。
IT =gt; 业务价值
IT 的主要兴趣是业务价值。在过去十年中，微服务、DevOps、CI/CD 和其他敏捷范例创造了一种新的思维方式。起源于硅谷科技巨头，拥有数百万用户和PB的数据，这是现在任何行业的新常态。是的，即使在自动化行业（即使您不想每天更新生产线的软件）。这就是”工业4.0″和类似术语发挥作用的地方…
行业 4.0 > OT + IT
行业 4.0 正在融合 OT 和 IT。这种数字化转型要求硬件和软件的新特点：
- 实时
- 可 伸缩 性
- 高可用性
- 解 耦
- 降低成本
- 灵活性
- 基于标准
- 扩展
- 安全
- 与基础设施无关
- 多区域/全球
2020 年，上述点在许多项目中在 IT 中是正常的
不幸的是，我们仍处于OT的早期阶段。至少，我们得到了一些开放标准，如 OPC-UA，用于供应商中立的通信。
车间、顶层、数据中心、云、移动、合作伙伴…
数据集成和关联性越多，实现的业务价值就越多。因此，OT 和 IT 的融合远远超出了车间和顶层。企业 IT 体系结构的其余部分也变得相关。这可以是在数据中心或公共云中运行的软件。
混合架构变得越来越普遍。与第三方应用程序集成可实现快速创新和差异化，同时与其他供应商和服务提供商建立复杂的合作伙伴关系。
正如您所看到的，实现工业革命 4.0 需要一些新的功能。这是事件流和阿帕奇卡夫卡开始发挥作用。
阿帕奇卡夫卡和事件流在自动化行业/IIoT
Apache Kafka 通过大规模提供数据引入、处理、存储和分析，从而帮助减少和消除 Sig 在制造中的巨大损失，而不会停机。
我不会详细介绍阿帕奇卡夫卡是什么，为什么人们在自动化行业和工业4.0项目中经常使用它。我在几个帖子中介绍了这个问题，已经：
- 阿帕奇卡夫卡是工业物联网、物流和零售边缘的新黑人。
- IIoT 数据集成和处理与阿帕奇卡夫卡，KSQL和ApachePLC4X。
- 阿帕奇卡夫卡作为数字双对，用于开放、可扩展、可靠的工业物联网 （IIoT）。
- 与阿帕奇卡夫卡的数字双子的物联网架构。
- 阿帕奇卡夫卡和机器学习，用于 IIoT 的实时供应链优化。
请注意，阿帕奇卡夫卡不是所有问题的全能者。上述帖子描述了何时、为什么以及如何与其他 IoT 平台和框架进行补充，以及如何将其与现有的传统数据历史学家、专有协议、DCS、SCADA、MES、ERP 和其他工业和非工业系统相结合
甚至这个领域的几家知名供应商也使用 Kafka 作为内部项目，而不是内部 IIoT 产品。通常，IIoT 平台具有 OEM 的多个不同旧版平台，用于中间件和分析。和其他组件。这种嵌入式技术动物园不能解决2020年IIoT项目的需求。
架构：卡夫卡作为数据历史学家4.0
以下体系结构显示了使用 Kafka 构建数据历史记录的一种可能选项：
这只是一个示例体系结构。显然，可以添加或删除单个组件。例如，现有的数据历史学家、HMI（人机接口）或SCADA系统，或其他IoT平台或流处理引擎可以补充或替换现有组件。
请记住：可扩展性和灵活性是成功的 IIoT 项目的两个关键支柱。遗憾的是，许多 IoT 平台都忽略了这些特性。同样，它们通常不提供可扩展性、弹性或高吞吐量。
我还看到一些公司使用”传统数据湖软件堆栈”构建企业数据历史学家：卡夫卡、Hadoop、Spark、NiFi、Hive 以及各种其他数据湖技术。在这里，卡夫卡只是进入HDFS或S3的摄取层。虽然使用此体系结构和这些技术构建数据湖仍然有效，但三个主要缺点是：
- 中央数据存储是静止数据，而不是实时数据。
- 拥有许多复杂技术的动物园。
- 由于技术和复杂的基础设施和体系结构，边缘部署不适用。
我在这里不会谈得更详细，这两种方法总是有权衡。考虑到这一点，现在让我们回到工业物联网中数据历史学家的关键支柱，看看这些结构如何与上述体系结构相适应。
数据集成/数据引入
当谈论数据历史学家或其他 IoT 体系结构时，一些供应商和顾问称此组件为”数据引入”。我认为这是非常不幸的，原因有三：
- 数据引入通常包括比将数据从数据源发送到数据接收器更多的任务。考虑筛选、动态扩充或类型转换
数据源
数据历史学家通常具有各种工业数据源，如 PLC、DCS（分布式控制系统）、SCADA、MES、ERP 等。Apache PLC4X、MQTT 或专用 IIoT 平台可用于数据引入和集成。
传统与工业集成标准
旧版集成仍然是2020年的主要焦点，不幸的是：文件、专有格式、旧数据库技术等。
OPC-UA 是标准化集成的一个选项。这仅适用于现代或增强的旧生产线。某些计算机支持其他接口，如 MQTT 或 REST Web 服务。
无论您是通过专有协议还是开放标准进行集成：集成通常发生在不同的层次上。虽然 OPC-UA、MQTT 或 REST 接口提供关键信息，但一些客户还希望直接从机器传感器集成原始 Syslog 流。这是更高的吞吐量（不太重要的数据）。一些客户还希望直接与SCADA监控系统集成。
与企业其他企业集成
虽然需要集成各种工业数据源，但这仍然只是故事的一半：当数据历史学家还与 IIoT 机器和应用程序以外的企业其他部门集成时，就会创造真正的附加值。例如，CRM、数据湖、分析工具、机器学习解决方案等。
此外，不同地区的工厂和中央群集（边缘和数据中心/云）之间的混合集成和双向通信。实时本地边缘处理加上用于聚合/分析的远程复制是最常见的混合方案之一。
卡夫卡连接/卡夫卡客户端/REST 数据集成代理
Kafka Connect是一种卡夫卡原生集成解决方案，为数据源和数据接收器提供连接器。这包括与旧系统、工业接口（如 MQTT）以及大型数据分析或云服务等现代技术的连接。大多数 IIoT 平台也提供自己的卡夫卡连接器。
如果没有可用的连接器，您可以轻松地通过Kafka 客户端 API 直接连接，几乎每种编程语言，包括 Java、Scala、C++、C、Go、Python、JavaScript 等
数据存储
卡夫卡不仅仅是一个消息系统。Kafka 的核心是分布式提交日志到存储事件，只要您想要或需要。博客文章”卡夫卡是一个数据库吗？“涵盖了所有的细节，以了解卡夫卡何时是正确的存储选项，何时不是。
分层存储，以降低成本、无限存储和弹性可扩展性
总之，卡夫卡可以永久存储数据。分层存储通过使用远程对象存储（如 AWS S3）实现无限存储、低成本和弹性可扩展性/操作，实现存储和处理的分离。
有状态的卡夫卡客户端应用程序
卡夫卡不仅仅是服务器端的。Kafka 应用程序是（或应该是）具有两个或多个实例的分布式应用程序，可提供高可用性和弹性可伸缩性。
Kafka 应用程序可以是无状态的（例如，对于流式 ETL）或有状态。后者用于构建数据（例如聚合）或业务应用程序的具体视图（例如预测性维护实时应用）。这些客户端将数据存储在客户端（内存中或磁盘上），以便进行实时处理。零数据丢失和保证处理顺序仍然得到保证，因为 Kafka 应用程序利用 Kafka 日志作为”备份”。
数据处理
数据处理为您的数据历史学家增加了真正的价值。不同数据源的不同数据流的验证、丰富、聚合和关联可实现有见地的监视、主动警报和预测操作。
实时供应链管理
供应链管理 （SCM） 与及时 （JIT） 和正序列 （JIS） 库存策略是一个很好的例子：关联来自生产线、MES、ERP 和其他后端系统（如 CRM）的数据。应用在数据湖中训练的分析模型进行实时评分，以便对合作伙伴订购零件做出正确的预测。
我最近与Expero进行了一次网络研讨会，讨论“Apache Kafka 和机器学习在 IIoT 中实时供应链优化的好处”。
使用卡夫卡流/ksqlDB 进行流处理
卡夫卡流（Java，阿帕奇卡夫卡的一部分）/ksqlDB（SQL，Confluent）是两个开源项目，提供卡夫卡原生流的实时大规模处理。 ksqlDB
这些框架可用于”简单”流式处理 ETL，如筛选或扩充。但是，可以联接不同流的强大聚合来构建有状态的应用程序。您还可以添加自定义业务逻辑来实现您自己的业务规则，或应用分析模型进行实时评分com/kaiwaehner/kafka-Streams-机器学习-示例”rel=”nofollow”目标=”_blank”=卡夫卡流示例，带有 TensorFlow 和KSQL，带有H2O.ai。
数据访问
现代数据历史学家不仅仅是HMI和SCADA。工业 4.0 具有越来越多的流数据，需要通过开放的体系结构和生态系统进行大规模实时监控、警报和分析。
人机接口 （HMI） 以及监控和数据采集 （SCADA）
人机界面 （HMI）是一种用户界面或仪表板，用于在工业流程的上下文中将人员连接到机器、系统或设备。HMI 允许用户：
- 直观地显示数据。
- 跟踪生产时间、趋势和标签。
- 监督关键绩效指标 （KPI）
- 监控机器输入和输出。
- 和更多。
监控和数据采集 （SCADA） 系统收集和记录信息或连接到数据库以监控系统操作。
HMI 和 SCADA 解决方案通常是专有解决方案;通常具有单一、不灵活且不可扩展的特征。
卡夫卡作为下一代 HMI、监控和分析
Kafka 可用于构建新的”HMI”，以进行实时监控、警报和分析。这不是现有技术和用例的替代品。HMI 和 SCADA 在过去几十年中为它们所构建的内容进行了良好的工作。Kafka 应补充现有的 HMI 和 SCADA 解决方案，以处理大数据集并实施创新的新用例！
实时扩展分析、商业智能和机器学习
HMI 和 SCADA 系统有限，专有的单体。Kafka 支持将工业基础设施与现代技术相结合，实现强大的流式分析（流推送与拉取查询）、传统的SQL 原生商业智能（使用 Tableau、Qlik、Power BI 或类似工具）和分析（使用 TensorFlow 或云 ML 服务等工具）。
卡夫卡连接是使用集成与你最喜欢的数据库或分析工具。对于某些用例，您可以简化体系结构，”只是”使用Kafka 本机技术，如 ksqlDB 及其拉取查询。
云中的数据历史学家
云在这里停留。它在某些场景中具有巨大的优势。但是，大多数公司将内部流程和 IT 系统与云联系起来非常谨慎。通常，甚至很难通过 TeamViewer 访问车间或顶层的计算机来调整问题在现实中，边缘和混合架构是非常保守的工业物联网市场的新黑色。这完全有意义，因为工厂和生产线无论如何都会留在内部。将所有大数据集发送到云没有意义。这对成本、延迟和安全性有着巨大的影响。
分布式、混合、边缘和全局阿帕奇卡夫卡部署的体系结构模式
Kafka 部署在各种体系结构中，具体取决于方案和用例。边缘部署与云基础结构和混合双向复制方案一样常见。
安全
无论您是否决定将数据移动到云中：安全性对于工业 4.0 计划来说都非常重要。
虽然数据历史学家的用例很棒，但安全性是成功的关键！身份验证、授权、加密、RBAC（基于角色的访问控制）、审核日志、治理（架构实施、数据目录、标记、数据血统等） 等。
许多车间没有任何安全（因此没有互联网/远程连接）。由于机器的制造可以停留 20 年、30 年或 40 年，因此很难调整现有机器。实际上，未来几年将给工厂带来旧专有的非连接传统机器和现代互联网功能新机器的混合。
从外部（即监视应用程序甚至其他数据中心），您可能永远不会访问不安全的遗留计算机。部署在工厂的数据历史学家可用作这些旧计算机的终止点。类似于互联网代理中的 SSL 终止。用 Kafka 将不安全的遗留计算机与其他计算机隔离，是我看到的越来越多的常见模式。
从 IT 和 OT 系统之间的网络安全角度来看，Kafka 是一个网关，但为任何可能为更有效地运营、设计或管理业务做出贡献的用户提供重要信息。当然，安全产品（如安全网关）是对卡夫卡数据流的补充。
与卡夫卡进行端到端安全沟通
卡夫卡支持开放标准，如 SSL、SASL、Kerberos、OAuth 等。可以配置/实现身份验证、授权、加密、RBAC、审核日志和治理。
这在目前大多数其他行业都是正常的。在自动化行业，Kafka 及其生态系统可以为不同系统之间的通信和数据处理提供安全的环境。这包括边缘计算，还包括替换边缘与另一个数据中心或云之间的数据时的远程通信。
卡夫卡作为数据历史学家，以改善OEE和减少/消除Sig大损失
连续实时数据大规模24/7的引入、处理和监控是成功工业4的关键要求与 Apache Kafka 及其生态系统一起进行事件流为实施这些现代 IoT 架构带来了巨大的价值。
此博客文章探讨了Kafka 如何用作数据历史学家的组成部分，以改善 OEE并减少/消除制造中基于设备的生产力损失的最常见原因（又名 Sig 大损失）。
卡夫卡不是全能选手。了解与其他技术相比，物联网项目中的附加值和差异化，并将其以正确的方式与现有和新的工业 IoT 基础架构相结合。