原文：
towardsdatascience.com/operational-and-analytical-data-54fc9de05330
不幸的是，我们仍然对操作数据和分析数据究竟是什么存在很大的困惑。因此，我们仍在努力寻找从整体企业视角处理数据的正确方法。
被识别为“数据大分裂”的东西，是我们今天数据架构中许多挑战的源头。操作数据和分析数据之间的区别在其当前的定义下并不有用。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/05562e47520e6f42c4df708f7ec6e7ea.png
图片由作者提供，灵感来源于 Zhamak Dehghani 的《数据大分裂》
我在之前的文章中讨论了那个特定的问题，并在我的“数据网格挑战与解决方案”系列的第一部分中做出了一个关键声明链接：
为了解决脆弱的 ETL 管道的挑战，让我们完全不要在操作数据和分析数据之间划一条严格的界限。相反，我们应该只区分源数据和派生数据——两者都可以用于操作和分析目的。
这个观点是如此基本，我想进一步阐述，以清楚地说明我为什么如此致力于**通用数据供应**，它有效地弥合了两个层面的差距。
错误观念
我之前已经说过，现在我要强调地重复一遍：
我们不应该区分操作数据和分析数据。
让我们分析 Zhamak Dehghani 在其关于数据网格的文章中提出的区分——遗憾的是，其他著名的架构老将在他们非常深刻的书籍《软件架构：难点》中重复了这一点；该书由 Neil Ford、Mark Richards、Pramod Sadalage 和 Zhamak Dehghani 共同撰写。
操作数据被解释为直接用于运营业务和为最终用户提供服务的使用数据。这些数据被收集并随后转换为分析数据。
来自他们书籍的一段引言：
这种类型的数据被定义为在线事务处理（OLTP），通常涉及在数据库中插入、更新和删除数据。
分析数据被解释为从操作数据转换而来的非易失性、集成、时变的数据集合，目前存储在数据仓库或湖中。
来自他们书籍的一段引言：
这些数据对日常运营并不关键，而是对长期战略方向和决策至关重要。
现在，这种区分有什么问题呢？
我提出了以下问题来挑战它：
在推导用于后续操作流程的智能 KPI 时，分析过程会产生哪种类型的数据？这是否是因为它基于数据仓库的输入在分析过程中推导出来的分析数据？还是因为它用于操作目的，直接用于运营业务，所以是操作数据？
数据湖和数据仓库（附带原始数据金库/数据湖）明确存储操作数据，用于后续的转换和分析目的。这是否是因为它在数据仓库或湖中以非易失性、集成和时变方式存储，所以是分析数据？并且推导出的分析数据实际上只存储在数据仓库或湖中？
我在提到的文章中没有明确给出答案，因为我认为没有它也很明显。但我不断遇到这种区分，我看到人们根据这个定义在管理数据时遇到困难。
所以，让我尝试说服你们，这种区分没有帮助，我们应该停止使用它。
在推导用于后续操作流程的智能 KPI 时，分析过程会产生哪种类型的数据？
让我们以一个现实世界的银行场景为例。我们从许多不同的操作系统中提取数据，并将其保存在我们的数据仓库中。我们从这些数据中推导出基本的 KPI，并将它们存储在数据仓库中，以便在操作在线贷款申请中计算个人利率。
我认为我们可以安全地说，KPI 是在分析过程中推导出来的，根据定义，结果是合格的作为分析数据。
但这些数据也用于操作目的，作为在线贷款申请中利率计算输入 – 这个在线流程肯定直接运行我们的业务。因此，它也符合被定义为操作数据的条件。
推导出的分析数据实际上只存储在数据仓库或湖中吗？
贷款申请的 KPI，尤其是利率，肯定不仅会存储在数据仓库/湖中。毫无疑问，它也会存储在操作贷款系统中，因为它是贷款接受的关键输入。
甚至有说法称，分析数据对日常运营并不关键，而是对长期战略方向和决策至关重要。
但用于利率计算的 KPI 以及贷款申请的接受对于商业银行的日常业务至关重要。
而这不仅适用于这个例子。规则而不是例外是，由分析过程创建的数据也用于后续的操作流程。
业务不区分分析和操作数据
这对于商业世界的现实场景来说根本不是一种有用的区分。只有业务流程，因此也是 IT 应用程序，可以被区分出具有操作或处置（计划或分析）目的。
但是，由于分析结果通常是改变业务运营方式决策的基础，这种区分也因此变得模糊。
然而，分析过程可以容忍更长的停机时间。因此，与运行业务的操作过程相比，分析过程的服务级别协议可以更加宽松。
但是，我们需要认识到所有数据，无论它是在操作或分析业务过程中生成的，对企业来说都很重要，始终具有操作意义。
数据不是一个过程，因此我们无法说操作数据就是OLTP。这根本说不通。
有用的区分
因此，让我们停止将数据分类为操作数据和分析数据。它缺乏有助的区分标准，并且从纯粹的技术角度来看，至多只能决定使用这些数据的应用程序应采用哪种服务级别。
源数据和派生数据
相反，我们应该区分源数据与派生数据——两者都可以用于操作和分析目的。
为什么这种区分更有帮助？
因为它与公司的业务视图相匹配。源数据是组织之前未可用的新数字化信息。它不能从企业中其他可用的数据中派生出来。
新数据必须通过人工输入或通过传感器、光学/声学系统或物联网设备自动生成。它也可以从组织外的数据提供者导入（或获取）。对于这种边缘情况，我们可以决定是否将其视为源数据或派生数据，尽管提供该应用程序的工作将超出我们的组织。
这种区分非常重要，因为派生数据可以通过将相同的业务逻辑应用于相应的源数据来重建。另一方面，源数据永远无法通过逻辑重建，因此必须进行备份以防止数据丢失。
数据本身是不同的，而不是使用这些数据的过程。因此，我们需要从技术和业务两个角度以不同的方式管理源数据和派生数据。
外部数据和内部数据
优秀的文章"外部数据与内部数据" by Pat Helland探讨了在面向服务的架构（SOA）环境中，在服务内部管理的数据与在服务之间共享的数据之间的区别。
Helland 的结论是，SOA 需要数据表示发挥各自的优势：SQL 用于内部数据，XML 用于服务间通信，对象用于服务内的业务逻辑。这种混合允许每个系统平衡封装、灵活性和独立性。
除了对 SQL、XML 和对象作为数据表示的严格使用外，我的核心观点仍然非常有效。
应用程序或服务应该是自包含的，封装的数据和逻辑仅通过消息进行交互。这种方法防止了对其他服务数据的直接访问，增强了服务内部的凝聚力，并解耦了服务之间的联系。
内部数据通常在 ACID（原子性、一致性、隔离性、持久性）事务上下文中操作，而外部数据则缺乏这种即时性。外部数据应表示为事件流（或数据原子）的集合，并最终保持一致性。任何发送到服务之外的数据一旦共享，应被视为不可变。我在《关于“数据网格挑战与解决方案”系列的第二部分》中对此进行了更详细的描述链接。
结论是，我们应该根据各自的优势使用数据表示。数据表示实际上是一个物理数据模型，任何支持该模型的数据库类型都有其特定的优势和劣势，适用于特定目的。
无论您在服务内部使用关系数据库、文档存储、图数据库，还是可能是一个非常基本的模型，如键/值存储，这都高度依赖于用例。
为了促进服务间的通信，提供模式独立性和灵活性的 XML、JSON、协议缓冲区、AVRO 或 Parquet 更适合用于外部共享不可变状态。
从我的角度来看，使用‘数据作为产品’作为不可变数据结构实现的方法最适合实现信息的通用共享。在您的服务内部选择要使用的物理数据模型是一个基于您的用例的技术优化决策。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/7f13677186cf4cc1cc8b00c85aa4428b.png
外部数据与内部数据对比 – 图片由作者提供
然而，您对整体业务信息的逻辑视图需要在所有应用程序或服务中保持一致，并且应独立于应用程序或服务内部使用的任何物理数据表示。
服务间通信可以通过 API 或数据作为产品的交换来实现。请参阅我的关于通用数据供应的文章，以了解整个概念。
如果你喜欢这篇文章，请考虑给它点赞。
你认为我们挑战开发一个可靠、易于更改和可扩展的数据架构怎么样？
我很乐意听听你的意见。
