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

视频记录

-大家好,我的名字是马克保罗,我将加入了Anshul亚太区。我们的标题是,建立一个联邦数据目录平台的公共卫生。bob体育客户端下载今天我们有很多报道,我们将首先讨论的问题集中的数据目录。然后我们将继续解决联邦数据目录平台的形式。bob体育客户端下载我们会谈论一些设计模式,我们将继续一个特定用例称为智能系统记录排名,然后我们会得到一些体系结构模式,你可以带回家和你在一起。所以我们从HealthDirect澳大利亚。我们是一个国家政府,非营利组织提供值得信赖的健康信息和建议所有澳大利亚人。在HealthDirect澳大利亚我们得到了国家卫生服务目录。这就是澳大利亚数字卫生基础设施,国家卫生服务和从业者提供的目录。

让我们首先看问题集中的数据目录。

医保目录——关键的医疗基础设施

医保目录基本上是关键的医疗基础设施支撑时大部分的世界各地的医疗系统。这是因为它使护理协调。举个例子,如果你去看医生,他会把你的专家,他们使用一个医保目录来定位,专家。或者如果你是去医院,会有一个出院小结发出你的医生在你的医院参观。他们使用安全的消息传递是由医保目录,因此它们是单点故障。这是特别放大如果你有糟糕的数据质量,使我们有临床风险的病人。举个例子,如果你不能找到你最近的急诊室在意外?所以我们需要更加积极主动地看这个问题。

当前的医保目录基本上是集中管理的数据库应用程序,通过内容管理系统与数据更新和呼叫中心。这个模型非常活泼,效率低下,主要是因为变化的高频数据目录中。例如,医疗服务不断改变他们的操作时间,和实践者之间的医疗服务不断移动医疗服务。有高数据波动,我们需要一个更积极的方式来处理这个问题。

无论你在医疗或其他任何行业,斗争与集中式数据存储问题,我们采用了一个解决方案是搬到一个联邦数据目录平台。bob体育客户端下载

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

你可能熟悉联邦数据库,基本上把多个自治数据库系统映射为一个联合数据存储。这里没有发生聚合。相反,它是多个数据存储的抽象。

然后你有联邦数据平台,基本上是通过使用创建标准的数据聚合多个自治控制起bob体育客户端下载源的数据源。这里去架构模式是采购我们所说的事件,你将熟悉。我们会详细讨论,在稍后的幻灯片。

所以对医疗数据联合目录可以被描述为建立一个联邦数据难题。如果你看屏幕,在你的右边,你可以看到我们考虑我们的黄金标准的难题。现在,我们不是大师这个数据相反,我们做什么,我们登记系统的记录创建这个谜题。我们本质上创建和协调创建通过管道。所以我们的角色,而不是创建拼图,让它通过使用系统记录的创建。所以在那个例子里,我们有歌剧的系统记录和我们有医疗保险拥有特定的难题,然后我们协调这个造物。

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

整个过程开始于我们所说的来源分类。基本上,我们确定权威的系统记录。一旦我们这样做,他们可以扮演三种角色。他们可以成为真理的来源,或者权威的老板我们的数据的一个子集。他们可以验证的来源,然后使用验证和提高数据质量,或者他们可能是一个通知,本质上增加一个数据的货币。数据货币基本上是在多大程度上我们的数据是最新的。

一旦我们有了,我们继续我们称之为实体/通道设置。所以我们创建实体黄金这是我们最后的实体模型。例如,医疗实践和组织从业者。我们有原始的实体,这些原始源特定的实体是在pre-map阶段我们将搬到转换成黄金的实体。我们然后来源渠道,基本上我们的管道渠道,这些原始实体过渡到我们的实体黄金版本。

我们接下来继续这一过程我们称之为属性采购。从本质上讲,这是识别系统的关系与我们的数据实体的记录。这样的例子在屏幕上,你看到一个医疗保健服务。对屏幕的中间,你可以看到这个东西叫医生的关系。基本上,从业者在这个诊所工作。和我们使用的系统记录称为健康的范围。你将使用他们的通知来保持这个特定的属性设置。这可以追溯到建立联邦数据难题的例子我之前谈到了一些幻灯片。

好的,我们想把你介绍给我们的策划数据湖。我们要进入具体细节在稍后的幻灯片。但在高级别上左边的屏幕你看看我们考虑我们的数据来源。基本上进入我们的系统记录的数据与系统记录的进入我们的策划数据湖到预处理层,然后移动到原始,阶段,金模式,你会熟悉,和一个黄金标准记录然后退出使用发布应用程序,然后让那些黄金阶段,原始标准数据提供给我们的下游消费产品。现在让我们深入其中的一些特定的层和谈论他们。

预处理层

所以这一切开始于预处理层。对我们来说,这些基本上是笔记本在我们的环境中。在这个笔记本,我们基本上达到API的起源,我们得到的数据提取,我们可以接S3数据为例。这一层的主要目的是产生所谓的源数据事件对象,其中包含两个属性。它包含的数据有效载荷,即原始实体有效载荷。然后它还包含一个来源用于源产地鉴别。

原料处理层(青铜)

预处理完成后,然后我们继续我们的原料处理层或铜层。这里,我们执行常规高水平数据的解析和清洗。没有具体的实体本身。但是我们看看之类的东西,这是文件格式正确吗?例如,甚至这是JSON。一旦完成,我们生成我们所说的一个核心数据事件对象,即基本构建块进行下游层和我们捕捉过渡/操作更改。然后我们产生我们所说的事件跟踪ID或端到端可追溯性标识符。我们也做这个东西叫做数据沿袭捕获或形式的数据沿袭对象,开始在这一层也发生在下游层。

阶段处理层(银)

所以一旦完成我们的角色,我们然后继续阶段处理层或银层。现在,这是一个批量操作的发生。这里有很多事情发生。但在一个非常高的层面,我们首先映射操作,我们将从原始源实体转换为黄金实体模型,然后进行引用操作,这基本上是浓缩使用参考数据查找。然后我们去我们的合并操作中我们得到最后已知的最好的版本,创建一个新版本的数据基于所需的更改集。最后,我们进入一个验证操作执行最终对我们的黄金标准验证规则。从本质上讲,你通过验证操作,你有一个新版本的黄金标准数据。

现在让我们看看,合并操作详细一点。原理,我们让一个请求改变一个特定的数据属性,然后比赛并获得最后一版的属性使用一个主键。然后我们上次版本合并使用这一过程被称为δ决心,本质上寻找我们需要实现的更改。然后我们生成新版本的数据。一路上,我们做这件事的,元数据属性,我们记录每一个改变属性,在每一个事件。这让我们做出一些运行时决定。看谁是最后一个人改变了这个属性。我们也在这一层生成数据沿袭对象。事实上,我们生成大量的数据沿袭对象在这一层,捕捉属性异常、违规行为,状态的变化等。

金处理层

一旦我们完成了阶段层,我们继续我们的黄金处理层。现在黄金处理层的职责是,确保实体关系验证,防止孤儿。因此,确保这些实体关系是完好无损。这也是我们做后处理的层和回放。基本上,我们可以如果你想申请一些参考数据或业务规则,我们可以从这一层重播。或者如果你想要回滚到一个旧版本的数据,我们可以使用这一层。黄金也是一种数据科学层,所以我们的数据分析师经常看我们的血统和历史数据更新,他们基本上得到数据质量标准,我们使用来提高数据质量。

数据来源对象

让我们看看我们的数据来源对象。所以这个对象,就像我所提到的,在我们的预处理层生成。用于将一个事件追溯到它的确切来源。我们可以看看之类的,确切的来源是谁想出了这个改变,我们甚至可以追溯到原始的源,它起源于,它甚至追溯到外部标识符像源空间Jira例如机票号码。我们还跟踪源的意图。换句话说,什么是源试图与这个特定的数据变化?

数据沿袭对象

然后我们有数据沿袭对象或DLO,这DLO生成在每一层。它封装了操作实体事件发生的结果,和帮助我们捕捉偏差的数据质量。所以我们捕捉异常和警告。例外是用来解决我们的数据和警告用于提高数据质量。我们也使用了端到端数据流和可见性,所以我们知道我们的数据到底发生了什么。现在我们获取很多DLOs,例如,过去的几个月,我们已抓获超过2500万的问题可以追溯到特定的来源。这些DLO对象起到至关重要的作用在我们的数据改进策略,我将描述下。

我们想搬到一个话题,我们想叫情报系统记录排名。这是一个内部过程中,我们一直在使用,这是我们第一次公开分享。所以我很兴奋与你分享这个。

正如您所看到的,到目前为止,我们是一个系统很大程度上建立在专用系统的记录,因为我们是一个联邦数据存储。所以这些专用转速,系统记录的完整更新我们的数据属性的权力。上游数据质量的问题,这是回归流入我们的系统,我们不希望。还有一些系统的记录没有变化的频率。这看起来好像我们数据不经常改变。所以我们没有数据的货币,这也是我们不希望的东西。

所以我们想出了一个解决方案来解决,这就是我们所说的系统记录或CSoRs候选人。现在你可以把这些作为备用系统的记录更新竞争相同的数据属性的专用系统记录。这样的例子,我们有一个医疗保健服务。和它的操作时间和联系方式。所以只能一个,这是记录的专用系统更新的能力。但是我们的候选人的记录系统B和C,也可能这个如果需要填写和更新。

手动排名

目前,我们鼓励并使这种竞争通过我们称之为手动更新数据排名。所以这基本上是基于业务优先级排名分配。在那边的例子,我们有系统的记录,也有优先级,来更新开放时间和联系方式。和候选人SoR B和C,有一个低优先级更新联系信息。当我们使用流媒体应用程序,在该方案中,我们有多个来源竞争同时更新相同的属性。我们使用这个排名指标基本上知道荣誉的。基本上,谁赢谁如果有更新数据的竞态条件。

自动排名

一旦我们有手动排名,它使我们能够做我们所说的自动排序。这基本上是数据沿袭结果聚合在过去的30天。这是由这些数据沿袭我谈论的对象。在这个例子中,我们系统的记录,你可以看到由10更新联系人,导致四个警告和两个错误。而我们有候选人SoR B 8更新,但只导致一个警告。通过观察这些聚合我们能够提高优先级根据最近表现的来源。最初,系统记录的优先更新联系信息,但通过观察候选人记录系统B的性能我们给它一个更高的优先级,如果我们觉得可以提高数据质量。

头脑聪明的排名——未来国家医疗服务实体特征

我们前往的地方,是我们所认为的聪明的排名,我们说这是一个未来的状态,但我们已经开始实施。我们的增长特性。换句话说,我们的消息来源基础指标,我们收集有关数据质量增长。所以在这个例子中,我们系统的记录,我们知道多少更新它。多少警告了那些,有多少错误导致的,有多少公众投诉可以追溯到系统数据更新的记录,我们甚至有经度和所有数据质量标准完整性、准确性,等我们收集。同时,我们的资源也越来越多。所以我们越来越系统记录和候选人的系统我们招收的记录。我们也有这个场景我们所说的,季节性数据回归,我们注意到一些系统的记录,他们经历,也许某些时候他们通过数据清理,也可以改善或导致数据质量差。所以对我们来说不再是可行的看看最近来源的性能。所以我们想出了一个源特定的数据质量模型。 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端点,或者通过安全FTP坐在上面安装S3 bucket。联合目录以来严重依赖于丰富的外部参考数据传入的事件,我们也收到分类参考数据,例如从第三方供应商。我们实际上有一个内部数据来源也通过运动流推动内容更新。所有这些数据源预处理程序并流经首先,负责数据采集和数据摄入两个关键步骤。所有这三个过程是使用数据砖笔记本与Scala编程语言的选择。并引发作为分布式计算引擎的选择。现在数据使用者的人依赖于巩固和聚合的信息视图可以从联邦医疗保健服务的目录中。 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.

现在说话的发展控制飞机,这架飞机是为了定义工具和工程团队使用的ide进行开发工作,建立新特性和应用bug修复,准备报告维护蔡先生管道等,现在数据砖笔记本是一种广泛使用的工具跨团队Healthdirect构建脚本,应用程序、仪表板、生成报告或运行特设查询,并执行计算密集的聚合。因为AWS是作为企业范围在Healthdirect云平台。bob体育客户端下载AWS代码提交结合代码部署和管道代码,例如,也是整个平台管理自动化管道用于更快的上市时间的结果。bob体育客户端下载

所以说数据控制平面和操作控制飞机。数据控制飞机,这主要是一个收集的各种实时处理应用程序使用Scala语言支持功能范式和它的火花结构化流作为分布式引擎,以促进基于事件的数据管道本身驻留在数据砖平台利用三角洲湖的力量。bob体育客户端下载现在,每一层内部数据处理管道有一个函数来执行。原始层为例,随着改变的过程集的决心也要执行数据清理通过初步基本验证像文件格式验证检查如果是一个有效的JSON格式的文件,例如,和出处水平验证检查所有强制性源识别相关信息是否可用。阶段层另一方面,主要负责匹配、合并和版本的实体元数据属性和附加源实体验证之后,最终实体验证按定义的数据质量标准。然而,金层应该是最后准备出版实体在一个聚合的格式,同时确保域实体关系是完整的,所以,任何联合国相关实体或所谓的实体往往是阻碍未来的级联回顾修正。所有这些层读取和写入中间结果和δ表分区的实体类型。现在δ表模式被设计以这样一种方式,它独立于底层域的实体模型。所有这些流媒体应用程序运行在集群互动,和三角洲现金加速驱动节点和工人节点下面。所有的这些应用程序单独依靠相应的检查点和明确的数据检查跟踪事件正在处理,以避免任何意外回放。 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着陆层事件现在流经原始阶段和金层之前提供给终端消费者。阶段层可以看到,取决于其他静态数据来源如射频数据,浓缩或质量改进医疗保险数据通过验证。在漫漫长路的每一步,传入的事件是生产数据沿袭对象,这是一个反映的所有操作和相应的结果,是否执行成功或失败事件在整个管道。现在,这些DLOs通过一个单独的流媒体应用程序之上的中间原料表,阶段表,表和黄金,黄金数据表得到巩固和存储在一个集中的三角洲表作为一个夷为平地DLO记录相应操作每个处理层的每个操作的结果为每个数据流经管道的事件。

数据平面和处理管道

这DLO三角洲表然后运营团队使用的异常报告,例如,或排名,正如我的同事在演讲中提到。现在,因为整个管道总是在一个append模式,这意味着任何新数据事件只是导致创建一个新的实体的版本,所以没有覆盖发生。这有可能继续增长这些三角洲表,并随着时间的推移影响性能。因此,我们所做的是有一些内务工作的地方运行在给定的时间表将历史版本的实体从假设,主要表存档δ表基于时间阈值标准实际上只留下最新版本的任何实体在所谓的主要三角洲表在任何给定的时间点上。所以,这种方式,黄金在三角洲湖成为当前目录的快照数据的来源。

连续流媒体应用

现在本质上,有不少的优点不断运行实时流媒体应用程序。不仅使我们能够有一个真实的事件采购从系统(如运动时发生,S3和δ表。而且运行micro-batches是帮助我们与更小,更易于管理的数据量。当然,通过检查点可恢复性是奖金,默认添加了火花流以及可靠性,因为使用增量表。现在,我今天结束我的演讲之前,我想简要地谈论最常见的数据问题

我们会解决它以及如何利用我们的架构的一些关键支柱。

现在,问题就在这里。想象一下一个下游健康积分器是抱怨一个未预料到的特殊的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.

用这个,基本上它从我们今天,和非常感谢支出占用了你宝贵的时间,听我们的故事,我现在想开了