自动化联邦航空管理局(FAA)全系统信息管理(SWIM)数据摄取和分析

视频记录

大家好，我叫Mehdi Hashemipour，是美国交通部的一名数据科学家。

我在交通统计局领导一个正在进行的项目，打算建立一个内部商业航空飞行数据库系统。本次演示是BTS为实现这一目标所做的努力之一，通过使用微软Azure和Databricks对FAA SWIM数据进行自动化数据摄取和分析的概念证明。

因此，我将给你们一个项目的概述，然后Marcelo和Sheila将分别讨论基础设施、体系结构和数据处理部分。

目标及效益

因此，建立商业飞行数据库系统有助于BTS测量和报告航空系统性能。这样做的一些潜在好处是能够及时估计航班和准点率，支持特殊的航空研究并为航空仪表盘和其他统计产品提供数据来源，最终成为运输中断和灾难系统的航空组成部分。

全系统信息管理(SWIM)

因此，大部分目标都可以通过使用FAA SWIM服务作为商业飞行数据库系统的主要组成部分来实现。让我们先来了解一下SWIM服务是什么?SWIM代表系统范围的信息管理，它是多种数据服务的组合，包括机场、航班、航空和天气数据。

SWIM是数字数据交付平台，可将原始国家航空航天系统或NAS数据转化bob体育客户端下载为航空利益相关者有意义的信息。消费者可以通过源FAA电信系统连接到系统，在那里他们可以实时检索来自生产者的数据。因此，为了开发概念验证系统，我们使用了一种SWIM服务，称为TFMS数据和TFMS或交通流管理服务，也称为空中交通管理，是根据容量和需求管理国家航空航天系统中的空中交通流量的技术。TFMS服务提供飞机态势显示数据，包括飞机调度、航路和位置信息。因此，终端数据分布系统(STDS)是另一种SWIM服务，它将从机场塔台和终端雷达进近控制设施收集的遗留终端数据转换为易于访问的信息。所以，STDS SWIM让用户可以访问200多个机场的数据。而这个SWIM数据来自于近400个独立系统的一个SWIM，数据格式为XML。通过打开SWIM流，我们接收到的数据量是巨大的，例如，一个星期的TFMS数据，我们收集了超过1500万条XML消息，占用了tb的空间。摄取和处理这些消息具有挑战性，需要快速可靠的数据处理工作流程。在这张幻灯片中是不同SWIM服务的架构，它由许多服务和数据组件组成，这些服务和数据组件从不同的生产者获取流，从FAA本身到其他外部发布者。 And the main categories of data are including weather, flight and flow and many other aviation related data components. So, using the SWIM data and more specifically the TFMS data, would help BTS to answer questions like airport airline performance, airport time delays, on-time performance estimates by cause and so on.

SWIM数据的潜在BTS用例

还有航空货运，航班延误的经济影响，

改道和取消，如航班延误和航线分析对财务的影响，航班延误和取消对运营和乘客的影响，如航班模式中断和航班晚到。最后是航班延误、改道和取消对乘客的影响。

BTS概念游泳建筑

因此，我们设计环境的初始概念架构包括连接到FAA SWIM服务，通过虚拟机方法或使用Apache Kafka的HD端方法直接流式传输类似的消息，然后处理这些消息并将其以结构或半结构格式存储到数据湖中，使数据为进一步分析做好准备。为了实现这个系统架构，Marcelo将更多地讨论开发阶段的系统组件及其在DOT Microsoft Azure环境中的部署。-谢谢Mehdi，让我们谈谈基础设施。

所以，从基础设施的角度来看，最初的目标从项目一开始就很明确。我们希望帮助像Mehdi和Sheila这样的数据科学家访问SWIM和内部的on-prem数据源，这样他们就可以尽快开始他们的工作。不用担心构建所需的基础设施，以及随之而来的所有配置任务，比如系统配置、数据库资源等等。确保它符合内部安全标准。当然，还应该能够根据需求或工作负载类型进行扩展。总之，我们必须尽可能地实现自动化。

因此，他们可以快速地拥有一个工作环境，并随时可以使用。基于Mehdi之前展示的概念架构上的这些目标，我们提出了这个物理架构，从基础设施的角度来看，它让我们很好地了解了所有需要脚本化和自动化的云资源和服务。

基础设施架构

这里需要注意的是，我们在Kafka中使用安慰源连接器来摄取数据。Solace提供了源连接器和接收器连接器，您可以构建并轻松地在数据集群中部署它们。通过一些较小的配置，基本上可以摄取所需的任何极端数据源。最好的是开源。bob下载地址其次，我们使用的是纯开源Apache Kafka，这使bob下载地址得解决方案具有可移植性。如果需要，您可以轻松地将其部署到其他地方。

自动化环境

我们专注于自动化这三个类别，基础设施本身，包括所有初始网络、子网、安全组、虚拟机、Databricks工作空间、存储等等。第二，Kafka，现在我们正在进行后配置，包括Kafka的安装、配置以及它的软件需求，比如Java。它所有的符号极端需要配置来访问特定的数据源，在正确的地方有正确的组合文件。用于摄取数据的安慰连接器及其所需的依赖项和库。最后是Databricks，它涉及集群创建和所需库的配置，如Spark-XML，用于解析和分析数据，导入初始笔记本，并设置秘密以正确安装对data Lake的访问。

在这一点上，我们知道我们需要构建什么以及我们想要自动化什么。

起程拓殖

现在我们必须拿出正确的工具。出于显而易见的原因，我们开始使用《Terraform》。迄今为止最好的工具是基础设施代码,特别是如果你是在多重云环境中至少由于大量的供应商,所有的共同语言,支持我们想构建所有的资源,使我们能够重用代码使用模块,定制它使用VM大小等变量,例如,这可能会改变根据环境和类型的工作负载,生产可能会需要一个结实的机器,而开发只是一个小虚拟机上的小测试。我们还可以在应用更改之前检查更改，这很好。还有terrraform云，它允许我们存储这个基础设施的状态，所以我们可以有一个分布式的团队，而不仅仅是一个人通过门户点击。

配置管理Ansible/Chef

一旦环境准备好了，下一步就是进行所有的供应后配置。为此，我们希望提供多种选择。因此，我们创建了chef cookbooks和Ansible角色，两者都提供了我们所需的相同功能，通过将这些配置构建为代码，它还可以作为关于如何配置这些服务以访问最新源下的流的文档。这是为了防止我们想要访问不同的SWIM数据源，而不是我们正在使用的初始数据源。

所以我们可以扩大规模。我们避免了配置滴漏，当您有多个环境时，这是一个非常常见的问题。总而言之，我们所有的资源和环境都保持了一致性，这是一个巨大的胜利。基本上没有雪花了。

对于Databricks的特定配置，我们使用Databricks CLI，这仍然是实验性的，但它提供了我们需要的一切，如导入初始笔记本，使用Json模板创建集群，插入库如Spark-XML等等。

砖CLI

同样，它仍在开发中，但非常强大，如果您想使用CLI与Databricks环境交互，强烈推荐使用。我了解UI，它非常适合自动化。

所以，因为我们把所有东西都作为代码，所以在GitHub中开始并使用GitHub动作来编排它是有意义的。

GitHub - GitHub动作

GitHub动作允许我们为任何操作系统、任何云中的任何语言创建工作流自动化。它甚至提供了一些预定义的操作，您可以将其作为起点。再次强调，如果您想轻松地编排这个自动化管道，强烈推荐使用它。

综上所述，我们有这样一条法则，即一切都始于开发人员将代码推送到GitHub。

CI / CD架构

所以我们可以提取请求pr，这样他们的变更就可以被审查和批准。在幕后，GitHub动作工作流被触发，这导致基础设施、Kafka或Databricks配置的变化。

最后，这里有一些我们在这个过程中学到的东西，最初的设置可能需要一些时间，让你的工具如Terraform chef或GitHub上的所有这些正确配置，并具有适当的权限和访问需要一些时间。您需要有某种类型的服务帐户，具有创建、修改或删除云资源的权限。也有一些学习曲线，特别是如果你不习惯将基础设施和配置作为代码，以及GitHub法律，有分支，提交pr以在他们提供代码之前审查代码之类的事情。一开始有很多测试和失败，主要是因为安全问题，因为所有的通信都必须是内部的，一些端点没有开放或需要开放。这些事情也需要一些时间。但最后，一切都很顺利。现在，如果需要或需要，我们可以在多个环境中轻松地部署解决方案。

最后，所有这些代码都是开源的，可以在这里找到。bob下载地址请随意使用它扩展。

现在，在演讲的最精彩的部分，Sheila将给我们展示一个很酷的最终结果的演示，谢谢。-谢谢，马塞洛。我现在要给你们看的是，我们对TFMS数据做了什么以及我们如何处理它。

所以你在这里看到的是我们对未来国家架构的设想。也就是包括关系数据库。比如Oracle和Sybase，它们有历史数据，并将其与流数据结合，并使用Spark和Databricks运行时将其带入原始Delta青铜表。然后从那里进行批处理，解析XML数据并针对非常复杂的嵌套TFMS模式进行模式验证，然后从那里进行连接和聚合，以便能够真正从数据中获得能量并能够执行分析或预测分析，在此基础上进行机器学习过程。在我将要向您展示的演示中需要注意的一点是，我们特别关注TFMS数据流。然而，未来状态包括来自SWIM数据的其他数据流。另一件值得注意的事情是，我要向你们展示的环境是防弹少年团实施的一面镜子。你现在看到的是Databricks平台。bob体育客户端下载我刚才展示的这张幻灯片中的架构，我们已经在Databricks中实现了一系列的三本笔记本。这是我们看到的一个简化图。 Again, we’ve mirrored, the BTS environment by hooking up from Kafka to the SWIM data, using the solace connector that Marcelo talked about. From there, we consume the messages into Databricks and immediately stream out to a bronze Delta level table. That’s the raw XML strings. From there, we in a batch processing mode where we specify a time period, we bring in those XML messages from the bronze table and we parse it using the Spark-XML package and write that out to our silver level Delta tables. From there, we can choose the time period, bring in the data from the silver level tables, during that period and do joins and aggregations of the different message types, to be able to start looking and doing our data exploration analytics against the data. We’re going to focus on this last line right here, where we’re going from silver to gold. But one thing I do want to point out before I jump right into there, is show you what the bronze level XML messages look like. And you’ll see that right here. That the XML messages are really hard to just look at and understand what’s going on in them. So the next step was to parse it using the Spark-XML package. If we scroll down, we can see what that would look like, for the messages themselves. Then we’re able to flatten them into a nice looking data frame, where we can easily see different data within the data frame itself. Now we’re going to jump right into the gold level table so we can see what the data looks like and understand these TFMS messages. One thing to note here, is that there are 20 different message types coming into TFMS and we are consuming them all and writing them to the silver level tables. So, what we’re going to do, is take that silver level data and enrich it with reference data. This is publicly available reference data on dealing with what the airport codes are, what cities are located in, as well as the airline information, what the codes are compared to the airlines. Now, if we scroll down, we can see that we take, we’re going to focus on departure arrival, as well as flight plan creation information and bring all of that data together. We can see, we have about 30,000 messages in departures and 30,000 in arrivals as well as about 11,000 flight plan creation messages. So what we’re gonna do is look where we have information for all of them, so we can start understanding the delays. So how the schedule departure and arrivals compared to the actual arrival and departures.

我们可以看到这里，飞行计划表。所以你可以很容易地看到我们有所有可用的信息。现在，当我们把这些信息和飞行计划结合起来，加上实际的到达和离开，我们可以计算出到达和离开的延误时间。当我们开始观察这些数据并将其可视化时，我们就可以开始了解哪些地方有较大的延误和到达，哪些地方我们可以提前到达。所以你可以看到在圣胡安和孟菲斯之间，在四天的数据中有更大的平均到达延迟。这些数据是在5月25日至5月28日之间采集的，不包括24小时。在BTS环境中，该数据每周7天，每天24小时运行。所以他们正在以tb或pb的规模消耗所有的数据，而同样的笔记本电脑在那里运行。这些实际上消耗了大量的数据。为了便于演示，我只展示了其中的一小部分。 Again, we can start even doing more analytics by calculating distance between airports and start looking at what about the elapsed flight time compared to what the flight plan said the elapsed flight time should be. Let’s start getting metrics as to where are we overcompensating for the flight plan and where are we not giving enough time for that flight to happen? And so we can begin to start kind of correlating these to potentially weather patterns or wind patterns. And if we keep going, we can pivot and start looking at cancellation messages because within the TFMS data, there are 20 different message types. So we have a lot of data at our fingertips. So in this case, we have 1,265 recorded cancellations of flights within those four days and those hours that we have data for, for those four days in this case. If we enrich it with that flight, with the airline and flight and flight and airport information, we can get a little bit of our, start diving into the data and understanding that American airlines seem to have canceled the most flights during those four days. We can also do analytics and see what routes were canceled the most. In this case, Albuquerque to Phoenix was canceled 56 times during those four days. So maybe we start looking at weather patterns and maybe there were big storms in that area. So that’s something that we can start diving into and analyzing why these cancellations are occurring. The same time by looking at American airlines, we can start doing some sort of analysis on where are these cancellations are occurring. So these are different departure airports from American airlines flights. We can see that from Miami, most flights were canceled. Well, Miami is American airlines hub. So that’s not necessarily too surprising, but where are these flights going that they’re being canceled? So if we look into what’s landing in Miami, or what’s departing from Miami, we can see that the flights going to Havana Cuba, that four, or that excuse me, eight were canceled during that time. So from this, we can see that by using Spark-XML to take these XML messages and flatten them out, we can really start diving into the root cause of why different delays and cancellations are happening, bringing in different streams of data. We can start to do predictive analytics. We can look at seasonal flights and see how the seasonal flights are changing in terms of cancellations in different areas of the US, I mean start diving in more, thank you. So we learned a lot of lessons along the way with implementing the data processing and looking at the XML messages coming in. The first is, the Spark-XML package is very powerful and that it’s improving and actually doing this project with BTS, we were able to actually improve that Spark-XML package to deal with these very complex and nested schemas. And currently we’re, we’re still looking into ways that we can improve it even more. So this is a constantly evolving package that’s becoming more and more usable. Next is to do the schema validation, we actually ran into every XML message that we were loading up the different scheme of files to, and the nest is schema. We’re bringing it in from storage, opening them, and then validating our data against it. So what we did to mitigate any file IO latency was actually take that schema and copy it out, teach it to the executor’s within the cluster. And what that allowed us to do is have that schema in memory cache, so that way we could easily and very quickly validate against the schema. So we went from validating on the order of minutes, to actually validating in just seconds.

我们学到的最后一件事是，对于输入的XML消息，如果我们从这些消息推断出复杂的模式，并不是所有的消息都那么复杂。因此，如果你对一小部分消息进行推断，当一个非常复杂的消息进来时，你可能会得到模式不匹配，并出现问题。因此，我们发现，基于需求，我们可以在一个小时的时间内进行批处理，并能够在这些XML消息的模式本身中解释所有这些复杂性。

那么，我们将何去何从?我们要做的第一件事，就是把我们处理过的数据和航空公司提供的数据进行对比验证。

下一个步骤

因此，当航空公司将数据提供给BTS时，他们能够查看它，我们可以将其与SWIM数据进行对比，看看是否可以通过这些SWIM数据消息获得相同的信息。此外，我们还想深入研究高级分析，研究预测模型，了解季节性问题和航班延误，以及这将如何影响乘客。Mehdi在前面的演示中提到的许多用例。最后，我们希望开放这个管道，并允许更多的SWIM数据提要。所以不只是TFMS，还有ST, DDS和其他我们在之前的幻灯片上看到的流。最后，我想说，如果你想联系我们，了解更多关于这个项目的信息或与我们交谈，我们的联系方式在这里，可以为你提供。最后，我要感谢美国交通部，以及交通统计局，尤其是迈赫迪，感谢他们允许我们进行合作。