发布于: May 27, 2021
大数据技术是信息发展的一大趋势，什么是大数据、如何利用大数据是如今热门的研究话题。本文调查了将 Amazon EMR 大数据处理平台用作 FRTB IMA 计算平台的实际情况，下图所示为用例中选择的特定 Amazon EMR 架构。
架构示意图：步骤顺序
- 本地日结触发器首先提取头寸、市场、模型与静态数据。
- 数据提取流程将头寸、市场、模型与静态数据上传至 Amazon S3
- 创建 Amazon EMR for Apache Spark 集群。各工作节点将 FSxfor Lustr 映射至 S3 存储桶（来自第2步）。各工作节点还将接入时序数据库。
- 调用 IMA 批处理驱动程序（Web 服务或 Amazon Web Services Lambda 进程）。批处理驱动程序创建计算任务，并将任务提交至 Spark 主节点。
- Spark工作节点将历史市场数据上传至该时序数据库，而后开始处理实际计算任务。
- 工作节点将 PnL 保存至 FSx Lustre 目录。一旦 Spark 作业处理完成，Amazon FSx 目录将被导出至 Amazon S3。
- 将 PnLs 从 Amazon S3 加载至 Amazon Redshift。Amazon Redshift 为各业务部门、办公室以及法人实体生成聚合 PnL，并计算预期短缺结果。
- Amazon QuickSIght 加载数据集并显示报告。
在这种“以数据为中心”的高性能计算（HPC）方案当中，各个投资组合/账户都将映射至一个独立的 Amazon EMR 节点，所需的计算任务将在这些节点上并行运行。而后，各 PnL 结果将被进一步汇总为交易账户以计算预期 PnL 与短缺结果。请注意，如果使用的是基于蒙特卡洛模拟的模型（而非本文中探讨的示例），则将产生生成基础流程的模拟路径（例如 Equity Index SPX 价格），而后利用这些模拟价格在各个 Amazon EMR 节点上为所有衍生产品定价（例如期权）。
解决方案亮点
Amazon EMR 是一套行业领先的云大数据处理平台，可使用多种开源工具（Apache Spark, Apache Hive, Apache HBase, Apache Flink, Apache Hudi, 以及Presto）处理大量数据。借助 Amazon EMR，您能够以不到传统本地解决方案一半的成本运行 PB 级分析，且速度比标准 Apache Spark 快三倍以上。对于短期运行的作业，您可以对集群进行纵向规模伸缩，并为实际使用的实例按秒支付费用。对于长期运行的工作负载，您也可以创建具备高可用性的自动伸缩集群以满足业务需求。
Amazon Elastic Compute Cloud (Amazon EC2) 提供超过 200 种实例类型供您选择，这些实例类型经过针对性优化以适应不同的用例需求。如此强大的灵活性，意味着您可以根据性能、成本以及可用性需求做出明智选择。例如，某些批处理作业需要在特定的小时数内完成以生成监管报告，则组织可以选择使用 Amazon EC2 预留实例在生产环境中运行 FRTB。而在开发与测试方面，组织则可选择使用各类 Amazon EC2 竞价实例以优化计算成本。
在本文中，我们选择了 Amazon EC2 m5.24xlarge 作为主实例。最佳实践是建议大家将预留或者按需实例作为 Amazon EMR 主实例。而在工作节点（Spark executors）方面，我们则建议使用 Amazon EC2 竞价实例以优化计算成本。
最后，还建议大家配置 Amazon EMR instance fleet 以充分利用多种多样的配置选项。
Amazon S3是一项对象存储服务，能够提供行业领先的可扩展性、数据可用性、安全性与性能表现。Amazon S3 在设计上拥有 99.999999999（11 个 9）的持久性，且集成有支持风险数据存储的安全功能并提供近乎无限的存储容量。
FSx for Lustre 是目前最受欢迎的高性能文件系统。它提供全托管选项，能够与 Amazon S3 相集成，并针对机器学习、高性能计算以及财务建模等需要快速处理的工作负载进行了优化。在接入S3存储桶之后，Fsx for Lustre 文件系统将把 Amazon S3 对象透明显示为文件形式，并允许大家将更改的数据写入回 Amazon S3 当中。
与 Hadoop 分布式文件系统（HDFS）等共享文件系统相比，Amazon FSx 在处理大量小型文件（例如头寸 PnLs 数组）的写入操作时性能表现更好。Amazon FSx 的另一大优势，则是支持可移植操作系统接口（POSIX），因此任何定价库/供应商模型只需要遵守 POSIX 标准即可与之匹配，无需进行重构。
解决方案模型详细信息
在我们的概念验证应用程序当中，我们选择了两种计算期权的方法，用于演示不同方法之间的差异：
- 经典布莱克-舒尔斯模型：虽然在计算美式期权价格时存在一定限制，但这种经典模型仍然得到广泛应用与充分认可。
- 朗斯特夫-施瓦茨（Longstaff Schwartz，简称LS)模型：使用几何布朗运动（GBM）模拟最长5年周期之内（共60个月点）中每个月的股票价格。这种模型得出的结果更准确，但占用的CPU资源也更多。
- 将蒙特卡洛路径的数量设置为10000。
- 在实际生产场景中，某些实现可能使用2万或10万条路径运行，这会显著增加CPU运行时间。
- 计算过程如下所示：
-
- St 在t条件下模拟价格
- r 在t条件下计算无风险利率
- 条件下的σ波动率（非随机）
- wt 布朗运动
- 我们使用GBM的第二种形式以模拟股票价格。
- 我们使用2因子基函数进行运动决策。
-
- yt 为内在值→ min (Strike -St, 0)。
- 在10000个蒙特卡洛路径中，我们仅采用yt 不为0的路径。
实例类型 |
vCPU/实例 |
实例个数 |
布莱克-舒尔斯模型 |
LS模型 |
c4.8xlarge |
36 |
100 |
50 秒 |
640 秒 |
c4.8xlarge |
36 |
200 |
28 秒 |
435 秒 |
c5.9xlarge |
36 |
100 |
20 秒 |
600 秒 |
c5.9xlarge |
36 |
200 |
14 秒 |
400 秒 |
c5.24xlarge |
96 |
100 |
47 秒 |
440 秒 |
c5.24xlarge |
96 |
200 |
27 秒 |
280 秒 |
c5.24xlarge |
96 |
40 |
30 秒 |
760 秒 |
c5n.xlarge |
4 |
100 |
50 秒 |
1740 秒 |
c5n.18xlarge |
72 |
20 |
53 秒 |
2560 秒 |
下图使用上表内的数据绘制而成。其中x轴代表总vCPU数量（vCPU/实例 x 实例数量），y轴则代表运行时长。
从图中，我们可以得出以下结论。对于LS算法，可以看到运行时长随着vCPU的增加而减少（呈指数级衰减，而非线性降低）。与之形成鲜明对比的是，对于运行时间本就较短的布莱克-舒尔斯模型，添加vCPU并不会带来明显的性能提升效果——结果的分散化可能源自所选实例类型集的函数。在使用相同的总vCPU数量时，布莱克-舒尔斯模型仍然存在多个运行时长点，因此基本可以支持这项假设。从表中可以看到，新型实例在执行分析负载时花费的时间更短。
时间与成本分析
上一节中介绍了在200万个头寸上，不同实例类型与vCPU搭配下的计算运行时长。
在这里，我们使用200个C5.24xlarge实例作为参考，反映整体FRTB运行一整天的实际运算量。这里我们还决定选择LS模型——这是因为此模型的CPU占用量更高，因此时间估算结果将更接近包含200万个蒙特卡洛类型模拟衍生头寸的最大计算时间（更接近于实际FRTB的运行情况）。
对于LS模型，运行时间为280秒，大约是5分钟。配合一年的历史数据（约250个交易日）以及4项风险因素（以股票期权为例，包括基本估值、部分股权估值、利率以及波动率），每个头寸的总体计算需求量为250 x 4 = 1000个估值/头寸。
以此为基础，可以看到使用选定集群规模时，总体运行时间为5分钟 x
1000，大概是85个小时。这种批量计算周期实在太长，所以我们需要选择规模更大的计算集群。
如果将完成FRTB批处理作业的目标时长设定为5个小时，那么我们需要85小时/5小时 = 17套集群（每个集群包含200个C5.24xlarge实例）。其中各个集群都可以独立运行（例如按办公室、业务部门或者区域划分）。
如上表所示，在运行布莱克-舒尔斯模型时，运行时间将显著缩短。结果就是，根据投资组合中头寸的类型与模型复杂度（计算任务质量），运行时间与成本都将有所区别。
相关文章