共计 8556 个字符，预计需要花费 22 分钟才能阅读完成。
机器学习、云计算、云原生等技术的提高给金融行业翻新注入了新的能源，以乾象投资 Metabit Trading 为代表的以人工智能为外围的科技型量化投资公司的工作就十分有代表性。他们通过深度交融和改良机器学习算法，并将其利用于信噪比极低的金融数据中，为投资人发明长期可继续的回报。
与传统的量化剖析不同，机器学习不仅关注股价、交易量和历史回报率等结构化数据，还注入来自研报、财报、新闻和社交媒体等非结构化数据来深刻理解证券价格走势和波动性。然而，将机器学习利用于量化钻研是具备挑战性的，因为原始数据可能蕴含噪声。此外，他们还须要应答许多挑战，如突发工作、高并发数据拜访和计算资源限度等。
为此，乾象投资在研发投入、翻新反对和根底平台建设方面继续发力。他们的钻研基础设施团队构建了一个高效、平安、规模化的工具链研发流程，通过正当利用云计算和开源技术冲破了单机研发的限度。本文将分享乾象量化钻研根底平台的具体实际，介绍基于 Fluid+JuiceFSRuntime 的公共云弹性量化投研工作撑持。
01 量化钻研的工作详解
作为 AI-powered hedge fund，通过 AI 模型训练进行策略钻研是咱们最次要的钻研形式。首先，在模型训练之前须要对原始数据做特征提取。金融数据的信噪比特地低，如果间接应用原始的数据进行训练，失去的模型乐音会十分大。原始数据除了行情数据，即大家常常会看到的市场上的股价、交易量之类的数据，也包含一些非量价的数据，比方研报、财报、新闻、社交媒体等之类的非结构化数据，钻研人员会通过一系列的变换提取出特色，再进行 AI 模型训练。能够参考上面咱们钻研场景中和机器学习关联最严密的策略钻研模式的简化示意图。
模型训练会产出模型以及信号。信号是对将来价格趋势的判断，信号的强度意味着策略导向性的强度。量化研究员会依据这些信息去优化投资组合，从而造成交易的实时仓位。这个过程中会思考横向维度（股票）的信息来进行危险管制，例如某一行业的股票不要适度持仓。当仓位策略造成之后，量化研究员会去模仿下单，而后失去实时仓位对应的盈亏信息，从而理解到这个策略的收益体现，这就是一个量化钻研的残缺流程。
02 量化钻研根底平台的需要
第一，突发工作多，弹性要求高。在策略钻研的过程中，量化研究员会产生策略想法，并会通过试验去验证本人的想法。随同着钻研人员新想法的呈现，计算平台就会产生大量的突发工作，因而咱们对计算的弹性伸缩能力要求很高。
上图是咱们某个集群一段时间的运行实例数据。以上图为例，能够看到在多个时间段里，整个集群实例数顶峰时刻能够达到上千个，然而同时整个计算集群的规模也会有缩容到 0 时候。量化机构的计算工作和研究员的研发进度是有很大关联的，波峰波谷的差距会十分大，这也是离线钻研工作的特点。
第二，热数据高并发拜访，除了计算须要弹性，数据缓存也须要弹性。对于热数据，比方行情数据，通常会有上百个工作同时拜访数据，它的吞吐要求十分高，峰值时数百 Gbps 甚至 Tbps 级别的聚合带宽能力满足需要。然而当计算集群中没有任何节点的时候，此时的吞吐需要为 0，如果是刚性吞吐这就须要弹性吞吐扩缩容的能力。
第三，容量和吞吐的独立线性扩大能力，对金融模型训练十分重要。传统分布式存储带宽与吞吐仅和数据应用容量成正比，而量化钻研过程中会创立大量的容器并发拜访存储系统的数据，会触发存储系统拜访限流。这就造成计算资源极致弹性与存储系统无限带宽之间的矛盾。而量化钻研的数据量其实不是特地大，很多市场的量价数据总量也不会超过 TB 级，然而数据拜访须要的峰值吞吐却十分高。
第四，数据亲和性调度，同一数据源屡次运行拜访本地缓存能够被复用。充分发挥热点数据集的缓存节点劣势，在对用户无感知的前提下，智能的将任务调度到数据缓存节点上。让罕用的模型训练程序越来越快。
第五，IP 爱护：数据共享与数据隔离。出于 IP 爱护的需要，不仅在计算工作上须要做隔离，在数据上也是须要具备权限管制的隔离能力；同时对行情数据这类绝对公开的数据，还须要反对研究员的获取形式是便捷的。
第六，缓存两头后果。计算工作模块化的场景会对两头后果的存储跟传输也有需要。举个简略的例子，在特色计算过程中会生成比拟大量的特色数据，这些数据会立即用于接下来大规模高并发的训练节点上。不言而喻在这种场景下咱们须要一个高吞吐和高稳固的两头缓存做数据传递。第七，多文件系统的反对。计算工作中各类型的工作会对应的各种个性的数据类型和应用形式，因此咱们不同团队会采纳不同的文件系统包含 OSS，CPFS，NAS，JuiceFS，以获取在各自状况下的性能最优化。Fluid 的不同 runtime 可能灵便的反对文件系统与工作的组合，使得工作计算可能在 K8s 上更高效正当的利用对应资源防止不必要的节约。
03 Fluid+JuiceFSRuntime：为云上量化钻研根底平台提供高效撑持
出于 POSIX 兼容，老本，高吞吐的思考，咱们抉择了 JuiceFS 云服务作为分布式底层存储。抉择了 JuiceFS，发现现有 Kubernetes 的 CSI 体系并不能很好地反对咱们对数据拜访性能、弹性吞吐能力以及数据共享隔离的需要，具体来看：
1. 传统的 Persistent Volume Claim 是面向通用存储的形象，不足对同一个存储简单数据拜访模式协同良好的反对：在不同的利用场景下，利用对同一存储中不同文件的应用形式不同，比方咱们少数并发计算工作要求只读；然而也有 Pipeline 数据直达，数据特色生成之后，须要直达到模型训练中，此时就要求读写；这导致了很难在同一个 PVC 中对立设置元数据更新和缓存策略。实际上，这些策略应该齐全取决于利用应用数据的模式。
2. 数据隔离与共享：不同数据科学家团队拜访不同的数据集须要人造隔离，并且要求比拟容易治理；同时反对公共数据集访问共享，特地是缓存数据共享，因为行情数据这类绝对公开的数据，不同的研究员团队会重复应用，心愿取得“一次预热、全公司收益”的成果。
3. 数据缓存感知的 Kubernetes 调度：雷同模型、雷同输出、不同的超参的作业以及微调模型、雷同输出的作业都会一直反复拜访同一数据，产生能够复用的数据缓存。然而原生的 Kubernetes 调度器无奈感知缓存，导致利用调度的后果不佳、缓存无奈重用，性能得不到晋升。
4. 数据拜访吞吐能够弹性扩容到数百 Gbps：传统的高性能分布式文件存储，个别的规格是 200 MB/s/TiB 基线的存储规格，其最大 IO 带宽是 20Gbps，而咱们工作的峰值 IO 带宽需要至多须要数百 Gbps，显然无奈满足咱们的要求。
5. 数据缓存的老本最优：因为公共云提供了计算资源极致弹性，能够短时间内弹出几百甚至上千计算实例，而当这些计算资源同时拜访存储时，在顶峰时吞吐须要数百 Gbps 甚至更高，此时须要通过计算中的缓存集群去服务热数据。然而很多时间段内，计算集群会缩容为 0，此时保护一个很大的缓存集群就得失相当了。咱们更偏向于在应用之前进行数据预热，同时依据业务的运行法则执行定时扩缩容；而当计算集群没有作业在运行，再缩容到默认缓存节点，从而达到对数据缓存吞吐的动静弹性伸缩管制。
为了达到上述指标，咱们迫切希望找到 Kubernetes 上具备弹性分布式缓存减速能力同时很好反对 JuiceFS 存储的软件。咱们发现 CNCF Sandbox 我的项目 Fluid[1] 和 JuiceFS 存储有很好的协同，JuiceFS 团队正好也是 Fluid 我的项目中 JuiceFSRuntime 的次要贡献者和维护者。于是，咱们设计了基于 Fluid 的架构计划并抉择了原生的 JuiceFSRuntime。
架构组件介绍
Fluid
Fluid 不同于传统的面向存储的 PVC 形象形式，而是在 Kubernetes 上针对“计算工作应用数据”的过程进行形象。它提出了弹性数据集 Dataset 的概念，以利用对数据拜访的需要为核心，给数据赋予特色，如小文件、只读、可读写等；同时将数据从存储中提取进去，并且给有特色的数据赋予范畴，如用户只关怀某几天的数据。围绕 Dataset 构建调度零碎，关注数据自身和应用数据的利用的编排，强调弹性和生命周期治理。
JuiceFSRuntime
JuiceFSRuntime 基于 JuiceFS 的分布式缓存减速引擎, 通过将数据分布式缓存技术与 Fluid 主动弹性伸缩 (Autoscaling)、可迁徙 (Portability)、可观测 (Observability)、亲和性调度（Scheduling）能力相结合，反对场景化的数据缓存和减速能力。在 Fluid 上应用和部署 JuiceFSRuntime 流程简略、兼容原生 Kubernetes 环境、能够开箱即用，并深度联合 JuiceFS 存储个性，针对特定场景优化数据拜访性能。
应用基于 JuiceFSRuntime 的 Fluid 的起因
- Dataset 形象满足云原生机器学习场景的性能优化和隔离共享等多样需要：
- 场景化性能调优：通过 Dataset 能够针对不同拜访特点的数据集作相应的优化，比方模型训练场景通常是只读，而特色计算须要读写。
- 数据隔离：Dataset 人造的通过 Kubernetes 的命名空间这种资源隔离机制用来限度不同团队对集群中数据集的拜访权限，并且不同的数据集对应 JuiceFS 中不同的子目录（JuiceFS 企业版还反对目录配额），这能够满足数据隔离的需要。
- 数据缓存共享：对于一些不同团队都会频繁应用的公开数据集，Fluid 反对跨 Kubernetes Namespace 的数据拜访，能够做到一次缓存，多个团队共享，这也满足了数据缓存共享的需要。
- Runtime 场景化的计算资源优化：Dataset 是数据的通用形象，而对于数据真正的操作，实际上由 JuiceFSRuntime 实现，所以 Runtime 的 CPU，Memory，网络和缓存 Worker 数量等资源配置势必会影响性能，这就须要针对 Dataset 的应用场景，对 Runtime 的计算资源进行优化配置。
- 弹性分布式缓存：反对丰盛的扩缩容策略，包含手动伸缩、主动弹性伸缩和定时弹性伸缩，能够依据须要找到最优的弹性计划。
- 手动伸缩：通过 Dataset 的可观测性，能够理解数据集的数据量和缓存 Runtime 须要的缓存资源，也能够依据利用拜访的并发度设置 Runtime 的 Replicas 数量（缓存 Worker 的数量），不必的时候能够随时缩容。
- 主动弹性伸缩：依据数据指标进行主动弹性伸缩。比方依据数据缓存量和吞吐量等指标进行缓存弹性伸缩，能够制订当缓存百分比超过 80%，或者当客户端数量超过肯定阈值的时候进行主动扩容。
- 定时弹性伸缩：依据业务个性设置定时弹性伸缩，能够实现无人参加的数据弹性扩缩容机制。
- 主动的数据预热：防止在训练时刻并发拉取数据造成数据拜访竞争，还能够和弹性伸缩配合，防止过早的创立缓存资源。
- 数据感知调度能力：在利用被调度时，Fluid 会通过 JuiceFSRuntime 把数据缓存地位作为一个调度信息提供给 K8s 调度器，帮忙利用调度到缓存节点或者离缓存更近的节点。整个过程对用户通明，实现数据拜访性能的劣势最大化。
落地实际
依据实际，咱们总结了以下教训供大家参考。
在 Fluid 的 JuiceFSRuntime 抉择高网络 IO 和大内存的 ECS 作为缓存节点
随着 ECS 网络能力的一直晋升，以后网络带宽曾经远超 SSD 云盘 IO 能力。以阿里云上的 ecs.g7.8xlarge 规格的 ECS 为例，其带宽峰值为 25Gbps，内存为 128GiB。实践上，实现 40G 数据读取仅须要 13s。咱们的数据是存储在 JuiceFS 上的，因而为了实现大规模的数据读取，咱们须要首先将数据加载到计算所在 VPC 网络中的计算节点中。以下为咱们应用的一个具体例子，为了进步数据读取速度，咱们配置 cache 节点使其抉择应用内存来缓存数据。这里须要留神：
Worker 次要负责分布式数据缓存，为了进步数据读取速度，咱们能够为 Worker 配置内存性能绝对较高的机型。而 Worker 的调度策略在 Dataset 中配置，因此须要在 Dataset 中为 Worker 配置亲和性策略。
当工作没有特定机型需要时，为保障 Cluster 的 AutoScaler 能胜利扩容，实际中也倡议在进行亲和性配置时抉择多种实例类型以保障扩容 / 工作执行的胜利。
Replicas 是初始的缓存 Worker 数量，前期能够通过手动触发或主动弹性伸缩进行扩缩容。
当指定 tieredstore 后，即无需在 Kubernetes 的 Pod 中设置 request 的内存，Fluid 能够主动解决。
如在缓存节点上的 JuiceFS mount 有不同的配置，例如 cache size 大小，挂载门路等，能够通过 worker 里的 options 进行笼罩。
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
name: metabit-juice-research
spec:
mounts:
- name: metabit-juice-research
mountPoint: juicefs:///
options:
metacache: ""cache-group:"research-groups"
encryptOptions:
- name: token
valueFrom:
secretKeyRef:
name: juicefs-secret
key: token
- name: access-key
valueFrom:
secretKeyRef:
name: juicefs-secret
key: access-key
- name: secret-key
valueFrom:
secretKeyRef:
name: juicefs-secret
key: secret-key
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: node.kubernetes.io/instance-type
operator: In
values:
- ecs.g7.8xlarge
- ecs.g7.16xlarge
tolerations:
-key: jfs_transmittion
operator: Exists
effect: NoSchedule
---
apiVersion: data.fluid.io/v1alpha1
kind: JuiceFSRuntime
metadata:
name: metabit-juice-research
spec:
replicas: 5
tieredstore:
levels:
- mediumtype: MEM
path: /dev/shm
quota: 40960
low: "0.1"
worker:
nodeSelector:
nodeType: cacheNode
options:
cache-size: 409600
free-space-ratio: "0.15“配置主动弹性伸缩策略
受业务状态的影响，Metabit 在固定时段会有跟高的用量需要，因而简略的配置定时缓存节点的弹性伸缩策略能到达到不错的收益，例如对老本的管制，对性能晋升。
apiVersion:
autoscaling.alibabacloud.com/v1beta1
kind: CronHorizontalPodAutoscaler
metadata:
name: research-weekly
namespace: default
spec:
scaleTargetRef:
apiVersion: data.fluid.io/v1alpha1
kind: JuiceFSRuntime
name: metabit-juice-research
jobs:
- name: "scale-down"
schedule: "0 0 7 ? * 1"
targetSize: 10
- name: "scale-up"
schedule: "0 0 18 ? * 5-6"
targetSize: 20更进一步，如果通过业务中具体的 metrics 如缓存比例阈值，IO throughput 等触发带有简单自定义规定的弹性伸缩策略能够实现更为灵便的缓存节点扩缩容配置以带来更高和更稳固的性能体现。具体来讲，在灵便度和性能层面会有以下一些长处：
无需精准感知底层数据或领有固定的扩缩容规定，根据集群状态自适应的配置缓存正本上上限。
阶梯式扩容防止一开始就创立过多的 ECS，造成破费上的节约。
防止爆发式的 ECS 拜访 JuiceFS 数据造成带宽抢占。
触发数据预热
通过数据预热晋升缓存比例，进而触发主动弹性伸缩；同时监控缓存比例，当缓存比例达到肯定阈值同时开始触发工作下发，防止过早下发高并发工作导致 IO 提早。
镜像预埋
因为 Metabit Trading 应用计算和数据弹性的规模很大，霎时会弹出十分多的 Pod，这就会导致镜像下载限流。网络带宽资源在 pod 拉起过程中是稀缺的，为防止 pod 创立时因拉取容器镜像延时带来的各种问题，咱们倡议对 ECS 的镜像进行客制化革新，对须要的系统性镜像做到“应埋尽埋”从而升高 pod 拉起的工夫老本。具体例子可参考 ACK[2] 的根底镜像。
04 弹性吞吐晋升带来的性能和老本收益
在理论部署评估中，咱们应用 20 个 ecs.g7.8xlarge 规格的 ECS 作为 woker 结点构建 JuiceFSRuntime 集群，单个 ECS 结点的带宽下限为 25Gbps；为了进步数据读取速度，咱们抉择应用内存来缓存数据。
为便于比照，咱们统计了拜访耗时数据，并与应用 Fluid 形式拜访数据耗时进行了比照，数据如下图所示：
能够看出，当同时启动的 Pod 数量较少时，Fluid 与分布式存储相比并没有显著劣势；而当同时启动的 Pod 越多时，Fluid 的减速劣势也越来越大；当同时并发扩充到 100 个 Pod 时，Fluid 相比传统分布式存乎能够升高超过 40% 的均匀耗时。这一方面晋升了工作速度，另外一方面也的确的节俭了 ECS 因为 IO 延时带来的老本。
更重要的是，因整个 Fluid 零碎的数据读取带宽是与 JuiceFSRuntime 集群规模正相干的，如果咱们须要同时扩容更多的 Pod，则能够通过批改 JuiceFSRuntime 的 Replicas 来减少数据带宽，这种动静扩容的能力是分布式存储目前无奈满足的。
05 瞻望
Metabit 在 Fluid 的实际上走出了虚浮的第一步，面对这个不断创新和继续输入的技术框架咱们也在思考如何施展在更多适合的场景施展其齐备的性能。这里简略聊聊咱们的一些小察看，抛砖引玉，供大家施展。
- Serverless 化可能提供更好的弹性：目前咱们通过自定义镜像的形式晋升利用容器和 Fluid 组件的弹性效率，咱们也关注到在 ECI 上应用 Fluid 能更高效和简略的利用扩大弹性，同时升高运维复杂度。这是一个在实践中值得去摸索的方向。
- 工作弹性和数据缓存弹性的协同：业务零碎理解一段时间内应用雷同数据集的工作并发量，并且工作排队的过程中执行数据预热和弹性扩缩容；相应的当数据缓存或者数据拜访吞吐满足肯定条件，触发排队工作从期待变成可用。
06 总结和致谢
Metabit Trading 在生产环境应用 Fluid 曾经靠近一年半了，包含 JindoRuntime、JuiceFSRuntime 等，目前通过 JuiceFSRuntime 实现了高效的大规模量化钻研。Fluid 很好的满足了简略易用、稳固牢靠、多 Runtime、易保护以及让量化研究员的应用感通明等益处。
Metabit Trading 的大规模实际帮忙咱们团队在应用公共云上积攒了很好的认知，在机器学习和大数据场景下，岂但计算资源须要弹性，与之配合的数据拜访吞吐也须要与之相匹配的弹性，传统的存储侧缓存因为老本，灵便，按需弹性的差别，曾经很难满足以后场景的需要，而 Fluid 的计算側弹性数据缓存的理念和实现则十分适合。
这里要特别感谢 JuiceData 的朱唯唯，Fluid 社区的车漾，徐之浩和顾荣老师的继续反对。因为有他们的保护，社区内有沉闷的探讨和疾速的响应，这对咱们的顺利 adoption 起到了要害的作用。
07 相干链接
[1] Fiuld：https://github.com/fluid-cloudnative/fluid
[2] ACK：https://www.aliyun.com/product/kubernetes?spm=5176.19720258.J…
08 作者介绍
李治昳，Metabit Trading – AI Platform Engineer，builder、云原生技术 learner，曾任 Citadel 高级工程师。
李健弘，Metabit Trading – Engineering manager of AI Platform，专一于在量化钻研畛域搭建机器学习平台和高性能计算平台，曾任 Facebook 高级工程师。
本文作者来自乾象投资 Metabit Trading，公司成立于 2018 年，是一家以人工智能为外围的科技型量化投资公司。核心成员毕业于 Stanford、CMU、清北等出名高校。目前，治理规模已冲破 50 亿元人民币, 并且在 2022 年市场中性策略收益排名中名落孙山，体现亮眼。
原文链接
本文为阿里云原创内容，未经容许不得转载。
