财务结算批量数据处理 流式

编者注 ：在纽约的Strata + Hadoop World 2016上，MapR企业战略与架构总监Jim Scott发表了题为“处理极端情况：财务扩展和流媒体”的演讲。

正如Jim所解释的那样，敏捷性在金融世界中占主导地位，而消息驱动的体系结构是一种用于构建和管理离散业务功能以实现敏捷性的机制。 为了适应快速的创新，数据管道必须不断发展。 但是，实现微服务会产生管理问题，例如在环境中运行的实例数。

可以在消息驱动的体系结构上利用微服务，但是必须深思熟虑地实现这一概念，以显示其真正的价值。 在这篇博客中，Jim概述了消息驱动体系结构的核心原则，并解释了其在金融领域中实时启用大数据的分布式系统中的重要性。 在此过程中，Jim讨论了涉及证券管理和欺诈的财务用例-从从潜在的数百个数据源中提取数据到在不牺牲性能的情况下将数据散布到所需的范本-并讨论了运营能力的优缺点使用相同的数据管道来支持开发和质量保证实践。

您可以在此处观看Jim Scott的演讲，或阅读下面的博客文章以了解更多信息：

旧版业务平台

为了搭建舞台，让我们从一个故事开始。 有一天，老板问我：“我们需要为此新用例构建一些新软件，以满足客户的需求，”并问我该怎么办。 在这种情况下，我要研究操作方面，因为我必须构建一个基于事务的系统，这意味着：我需要存储，并且需要一个关系数据库–因为这是每个人都一直使用的工具。最近20年解决了每个存在的业务问题。 另外，我们基于Java，因此我们将使用J2EE应用服务器，此外，我将要实现消息驱动的体系结构。

我们已经完成了这一标准设置； 它运作良好，可扩展，并能满足我们的所有需求。 但是，几个月后，我的老板提出了一个新要求：“我们如何才能将产品交叉销售给客户？ 我们的十大用户是谁？” 现在我们需要一个分析平台。 那么我们该怎么办？ 我们建立了另一组专用存储，并获得了另一个数据库。 而且由于它将成为我们的数据仓库，我们必须放置一个ETL工具，因为我们必须从我们的运营数据库中获取数据，然后，当然，我们需要那里有一些BI工具。

完成这些工作后，老板对结果感到满意，并称赞我的工作。 然后他说：“但是”，但最重要的是：“我们需要有完整的历史深度，因为我们要把新功能放回到该用户界面中。 我们想即时定制体验。 我们希望能够提出更好的实时建议。”

您可以生产该数据仓库以达到与操作端相同的服务水平吗？ 从技术上讲，如果您投入足够的钱，则可以。 但是您仍然必须保持双手交叉，希望它在峰值负载下不会掉落在其表面上。 这里的问题是IT团队必须完成许多额外的集成工作。 在企业数据仓库领域进行大规模扩展会产生巨大的成本。 它非常昂贵。

融合数据平台

我们习惯于使用两套完全独立的专用存储和具有完全不同数据模型的平台-一套用于分析应用程序，另一套用于运营应用程序。 对于运营与数据仓库，数据模型看起来有所不同，这是因为需要及时将数据提供给用户的速度和可用性。 出于同样的原因，数据的非规范化也是另一个概念：我们必须权衡使用关系数据库来解决我们遇到的每个问题。 尽管我们已经这样做了很长时间，但是我们可以对基础架构进行更改，以使其成为一个更敏捷，更敏捷的组织。 构建下一代平台的基础是将这些单独的领域融合在一起。

当您处理两个不同的数据模型时，您经常会听到：“我想为工作选择合适的工具。” RDBMS是答案，因为IT团队支持它使软件投入生产，并且他们已经想出了备份策略。 在分析方面进行工作时，您正在数据仓库上创建BI报告或KPI，或进行数据科学建模，因此需要历史记录。 当您在开发人员方面工作时，您将在创建数据库以支持持久性并需要基于事件的应用程序。 您需要使用API​​，需要将数据持久存储到数据库中，并且希望有一个消息驱动的体系结构，所有这些都支持公司的运营方面。

融合数据平台在改变这种二分法中起着关键作用。 该模型的优点在于，当您在聚合数据平台上运行时，您将所有东西都放在一个地方。 您不必将数据从一种模式转移到另一种。 您不必进行转换就可以查询数据。 双方都可以同时处理此信息。 使用融合的应用程序，您可以在一个平台上完全访问实时和历史数据。

我们有以这种模式运作的客户，尤其是在金融行业，他们通常会问我们这个重要的问题：“我需要连续两次问相同的问题并获得相同的答案，如果我愿意，在我的运营平台上进行分析时，我该怎么做？” 实际上，这就是MapR出现的地方，因为对于这种类型的平台，您可以对所有数据（无论是事件流，数据库还是文件中的文件）进行一致的时间点快照。系统。

因此，您可以根据一致的时间点视图构建模型。 当您完成所有分析之后，您可以指向实时数据，然后就可以完成。 无需额外的工作，它是一个写时复制的文件系统，因此您不必弄清楚如何对其进行操作或如何使团队支持它。

应用开发与部署

为什么这很重要？ 好吧，第一，因为每种语言都有JSON序列化器和反序列化器，所以您可以减少用单行代码保存数据所花费的文档数据库的总时间。 一行代码使您可以将数据结构持久化到数据库中，或者通过一行代码可以将其从数据库中拉出并放入数据结构中。

十年前，要构建软件堆栈，它们并不需要是超创意的。 这是一个简单的设计。 他们没有能力在这些不同的技术上花费大量金钱。 我们现在在生态系统中看到的具有所有选择的开源运动尚未兴旺。 但是今天这是它的样子：

对于不同的用例，您具有不同的数据存储。 一旦拥有多个数据库，几乎每个公司都有多个数据库，就开始创建数据孤岛。 隔离数据后，您必须弄清楚如何集成以及如何将所有内容整合在一起以提供功能。 但是，使用MapR，您实际上可以在同一平台上完成所有这些操作。

这并不一定意味着您在一个群集中完成所有操作，但是您拥有针对所有这些功能的所有企业功能。 您可以同时对其中任何一个或全部执行分析。

MapR平台服务：开放API架构

MapR平台服务提供了开放的API架构，可确保互操作性并避免供应商锁定。 这很重要，因为这意味着您可以在适合自己的情况下选择适合自己的产品。

• MapR-FS支持HDFS API，该API支持分布式计算。 您可以使用任何支持HDFS API的开源引擎或工具，例如Spark或Apache Flink，它可以在任何地方使用。
• MapR-FS是POSIX文件系统，可让您直接读写MapR集群。 您的公司中可能有一个Apache Web服务器，并且在该服务器上写入了日志； 然后，您可以使用某种方式来传输日志，以便稍后对其进行分析。 将日志直接写到执行分析的平台上会不会很神奇？
• MapR-DB允许您具有不同类型的查询功能和键值数据存储。 您可以快速，简单地存储JSON文档并在数据库中的文档上进行更改。
• MapR Streams允许您处理事件流。 借助Kafka API，您可以在本地或云中运行。 您可以处理任何地方发生的事件。 您可以将它们复制到其他任何地方。
• 借助这种开放API架构，您还可以利用云作为基础架构即服务。 如果您具有事件驱动的体系结构，并且正在实时响应，并随着时间改变用户的会话，则可以将其构建在一个位置，并在任何时候对整个事情进行分析，而不必弄清楚如何在两个不同的位置之间移动数据，以及是否有足够的存储空间来移动数据。 当您不受限于将您锁定在云提供商中的API的约束时，您就可以自由选择任何基础架构平台。 如果有一家新公司成立，例如为您提供裸机访问权限，则可以更换提供商。 您将复制作为平台的一部分进行处理。 您不必编写所有这些功能（快照，镜像，表复制，事件发生时），就可以为业务提供解决方案，从而使您可以专注于公司的核心竞争力。

我喜欢和其他人一样去修改和编写代码，但是最终，开源生态系统的好处是您可以更快地解决问题。 将所需的工具放在手中，并在一个统一的数据平台上启用它们，使您能够选择应用程序，从而确定最适合您的应用程序。

讯息平台

什么是流？ 流是从一组生产者携带到一组消费者的无限制事件序列。 生产者产生事件； 消费者消费事件。

简而言之：如果我是一家报纸出版商，我将有一堆我制作的报纸。 准备消费时，您会来拿起报纸。 这就是消息队列的概念。 生产者和消费者之间不必相互了解。 相反，他们参加共享主题。 此发布/订阅模型是您真正提高速度的地方。 当您开始研究不同类型的事件主题以及如何处理它们时，您需要弄清楚如何处理流媒体的极端情况。

极端是什么意思？ 我估计极端事件每天大约有上万亿事件。 我看到每秒可能有数百万个生产者或数十亿个事件通过具有多个消费者的系统流动。

这一点非常重要，因为在创建消息驱动的体系结构时，要推出新版本的代码，要构建新的服务，并希望能够连接到正式的生产流并进行测试。 对于开发人员来说，这将是乌托邦式的情况，即能够访问实际生产数据以查看代码是否确实有效，同时仍能隔离事件。 如果使用的是远程过程调用，则相互通信的组件之间必须紧密绑定。 但是，当您使用消息驱动时，突然之间就将其解耦了。 您现在可以按照自己想要的速度进行测试和移动。 您具有随着时间推移发生的事件的完整历史记录，以便能够进行操作。

另外，我认为多个数据中心是极端的。 随着云的出现，如果您拥有面向Web的客户服务并且您正在单个云上运行，那么我认为您有机会进行多云和负载平衡（50/50或其中的一些变化）在多个数据中心之间。 然后，您将拥有数据的全局可用性。 您可以在这些数据中心之间进行复制，而不必担心单个云提供商存在问题。 最终，您最终将能够以不同的方式满足不同的服务级别，因为您可以选择使用哪种硬件和基础结构服务来满足您的需求。 然后，您的选择是无限的：您可以在云中进行流事件，拥有本地数据中心，将汇总信息带回到数据中心，进行欺诈检测分析并围绕用户个人资料建立模型等。

由于诸如MapR Streams和Kafka之类的工具可让您分解服务和应用程序，因此推动人们能够更轻松地支持微服务的概念，从而使您能够将较小的组件部署到您的环境中。 因此，对于您部署的每种微服务，您都将希望监视每个组件的各个方面，并发出自己的指标来衡量其性能。 有多少人通过您的服务？ 正在使用哪些功能？

当您开始累加产生的所有不同指标，产生的采样率，捕获信息并将其推入事件流的能力时，通过这种简单的设置，您每天将看到近20亿个事件。 每天有数十亿个事件是现实的，当您考虑到“我想根据流中的原始生产数据来生产更多的软件”时，您的开发人员现在可以从该生产流中进行消费以测试新的他们发布的代码。 每次添加时，您将在此环境中运行的实例数量增加很多倍。

使用此模型有多困难？ 编写几行代码来生成事件，这很简单，很容易，该事件通过流，然后只需几行代码，消费者就可以从流中读取数据。

现在，当您考虑使用Web服务时，便可以使用后端或前端，并且您可能会受到呼叫的影响，并且可以代理大量其他服务。 这些服务中的每一个都可以是消息驱动的，完全解耦的和异步的。 您可以将消息写到正在侦听的微服务中，然后将其放在同一流的返回主题上。 设置，自动化和管理非常容易：您可以使用相同的主题名称，并在主题名称中添加“ return”，所以现在这是发件人，这就是返回。

生产者和消费者

在下面的图形中，您可以看到有关生产者和消费者类别的一些概括示例。

在生产者端，您的应用程序堆栈中有任何可用于产生事件的东西。 另一方面，您可以让使用者显示信息或利用管道中事件流中的数据。

考虑消息传递平台

就在七年前，当我使用Apache qpid时，我们在该标准消息队列上每秒获得50,000-100,000条消息吞吐量，我们认为这是惊人的。

但是，它的问题是，您无法轻松地在旧式消息队列上构建完整的消息驱动的体系结构。 它不具有发布/订阅模型所具有的功能。 因此，缩放比例是您在发布/订阅模型中获得的最大收益。 例如，让我们考虑一个微服务模型：如果您有10个服务，并且正在使用标准的问题消息队列，并且在服务器上每秒看到50-100k条消息，则可以看到您您将不得不非常Swift地扩展您的消息传递平台，以便跟上您在其中提供的每一项服务。 使用pub / sub模型，您可以开始查看它到底有多快-Kafka模型正在快速发展。 这些是我们在MapR Streams上拥有的基准测试：

• Kafka 0.9 API，消息大小为200字节
• 5节点群集上的MapR流可持续1800万个事件/秒
• 吞吐量为3.5GB / s和每天超过1.5万亿个事件

我们已经独立验证了这些基准。 当然，您将无法达到这些速率，因为要达到这些速率，您需要每秒3.5 GB的吞吐量。 三个绑定的10Gb以太网链路已完全饱和。 大多数人不会以这种方式建立网络。 当您扩展网络功能时，如果您拥有100吉比特，您可以达到这个目标吗？ 绝对。 我保证您会很容易找到这些类型的数字。 作为扩展点，MapR Streams平台不会成为您的瓶颈。 那是好处。 您不必担心每秒50-100k条消息使您失望。 您将不必再担心开发人员想要连接到您的生产消息传递并降低所有功能，因为您将无法处理每秒处理300,000条消息并让某人测试其构建的模型。

旧消息队列需要手动分片，以定义路由的去向，这是一个痛苦的过程。 如果您进行手动分片，并且必须提出一种算法来执行此操作，则在某个时候更改分片时会遇到问题，并且突然之间会出现流经消息的热点。 这是一场噩梦。

财务中的用例

当您开始寻找基于事件的，数据驱动的应用程序的不同机会时，您可以涵盖很多领域，例如实时启用欺诈防护以及通过网络或金融客户进行广告宣传。

欺诈邮件

互联网是一个快乐的云，没有发生任何不良情况，这就是为什么我们不需要银行内部的欺诈和风险部门。 哦，对不起，我已经完全倒退了。 实际上，我们的舞弊活动全都在发生。 我们有一团愤怒的乌云，想下雨，向所有人投掷雷电，然后把我们全部摘走，当然，这并不能使消费者满意。 我们必须处理这一现实。

欺诈性电子邮件有多种类型，包括恶意软件，垃圾邮件和网络钓鱼尝试。 让我们考虑一个例子：您可能在一家财务公司工作，该公司想跟踪所有收到的电子邮件，并根据他们的银行对网络钓鱼尝试进行分类。 我们可以采取的一些预防措施是训练人们并告诉他们：“永远不要单击电子邮件中出现的随机链接。” 但是我们都知道那是行不通的。 像梭子鱼这样的电子邮件设备会阻止用户看到电子邮件的正常运行，但是它们通常需要用户干预，不容易自定义，而且价格昂贵。

因此，让我们看一下构建电子邮件管理管道的特定用例，尽管它确实非常适合财务，但它可以适用于任何公司，不仅适用于财务公司。

首先，我可以部署一个Postfix邮件服务器，开源，并将所有电子邮件都放入其中。 从那时起，我可以创建我的邮件传输代理，并从入站邮件服务器中提取所有电子邮件。 我的用户从未看到此边缘邮件服务器。 从那里，我收到每封电子邮件，并将其放在流中。 现在，因为它在流中，所以我具有完全的可伸缩性和完全的灵活性，可以实现所需的任何东西。

每个银行和每个金融机构的每个法律团队都在做什么？ 这些行业出于监管目的会在一段时间内保留所有电子邮件。 因此，尽管用户从未见过，但我拥有所有电子邮件的合法存档。 它可以存储在JSON文档数据库中，这使其结构合理，易于持久和搜索，现在，当我们进行法律查询时，我们可以访问它，并且可以通过更改文档来对这些查询进行诉讼保留。

另一方面，我也从相同的电子邮件流中进行处理，假设我要进行自己的分类。 在电子邮件使用者没有看到电子邮件之前，我已将所有要做的事情都放在适当的位置：网络钓鱼分类，内部人员泄漏信息的内部事务以及垃圾邮件过滤器。 从那里，我有另一个邮件传输代理，然后将其放回另一个Postfix（或其他）邮件服务器。

如果您可以想象此管道可以满足您的用例那么复杂或那么简单，那么它的功能就非常强大。 您可以将自己的网络钓鱼分类汇总在一起。 并且，您可以通知您的合作伙伴或客户，并让他们知道您可以对进入公司的所有欺诈性电子邮件进行分类，跟踪和列出风险。

现在，让我们考虑用户发送电子邮件的第二种用例。 想象一下，您自己的内部邮件服务器用于出站邮件，您可以通过相同类型的管道运行该服务器。 也许您想确保公司中没有人泄漏专有的机密信息。 也许您正在尝试评估组织中各个方面的风险，以应对公司即将发生的事情。 这种内部事务类型的模型将使其易于实施，并且用户无需了解它。 它易于扩展，并且全部由消息驱动，可以解决您在电子邮件中遇到的任何问题。

回顾一下，这些是此方法的最大优点：

• 可定制的管道
• 可以学习和应用新政策
  • 垃圾邮件
• 保留政策
  • 可审核的

欺诈性网络流量

并非所有的网络流量都是不好的，但大部分都是–人们在做不应该在互联网上做的事情。 我该怎么做才能标记欺诈性的网络流量？

首先，我想获取点击流，而不管它是什么，然后将其通过活动流。 我希望能够扩展它，并且希望能够对其执行不同类型的分析，我将其称为分类器。 这些分析将使我能够创建一个模型，该模型将我过去针对的某些已知活动类型分类为欺诈活动。 我想创建一个黑名单，但我也想创建一个白名单，这将使我能够识别每个普通用户都可以执行的活动，而机器人却不可以。 另外，我要分类：我与正常水平的偏离是什么？ 想象一下在此模型中构建用户配置文件，并且随着用户点击流的通过，您可以将该活动与他们的正常活动进行比较。 此外，您可以为人员类型或帐户类型创建自己的细分受众群。 然后，您可以通过将他们与自己以及人群进行比较，来确定此类帐户的人的正常活动。

这种分类的结果是，我们现在想要通过对点击流进行分析和分类，来更改用户的会话（无论是为好人提出建议还是削弱坏人的功能）。 在此会话更改流中，我还希望具有通知安全的功能，因此我可以打开查询或进行深入分析以跟踪这些威胁的来源。

该图可能会更复杂，具体取决于您如何部署模型。 但是，在事件驱动模型中，核心功能是扩展这些组件变得非常容易，并且当您选择新的分类模型和新的推荐引擎时，将它们插入点击流和链接也变得非常容易。它们一起放在分类引擎中。 您将自己的规则放在一起，因此具有很大的灵活性。

营销与欺诈之间的相似之处

我最近注意到行销与诈骗之间有一些重要的相似之处。 客户360和市场营销欺诈非常相似。 首先，在这两种情况下，您都需要构建用户个人资料。 使用配置文件的主要区别在于：也许您想向他们提出建议，也许您正在查看正常的使用模式，但是最终还是使用了此历史记录并加以使用。 其次，在两种情况下，您都构建了分段概要文件。 您想要在市场营销中创建细分的人群，因此您知道如何定位受众。 您在欺诈方面也做同样的事情，因为您想弄清楚这种类型的帐户的正常情况。 第三，双方都动态地更改您的网站。 这是当今Internet上最常见的事情，它使用cookie跟踪和点击流分析（有时还包括网络钓鱼尝试），使人们在您的网站上停留的时间更长，并通过为他们提供保持其位置的内容来降低跳出率。 最后一个相似之处是它们都启动了外部工作流程。 在营销方面，这些可能是培育电子邮件； 另一方面，它将启动安全工作流程。 这两件事是Customer 360和欺诈检测的核心基础。

如果您试图弄清楚如何向人们解释这些功能的作用，那么这些相似性非常重要。 简单地说：“如果我们完成了其中一项，就可以做到另一项，”尤其是从财务角度而言，因为它是相同的用户配置文件。 双方之间有很多重叠之处，这在营销和欺诈团队有机会进行互动时变得很明显。 在一个始于网站欺诈的案例中，营销团队的一位客户说：“我们一直在努力获取这些信息。 我们实际上将其存储在系统中了吗？” 欺诈团队向市场营销团队开放了该数据，然后他们有了它。

总之，在考虑实施下一代工具和技术时，请记住，并非所有数据平台都是相同的。 如果您想了解有关MapR融合应用程序蓝图的更多信息，请访问此链接 。

翻译自: https://www.javacodegeeks.com/2017/03/handling-extremes-scaling-streaming-finance.html

财务结算批量数据处理 流式