美国移民局数据分析平台现代化的经验教训bob体育客户端下载

视频记录

-大家好。我是肖恩·本杰明。我是美国移民局公民和移民服务局的。我是数据和商业智能部门的主管。自2006年以来，我一直在USCIS工作，我们在USCIS创建了第一个企业数据仓库，我在这里谈谈我们使用Databricks和云服务实现现代化的旅程。所以我们大概是在2016年1月开始使用云技术的。我们知道我们会带来一些问题。事实上，我们正在移动数据。所以我们面临着一些问题，我们使用的是ETL, Informatica ETL，管道相当脆弱，它的开发周期很长，工作流程也更长。我们真的缺乏实时和接近实时的能力，我喜欢称之为相关时间数据，真正缺乏数据科学平台。bob体育客户端下载 So we knew where we were going into the cloud and we knew where we wanted to be. So the real question we had to ask ourself was how do we get there?

遗留下来的建筑

所以我们把这个传统建筑带了进来。所以我们用Informatica把源系统数据放进我们的数据仓库也就是Oracle数据库。甲骨文至今仍在运营。然后通过Oracle OBIEE展示这些数据这是一种我们在USCIS和SAS中命名为Smart的产品。我们确实有一些数据科学家，他们从这些工具中提取数据，把它带到他们的笔记本电脑上，运行他们的R和Python代码，试图做一些计算能力较低的数据科学活动，而且肯定不在企业愿景范围内。我们已经有相当多的商业分析师和统计人员在使用SAS和Oracle。

但我们知道，进入云计算，我们带来了这样的环境，这是我们非常自豪的。正如你在这里看到的，我们有36个数据源和28个ETL进程，2300个用户。我们这样做了，这是一个大约花了8年时间才得到的进化。

但一旦我们进入AWS，我们就知道我们需要扩张，我们的用户群也在扩大。他们的发展速度绝对是我们想去的地方。所以我们开始做一些研究，当我们第一次进入云的时候这个叫做eCISOR的区域你们在屏幕左下角看到的都是在Oracle内部。

DBIS

智能主题区在OBIEE上面，你可以看到员工的图书馆是正确的，我们将数据转移到ArcGIS格式，但我们并没有成功地将数据及时提供给用户。我们自己也刚刚开始了解从数据湖中获取数据意味着什么。这是我们非常感兴趣的方向。

我们需要一个工具才能到达那里。当时我们有一个解决方案架构师，我们开始深入研究，我们发现了Databricks，这让我们明白了我们需要做些什么来保持相关性。所以我们引入了Databricks，成功地证明了这个概念。我们引入了我们的VPC，我们进入了一个26个节点集的设置，在那里我们试图实现这四个目标，我们如何支持，基本上我们目前的任务是什么，并继续前进。显然我们需要连接到Oracle数据库。因此，我们将数据库集群连接到那些数据库，创建了我们需要的相关蜂巢，开始复制数据，我们看到了这些巨大的改进，我们说，你可以在Databricks中使用Scala代码在10分钟内将这1.2亿行表从Oracle引入S3。我想我们的Informatica时间表大概是两到三个小时。我们需要确定适当的参与者屏幕，并且显然需要创建多个notebook。我们开始想把它推广到我们的用户群中，让他们在很长一段时间内看到产品的功能。我们现在基本上得到了我们当前的实现。 And as you can see with Databricks and Spark setting alongside of Informatica as our ETL tool, the driving data from the sources, various sources whether it’s Kafka topics to Oracle Database Postgres SQL databases into the data lake as well as being able to source from both directly and through Databricks or from the Lake within our user interface tools such as Tableau, which we’ve recently procured, OBIEE and SAS and plus having a wealth of users within the Databricks Notebooks.

从一个点向多个组交付能力，而不需要进行太多的转椅活动。我们在实现中做的一件事是，我们决定需要将整个数据仓库带入数据湖。这样，我们就可以利用我们在USCIS拥有的所有数据中的所有接口工具。

所以你现在看到的是我们在亚马逊大约四年后的样子。我们已经从30多个数据源激增到75个数据源。有了35个应用程序接口，我们的用户群规模增加了两倍，因为我们的能力已经得到了推动。所以你现在在这张幻灯片的底部看到的都是美国移民局的企业数据湖。

然后我们仍然保留我们的甲骨文平台。bob体育客户端下载我们现在所做的是，当我们刚开始使用Databricks时，我们试图把数据从数据源和Oracle带到湖中。我们已经意识到，为了节省成本和摄入速度，直接去湖边会更好。我们开始逆转，或者重新设计数据流，将数据从源数据转移到Lake，如果需要的话，再转移到Oracle。我们可以用所有的ui访问数据湖。

其中很多都是通过数据库访问或湖泊利用的。所以Databricks就坐在ArcGIS的存储区。我们现在正在做的是将我们的数据合并和仓库直接建在湖中。

我非常欣赏的一件事是，你可以看到我们发展的速度是Databricks给了我们分析数据或快速移动数据的能力，并以更快的方式更多地了解数据。当我和我们的客户交谈时，我谈到的一些成功的故事，就是我让他们改用我们的产品是快速失败和恢复的能力。当我说我们能够拥有团队时，我们从全国各地请来了一些团队来构建一个产品，我们称之为国家实践数据集，这是在较旧的工具中，因为他们使用SAS开始。他们花了一天时间才发现他们的逻辑是不对的。所以他们会建立这个逻辑，他们会通过这个逻辑运行所有的数据，然后发现这个逻辑是正确的。

在Databricks中，这是一个真实的故事，我们在Databricks中运行了一个非常复杂的查询，去吃午饭，19分钟回来，就完成了。团队意识到他们的逻辑是错误的。所以8小时的损失是19分钟的损失。你可以看到房间里的数据分析师和业务分析师会说，“哇，这个产品为我们节省了这么多时间。”他们可以重新设计他们试图建造的东西，并再次尝试，并看到成功。我们也有类似的故事，把一些更大的SAS逻辑放在那里，在SAS中运行6个小时，构建你所谓的即时仓库，移动到Databricks，我想，只需要10分钟，实际上更准确。所以这些功能已经开始，我们已经能够把这些故事带到用户社区。现在，许多团队开始在湖中构建自己的数据池，并将其扩展到企业。

通过Databricks我们在相对较短的时间内看到的成就就是Delta Lake项目的实施我们可能会在后面稍微讨论一下。

插入更新，删除的能力，这对任何IT组织来说都是一个巨大的操作，并且能够将其带入湖中。拥有德尔塔湖的那种能力，以及它给球队带来的东西。与我们的工具集成的便利性是所有这些本地连接器与OBIEE和SAS Tableau的关键。这对每个人来说都很容易。与GitHub集成，用于我们在部署中的持续集成。我们将继续使用Databricks自动化我们的帐户配置。这样我们就不会少花时间。创建账户，我们最近收到了很多请求。这个工具真的为我们起飞了，特别是自从我们进入了最后一个泡沫，在我们的MLFow集成中的机器学习。在USCIS内部，在我们的直接团队之外，有多个团队已经走上了构建大型ML项目和实验的道路。

使用Delta Lake更改数据捕获

现在我要把演讲交给Prabha Rajendran他是我们团队的首席工程师负责数据数据库的实施和安装。-谢谢肖恩的介绍。我是Prabha Rajendran，我从2013年开始就在USCIC项目工作，我也有机会开始做POC，为Databricks做基础工作，然后开始我们今天的工作。

我也是这个旅程的一部分，这是我的荣幸。回到我们所做的技术方面，不管Shawn在之前的幻灯片上说了什么我们目前所做的一些成就。首先是变更数据捕获。当我们开始这段旅程时，我们想先把甲骨文目标的数据复制到湖中。我们怎么做呢?所以我们只是确保有一个管道或FOK为额外的目标，我们可以卸载所有的数据到湖中通过Databricks或使用Scala代码。这就是我们从一个简单的代码开始的地方。你可以把它叫做把数据拉进湖中。因此，至少BIEE应用程序用户将开始使用数据湖。这就是我们开始的方式，但是我们如何跟上变化数据捕获正在发生的事情。 If we have to have a new, real-time replication, how can we even accomplish this? Especially our two, three years before when Delta was not there, or it was not so popular at that time. Then we started everything with, we have to insert all the records into the lake. And then we had to do a rank function to do the de-duplication as well as to show the unique value for that particular record so that the reporting will not be affected the same way. So they transitioned from the Oracle to the Lake is seamless. So that’s how we started. That was a tedious way of coding for us, but Delta Lake which was introduced with all the enhancements that has been made so far in the Delta Lake for all the insert, updates and deletes to be captured made our life very easy. So we can use any of the streams like Kafka or Kinesis, or even AWS DMS, anything to land the data into S3. And then from there we wrote a framework in Delta. So all the data will be stored in S3 as a Delta Lake. So that’s how we transitioned. So what are we gained out of this is one is the users who are reporting off the Central Lake, they will not have the latency because the inserts and the rights were happening at the same time. And there was no latency for the users to retrieve these records. That was one advantage. And also there was a fast ingestion of the CDC changes. Then the quality of the reports which they were going against the Delta Lake, the performance was improved. That’s another thing, and if there was any schema changes back in the So System, it was very seamlessly replicated. Also the failures were gracefully tackled. So these were some of the advantages which Delta Lake as such had in its product. We kinda utilized that in our program, and we took forward that. But yes, what all we learned through this process when we implemented Delta Lake? Some of the things which we did not pay attention to was the vacuuming. We kinda, initially when we started this experimentation with Delta Lake. So the vacuuming was something which we kinda accommodated for a month and we still had our own hiccups when the logs were too huge and it really broke down our system. So vacuuming one mandatory thing, which we now have a seven day retention period, and even sometimes two day retention period, if the volume of the incremental for the CDC is more. So we kinda made sure that vacuuming is also part of this, any of this Delta Code Framework. So that is one thing we learned. And also one more thing we noticed out of this data was the storage requirement obviously increased on our end because we keep the logs aside. So that’s how we kinda modernized the Change Data Capture into our program. Let’s talk about once the data is landed into the Lake, how did our applications connect and how did our applications connect to these analytical platform? I’m sorry, the applications connected to the Lake. So that’s where comes in Tableau. These are some of the dashboards, which we wanted to show what we have implemented so far. And the connectivity initially when we started Databricks, when there was no inbuilt connector available, the need to connect as available. we kinda utilized the ODBC simmer drivers to fetch data from the Lake into the Tableau. But now because the Databricks has its own way to connect us. This has become even easier for us and the performance for extraction of data into the Tableau servers has become faster. When I’m talking about a faster performance, that is one more milestone which we achieved was the Hyper API. The concept of Hyper API which helps us to extract data faster in the Notebook in the database, and then publish that to the server so the reporting end will not take that strain. So that was one of our bigger Milestone which we have achieved, and that helped us to even refresh data in a faster rate on the reporting end. This is another example of the OBIEE and SAS, which we pointed to the Lake from the data which was loaded through Databricks Scala code, OBIEE and SAS before it was pointed to Oracle Targets.

移民服务

我们注意到，一些查询，一些仪表板，是在OBIEE中创建的，它在15分钟左右运行，有时这些仪表板不会返回结果因为Oracle数据库上有负载。有时候这些查询会停留很长时间，它不会出现，但是，当我们运行指向Databricks的相同查询时，查询或返回不到15秒，可能是15到20秒。所以我们注意到的是，性能是剧烈的，失败的数量或查询总是返回，这是一致的。这是我们将数据指向Lake的另一个优势，特别是在现有的仪表板上，它指向一个数据库，指向一个Lake，数据在下面通过Delta Lake写入。

接下来，我们在数据科学领域做了什么?这本身将是一个更大的讨论，但让我简单介绍一下我们在这一过程中所做的事情。我们是如何开始的?我们开始为USCIS提供一个特殊的用例。我们想要看到，我们只是想要数据或预测，

人们不赴约的概率是多少，为什么他们不赴约，生物识别预约或他们与USCIC的任何预约。他们为什么没有出现?预测是什么?这怎么能被授予呢?或者是什么预测因素导致了约会中没有出现?这是一个简单的用例。我们是如何向前推进的?我们在后端使用R和Python，我们使用一些内置库来处理大量数据，我们有数据，我们划分了70% 30%的规则。我们通过预测模型运行这些数据来预测一个人的位置或者预约的提前时间。这些其他因素导致了这种不出现或一个人没有出现在约会中吗? So these are some of the prediction models, which we did in using the Databricks platform. And we did not stop there. We also took that model and ran it through our MLFlow with our runtime clusters, which we have the Databricks we kinda used that, and we ran end to end on an ML model to see how this can be predicted and how this can be run through a model to see what is the pattern we are seeing. As a next one also we took another level where we wanted to analyze

或者对任何调查数据做一些情绪分析。这是我们在这里展示的一个例子是关于文本和日志挖掘的。在文本挖掘中，我们只是想看看它在特定数据集中有什么情绪。这个预测是用R和Databricks完成的。我们能够在很短的时间内做到这一点在一两天之内就能给出情绪分析结果。因为Databricks中所有的内置库都能帮助我们得到这些结果，所以它非常快。我们还做了一些日志挖掘，以了解任何系统的性能如何，或者有多少用户登录。用户登录的频率是多少。所有这些东西都来自输入数据日志，我们存储在S3中的东西，我们想对其做一些预测，所以我们做了一些日志挖掘以及我们的部分实验。我们创建的模型怎么样? We also did the time series to predict how many number of applications were coming in the future years. Or what is the pattern that was so deep but also high and how many recipients are even applying for certain kinds of applications. These were also run through the time-series models. And what we did was we kinda ran through all the algorithms, like the RainForest Regression Models or Logistic Regression all these models and we predicted which will be the best, which has the better accuracy based off that we kinda predicted the same models, which we had done it in a previous library. We kind of managed to do that this year. And also there was one more thing on the Hedge Tool Integration. Hedge Tool is another AutoML.

AutoML可以与我们一起使用，这帮助我们无缝地集成到Databricks中。它只是现有集群的附加集群和附加的库，库到集群。这也帮助我们利用对冲工具作为实验的一部分。让我们回到这张幻灯片的安全和治理部分。

我们正在将思维模式从“遗产”转向“数据湖”概念。我们希望对所有数据集保持相同的权限和访问控制列表，

我们在湖中拥有同样的角色和特权。这个Databricks内置了ACL和ACL，我们可以做到。也要有证书，

凭证秘密管理，我们有一个秘密管理器来存储所有凭证并在笔记本中引用它们。这就是Databricks中一些可用的特性，我们将其作为系统的一部分。我们还创建了S3桶级别所需的确切的IAM规则，以及Databricks上的ACL规则，以便为我们拥有的任何数据集提供这种安全性和治理。关于Databricks管理API的使用。因此，这是Databricks的一个内置功能，我们能够创建任意数量的集群或作业，并每天监控它们。我们还集成了气流来管理和编排监控体验。这是我们在库中所利用的东西。可以使用现有的可用库列表在notebook中复制任何内容。因此，对于我们的机器学习和数据科学团队来说，做任何需要很长时间的程序都更容易。团队应该花更多的时间来编写代码，而不是附加到一个库中。 So this was more easy for us to do that. And also integration in deployment. We integrated Git automatically we did the configuration of Git Databricks and that was an easy sync for us to enable for us to sync all our changes. And also it helped us in our continuous integration and deployment perspective. Apart from that, the last one is the MLFlow, MLFlow is a big milestone for us, and we are able to run these models using the MLFlow clusters. And the API has been helpful so far.

这就是我今天要讲的全部内容，肖恩。-谢谢你，Prabha，告诉我们这些年来你所做的工作。我们付出了巨大的努力，取得了巨大的成就。在最后几张幻灯片中，我们讨论的是我们学到的经验。这是我们在研究过程中发现的一些东西的结合。其中一件事就是制定一个培训计划。当我们引进这个产品的时候，USCIS还没有完全理解什么是数据科学。所以我们试着自己去了解。所以我们自己进行了使用产品和工具的培训。然后我们从全国各地不同的办公室请来了大约30人来参加培训，其中一些人很先进，他们能够很好地掌握概念，有些人则不是那么好。 So at that moment there we decided that we needed to work harder with our user base and build our own internal development plan for our users. Like with any place of business training within your own data sets is always very big. It helps the user base to realize the power of the product. We’re actually in the process right now of building a customized training plan alongside Databricks and training and support that will suit the needs of our mid-level to advance users. Especially as a lot of

商店现在开始抓住Databricks，他们想把他们的代码从SAS转移到Databricks。因此，建立更多的定制化培训，让我们能够与用户建立更紧密的联系。通过这个工具，我们已经完全实现了基于云的体验。我们认为立即移动到云端，就像任何人都卖任何东西一样，会立即快速和轻松。直到我们引进数据库。我们可以抓住这一点。我想我向你们展示了，随着我们变得如此可扩展，我们不仅扩大了向人们交付的产品数量，我们还扩大了我们自己团队的知识库。当Probha第一次成为第一批使用该产品的人时，我认为这引起了我们开发团队中其他成员的很大动力，他们想要学习这个工具和产品。通过这个我们带来了一群Informatica ETL开发人员OBIEE开发人员

学习如何使用这个工具。问题在于第一波学习如何使用产品和理解它。她训练了第二波，现在第二波正在训练我们队的其他成员。在我们的开发团队中，有很多人对该工具有丰富的经验，并且知道如何使用产品来交付。主题专业知识也非常重要，不仅仅是Databricks或云计算领域的主题专业知识，还有数据。这又回到了训练计划。你对数据了解得越多，产品允许你用数据做什么，就能真正解锁一些非常强大的东西。所以当我们开始把数据方面的专家，引入到产品中，培训他们如何至少精通产品。他们看到了价值，开始变得更好。反过来，他们开始成为工具本身的主题专家。 Not necessarily coming to IT for support, but going to each other. What I like to call it, Tier Zero, ask your friend and they may know the answer and you may be able to help you along. And when you start getting that type of organic ground roots support within these tools, it just makes everything easier for everybody. And it all aligns your business to your IT. In the automation is unbelievable of what we’ve been able to accomplish there.

当我们谈论自动化时，不仅仅是工作的自动化和数据的自动化，以及它如何为你工作。为了节省USCIS和亚马逊的成本，我们会在一夜之间恢复很多服务器。在非工作时间，我们已经能够在开发人员可以进入的地方建立工作。每个人都是远程的，尤其是现在，我们都在不同的时间周期内远程工作。我可以进入，通过数据打开工作环境，关闭你的环境。能够让人们这样做，因为我们已经看到了一些主要的成本节约。最终我们想要得到的是

我们正在使用机器学习和操作我们的机器学习模型来完成繁琐的工作，在这些工作中，我们可以节省人力因素的时间，并将工作量重新集中在其他地方。

因此，当我们实施Databricks时，我们建立了一个成功战略，我们触及了我们成功战略的每一点，正如你在这里看到的。因此，首先是性能，很明显，有了扩展和利用域和定位实例的能力，Oracle过去没有这种能力，我们马上就看到了好处。我们在S3上的可伸缩读写性能是惊人的。对各种统计程序的支持对USCIS来说是巨大的，USCIS的大部分用户都是SQL开发人员和SQL程序员。所以能够用最少的语言将它们滑动到工具中，我们也有很多R和Python的用户。但他们能够通过一个笔记本学习多种语言，并在语言之间切换。正如机构听到我们谈论了很多关于Scala开发的内容，因为这些是ETL的主要代码首选项。我们向我们的用户展示了这种语言的强大功能，现在这些用户实际上希望更加熟悉Scala并接受相关培训。

当他们迁移到Databricks时，使用多种语言工作的能力实际上为我们的分析社区提供了多样化。显然，这些工具中的机器学习和深度学习，我们已经能够将数据通过机器过程移动的概念，转化为结果，我们可以开始执行枯燥的工作功能，在一个职员或单个人的水平上，通过过程移动数据，并从中获得直接价值的能力。现在你可以将这些资源从一个更乏味的任务转移到其他功能领域。

与我们现有工具的集成允许我们连接所有的工具，这对我们来说是非常非常大的。现在有这么多OBIEE、Tableau和SAS的用户界面，我们能够将产品相互集成。我们试图关注并让我们的用户社区做的是在Databricks的时间仓库中构建Justin时间，构建数据，在那里做繁重的工作。如果你更习惯使用SAS，或者在Tableau中更习惯使用这些，在Databricks中进行繁重的工作，构建你的数据集，然后使用SAS，使用Tableau来分析和处理数据。我们的演讲到此结束。

非常感谢大家允许我和Probha与你们分享我们的旅程。