使用Apache Spark的医疗保健索赔报销

视频记录

大家好，我是萨利姆·赛义德。我是Optum的首席架构师。Optum是医疗保健服务领域的领导者。今天我们将讨论使用Spark重写索赔报销的过程。

Spark理赔

今天我们将讨论索赔报销系统的简要业务概述。为什么我们选择Spark重写，我们的旧系统进入新系统。该声明ETL重写使用Spark。我们将首先讨论这个问题，然后是迁移和挑战。然后我们将讨论使用Spark的索赔报销重写系统。然后，我们将讨论Delta-lake收养。收益和性能。我们所看到的成果。其次是扩大视野和成功迁移的技巧。

下面简要介绍索赔报销制度。如你所见，在右上角的零层，有一份合同和一份保险。保险范围是保险公司为病人提供的医疗保险。这规定了病人的责任是多少，自付是多少?不是巧合，哪些服务是包括在内的?

你可能知道类似的东西，合同是，提供者，也就是医院和付款人，也就是保险公司之间的合同文件。所以合同是在幕后的，我们永远看不到，它谈论的是为病人提供的服务需要支付多少费用。所以，合同中有概念的复杂性。

所以我们的软件可以使用这个合同来评估一个给定的索赔需要支付多少钱。我们来看一个场景。在左边，你可以看到一个病人，他生病的时候走进医院，提供了保险文件，也就是保险卡，然后病人就被收治了，接受了治疗，在所有的护理都提供了之后，病人现在好了，他离开了医院。之后，医院会把所有的费用和为病人提供的服务都汇总起来。为这些服务准备索赔，并将索赔发送给付款人。付款人会根据已经协商好的合同评估这个索赔要求，并进行报销，然后支票中的报销金额会回到医院。有可能这种报销是错误的或少支付的，在这种情况下，医院将失去收入。所以，有一个过程，医院可以发现有少付的情况发生。所以他们可以提出上诉，作为上诉的一部分，支付人会评估，然后可能会调整支付。本质上，我们的Optum 360软件，在支付费用的情况下，可以帮助医院满足诉求。 So you can say essentially it brings money, in the sense that there are no losses that are happening behind the scene, that you know that would go unnoticed, unless our software is placed in the hospital and which is working for them to recover the losses.

我只是看到索赔报销系统是一个复杂的系统，因为在美国医疗保健系统中有复杂的报销规则。

为什么火花

因为有太多的支付人，

比如医疗保险和医疗补助以及许多商业支付方，在幕后有大量的谈判，制定了大量不同的规则来进行报销。因此，一个建立在PL SQL和SQL之上的系统和我们的DBMS开始出现问题，或者开始出现可伸缩性和性能问题，因为规则的复杂性增加或容量增加，或者两者都发生，这就是为什么我们选择Spark来重写我们的系统。所以我们可以从Spark中获得性能和可扩展性。根据我们的经验，它适用于大容量和小容量的场景。它适用于，通常适用于任何应用，即使大数据的三个V并不适用。V代表体积、速度和种类。因此，通常建议如果你有这三个V，那么你需要一个更大的应用程序，但如果你没有这些，在我看来，你仍然可以采用Spark。Spark是稳定的，是生产级的，你可以依赖它来编写企业数据应用程序。API简单而成熟，非常容易采用，围绕它的工具集也很成熟，因此，它将帮助您从开发到生产支持和维护。软件的所有阶段都可以开发。 It can be cost effective, essentially because as comparing to IBM as you might, well, you might be paying a license fee. Here, there is no license fee, the open source file is completely free and and source of your software. There is a possibility of cost saving, if you can adopt dynamic scaling in a cloud environment, because Spark loves to do sources. So, if you run a long running cluster with all that much resource, then it’s going to continue, you know it is not going to be costly. So you will need to adopt dynamic scaling to adopt that, but there is a definitely possibility of reducing costs as compared to IBM’s.

我们选择Spark的原因是，它很容易被采用，因为正如你所知道的，在其他一些需要掌握的概念中，Spark在幕后处理它们方面做得很好，这样你就不用担心在幕后使用分布式编程，分布式执行。你只需要编写简单的代码，Spark就会处理一些事情，比如Lazy执行、分布式执行等，这些事情会在幕后发生，但你不会意识到。所以很容易接受。API非常流畅，它会，它会，它会，它会，它会，它会，对你来说，它会很自然，很容易使用。Java和Python是非常常见的技能集。让开发人员开始开发Spark很容易。整个开发过程可以基于ID，因为Spark可以运行你的测试用例。就像您正在学习这些测试用例的任何标准一样，您不会觉得在场景背后有一个集群，它正在执行您的工作流。在开发环境中运行作业不需要任何虚拟机。就像Hadoop，不像以前的Hadoop。

你要写的代码将是批处理和流兼容的。因此，您不必为相同的业务逻辑编写两组代码。它与许多系统兼容，它有一组惊人的连接器，可以连接到各种数据技术，以及其他技术，所以兼容性是存在的。你永远不会感到孤独。有一个活跃的社区支持，例如，你知道，如果你在Stack Overflow中问一个问题，你可能会在一天左右得到另一个回复。Spark的官方网站上有大量关于数据砖的教程、博客和文档。这样可以帮助你加快这个过程。

让我们更深入地研究ETL。声明ETL重写过程。索赔ETL是一种获取索赔的系统，然后清理它们，然后在上面做一些业务逻辑，然后为偿还做准备。第一部分是，获得ETL的权利要求。

这是之前和之后的系统。在左边，前面是一个典型的PL SQL系统，声明以文件的形式出现。然后我们写了一个解析器，审计解析器，它可以解析EDA格式的声明。所以，它会解析它们并将它们放到某个staging表中，然后我们运行PL SQL代码从staging表中获取数据。清理它们，处理它们，然后将它们推入最终的Oracle表。然后从那里开始，它进入了下游流程，比如，分配规则，(模糊的)流程报销流程等等。图中没有显示。我们用Spark重写了这个系统，就像你们在右边看到的。你可以看到主要的区别是(听不清)块被替换为as Spark和(听不清)所以在新系统中，我们以与文件相同的方式获取索赔文件，然后我们将其传递给相同的解析器，现在Spark以文件的形式获取输出，作为部门文件，然后我们在那里执行所有的业务逻辑。然后我们使用基于市场的数据湖来运行我们的运行我们的…进行历史查询并运行所有的商业价值。 And then after it’s finished, the result goes back to the staging tables and then those staging tables, from then those staging tables, it goes back to the record table. So what I mean is Spark processes the claim files and uses that data lake to do a historical lookup and helps in processing. At the end of the processing, the result goes back to the data lake, as well as originally is pushed into the Oracle finals tables, through the staging tables. So data is pushed to the staging table and then from there we run some words sequel that which kind of merges the data from the staging table into the primary table. And then once the data lands in the primary tables, there are many downstream systems from here, which are dependent on the table, so they will pull it up from the Oracle table and handle it for the staff.

让我们看看声明ETL重写过程的重点。因此我们使用Spark 2.4，开源版本。我们的数bob下载地址据湖是拼花板格式，我们正努力将其从拼花板格式迁移到Delta lake，我们将在本演示结束时了解更多关于其性能优势的信息。BOB低频彩

我们目前使用的是Spark独立集群。我们计划迁移到Azure公共云。有时是一些蛾子。然后我们还使用齐柏林笔记本和Spark Shell等工具来调试其他Spark上的问题。

让我们讨论一下我们已经看到的成果和挑战。如你所见，这个巨大的图形，x轴是体积y轴是时间。橙色的盒子代表Spark法则，灰色的盒子代表Pl/SQL程序。如你所见，Spark负载非常稳定。所以销量从400万上升到2000万。还是做得好时机没有涨那么多。因为它可以扩展，而其他的PVSQL程序，你会看到随着容量的增长，时间变得越来越长，与此同时，如果容量继续增长，我们就会负载失败。所以，正如你在这里看到的，从中高容量的场景来看，Spark在性能和可伸缩性上总是胜过Pl/SQL系统。我在这个图中没有显示的是一个低容量的场景，假设有50万条记录的场景，其中Pl/SQL的加载实际上比Spark的加载更快。

因为他们只是，你知道，Spark负载，有一些开销来分发数据，分析它，学习它。

所以，在较低的情况下，Pl/SQL胜出，但在时间上的差异是几分钟，所以，这并不重要，它在低容量时更快，在高容量时极慢。因此，在所有情况下，我们都觉得在性能和可伸缩性方面，Spark将优于传统的pl/SQL系统。

继续进步，你知道，随着时间的推移，我们使用的代码库和技术变得陈旧，失去了它的光芒，所以，可能会有时间，老代码库上的技术债务会越来越多。因此，作为重写的一部分，我们在某种程度上摆脱了所有的技术债务和代码中的问题。这就是关键。就像我之前说的，通过使用动态缩放，有可能节省成本，重写的一个副作用是，现在我们的数据被放在两个地方，比如现在在数据库和数据湖中。所以数据湖数据是完全可分割的，它可以用于任何可以使用相关性的处理，因为它是可分割和组合的。因此，它是一个很好的基础设施，用于进行临时分析和机器学习一类的工作负载。

所以这是一个优势，你可以用它来做其他你不能用我们的DVR系统做的事情。

挑战

让我们看看挑战。这对任何新系统来说都是一个典型的挑战，对吧?如果您编写了一个新系统，那么该系统上就没有子系统。你会意识到，你知道，运营团队和支持团队，他们已经围绕它建立了这个工具集。现在你和他们都习惯了旧的系统，所以你使用更大的系统，是你与数据集交互的方式。所以这一切都需要改变。所以你需要考虑操作化，你的代码库，这远远超出了它的开发。所以你需要考虑所有需要改变的辅助工具，所有的过程和程序。所以，你需要开发新的工具集来进行交互，告诉人们使用这些工具集。

数据湖和数据库有点不同，因为数据库有索引，所以它可以快速访问数据，但是基于parque的数据湖在你访问(听不清)时就没有那么快了，所以它对于大容量的数据非常有效，但是如果你在调试一些东西，你想要一条记录，那么你可能要等20分钟，30分钟才能舒服地看到记录。所以有时候这很有挑战性。然后人们需要学习新的技能，能够使用Zeppelin和Spark SQL，这非常像SQL仍然是逻辑。

有些挑战是，你知道，有自定义工具和脚本，就像我之前说的那样。所以这也需要重构。节约成本是可能的，但只有在动态环境中才能节约资源。所以，如果我们有。如果你有一个没有损坏的基础设施，每月或每年可以动态扩展10亿秒，那么你将会产生大量的成本，因为Spark需要大量的资源，如果你要长时间维护这些资源，那么你会很痛苦。但如果你使用的是云计算，那么就有可能采用分钟计费或小时计费。那么在这种情况下，你就不会感到足够舒服(不清楚)来完成工作。在这种情况下会有成本。所以我想说的是，这实际上是他们节省成本的优势，但在你互动之前，不要保证节省成本。这就是挑战所在。开发过程，就像你可能在开发周期中有多个团队。 So, your one team they have experience by working on on the Spark project, other teams may not and you know, so but to adopt you need a wider skill set. So, you may also need to be in obtaining the development team, to be able to make contribution to this. So you need to take care of that as well. So the last point here, possible data consistency, is a very specific case here. What I mean to say here is that, here you saw the data is copied in two sources. Like into the data lake and the database and so, So, if the process depends on the in perfect sync, then there might be issues arising from that, because if a job fails in one system, but the push of a button does not fail, that could be a sync issue created. They could be out of sync and that may cause issues. So, if you are developing a technology along the line where data is duplicated, then you have to make sure that it is resilient, that failure in one system, is not affecting the other system. If you tie them down, to be perfectly synced, then there would be issues. There will be issues in all/some of the data.

第一部分是ETL。一旦ETL完成，数据就会进入那些(不清楚的)表，然后报销软件启动，做我们必须做的事情，这是我们将讨论使用Spark重写索赔报销的部分。这是一个非常复杂的系统，就像我说的合同，合同是用非常复杂的业务规则定义的。因此，由于复杂性，我们选择了Spark，这样我们就可以处理所有的复杂性，这是典型的SQL算法无法处理的，因为随着后续的复杂性(模糊)变得太复杂，然后数据库在生成最佳计划时出现问题，这导致了大量的可伸缩性问题，也没有不育性。那么，让我们看看我们是如何依赖它的。

这是整个密歇根大学系统的对比。在左边，你可以看到旧的系统正在从一个叫做票据交换所的实体接收数据，它是Optum的票据交换所，用来接收来自所有供应商的索赔。所以那些声称从票据交换所最终变成一个数据库,然后到一个文件系统和数据库,最终我们的系统,有一组PLSQL程序,以及一些工作或共产主义也是麦哲伦PL SQL,这使索赔投资计划和储备被推到像一个表,组表,然后从那里,它进入一个提要进一步过程和下游过程。所以这个系统已经基本完成了，而且基本上已经完成了。不仅仅是一个PL SQL进程被改变了，整个(听不清)都被改变了，因为我们正在现代化整个数据采集和处理(听不清)。在右边，我们正在做的是，我们通过CMTN公司获得所有的权利。但是票据交换所和我们的系统之间几乎没有直接的交流。通信是通过Kafka进行的，所以我们在两个主题中定义了Kafka，所以索赔被发送到一个特定的主题，然后我们的应用程序监听该主题，接收索赔，这个系统是一个流系统。它接收关于卡夫卡主题的声明。处理它们，然后将数据推回另一个主题，这也是在Kafka上。 At the same time it also pushes the result back into a data lake, which is a data lake based data lake for Ad hoc analysis as well as it also pushes the data back into a data warehouse.

我们来详细看看这是怎么回事。

设计约束

因此，由于这是一个专有系统，通常用于声明我们必须，我们希望确保，该功能以多种方式公开。例如，作为一个REST API和流式API，也是批处理兼容的，它需要是一个内部源代码和共享库。我们还希望能够使用公共领域驱动的设计来解决开发过程的复杂性。

因此，这个约束的裂缝是，我们希望这个核心功能以尽可能多的方式公开和重用。所以我们希望尽可能减少对任何技术的依赖。同时，我们也想要，可扩展性和性能，我们不希望它受到(听不清)的限制，所以在这里，我向你们展示了集成的三个版本。

所以，在你看到的三个版本中，索赔报销罐。这是核心能力或补偿，它是用Java开发的，它可以接收平面或对象的输入。想象一下它的两个输入我们会看到穷人。想象一下这是一个可共享的基础设施。所以我们可以把这个插入到许多不同的交付机制中，以各种方式实现索赔补偿。最上面的是一个流机制，他们向你展示了数据通过Kafka来自清算所，然后我们使用Spark能够并行流化这些数据，然后将这些数据以JSON格式转换为域对象。然后这些领域对象被输入到索赔报销软件罐子中。重新访问到Java API，然后进行补偿…这进行补偿，输出返回到Kafka que，以及Delta湖和数据仓库。类似地，有一个批处理机制，本质上可以说是流机制，数据从不同的源读取，这是一个数据湖。同样，通过使用数据集API将数据从数据包转换为数据对象，转换为JSON对象，域对象，然后将其传递到索赔报销软件APA。 And then that does all the heavy lifting of reimbursing and then the output is being pushed into (indistinct) The third one I’m showing is a non Spark application. It is a typical a REST API. So we have requirements that the users or even other systems could be doing any live interaction. They could be standing it in live and expecting the reimbursement to be done quickly, returning back for that kind of delivery mechanism. The same core software, which is the Claim reimbursement jar. The same software is plugged in into as a REST API and and delivered… The securities are delivered over the website, or from one application to another application. So as you see in all the three different integration frameworks, the common is the Claim reimbursement API, which is the core software, whereas the data piece is handled by different pieces, for example, by Kafka or by Delta Lake and then the scaling is also a little bit different. So in the top two cases, Spark takes care of scaling and performance. Well, at the bottom, it will be different.

示例代码

让我们看一个示例代码，它是对这段代码进行流式处理的。在上面，我展示了两个重要的东西，一个是索赔补偿API，(听不清)本质上，你知道，我们正在从Kafka队列读取索赔，索赔是JSON格式的。他们正在转换索赔，如第30行所示。使用数据集API将索赔从JSON格式转换为索赔对象。

正如我们所知，为了报销，我们需要数据集，我们需要索赔，我们也需要合同。第11行和第9行直接从数据库中读取合同。因此，这些合约被读取，然后被广播，这样它们就可以在所有的执行程序中查看。一旦我们在合同中得到索赔，这里，在第15行，我向你们展示作为一个映射操作，我们简单地称它为索赔。报销人在合同中通过这一点，作为经理，你知道，这都是关于合作的，他们承诺要求。然后，claim .报销。calc将执行大部分业务逻辑。因此Spark的职责是能够以并行机制获取数据并扩展处理。索赔方的责任。报销混合API是为了完成业务逻辑。Kafka系统的职责是能够将数据从一个系统移动到另一个系统，这三个系统一起，为我们提供了我们试图实现的可伸缩性和复杂性。

实现亮点+相同的索赔报销库跨流，批处理使用

让我们来看看实施的重点。正如我所说，库的核心是用Java编写的库，所以我们可以在许多不同的技术上公开它，比如流、批处理和REST API。所以业务逻辑是用Java编写的。我们选择Java是因为它兼容Java和Scala。我们可以在Scala上写Spark代码，只需要调用库我就是这么做的。我们特意尝试避免用Spark SQL编写业务逻辑。

因为一旦我们使用了Spark SQL，那么该软件只能运行Spark(不清楚)，我们不能在REST API上运行它。因此，由于这个原因，我们没有使用Spark SQL来编写核心逻辑，但我们使用Spark SQL来获取数据，转换数据，将其转换为域对象，然后调用API。

我们大量使用数据集API，如果你使用的是小数据，如果你从Scala使用Java API，你可以这样做，但你可能需要将对象从Scala转换为Java。你甚至可能不得不使用collection. Java转换器API来将Scala集合API转换为Java集合API，然后你将能够调用大多数。我们大量使用spot是因为它的可伸缩性、可伸缩性和稳定性，以及与许多不同数据源的连接性。所以它是这个体系结构的核心组成部分。

所以我们大量使用数据集API，这样我们就可以使用APA来进行操作。

我们仔细地设计了基础结构，将索赔的所有组件作为一个聚合对象放置在一起。所以我们不需要做任何关节来构建claim对象。因此，在ETL过程中预先构建索赔对象，将索赔的所有信息集中在一条记录或一个对象中以避免连接，然后直接从数据库中读取并广播合同。基本上，本质上计算过程最终变成了这个的映射，因为你有了整个对象你可以调用API(模糊地)传递给对象而不用担心关节。这对性能有很大影响。所以，你必须做很多计划才能提前设计那个对象，但它是什么。

让我们看看新旧体制之间的结果。所以，这是一个实验，这是我们在一个完整的数据湖上进行的性能运行。因此，我们的一个数据湖包含8000万条索赔记录，大约100g。所以，我们使用两个系统，旧的和新的，看(不清楚)，典型的索赔报销系统有两个步骤。一个是补偿，就像你得到索赔，你赢得了合同，你应用业务规则来计算补偿。这是一件事。一旦计算出补偿，第二步是将数据推入其他来源，例如，在您的数据仓库甚至数据库中。

(模糊)数据库，这样它可以被报告，它可以显示在用户界面上。所以有两个组成部分，我之所以把它们叫出来是因为它们有不同的可伸缩性。例如，第一个系统，你知道，从一个文件系统运行到另一个文件系统，或者从一个流源运行到另一个流源，运行得非常快。这就是它的可扩展性。正如你所看到的，八千万份索赔单在86分钟内就被处理了，这里的复杂性非常高，但它会有规律地扩展，吞吐量将会是，每分钟一百万份索赔单。然而，将数据推入DBMS并没有那么快。实际上我们很幸运，这个操作只是一个次要操作。因为它的性质，但如果它是一个更新操作或删除数据操作，那么它会慢得多。所以，即使是插入操作，也要慢两倍。所以，这个系统给我们的吞吐量几乎是每分钟333,000个请求，这是用20个虚拟cpu和100gb内存之类的硬件实现的。 If we compare that with our old system, then there is no exact one to one competitor, because we never would have run over systems on such a high volume. We could not say that “My database had 80 million records. Can you go ahead and calculate all the things.” We could not do that, but we have done 300,000 accounts per hour.

如果我们能计算的话，甚至每小时有一百万个账户。比如我们同时想要(模糊地)8000万，但如果我们能把它分成50万的小块，那么我们就能在整个系统中计算它。这样的话，如果你比较一下性能，整个系统大约每小时40万索赔，而新系统大约每分钟33万索赔，所以本质上，新系统比旧系统快50倍。

从成本的角度来看，新系统比旧的要好得多，因为，就像我说的，如果你在云上，我们也要在云上，但我们还没有到那一步。如果你在云端，那么典型的硬件，比如D类软件。D类，抱歉，D类节点。对不起，我有20个cpu, 140 GB，高级层和数据工程类的包，有Databricks，几乎每小时4美元。以这样的工作量，我们可以在20小时内完成8000万份索赔计算，再加上我们还要支付存储费用。但是相比之下，如果我们使用非DBMS，那么这里就没有直接的竞争对手，因为，例如，云上的Oracle不为非Exadata工作负载提供动态分配和动态扩展。如果您使用的是普通的Oracle，那么您是在一个虚拟机上，它不可能那么容易地扩大和缩小。

所以它不能通过扩大或缩小资源来节省成本。这在那里是不可能的。在PostgreSQL中，这是可能的，但是伸缩性不是那么好。就像扩容需要重新启动你的应用程序一样，与此同时，我们还没有见过这么大的容量。所以这里没有确切的比较，但如你所见，有可能节省成本。如果你将所有复杂的工作负载转移到Spark，然后使用IDBMS来生成报告(听不清)，这将节省大量的成本。在这种情况下，你不会花费大量的资源，也不会在数据库上花费高峰资源。因此，无论何时，你都可以在基于Spark的工作负载上花费一些成本。

三角洲湖泊吸收

关于直接索赔的讨论到此结束。

让我们进入下一个话题，那就是三角洲湖泊收养。所以，正如我之前向你们展示的，我们目前有(不清楚的)数据湖，我们正在努力用三角洲湖取代它。所以，这些是数字的表现和我对系统的笔记。

因此，我们目前使用的是开源数据湖，bob下载地址而不是管理Delta湖的数据砖，这个开源的Delta湖对我们来说已经足够好了。所以，在开源版本中，你bob下载地址没有z轴次序。我们所做的就是用一个键划分三角洲湖用另一个键对数据进行排序我们选择了这个分区键和排序键，有意识地依赖于大多数访问键。如果我们大部分时间通过两个键访问Deltalake，那么这两个键就是我们用来分区的。这样做的结果是，任何查找，任何对这些键的插入更新都非常快。而对其他键的任何其他操作都是相同的性能。这里有一些注意事项，如果你在Delta lake环境之外使用开源版本，那么z顺序是行不通的。bob下载地址Z_order是一个很好的功能，你可以…

实际上，您可以让您的数据湖为几个键执行。比如，没有z轴顺序，你可以按一个键来排列你的数据湖。在这种情况下，通过一个键访问将会很快，但是在z轴顺序中，你可以使用多个键。不同之处在于你可以有3个4个键，但是z轴效率会随着键数的增加而降低，所以你不会用太多的键，但有几个就可以了。

optimize命令也只在数据块注册的情况下有效。为了解决这个问题，你必须使用。基本上是重建你的三角洲湖，偶尔重建一次就能达到乐观的效果。但我们计划很快进入云计算，然后我们将使用数据库，所以我们最终会使用乐观主义和尤达，只是时间。

我说过按顺序划分的键你需要仔细设计因为这对性能影响很大。所以任何超出这些键的东西仍然会以同样慢的速度。

使用Oculus develop访问同样缓慢，但使用这些键访问将非常快。

正如你在这里看到的，这两个键上的所有查询都非常快，这是一个代码示例，我向你展示如何在一个(听不清)上构建你的Delta lake，你基本上把数据作为parque的一部分读取，然后用Order Back子句和partition Back子句作为数据保存。因此，该地区将成为一个数据湖，速度将非常快。让我们看看表演是什么样的。

性能比较

这里有个性能对比在前几行中，所有的操作，插入，更新，合并，连接，所有在这些键上进行的操作都非常快。作为队长，你可以看到一个简单的实际操作需要18分钟，而现在只需要20秒。对一列进行简单的前导操作，之前需要3秒，现在只需要1秒，然后就停在这里了，如果你在做更新合并，那就需要(听不清)但现在你可以在不暴露数据的情况下做这些操作。所以，它非常快，1小时10分钟，而不是370秒。-加入我们也更快。速度不快的东西排在最后一排。它可以做任何不在这些键上的操作，那么时间框架是相等的你可以通过增加资源来减少时间。

所以你可能不会被这个挑战因为大多数的处理不是通过这些键发生的，而是有一些你用过的键，在网上发布。

拓展视野

所以在重写之后，我们现在正在扩大我们的视野。我们期待着使用新技术。

我们现在不受大批量操作的挑战。如果有数量增加，那么就变成了硬件扩展的问题。我们不依赖于续作优化，也不依赖于IDBMS的表现来处理Spark的复杂性。

没有任何实际的性能问题。与流工作负载的集成更大，更容易，与硬件连接相比，应用机器学习我们的数据库设置。再仔细看看，我们也很期待销售成本。

所以你从我们做的两本杂志中得到了一些建议。这对你来说可能很方便，所以，现场运行并不能节省成本。这就是我之前说的。因此，计划将云迁移作为模型的核心组件。这样你就可以保证节省成本，这对企业来说是非常有吸引力的。考虑更改生产支持过程和其他工具集，它们不是软件的直接组成部分，但随着您将软件交付到生产环境中，其他团队可能也会参与进来，它们将发挥作用。当然，使用德尔塔湖。完全不要使用基于拼花的数据湖。因为这几乎没有任何理由。三角洲湖是快速的，它几乎相当于一个拼花扩展操作。

最优的模式设计将提供最大的性能遗传算法

花点时间设计你的模式。最佳设计方案将带您进入设计和性能应用程序的很长一段路。这样游客们就可以在那里度过一段时间了。与数据帧API相比，我们使用数据集API的程度更大。区域是我们愿意的，复杂的逻辑和我们希望编译时安全。我们的团队擅长Spark、Scala和Java代码。所以不是每个人都需要知道Spark语法。它们可以用Java和Scala语法编写永恒代码，如果你使用数据集API如果你有任何可用的库，你就可以使用它，但它的一个缺点是API相对于数据帧来说有点慢因为它必须很容易地分析数据。

所以有时候我们会同时使用这两种方法。所以当业务逻辑比较复杂时，我们使用数据集，但是当你访问数据时，非常方便。

了解整个数据管道的整个体系结构。你可能只激励了一个人。你可能会因此陷入瓶颈，但与此同时，你可能会离开对方。因此，当您承诺可伸缩性和性能时，请考虑整个管道。假设你碰到了一个，那么，在那之后，水线会移动到另一个地方。所以，在做出预期之前，要考虑所有这些因素。我们很乐意使用开源Spark。bob下载地址所以现在我不再害怕将它用于生产级应用程序，用于企业应用程序。放手去做吧。这是一个非常稳定的应用程序，软件和框架都非常稳定。 Even though you do not have those V’s, TVs or six V’s or big data application, you still be okay using a Spark data analyser. It will not disappoint you.

非常感谢你来参加我的会议。请给我你的反馈，你可以通过我的邮箱联系我，(电子邮件保护)