为获得金融服务的实时洞察，需要采用设计模式

1 年 ago
科, 颖
2 minutes

金融服务中的实时洞察力- Databricks博客的翻译。

這本書是一份縮寫翻譯，並不保證內容準確性。請參考原文以獲得準確的內容。

用于个性化的流媒体基础架构

在银行到保险公司等几乎所有金融服务机构（缩写为FSI）中，个性化已成为竞争力的差异化因素，如今已成为投资管理的平台。所有FSI都希望向客户提供智能且实时的个性化服务，但在许多情况下，基础只是表面的或者是不完善的平台，导致过时的见解、市场供应滞后和生产力损失，尽管需要将流媒体、人工智能和报告服务结合起来。

本文介绍了如何在金融服务领域的使用案例中，通过Databricks Lakehouse平台构建稳固的基础，以实现从OLTP数据库到变更数据捕获（CDC）到仪表板报告的实时洞察。Databricks长期以来一直支持平台本地的流式处理。最近发布的Delta Live Tables（DLT）进一步简化了流式处理，并通过新的CDC功能提供了更强大的性能。最近发布的综合博客文章涵盖了使用DLT进行CDC的指南。本文专注于金融服务业的流式处理，并解释了这些功能如何成为新产品的差异化因素，并支持金融服务业内部的洞察。

为什么流媒体捕捉如此重要

在深入探討技術细节之前，让我们讨论一下为什么Databricks是个性化用例的最佳选择，尤其是为什么应该首先实施流式处理。许多使用Databricks实施客户360项目和全漏斗营销策略的客户通常具有以下基本要求。请注意临时的时间相关数据流。

FSI的数据流和需求

    1. 面向用户的应用程序将保存和更新诸如点击流、用户更新和位置信息数据等数据 – 这需要操作数据库。

通过云账户上的对象存储或数据库向第三方的行为数据增量交付 – 需要具有流式功能来递增、更新和删除新数据，作为可靠的唯一信息源供分析之用。

FSI具有将用户更新、点击流和用户行为数据等所有数据库数据导出到数据湖中的自动化过程 – 需要执行捕获变更数据（CDC）的工具和处理工具，以及半结构化和非结构化数据的支持。

数据工程团队将执行自动化数据质量检查，以确保数据始终保持最新 – 需要数据质量工具和本地流功能。

数据科学团队将利用数据进行下一步最佳操作和其他预测分析 – 需要本地机器学习（ML）功能。

分析工程师和数据分析师将使用数据模型来材料化和利用数据进行报告 – 需要仪表板集成和本地可视化功能。

假设我们考虑到零售银行借助数字营销以吸引更多客户并改善品牌忠诚度的目标。我们可以通过识别客户购买模式中的关键趋势，并利用实时的定制产品优惠为客户提供个性化沟通。虽然这个概念很简单，但为了捕捉到客户行为和风险配置文件中的变化，同时需要使用流式数据和变更数据捕获（CDC）方面的技术。这是一个非常重要的应用场景。

尝试开始流媒体播放

在本部分中，我们将使用Databricks的流处理功能，介绍如何捕捉来自事务数据库的持续变化，并将其存储在Lakehouse中，从而能够清楚地说明一个简单的端到端数据流程。

流程 #1 – 数据导入

通过本地化的结构化流媒体选项进行导入

随着客户通过银行和保险应用程序提供的数据增加，FSI面临着在各种用例中利用数据的下游团队需要制定数据收集战略的压力。这些公司面临的最基本的决策之一是如何捕获客户在生产环境的应用服务、用户生成的策略、贷款应用和信用卡交易中产生的所有变更。基本上，这些应用程序依赖于交易数据源，并使用其他非结构化数据库，如MySQL数据库和MongoDB。

幸运的是，我们有很多开源工具，如Debezium，可以从这些系统的外部导入数据。或者，我们还看到许多客户自己开发了具有状态的客户端，用于从事务数据存储中读取数据，并将其写入托管的Kafka集群等分布式消息队列。Databricks与Kafka紧密集成，直接连接流处理作业被推荐用于需要数据尽可能新鲜的场景。通过这种设置，我们可以实现对业务的准实时洞察，例如实时交叉销售推荐和实时损失视图（对资产负债表中现金奖励的影响）。这种模式如下所示：

    1. 搭建用于编写Kafka变更记录的CDC工具

 

    1. 设置Kafka Sink以用于Debezium或其他CDC工具

 

    直接将数据从Kafka发送到青铜表，并使用Delta Live Tables在Databricks上解析和处理变更数据捕获(CDC)记录

考察 – chá – Investigation

优点

    • 低レーテンシーでデータが継続的に到着するので、利用者はバッチのアップデートに依存することなしにニアリアルタイムで結果を取得できる。

 

    • ストリーミングロジックに対する完全なコントロール。

 

    • ブロンズレイヤーに対してDelta Live Tablesはクラスター管理を抽象化しながらも、ユーザーにオートスケーリングを提供することでリソース管理を効率的に行える。

 

    Delta Live Tablesは、完全なデータリネージュとブロンズレイヤーに到着するデータに対するシームレスなデータ品質モニタリングを提供。

缺點

    • Kafkaからの直接読み込みは、ブロンズのステージングレイヤーにデータが到着した際に必要となるパーシングのコードが必要になる。

 

    直接の接続を確立するツールを用いるのではなく、データベースからデータを抽出し、メッセージストアにデータを投入するために、外部サードパーティのCDCツールに依存している。

合作伙伴的数据导入选项

通过使用COPY INTO选项，两个选项可以将许多与在Delta Lake中加载原始数据和数据到达相关的核心逻辑抽象化。在这个模式中，将执行以下步骤。

    1. 设置写入变更记录到Kafka的CDC工具（与上述相同）

设置Confluent Cloud的Databricks Delta Lake Sink连接器，并连接到适当的主题。

这个选项与本地流选项的主要区别在于是否使用Confluent的Delta Lake Sink Connector。让我们看一下权衡来理解选择哪种模式。

考察 chá)

优点

    • オンプレミスのレガシーソース、データベース、メインフレームからの高速なデータ複製をサポートするパートナーツール(Fivetran、Arcionなどデータベースと直接接続できる他のツール)を通じたローコードのCDC。

 

    • ストリーミングパートナーに馴染みのあるデータプラットフォームチーム向けのローコードのデータ取り込み、Apache Spark™を使わずにDelta Lakeにデータを取り込める環境。

 

    Confluent Cloud(Fivetranも同様)でのトピックとシンクのコネクターの集中管理。

缺点

    • 初期ETLステージにおけるSparkやサードパーティライブラリによるデータ変換およびペイロードのパーシングに対する低いコントロール。

 

    コネクター向けのDatabrikcsクラスターの設定が必要。

文件导入

移动车联网提供商、信用数据提供商、内部数据生成商等多个数据供应商将通过提供文件向客户提供服务。为了最适当地处理增量文件导入，Databricks引入了简单且自动化的流式处理工具Auto Loader，用于跟踪旅行数据的白天数据流、交易与报价(TAQ)数据以及用于收入预测的销售收据等增量数据状态。

Auto Loader可以在Delta Live Tables的管道中使用，并且可以轻松处理数百个数据源，而无需设置低级别的细节。Auto Loader可以进行大规模扩展，并且可以轻松处理每天数百万个文件。此外，在Delta Live Tables API的上下文中，可以简单地使用它（请参阅下面的SQL示例）。

CREATE INCREMENTAL LIVE TABLE customers
AS SELECT * FROM cloud_files("/databricks-datasets/retail-org/customers/", "csv", map("delimiter", "\t"))

步骤二 – 变更数据捕获

需要一种能够将核心系统中的更改保存到集中管理的数据存储中，而无需给事务数据库增加额外负荷的变更数据捕获解决方案。由于数字数据的大量流动，捕捉客户行为的变化以个性化银行和理赔体验成为一个非常庞大的任务。

从技术角度来看，我们使用Debezium作为我们的CDC工具来突出显示。值得注意的是，Delta Live Tables (DLT) 使用Debezium的datetime_updated作为排序键，通过记录实时最新的更改并将其应用于目标表。重复一遍，由于用户旅程涉及到重要的时间要素，更新用户状态所需的复杂性被DLT的APPLY CHANGES INTO功能抽象化为一种优雅的解决方案。DLT通过一行SQL或Python命令简单地实时更新状态（即，将参与的事件数量从3更新为5，并增强提供个性化优惠的机会）。

在这里需要注意的事项有几个。

CREATE STREAMING LIVE TABLE customer_patterns_silver_copy
(
 CONSTRAINT customer_id EXPECT (customer_id IS NOT NULL) ON VIOLATION DROP ROW
)
TBLPROPERTIES ("quality" = "silver")
COMMENT "Cleansed Bronze customer view (i.e. what will become Silver)"
AS SELECT json.payload.after.* , json.payload.op
FROM stream(live.customer_patterns_bronze);


APPLY CHANGES INTO live.customer_patterns_silver
FROM stream(live.customer_patterns_silver_copy)
 KEYS (customer_id)
 APPLY AS DELETE WHEN op = "d"
 SEQUENCE BY datetime_updated;

第三步骤 – 客户偏好和简洁优惠的概述

总结

在这篇文章中，我们强调了数据导入过程的多个方面，这对于支持金融服务的各种个性化用例非常关键。更重要的是，Databricks支持本地和准实时的用例，可以立即使用抽象化API（Delta Live Tables）来处理新鲜的洞察和变更数据，无论是使用Python还是SQL。

随着银行和保险提供商提供更加个性化的体验，支持模型的开发变得重要，但更加重要的是构建一个稳固的基础设施来进行增量数据导入。最终，Databricks的数据湖仓平台将提供无与伦比的流媒体和AI驱动的个性化，从而带来更高的CSAT/NPS，降低CAC/解约，并使客户能够快乐获益。

如果你想要了解在这篇文章中使用的Delta Live Tables的方法的详细信息，只需要检查GitHub存储库中的所有示例数据和代码即可。

Databricks 免费试用

Databricks 的免费试用

✖
广告
将在 10 秒后关闭
bannerAds