在Apache Spark中过滤和丰富数据

视频记录

-嗨，大家好!希望每个人都做得很好，你们都能适应这种在家工作和虚拟出席会议的新规范。这是我今年的第二次虚拟会议，我希望你们都能赶上。感谢您花时间在Apache Spark中进行丰富数据和过滤数据的讨论。我希望这个演示提供了两种不同模式的上下文，您可以在基于Spark的应用程序中使用它们。让我们开始吧。

在我们进入技术话题之前，我想先简单介绍一下我自己。

我是在Capitaone工作的软件工程师硕士。如果你拥有我们的信用卡，你可以在星巴克刷卡，买咖啡，你能得到多少奖励是由我的应用程序计算的，我从一开始就在开发基于Spark的应用程序。我称之为1.2和Java 2，我一直密切关注大数据技术，我已经研究大数据技术有一段时间了，我定期为Capitalone Medium技术博客撰稿，我在我们的Medium网站上写了很多博客。

你可以在推特和领英上找我。我已经提供了我的提法。

好了，这是今天讨论的议程。所以，首先我们会讲到基于奖励的用例。我们在首都所经历的一切。这将为我们讨论我们在这里使用的是哪种模式以及哪种模式更能发挥作用奠定基础。这些都是我们在用例上下文中会讲到的。首先，我们会讲到过滤方法以及我们在用例中是如何使用过滤方法的这种方法有什么问题以及我们如何使用另一种叫做丰富数据方法的方法来处理这种方法。最后，我们将得出结论，并留下一些提问的空间。

(键盘键点击)在我们深入讨论用例之前，现在我们可能知道Capitalone已经进入了技术领域，在技术方面我们是银行业的先驱，我们的大部分软件都是开源的，很快我们就会完全在云上运营，我们很快就会退出我们的数据中心。bob下载地址

《CapitalOne》中的用例

我们在各种用例中广泛使用Apache Spark。轮盘，批处理，流式处理，机器学习工作负载。它被广泛应用于各个地方。

(键盘按键点击)好的，我们将详细讨论用例。因此，这个特殊的用例来自Capitalone的奖励部分，为了便于理解和简洁，我将应用程序抽象为更简单的上下文。所以，我们应用特定的基于账户的规则和特定的基于交易的规则我们计算收益并在数据库中提示我们的系统，对吧?所以，你在星巴克刷信用卡买咖啡，你应该得到一笔特定的收入，对吧?这就是整个应用程序的功能。所以，它会给你提供奖励。它完全是在Apache Spark中完成的这就是我们要讨论的用例使用两种不同的方法，一种是从基于过滤的方法开始我们会讲到另一种方法，以及我们为什么选择。首先，我们将介绍基于过滤的方法。

数据过滤方法

基于过滤的方法使用Spark的内部连接，对吧?连接是很标准的，我们用在大多数数据集计算中，对吧?在这种基于过滤的方法中，我们为什么要这样做呢?我们在这里引入两个不同的数据我们在特定的连接标准上进行内部连接这就是我所说的阶段以及计算是如何发生的开始我提供了一个基于过滤的方法图。稍后我们将讨论一个基于数据的示例。信用卡用例中的过滤方法，不管我刚才说了什么，它是如何流动的?因此，我们引入了10个事务，我们应用了基于帐户的过滤器，它过滤出了5个事务，这是在内存中使用Spark内部连接完成的。这样就过滤掉了五个交易。然后我们应用基于事务的业务规则。例如，基于事务的业务规则是，只考虑购买。 Don’t consider the payments. Similar to that for account based, its something like, whether the account is in good standing. This is not a defaulted account. Or those kind of the simple cases what I am defining by account or business based rules, right? So, then that transaction based rules filters out another three. Finally, yields us two transactions which is what we are using to compute earn, right? So, this is what I mean bu a filtering approach. We are starting off with ten transactions. We are ending up with two transactions, which is a valid reason but on the whole process, in this simple example, we have filtered out eight transactions which happened in memory, right?

那么，让我们用同样的用例，来看看基于数据的例子，对吧?

过滤方式举例

所以。

好的。同样的例子，我只得到三个交易，我们试图对这些交易应用基于账户的规则。在本例中，交易数据集，左手数据集和基于帐户的数据集，右手数据集。我们正在从基于帐户的数据集中读取良好的帐户当我们试图使用内存中的内部连接来连接它时就会产生一个结果，对吧?

所以，现在你可能知道结果是什么了。所以它删除了一个默认交易，得到两个，这是良好账户的交易。同样的，当我们应用基于事务的内连接时我们试图读取购买类别我们在同一个事务数据集上应用内连接，得到一个事务。这是有效的交易，账户状况良好，这是一笔购买交易，应该获得奖励，对吗?这就是我所说的过滤方法我们从三个事务开始，在这个简单的例子中，我们最终得到一个事务，这是一个有效的事务但是这种方法有它自己的问题，对吧?

过滤方法的问题

我们现在就来讨论这个问题。那么，过滤方法有哪些问题呢?

因此，处理这种小数据集非常简单，但这不是典型的实时用例，对吧?大数据处理，当你在大数据集上部署这种过滤方法时，在部署后调试应用程序就变得非常困难。一旦应用程序部署了，由于处理量太大，我们就很难看到为什么这个特定的事务没有进入到earn的计算中，对吧?所以，如果我们在某一天处理2000万笔交易，4000万笔交易，对吧?如何在粒度层面上识别，交易发生了什么，对吧?这就是我所说的数据回溯很难当计算发生在内存中时，对吧?在同样的例子中，我们以三个事务开始，以一个事务结束，我们知道两个非处理事务不会被过滤掉。但如何确保这是经常发生的，对吧?这就是回溯追踪来自一个受监管的行业，我们需要这种回溯追踪特定交易为什么没有通过的能力，对吧?有了这样的处理量，重要的不是我们计算了什么，而是我们需要确保我们计算了什么以及为什么我们没有计算其他事务，对吧?

我们可以说，计数是每个人在快速创建基于Spark的应用程序原型时都会用到的操作，对吧?但是当你处理一个巨大的数据集时，计数并不是一种有效的方法，对吧?我们可以说，在同一个例子中，我们可以在每个阶段进行计数，并尝试获得记录的数量，我们可以协调，但问题是计数总是提供给我们关于有多少交易的信息，但在这种情况下，我们需要的是为什么它没有通过。所以每个阶段的上下文信息，计数无法提供。计数只能提供被处理的数量。Spark世界里的每个人都知道计数是一项昂贵的操作。它在驱动端施加了抑制通常我们倾向于避免计数但如果我们仍然坚持使用过滤方法，这是可以减轻的，对吧?但是我们如何在没有计数的情况下克服这种基于过滤的方法问题呢?这就是我们采用丰富数据方法的时候。

(键盘按键点击)如此丰富的数据方法。

丰富数据方法

同样的例子，我们将通过丰富数据方法的镜头，对吧?在我们开始之前，丰富数据方法的关键是，这里我们不使用Spark的内部连接。相反，我们使用左外连接。而不是过滤数据我们所做的是，我们不断丰富信息从右边到左边的数据集。这意味着在同一个例子中，对吧?我们引入了10个事务我们试图在一个基于同样5个事务的帐户上做左外连接，对吧?而不是过滤掉前一个模式中发生的5个事务，我们在这里所做的是，我们只把我们需要的信息从右边的数据集中带到左边的数据集中，但我们没有过滤掉，相反，我们只是丰富数据。因此，对于相同的用例，我们从帐户中添加我们需要的东西，然后同样的10个事务进入下一阶段，我们将基于事务的信息添加到相同的数据集中。因此，它保持了交易的数量不变，因此，你应用业务逻辑，它将产生我们应该获得的相同的两个交易，这是我们需要的预期结果，而当我们采用丰富数据方法时，我们如何得到相同的结论或相同的结果略有不同。(键盘键点击)我们将通过类似的基于数据的示例进行丰富，类似于我们使用过滤方法所做的事情。

我们还是用同样的例子。(键盘按键点击)我们有相同的三笔交易，我们带着相同的账户。

丰富方法示例

这个例子和我们过滤数据的方法是一样的。因此，当我们尝试对相同的数据集进行左外连接时，在这种情况下，交易数量保持不变，但我们将需要的数据从帐户数据集中引入到事务数据集中。这就得到了这样的结果集。

所以如果你看到这里我们需要处理时的账户状态，主要是计算时的状态信息，对吧?如果你看这里，结果集，同样的三笔交易被帐户状态增强到数据集中。当我们对基于事务的数据做同样的处理时我们引入了类别当我们做左外连接并用类别增强事务数据集时，它会得到这个，对吧?所以这里我们引入了一个类别，可能是购买，购买，付款，只是一个简单的例子。

用同样的例子，我们可以做的是，现在我们有了数据集，现在我们可以应用业务规则，任何我们想在上面捕获的东西。我们可以使用特定的标志。这是我们采用的模式。因此，当我们应用业务逻辑时，它可以是多个标志。你可以保持这意味着你想要保留多少细粒度的信息，对吧?在这里，我只展示了一个简单的标志，表示它有资格进入下一阶段，这是基于数据集计算的，其中状态良好的类别购买。所以只有这一点它才设为真，其他的都是假的。我们可以进入更细粒度的级别，通过转到每一列来捕获信息。并将其捕获为有状态标志。然后对这些标记进行操作，得到一个更好的标记，可以用于下一阶段的计算。 So in this example, eligible for next stage flag is said based on status of good and the purchase category. So which yields us (Keyboard keys clicking) one transaction, which is the same result what we have achieved with the filtering approach as well. But with enhanced enriching approach, right? What we are doing is, we are capturing additional information at each stage of the computation. This is what makes it easy for us to back trace or go back and see why this particular transaction is not making through. That kind of granular information helps us post deployment. Now let’s see what are the advantages of enriching over filtering approach.

丰富优于过滤的优点

因此，每个阶段的数据都被增强或丰富到原始数据集中。在这个例子中，我们看到，我们引入帐户信息我们需要对特定数据集进行操作，我们将其丰富到原始数据集。因此，它在计算时捕获状态信息，这使得以后调试甚至分析数据集更容易。所以我们可以回头看看为什么这个特定的交易没有通过。随着旗帜的接近，你会看到“哦，这个特殊的旗帜设置得太快了。”这就意味着，由于你的交易处于特定的阶段，所以不能计算收益。因此，我们还在每个阶段捕获数据列或标志，这为我们提供了更细粒度的细节，以便回溯事务，对吗?基于交易的业务规则或基于账户的业务规则的例子，这里我们试图看到它是良好的账户或购买交易。所以我们知道没有通过的交易属于任何一种情况。因此，对于大量的处理，我们知道我们得到了期望的结果，但我们如何返回并协调没有通过的数据。

这对于这种受监管的行业来说是非常重要的，我们需要回顾并在粒度层面上查看每一笔交易。是的，丰富数据方法为我们提供了那种灵活性和细粒度细节。

你不需要在计算的每个阶段都做昂贵的计数操作。

取而代之的是我们捕捉到的细节作为标志或者在处理时得到丰富的附加列。这是我们在后期分析调试时可以使用的。所以在任何阶段都不需要计数。

与过滤相比，这仍然是一个巨大的胜利。即使我们使用计数，它可能不能提供我们需要的所有细节，这是一个昂贵的操作，如果你在一个巨大的数据集上做丰富的方法，这显然是可以避免的。

因此，我们在生产中使用了基于过滤的版本1几个月，在部署后，我们发现对我们来说，回溯事务变得很麻烦，也很难进入事务的细节，因为主要是所有的计算，不管我们一直在做什么。我们一直在应用的一堆业务规则。它为我们提供了结果，但是如何返回并查看在内存中被过滤掉的事务以及为什么它被过滤掉。这是我们在部署后遇到的问题，在部署之后，我们立即，在几个月内，开始使用过滤方法迭代我们的第二个版本，我们已经部署了

丰富基于版本2的数据方法。它开发了几个月，我们将其作为第二个版本部署到生产环境中。(按键盘键)

因此，我们在生产中切换到基于丰富的版本2，这种基于特定模式的spark应用程序目前在我们的环境生产中成功运行了几年，这是我们用来为我们的Capitalone客户提供数百万英里、现金和积分作为奖励的方法。(按键盘键)

如果你用我们的信用卡刷卡，就像我之前在讨论中提到的，我们的应用程序会计算你刷信用卡应该赚到的钱如果你用我们的信用卡购物，

这就是使用丰富数据方法在生产中处理事务的方式。

Gokul:谢谢大家给我这个机会。