序言
跟随我进行数据统一的旅程。我使用的应用程序之一是现代，分布式，基于事件驱动的且基于服务器的架构。这意味着数据与其他组件完全隔离，并以与邻居不同的速度发展。使用具有AWS的事件驱动的无服务器数据架构可以实现此类体系结构。
如果您要构建交易系统，这很棒。您有隔离，独立的组件缩放和功能交付，以团队的速度进行。那怎么了？除了现代分布式系统很复杂的事实之外，这可能没有什么好处？最大的问题是所有这些数据都不在同一位置。
将所有东西都放在同一地点的地方有什么意义？简单的。真相来源：
- Reporting
- 公共API
- 版本化
- 审核
- 数据沙盒
这些只是冰山一角。当您在一个带有大量数据的大型系统上工作时，当您谈论上述内容时，具有单个入口和出口点很重要。
解决没有AWS的求解
让我清楚，上面可以在没有AWS及其大量云服务的情况下完成。那里有开源项目/产品，可以将碎片和零件融合在一起。但是，这意味着您必须安装，管理，修补和不断监视一堆独立的产品和服务。
例如，此数据需要以FHIR格式存储。有一个数据湖本地这样做吗？它如何管理版本控制和升级？当然，Hapi Fhir引擎真的很不错，我建议在很多用例中推荐它，但这只是一部分。根据我的最佳估计，这里是您必须拥有的高级部分。
- 数据更改检测和捕获（源系统）
- 转换和标准化工具
- 用于转换数据的可扩展且高度可用的数据存储
- FHIR有能力。对于医疗保健数据，这是一件大事。 CMS正在努力使组织采用此标准
- 可扩展性 - 如何使用和扩展数据？报告，仪表板，分析，机器学习和API仅举几例。
- 治理与安全 - 不用说几乎所有数据，但是在医疗保健中，这是非常重要的
这不是关于替代方案的文章，但是上面的列表很容易带入6、8、10甚至20个不同的工具和项目。更不用说无法管理的。因此
未差异的繁重举重
我以前在其他文章中提到过这一点，但是我认为选择云提供商的真正力量是，您可以利用其本地工具和能力。看，尝试成为云不可知论或避免“供应商锁定”没有错，但是您没有这样做。您只是在降低锁定的位置的栏，并在添加到团队中的复杂性和可维护性方面提高标准。
我多年来所学到的知识，尤其是作为领导者和建筑师，当您建立一些东西时，您希望创意建筑商专注于产出和价值，而不是帮助他们建立该价值的事物。同样，有些空间不是这样的，但是对我而言，以及我从事的工作，我构建了以用户为导向的应用程序，客户从使用中获得了价值。我为构建下一个最佳图形数据库或其他工作所做的工作而建立的客户没有任何价值。
拥抱您的云提供商及其工具。正确完成后，它可以节省您的时间，金钱和运营复杂性。不要为“锁定”而烦恼，而要拥抱连通性，共同的SDK的价值和安心，因为他们知道别人正在照顾和支持您使用的锯子，锤子，指甲和胶水建立您的价值。
AWS无服务器和Healthlake
要重申拥有可扩展，可扩展且易于监视和操作的统一数据存储的目标，让我们继续探索使用无aws serverless的事件驱动的数据架构。下图是本文其余部分的基础。
我将把这张图的4个车道分解为不同的部分，并谈论在每个部分中工作的工具和经验。这不是理论上的事情，而是我在编码和操作的个人实践经验中。
事件驱动的来源
当您通过无服务器和事件驱动的眼镜看世界时，您就开始将所有内容视为事件。这不一定是一件坏事，但消息来源是事件的生产者。在最左侧的列中，该图突出显示了以下资源：
- API网关 - 外部API事件可能在外部发生（希望以FHIR格式如图所示）
- rds-如此多的系统具有关系数据的核心。它完全没有错，但是不要睡在上面，因为它可以是EDA来源
- DynamoDB-在AWS世界中，没有比Dyanamodb拥有内置流支持更好的EDA数据源了。如果您还没有阅读，here's an article that talks more about it.
- S3/Transfer-无关紧要您的工作，很难摆脱基于文件的传输，而S3 and AWS Transfer是很棒的选择。
关于来源的重要重要一件事是它们产生了东西，大多数是在改变。一词更改数据捕获或CDC对于此体系结构非常重要，因为这些更改变成了“来源”的事件，然后可以将其转换为“统一数据”。
我希望您在以AWS为驱动事件驱动的无服务器数据架构的旅程中遵循。
清洁和准备
回到标准化的工具并倾斜到云提供商中，如果您选择了足够高的水线，那么“如何构建东西”的心理跳跃很快就跳到了“我们正在构建的东西”。当您消除有关如何并转移到什么，原因和原因的疑问和疑问时，魔术会发生。
我发现在此准备阶段会发光。因为通过在使用AWS构建事件驱动的数据和无服务器数据架构时利用更多的概念和功能，您可以通过让相同的开发人员工作，训练，配对甚至构建不同功能集的合作伙伴来提高速度。这意味着应用程序DEV可以帮助数据开发人员和数据开发人员可以与应用开发人员配对。我并不是说每个人都在做任何事情。但是，当每个人都知道lambda，dynamodb，sqs，eventbridge，然后撒上2或3种编程语言，他们就有这些常见的构建块，能够构建在“如何”上删除“如何”并专注于“什么”
我认真地无法强调这一点，并且已经看到了这种方法的力量。我与之合作的大多数开发人员是核心解决者。这些工具是解决问题并建立出色问题的一种手段。
当我在工作流程的此阶段工作时，转换和准备工作在一定程度上取决于数据源以将原始数据输入状态计算机。例如：
国家机器发光
- rds-使用DMS拾取事务日志以推入S3并存储在Parquet中。如果您想看看如何解析parquet，head over here。
- dynamodb-流，流，流。您需要使用流。
- API网关 - 如果数据在FHIR中格式化，则是蛋糕。如果不是，则一台从网关开始的状态机都很棒。
- AWS转移 - 类似于RDS方法。先获取S3中的数据，然后从那里进行。
这些路径中的每一个最终都需要流入状态机。我发现的是，一旦我使用正确的AWS工具从源来处理CDC，步骤功能，lambdas和eventbridge就可以轻松地用于照顾其余的。
这就是我对每个方法采取的方法。最终输出是将数据输入FHIR格式，以便下一列中的内容可以消费。
统一事件驱动的无服务器体系结构数据
HealthLake作为服务
在某个时候，我需要写更多有关Healthlake的信息
这件技术位于设计的中间。没有它，我需要很多零件和零件来代替它。简而言之，它是Hadoop，Hapi，AWS理解，S3，OpenSearch和API Gateway全部滚动成一个，再加上一堆。我已经用它来统一我上面谈论过的各种EDA资源。
HealthLake作为Unifier
一旦在各种状态机工作流中转换数据后，它将输出为准备发表到HealthLake的FHIR资源。我非常喜欢HealthLake的数据存储，这使我对正确格式化的FHIR资源以及可靠的编码（医疗编码）模式以及连接FHIR资源的易于能力负责。我这么说很多，但是几乎所有数据都有我关心的标准。
- 合同标准化 - 传输数据的格式。 fielda = fielda。 Fielda是
int类型，很棒，它必须是int - 内容标准化 - 仅仅是因为一个领域可能是“年龄”的
int，它是否在几天，几个月或几年中年龄？是代码字段，Snomed，ICD，CPT吗？这些事情很重要。
Healthlake在使用它时给我一个想法，我可以实现这两种将系统之间的互操作性作为一种可能性而不是时空梦的互操作性。
我已经在生产中运营健康莱克已有6个月以上，我可以告诉您，我遵守这些标准，非常重视它的护理，并为我提供了一致的API和经验。它还使我可以选择在“消费”列中使用我想要的类似。
消耗AWS无服务器数据
我想将“消费”分为两个部分：
- 带来人价值的输出
- 带来系统值的输出
人价值的产出
我对此的看法是分析，报告和机器学习。这是人类嵌入应用程序时可以消耗的三个非常特定的输出。这就是我肯定使用它们的方式。
分析对我来说意味着可以计算出来的东西，也许随着时间的流逝，有多个输入以帮助提出决定。在医疗保健领域，想到住院的患者。这是对患者的“遇到”接纳的天数或小时数的计算。
与机器学习紧密相关。我们大多数与AWS建造的人都听说过Sage Maker。但是，为了使事情变得简单，可以根据许多因素来预测患者住院时间的算法呢？该输出可以由临床医生或操作员以多种方式使用。我已经看到其中的力量。
最后，报告。不是棚子里最华丽的工具，但是如果不报告，您就无法建造任何东西。想想打印患者的个人资料用于共享。这就是我的意思。
至于完成AWS的人，我一直在使用Quicksight和Sage Maker来完成这些任务。同样，当我继续回到它时，坚持使用相同的生态系统使其变得非常容易，因为SDK相似，相互作用相似，并且使用AWS IAM进行访问和控件使所有内容都非常均匀。
>系统价值的输出
当我谈论系统价值时，我一直在用事件驱动的数据架构来建立系统价值，我在谈论另一个系统的能力
- 拉更改
- 接收更改
用于拉更改，这是一个API。对我而言，我在AWS中构建和发布的几乎所有API都是使用API网关或Appsync完成的。我用来在HealthLake之上构建API的方法更像是它当前提供的FHIR API的包装器。添加自定义授权器，Cognito或两者都提供外部专注的身份经理也非常有效。
用于推动更改。疾病预防控制中心也在这里发挥作用。您如何将Healthlake变成CDC生产商？好吧，HealthLake目前不支持这一点。但是，由于AWS中的几乎所有事件都可以是一个事件，所以我自己滚动了。 I'd love for you to read about that here
我对这些工具所做的工作是使HealthLake成为平台的中心，因为它不仅是消费者和统一者，而且是生产者。我对此非常满意。
包起来
我希望以上已经向您展示如何使用AWS工具构建无事驱动的无服务器数据架构。我真的做不到这一点。不要害怕供应商锁定。除非您是ISV，否则我不会购买多云。作为SaaS供应商，最好专注于价值并将其交付给客户，而不是对您的基础架构进行对话。选择一条车道，学习并保持惊人。您的客户会感谢您。
当我回顾本文之外的上述旅程时，我仍然受到建筑商技术进步的鼓励。我也想鼓励您出去尝试新事物。事件驱动的架构和扩展的微服务模式不是银子弹。而且它们绝不是在所有情况下都很“简单”，但是当您与团队或团队团队建立时，隔离，去耦和功能部署令人垂涎是我目前最喜欢的方式来实现这一目标。
您阅读以上内容的最终希望是，现在您已经看到，您用于构建应用程序的技能，模式和工具也可以用于构建超酷的数据应用程序和数据平台。无服务器和事件驱动的AWS架构不仅用于网络和移动应用程序，而且可以用于更多！
！