CFM如何利用Amazon EMR构建一个良好治理和可扩展的数据工程平台

合作作者：Julien Lafaye Joel Farvault Matthieu Bonville2024年9月13日，发表于 Amazon EMR、AWS Lake Formation、Customer Solutions、Financial Services

关键要点

CFM简介：CFM是一家总部位于巴黎的另类投资管理公司，拥有纽约和伦敦的员工，采用科学的方法进行金融投资。投资策略：CFM依赖于系统化投资策略，使用定量技术并寻求非常规数据源以提高投资决策的有效性。数据平台构建：CBM的数据工程平台利用AWS服务，包括Amazon EMR和Lake Formation，促进良好的数据治理和可扩展性。

Capital Fund ManagementCFM是一家总部门位于巴黎的另类投资管理公司，同时在纽约和伦敦设有员工。CFM采用科学的金融方法，利用定量和系统化的技术来开发最佳投资策略。多年来，CFM的旗舰产品Stratus因其20年的卓越业绩而屡获殊荣，这是一种多策略投资程序，通过分散投资策略实现去相关收益，追求的风险特征则稳健于传统市场指数。CFM目前管理资产达150亿美元。

传统的系统化投资方法通常依赖于对历史资产价格趋势的分析，以预见未来价格波动并做出投资决策。然而，投资行业的发展使得单靠历史价格已不足以保持竞争力：传统的系统化策略逐渐公开化且效率低下，参与者增多使得市场份额变小这种现象称为衰减。近年来，随着数据存储和处理解决方案的商品化，越来越多的系统化投资管理公司开始转向非常规数据源，以辅助投资决策。公开的例子包括使用卫星图像分析商场停车场以估计消费者行为趋势及其对股票价格的影响，使用社交网络数据也常被引用为改善短期投资决策的潜在数据源。为了保持在量化投资的前沿，CFM建立了大规模的数据获取策略。

作为CFM数据团队的一员，我们不断监测新的数据源与供应商，以持续创新。试验数据集的速度，以及确定其对我们业务的有用性，是成功的关键因素。试验是通常耗时数月的短期项目；当我们发现数据集中有助于投资过程的信息时，试验的结果即为购买或不购买的决策。遗憾的是，由于数据集形态各异，提前数月规划硬件和软件的需求非常具有挑战性。一些数据集需要特定的计算能力，如果试验失败，我们无力承担这些费用。AWS的按需付费模式以及数据处理技术的持续创新，使CFM能够保持灵活，促进持续的试验和探索。

在本篇文章中，我们将分享如何使用 Amazon EMR 构建一个良好治理和可扩展的数据工程平台，以生成金融特征。

AWS作为CFM业务战略的关键推动者

我们确定以下因素是数据战略的关键推动者：

因素描述托管服务AWS托管服务降低了复杂数据技术如Apache Spark的部署成本。弹性计算和存储的弹性免去了我们需要提前规划和采购硬件的负担。治理我们的数据团队被分为各自独立的小组，根据需求和技能使用不同的技术。

在CFM中，为了分享数据给内部用户，我们利用 AWS Lake Formation 通过LFTags简化管理访问权的过程。

数据集成工作流

典型的数据集成过程包括数据摄取、分析和生产阶段。

CFM通常与供应商协商数据下载方式，以便于双方。我们发现有多种数据交换可能性如HTTPS、FTP、SFTP，但越来越多的供应商开始标准化使用 Amazon Simple Storage Service (Amazon S3)。

CFM的数据科学家通过Jupyter Notebook查找数据并构建可用于交易模型的特征。我们大部分数据科学家都是Jupyter Notebook的重度用户，这是一种交互式计算环境，能够让用户创建和分享包含实时代码、公式、可视化和叙述文本的文档。它们提供了一个网络界面，用户可以以不同编程语言如Python、R或Julia编写和运行代码。Notebook被组织成单元，可以单独运行，便于迭代开发和数据分析及计算工作流的探索。

我们投入大量精力优化我们的Jupyter生态系统例如，开源项目 Jupytext 是由一位前CFM员工发起的，并对与我们当前生态系统的集成程度感到自豪。尽管我们探索了使用AWS托管Notebook来简化部署过程的选项，但决定在现阶段继续在我们的本地基础设施上托管这些组件。CFM内部用户很欣赏现有的开发环境，切换到AWS托管环境将会改变他们的习惯，并导致暂时的生产力下降。

对于小数据集的探索，在Jupyter环境中完全可行，但对于大数据集，我们将Spark视为首选解决方案。我们本可以在数据中心部署Spark集群，但发现使用Amazon EMR显著减少了部署集群所需的时间，并提供了许多有趣的功能，例如通过 AWS Graviton 处理器的ARM支持、自动扩展能力和临时集群的能力。

在数据科学家编写特征后，CFM会部署一个脚本到生产环境，随着新数据的进入刷新特征。这些脚本通常在相对较短的时间内运行，因为它们只需处理少量新数据。

交互式数据探索工作流

CFM的数据科学家倾向于通过Jupyter Notebook与EMR集群交互。由于我们在本地管理和定制Jupyter Notebook已有悠久历史，因此选择将EMR集群集成到现有生态系统中。用户的工作流程如下：

用户通过 AWS Service Catalog 和 AWS Management Console 提供EMR集群。用户也可以使用API调用来实现，但通常更喜欢使用Service Catalog界面。用户可以选择不同实例类型，包括不同组合的CPU、内存和存储，为应用程序选择合适的资源。用户启动他们的Jupyter Notebook实例并连接到EMR集群。用户通过Notebook互动地处理数据。用户通过Service Catalog关闭集群。

解决方案概述

Notebook与集群之间的连接是通过以下开源组件实现的：

Apache Livy 提供REST接口的Spark驱动程序在EMR集群上运行。Sparkmagic 一组Jupyter magic命令，提供一种简单方式连接到集群并通过Livy端点发送PySpark代码。Sagemakerstudioanalyticsextension 提供一组magic命令将分析服务如Amazon EMR集成到Jupyter notebooks。由于我们需要使用自己的notebooks，因此最初并未从此集成中受益。为了帮助我们，Amazon EMR服务团队在PyPI上提供了这个库，并指导我们完成设置。我们利用这个库来促进Notebook和集群之间的连接，并通过运行时角色将用户权限转发到集群。这些运行时角色用于访问数据，而不是分配给集群中Amazon Elastic Compute CloudAmazon EC2实例的实例角色。这使我们能够对数据进行更细粒度的访问控制。

下图展示了解决方案架构。

使用GetClusterSessionCredentials API在EC2集群上设置Amazon EMR

运行时角色是AWS身份和访问管理IAM角色，在向EMR集群提交作业或查询时可以指定。EMR的 getclustersessioncredentials API使用运行时角色基于附加到运行时角色的IAM策略在EMR节点上进行身份验证我们记录了启用Spark终端的步骤；类似的方法可以拓展到Hive和Presto。此选项在所有AWS区域普遍可用，推荐使用的版本为emr690或更高版本。

从Jupyter Notebook通过GCSC API连接Amazon EMR EC2集群

Jupyter Notebook magic命令提供了快捷方式和额外功能，以加快Notebook的工作效率。我们利用Jupyter magic来抽象从Jupyter到EMR集群的底层连接；分析扩展通过Livy使用GCSC API建立连接。

在您的Jupyter实例、服务器或Notebook PySpark内核上，安装以下扩展，加载magic并使用运行时角色创建与EMR集群的连接：

bashpip install sagemakerstudioanalyticsextensionloadext sagemakerstudioanalyticsextensionmagicssmanalytics emr connect clusterid jXXXXXYYYYY authtype BasicAccess language python emrexecutiojnrolearn

使用Amazon EMR Serverless进行生产

CFM实现了一种基于数十条管道的架构：数据从Amazon S3摄取，通过 Amazon EMR Serverless 以Spark进行转换，生成的数据集再发布回Amazon S3。

每个管道作为单独的EMR Serverless应用程序运行，以避免工作负载之间的资源争用。每个EMR Serverless应用都分配了个别的IAM角色，以施行最小权限访问。

为控制成本，CFM采用了EMR Serverless自动扩展结合最大容量功能定义了所有作业在该应用下最多可消耗的vCPU、内存和磁盘容量。最后，CFM利用AWS Graviton架构进一步优化成本与性能如下图所示。

经过逐步迭代，用户将生成的最终脚本投入生产。对于初始部署，我们依靠Amazon EMR在EC2中运行这些脚本。基于用户的反馈，我们进行了迭代，并调查了减少集群启动时间的机会。集群启动时间可能长达8分钟，而实际运行所需的时间远少于此，这对用户体验产生了影响。此外，我们希望减少启动和停止EMR集群的运营开销。

因此，我们决定在EMR Serverless初次发布几个月后进行迁移。这个过程出人意料地简单，因为不需要任何调整，且能马上运作。我们唯一看到的缺点是需要在我们的软件栈中更新AWS工具和库，以纳入所有EMR功能如AWS Graviton；另一方面，这导致了启动时间的减少、成本的降低，以及更好的工作负载隔离。

目前，CFM的数据科学家能够进行分析并从原始数据中提取价值。生成的数据集随后被发布到我们组织内的数据网格服务，供科学家们用于预测模型。在CFM的上下文中，这需要强大的治理和安全措施，以对数据进行细粒度访问控制。这种数据网格方法使CFM能够从审计角度清楚地了解数据集的使用情况。

利用Lake Formation实现数据治理

在AWS上，数据网格是一种架构方法，其中数据被视为产品并由领域团队拥有。每个团队使用AWS服务如Amazon S3、AWS Glue、AWS Lambda和Amazon EMR独立构建和管理其数据产品，而AWS Glue数据目录等工具则使得数据可发现性得以实现。这种去中心化的方法促进了数据的自主性、可扩展性和跨组织的协作：

优点描述自主性CFM的团队拥有不同的技能和技术需求，使得团队能够自主工作成为我们采用去中心化模型的关键原因。可扩展性没有任何障碍阻止其他组织单位加入数据网格结构，我们希望更多团队参与改善和共享数据资产的工作。协作Lake Formation为使数据产品可被CFM内部消费者发现奠定了良好基础。

Lake Formation的文档内容详尽，提供了一系列达到与每个组织需求匹配的数据治理模式。我们做出了以下选择：

LFTags 我们使用LFTags而非命名资源权限管理。标签附加在资源上，用户被赋予访问某标签下所有资源的权限，使得权利管理过程的扩展变得简单。这也是AWS推荐的最佳实践。集中化 数据库和LFTags在一个集中管理的账户中进行管理，由一个团队进行管理。权限管理去中心化 数据生产者有权限将标签与其负责的数据集关联。消费者账户的管理员可以授权访问标记的资源。

结论

在这篇文章中，我们讨论了CFM如何构建一个良好治理与可扩展的数据工程平台，以生成金融特征。

Lake Formation为跨账户共享数据集提供了坚实基础，简化了通过IAM和资源政策管理复杂的跨账户访问的操作复杂性。目前，我们只利用它来共享数据科学家创建的资产，但计划在不久的将来添加更多领域。

Lake Formation还无缝集成了其他分析服务，如AWS Glue和Amazon Athena。向用户提供一个全面和集成的分析工具套件是我们采用Lake Formation的强烈理由。

最后但同样重要的是，EMR Serverless减少了运营风险和复杂性。EMR Serverless应用的启动时间不到60秒，而在EC2实例上启动EMR集群通常需要超过5分钟截至该文撰写时。这些节省下来的时间有效消除了任何错过交付截止日期的情况。

如果您希望简化数据分析工作流、简化跨账户数据共享并减少运营开销，请考虑在您的组织中使用Lake Formation和EMR Serverless。请访问AWS大数据博客，并联系您的AWS团队，了解AWS如何帮助您利用托管服务提高效率，发掘数据中有价值的见解。

关于作者

Julien Lafaye是CFM的董事，负责在AWS上推行数据平台的实施。他还是一支负责提供日内特征以支持CFM交易策略的数据科学家和软件工程师团队的负责人。在此之前，他开发低延迟解决方案以转化和传播金融市场数据。他获得了计算机科学博士学位，并毕业于巴黎的Ecole Polytechnique。在闲暇时，他喜欢骑自行车、跑步以及玩弄电子设备和计算机。

Matthieu Bonville是AWS法国的解决方案架构师，专注于金融服务行业FSI客户。他利用自己的技术专长和对FSI领域的了解，帮助客户架构出有效的技术解决方案以应对业务挑战。

Joel Farvault是AWS的首席专员SA分析师，拥有25年的企业架构、数据治理和分析经验，主要在金融服务行业工作。他领导过多项数据转型项目，涉及欺诈分析、索赔自动化和主数据管理，充分发挥其经验为客户提供数据策略和技术基础方面的咨询。

魔方加速器免费正版

加载评论