泰安本地网站wordpress主页广告

泰安本地网站,wordpress主页广告,网站所需的主要功能,wordpress制作大型网站原文#xff1a;towardsdatascience.com/operational-and-analytical-data-54fc9de05330 不幸的是#xff0c;我们仍然对操作数据和分析数据究竟是什么存在很大的困惑。因此#xff0c;我们仍在努力寻找从整体企业视角处理数据的正确方法。 被识别为“数据大分裂”的东西&a…原文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 或数据作为产品的交换来实现。请参阅我的关于通用数据供应的文章以了解整个概念。如果你喜欢这篇文章请考虑给它点赞。你认为我们挑战开发一个可靠、易于更改和可扩展的数据架构怎么样我很乐意听听你的意见。