构建公共卫生联邦数据目录平台bob体育客户端下载

视频记录

大家好，我是Mark Paul，今天和我一起的是Anshul Bajpai。我们演讲的题目是，为公共卫生建立联邦数据目录平台。bob体育客户端下载今天我们有很多内容要讲，我们将从讨论集中式数据目录的问题开始。然后，我们将转向联邦数据目录平台形式的解决方案。bob体育客户端下载我们将讨论一些设计模式，我们将继续讨论一个被称为智能记录排名系统的特定用例，然后我们将以一些可以带回家的架构模式结束。我们来自澳大利亚健康直接公司。我们是国家政府所有的非营利组织，为所有澳大利亚人提供可信的健康信息和建议。在澳大利亚健康直接网站上，我们有国家卫生服务目录。这基本上是澳大利亚数字卫生基础设施、国家卫生服务目录以及提供这些服务的从业人员。

因此，让我们从集中式数据目录的问题开始。

医疗保健目录-关键医疗保健基础设施

医疗保健目录本质上是重要的医疗保健基础设施，因为它们支撑着世界各地的大多数医疗保健系统。这是因为它能促进护理协调。例如，如果你去看医生，医生会推荐你去找一位专家，他们会使用医疗保健目录来找到这位专家。或者如果你要去医院，在你住院结束时，会有一份出院总结发给你的医生。它们使用由Healthcare Directory提供支持的安全消息传递，因此它们是单点故障。如果你的数据质量不好，这就会被放大，因为我们对病人有临床风险。例如，如果你在事故中找不到最近的急诊室会发生什么?所以我们需要以一种更积极主动的方式来看待这个问题。

当前的医疗保健目录本质上是集中管理的数据库应用程序，这些数据通过内容管理系统和呼叫中心更新。这个模型反应性很强，效率很低，这主要是因为目录内的数据更改频率很高。例如，医疗保健服务不断改变其工作时间，医疗保健服务中的从业人员不断在医疗保健服务之间移动。所以数据波动很大，我们需要一个更积极主动的方法来处理这个问题。

无论您是在医疗保健行业还是任何其他与集中式数据存储相关的问题作斗争的行业，我们采用的一个解决方案是转移到联邦数据目录平台。bob体育客户端下载

联邦数据是一个强大的概念。

您可能熟悉联邦数据库，它基本上是将多个自治数据库系统映射到单个联邦数据存储。这里没有聚合。相反，它是多个数据存储的抽象。

然后是联邦数据平台(Federated Data Platform)，bob体育客户端下载它基本上是通过使用多个自治源数据源来创建黄金标准数据的受控聚合。这里的转向架构模式就是我们所说的事件来源，你们应该很熟悉。我们将在后面的幻灯片中详细讨论。

因此，医疗保健目录的数据联合可以描述为构建联邦数据谜题。如果你看那边的屏幕，在你的右边，你会看到我们认为的黄金标准谜题。现在，我们不是这些数据的主人，相反，我们所做的是，注册记录系统来制造这个谜题。我们基本上通过管道来创建和协调创建。所以我们的角色不是创造谜题，而是通过使用记录系统来创造谜题。在这个例子中，我们有Opera，它是记录系统，我们有医疗保险，它拥有这个难题的特定部分，然后我们协调这个创造。

让我们看看联邦数据平台的一些设计模式。bob体育客户端下载

整个过程始于我们所说的来源分类。基本上，我们确定权威记录系统。一旦我们这样做了，他们可以扮演三个角色中的一个。他们可能是真相的来源，也可能是我们数据子集的权威所有者。它们可以是验证源，然后我们用它来验证和提高数据质量，或者它们可以是通知源，本质上是增加数据货币。数据货币基本上是我们的数据是最新的程度。

一旦我们有了这些，我们就进入我们所谓的实体/渠道设置。我们创建了黄金实体这是我们最终的实体模型。例如，医疗保健从业者和组织从业者。我们有我们的原始实体，这些是原始源特定的实体，它们处于预映射阶段，然后我们将其转换为我们的黄金实体。然后我们有我们的源通道，基本上是我们的管道通道，将这些原始实体转换成我们的黄金版本实体。

接下来，我们进入一个称为属性来源的过程。本质上，这是确定记录系统与我们的数据实体之间的关系。通过屏幕上的例子，你可以看到一个医疗服务。在屏幕中间，你可以看到这个叫做从业者关系的东西。基本上，从业者在这个诊所工作。我们使用一个叫做健康范围的记录系统。您将使用它们作为通知源，以保持该特定属性的设置是最新的。这又回到了我之前讲过的建立联邦数据谜题的例子。

好了，我们要向你介绍我们的数据湖。我们会在后面的幻灯片中详细讲解。但在屏幕的左边，你可以看到我们认为我们的数据来源。所以基本上是登记我们的记录系统的数据从那些系统的记录进入我们的管理数据湖到一个预处理层，然后我们把它移动到一个原始的，阶段，黄金模式，你会很熟悉，然后一个黄金标准记录退出使用一个发布应用程序，然后使这些黄金，阶段，原始标准数据可用于我们的消费产品下游。现在让我们深入其中一些特定的层次并讨论它们。

预处理层

所以这一切都始于预处理层。对我们来说，这些基本上就是我们环境中的笔记本。在这个笔记本电脑中，我们基本上会触及原始API，我们得到数据提取，比如我们可以从S3中获取数据。这一层的主要目标是生成我们所说的源数据事件对象，它包含两个属性。它包含数据有效负载，即原始实体有效负载。它还包含一个出处，然后用于来源鉴定。

原始加工层(青铜)

一旦预处理完成，我们然后转移到我们的原始处理层或青铜层。在这里，我们执行常规的高级数据解析和清理。没有具体到实体本身。但我们会考虑，这个文件格式正确吗?或者这甚至是JSON。一旦完成，我们就生成了所谓的核心数据事件对象，这是传递到下游层的基本构建块，我们也可以捕获转换/操作更改。然后我们生成事件跟踪ID或端到端跟踪标识符。然后我们还以数据沿袭对象的形式进行数据沿袭捕获，它从这一层开始，但也发生在下游层。

阶段处理层(银色)

因此，一旦我们的角色完成，我们就会转移到我们的舞台处理层或银层。这就是大部分手术发生的地方。这里发生了很多事情。但是在非常高的级别上，我们从映射操作开始，从原始源实体转换为黄金实体模型，然后继续进行引用操作，这基本上是使用引用数据查找进行充实。然后，我们转向合并操作，在此操作中，我们获得最后一个已知的最佳版本，并根据所需的更改集创建数据的新版本。最后，我们进入验证操作，根据黄金标准规则执行最终验证。从本质上讲，通过验证操作，就得到了新版本的黄金标准数据。

现在让我们更详细地看看合并操作。它的工作原理是我们得到一个改变特定数据属性的请求，然后我们匹配并使用主键得到属性的最后一个版本。然后我们使用一个叫做Delta Determination的过程来合并最后一个版本，本质上是寻找我们需要实现的更改。然后我们生成数据的新版本。在这个过程中，我们做了这个叫做元数据归因的事情，在这里我们记录每个事件中每个属性的每个变化。这让我们可以做一些运行时决策。通过查看谁是最后一个改变这个属性的人。我们还在此层中生成数据沿袭对象。事实上，我们在这一层生成了大量的数据沿袭对象，以捕获属性异常、违规、状态更改等。

黄金处理层

所以一旦我们完成了阶段层，我们就会转向黄金处理层。现在，gold处理层的职责是确保实体关系验证并防止孤儿。所以它确保这些实体关系是完整的。这也是我们进行再处理和重放的一层。基本上，我们可以如果你想重新应用一些引用数据或业务规则，我们可以从这一层重放。或者，如果您想回滚到数据的旧版本，我们也可以使用这一层。黄金层也是一个数据科学层，因此我们的数据分析师会不断查看我们的谱系和数据更新历史，他们基本上会得出数据质量基准，我们用这些基准来提高数据质量。

数据来源对象

让我们看看数据来源对象。这个对象，就像我提到的，是在预处理层生成的。它用于追踪事件的确切起源。我们可以看看，谁是提出这个改变的确切来源，我们甚至可以追溯到它的原始来源，甚至可以追溯到外部标识符，比如源空间Jira Ticket号码。我们也追踪源意图。换句话说，源试图对这个特定的数据更改做什么?

数据沿袭对象

然后我们有数据沿袭对象或DLO，这个DLO是在每一层生成的。它封装了实体事件发生的操作结果，并帮助我们捕获随时间变化的数据质量偏差。因此我们捕获异常和警告之类的东西。异常用于修复数据，警告用于提高数据质量。我们还将其用于端到端数据流和可见性，因此我们确切地知道我们的数据发生了什么。现在我们捕获了很多这样的dlo，例如，在过去的几个月里，我们已经捕获了超过2500万个可以追溯到特定来源的问题。这些DLO对象在我们的数据改进策略中扮演着关键的角色，我接下来将对此进行描述。

我们将进入一个主题，我们称之为记录排名的情报系统。这是我们一直在使用的内部流程，这是我们第一次公开分享。所以我很兴奋能和你们分享这个。

到目前为止，您已经看到，我们是一个大量构建在专用记录系统上的系统，因为我们是一个联邦数据存储。所以这些专用的SoR，记录系统对我们的数据属性有完全的更新权限。这样做的问题是上游数据质量回归流到我们的系统中，这是我们不希望看到的。而且这些记录系统中的一些没有频繁的变化。这使得我们的数据看起来似乎不经常变化。所以我们没有数据货币，这也是我们不想要的。

所以我们想出了一个解决方案，我们称之为候选记录系统或CSoRs。现在，您可以将它们看作是与专用记录系统竞争更新相同数据属性的备用记录系统。比如那边的例子，我们有医疗服务。它有营业时间和联系方式。所以SoR A，也就是专用记录系统有能力更新这个。但是如果需要的话，我们的候选记录系统B和C也可以填写和更新。

手动排名

目前，我们鼓励并支持这种竞争，通过使用我们所谓的手动排名来更新数据。这基本上是基于业务优先级分配的排名。在那边的例子中，我们有记录A系统，它有第一优先级，用来更新营业时间和联系方式。候选SoR B和C更新联系详情的优先级较低。当我们使用流应用程序时，在我们有多个源同时竞争更新相同属性的场景中。我们使用这个排名指标来了解哪个要比哪个更重要。基本上，如果有更新数据的竞争条件，谁赢谁。

自动排名

一旦我们有了手动排名，它使我们能够做我们所谓的自动排名。这基本上是过去30天内数据谱系结果的汇总。它是由我说过的数据谱系对象提供支持的。在这个例子中，我们有System of Record A，你可以看到它对联系人进行了10次更新，这导致了4个警告和2个错误。而候选SoR B进行了八次更新，但只产生了一次警告。因此，通过查看这些聚合，我们能够根据源的近期性能提高优先级。本来记录A系统有更新联系方式的优先级，但是通过观察记录B候选系统的性能，我们给了它更高的优先级，好像我们觉得它可以提高我们的数据质量。

hea智能排名-未来状态医疗保健服务实体功能

我们的目标是智能排名，我们说这是未来的状态，但我们已经开始实施了。我们的五官在长。换句话说，我们收集的关于数据质量的源基础指标正在增长。在那个例子中，我们有记录A的系统，我们知道它要进行多少次更新。有多少警告导致了这些，有多少错误导致了这些，有多少公众投诉可以追溯到记录系统的数据更新，我们甚至有像经度和所有数据质量指标的完整性，准确性，等等，我们正在收集。与此同时，我们的资源也在增长。所以我们有了更多的登记系统和候选人登记系统。我们也有这种情况，我们称之为，季节性数据回归，我们注意到一些记录系统，他们经历了，也许在一年的某个时候，他们经历了数据清理，这可能会提高或导致数据质量下降。因此，对我们来说，研究能源的近期表现已不再可行。所以我们提出了一个数据源特定的数据质量模型。 And essentially what this gives us is a confidence score based on past performance, which we then can apply in real time. So we’re not far from implementing this. And this then becomes the foundation for what we call Organic Data Quality improvement. Cause once we have this in place, all we have to do is enroll as many sources as possible, and then naturally compete to increase our data quality in this environment.

接下来，我将介绍一些架构模式。我想邀请Anshul，他将展示这一部分。-谢谢马克，为我们提供了背景。

现在让我们看看联邦目录中的体系结构模式。谈到Healthdirect的架构模式，我们基本上在架构中有几个主要组件，数据生产者，数据消费者，开发控制数据控制平面和操作控制窗格。现在，数据生产者要么把数据推送给我们，要么我们从数据中抽取数据，Healthdirect基本上与几家健康整合商达成了数据共享协议。根据数据源的类型，我们有多种方法来获取和收集链集，比如通过API端点，或者通过位于挂载S3桶顶部的安全FTP。由于联邦目录严重依赖外部引用数据来丰富传入事件，因此我们也接收分类法引用数据，例如来自第三方供应商。事实上，我们有一个内部数据源也通过kinesis stream推送内容更新。所有这些数据源首先都流经预处理器，作为两个关键步骤，预处理器负责数据采集和数据摄取。所有这三个进程都是使用数据砖笔记本构建的，并选择Scala作为编程语言。Spark作为分布式计算的引擎。现在，数据消费者依赖于医疗保健服务联邦目录中可用信息的统一和聚合视图。 A data event, when successfully processed inside data control plane gets published to the kinesis stream, which then gets loaded on to one of the dynamo DB tables. This in turn gets exposed to the external health integrators and internal users like Healthdirect service finder via consumer API’s, file API’s and other channels.

现在谈论开发控制平面，这个平面意味着定义工程团队用于执行开发工作、构建新特性和应用错误修复、准备报告、维护CICD管道等的工具和ide。现在，数据砖笔记本是Healthdirect团队中广泛使用的工具之一，用于构建脚本、应用程序、仪表板、生成报告或运行特别查询，并为此执行计算密集型聚合。由于AWS在Healthdirect内被用作企业级云平台。bob体育客户端下载例如，AWS代码提交与代码部署结合在一起，代码管道也可以在整个平台上使用，以管理自动化管道，以便更快地将产品推向市场。bob体育客户端下载

说到数据控制平面和操作控制平面。数据控制平面，这主要是各种实时处理应用程序的集合，这些应用程序是使用Scala作为支持函数范式的语言构建的，它的Spark结构化流作为分布式引擎，以促进基于事件的数据管道托管在数据砖平台上，固有地利用DELTA lake的功能。bob体育客户端下载现在，数据处理管道中的每一层都有一个要执行的功能。例如，原始层，连同更改集确定的过程，还意味着通过执行基本验证来执行初步数据清理，例如文件格式验证，以检查它是否是一个有效的JSON格式文件，以及出处级别验证，以检查是否所有强制性的源标识相关信息都可用。另一方面，阶段层主要负责匹配、合并和版本化实体，以及元数据属性和其他源实体验证，然后根据定义的数据质量基准进行最终实体验证。然而，Gold层应该最终准备实体以聚合的可呈现的格式发布，同时确保领域实体关系是完整的，因此任何不相关的实体或所谓的实体都被保留以供未来的级联回溯更正。所有这些层都读写中间结果和按实体类型划分的DELTA表。现在，DELTA表模式已经设计成独立于底层域实体模型的方式。所有这些流应用程序都运行在交互式集群上，并在其下面有DELTA现金加速驱动程序节点和工作节点。所有这些应用程序都单独依赖于它们相应的检查点和明确的数据检查来跟踪正在处理的事件，以避免任何意外的重放。 Operational control plane is basically a place where we deal with the stuff like how the data can be securely accessed by various teams involved and the necessary administration setup to facilitate seamless data access and how the content is also going to be actively managed through internal management UI etc. So broadly speaking, we’ve got two types of teams requiring access to data and data bricks platform. Engineering teams and operations team. Both these teams require different level of privileges to be able to manage data processing pipeline and analytics or reporting needs respectively. And as a result, we have created two categories of interactive clusters associated with two different instance profile, essentially, two different IM roles with necessary AWS policies and permissions attached. These underlying AWS IM rules precisely defines what data someone can access and what operations are allowed to perform. All the batch jobs, streaming jobs, reporting jobs and analytics jobs, whether notebook based or jar based. They’re all deployed through automated CICD pipelines. These CICD pipelines use data bricks jobs APIs to manage jobs with the necessary configuration including the schedule.

现在，让我们看一下底层架构。考虑到S3作为着陆层，在最终消费者可以使用它之前，事件正在经历原始阶段和黄金层。如您所见，阶段层依赖于其他静态数据源，如RF数据、医疗保险数据，通过验证来丰富或提高质量。在此过程中的每一步，传入事件都会产生数据沿袭对象，该对象反映了在整个管道中对事件执行的所有操作和相应的结果，无论该操作是成功还是失败。现在，这些DLO通过一个单独的流应用程序位于中间原始表、阶段表和黄金表之上，黄金数据表被合并并存储在一个集中的DELTA表中，作为一个扁平的DLO记录，对应于流经管道的每个数据事件的每个处理层的每个操作结果的每个操作。

数据平面和处理管道

现在，这个DLO DELTA表被运营团队用来做异常报告，例如，或者一个排名，就像我的同事在他的演示中提到的那样。现在，由于整个管道总是在追加模式下工作，这意味着任何新的数据事件都只会导致创建新的实体版本，因此那里不会发生覆盖。这可能会不断增加这些DELTA表，并随着时间的推移影响性能。因此，我们所做的是，在给定的时间表上运行一些内部管理工作，将实体的历史版本从主DELTA表移动到基于时间阈值标准的存档DELTA表，实际上，在任何给定的时间点，在所谓的主DELTA表中只留下任何实体的最新版本。因此，通过这种方式，DELTA湖中的黄金表成为当前快照目录数据的来源。

连续流应用

所以，从本质上讲，持续运行实时流应用程序有很多优点。它不仅使我们能够有一个真正的事件来源，当它发生在像kinesis, S3和DELTA表这样的系统时。但是运行微批处理也在某种程度上帮助我们与更小、更易于管理的数据量进行交互。当然，通过检查点的可恢复性是Spark流默认附带的额外奖励，因为使用DELTA表而增加了可靠性。现在，在我结束今天的演讲之前，我想简单地谈谈最常见的数据问题

以及我们如何使用我们架构中的一些关键支柱来解决这个问题。

现在，这是问题陈述。因此，假设一个下游健康状况集成商抱怨服务描述中出现了一个意外的特殊Unicode字符，这在某种程度上破坏了他们的集成。

我们通常遵循的一些步骤，来解决这类数据问题，本质上是去获取系统中可用的最新版本，并作为第一步检查有效负载，基本上是第一件事，然后尝试分析与最新版本相关的元数据归因，以找出两个层次的见解。第一，这个特定的属性是什么时候修改的，谁是这个修改的发起者?根据确定的时间轴，我们尝试获取满足时间阈值标准的所有历史版本，然后通过比较机器之间的有效负载来隔离故障版本。然后我们还额外地尝试抓取错误版本的出处，以追踪到它的起源。此外，我们还尝试获取错误版本的数据沿袭，以找出在该时间点上对该事件执行的所有操作，并查看是否生成了任何其他警告。这样，我们还能够从最初摄取的文件中检查其他事件，以确定其他实体是否也受到影响。最后，我们现在可以重播所有受影响实体的最新版本，并纠正有效载荷，以便能够创建新的版本。现在，所有这些都完全有可能，因为这四个重要而重要的因素。一是尝试遍历静态版本的能力。其次，将元数据属性与每个版本相关联，以隔离故障版本。 Third, visibility on the series of operations performed on the faulty version through the data lineage. And fourth one is tracing it to its origins source through the provenance, which is actually supported up to millisecond precision in our system. And this way, we have not just been able to achieve the complete auditory but also being able to generate data quality reporting for any system of record.

这就是我们今天的内容，非常感谢你们花宝贵的时间来听我们的故事，现在我想开始了