从资源弹性到数据弹性，乾象如何将云上量化研究效率提升 40%？

机器学习、云核算、云原生等技能的进步给金融职业立异注入了新的动力，以乾象出资 Metabit Trading 为代表的以人工智能为中心的科技型量化出资公司的工作就十分有代表性。他们经过深度融合和改善机器学习算法，并将其运用于信噪比极低的金融数据中，为出资人发明长期可继续的回报。

与传统的量化分析不同，机器学习不只重视股价、买卖量和前史回报率等结构化数据，还注入来自研报、财报、新闻和交际媒体等非结构化数据来深入了解证券价格走势和波动性。可是，将机器学习运用于量化研讨是具有应战性的，因为原始数据或许包含噪声。此外，他们还需求应对许多应战，如突发使命、高并发数据拜访和核算资源约束等。

为此，乾象出资在研制投入、立异支撑和根底渠道建设方面继续发力。他们的研讨根底设施团队构建了一个高效、安全、规划化的工具链研制流程，经过合理运用云核算和开源技能打破了单机研制的约束。本文将分享乾象量化研讨根底渠道的详细实践，介绍依据 Fluid+JuiceFSRuntime 的公共云弹性量化投研工作支撑。

量化研讨的工作详解

作为 AI-powered hedge fund，经过 AI 模型练习进行战略研讨是咱们最首要的研讨方法。首要，在模型练习之前需求对原始数据做特征提取。金融数据的信噪比特别低，假如直接运用原始的数据进行练习，得到的模型噪音会十分大。原始数据除了行情数据，即大家常常会看到的商场上的股价、买卖量之类的数据，也包含一些非量价的数据，比方研报、财报、新闻、交际媒体等之类的非结构化数据，研讨人员会经过一系列的改换提取出特征，再进行 AI 模型练习。可以参阅下面咱们研讨场景中和机器学习相关最紧密的战略研讨形式的简化示意图。

模型练习会产出模型以及信号。信号是对未来价格趋势的判别，信号的强度意味着战略导向性的强度。量化研讨员会依据这些信息去优化出资组合，然后构成买卖的实时仓位。这个进程中会考虑横向维度（股票）的信息来进行危险操控，例如某一职业的股票不要过度持仓。当仓位战略构成之后，量化研讨员会去模仿下单，然后得到实时仓位对应的盈亏信息，然后了解到这个战略的收益体现，这便是一个量化研讨的完整流程。

量化研讨根底渠道的需求

榜首，突发使命多，弹性要求高。 在战略研讨的进程中，量化研讨员会发生战略主意，并会经过实验去验证自己的主意。伴随着研讨人员新主意的出现，核算渠道就会发生许多的突发使命，因而咱们对核算的弹性弹性才能要求很高。

上图是咱们某个集群一段时刻的运转实例数据。以上图为例，可以看到在多个时刻段里，整个集群实例数顶峰时刻可以到达上千个，可是一起整个核算集群的规划也会有缩容到 0 时分。量化组织的核算使命和研讨员的研制进展是有很大相关的，波峰波谷的距离会十分大，这也是离线研讨使命的特色。

第二，热数据高并发拜访，除了核算需求弹性，数据缓存也需求弹性。 关于热数据，比方行情数据，通常会有上百个使命一起拜访数据，它的吞吐要求十分高，峰值时数百 Gbps 甚至 Tbps 等级的聚合带宽才干满意需求。可是当核算集群中没有任何节点的时分，此刻的吞吐需求为 0，假如是刚性吞吐这就需求弹性吞吐扩缩容的才能。

第三，容量和吞吐的独立线性扩展才能，对金融模型练习十分重要。 传统分布式存储带宽与吞吐仅和数据运用容量成正比，而量化研讨进程中会创立许多的容器并发拜访存储体系的数据，会触发存储体系拜访限流。这就形成核算资源极致弹性与存储体系有限带宽之间的矛盾。而量化研讨的数据量其实不是特别大，许多商场的量价数据总量也不会超越 TB 级，可是数据拜访需求的峰值吞吐却十分高。

第四，数据亲和性调度，同一数据源屡次运转拜访本地缓存可以被复用。 充分发挥热点数据集的缓存节点优势，在对用户无感知的前提下，智能的将使命调度到数据缓存节点上。让常用的模型练习程序越来越快。

第五，IP保护：数据同享与数据阻隔。 出于 IP 保护的需求，不只在核算使命上需求做阻隔，在数据上也是需求具有权限操控的阻隔才能；一起对行情数据这类相对揭露的数据，还需求支撑研讨员的获取方法是便捷的。

第六，缓存中心成果。 核算使命模块化的场景会对中心成果的存储跟传输也有需求。举个简略的比如，在特征核算进程中会生成比较许多的特征数据，这些数据会立刻用于接下来大规划高并发的练习节点上。显而易见在这种场景下咱们需求一个高吞吐和高安稳的中心缓存做数据传递。

第七，多文件体系的支撑。 核算使命中各类型的使命会对应的各种特性的数据类型和运用方法，因而咱们不同团队会采用不同的文件体系包含 OSS，CPFS，NAS，JuiceFS，以获取在各自情况下的功能最优化。Fluid 的不同 runtime 可以灵敏的支撑文件体系与使命的组合，使得使命核算可以在 K8s 上更高效合理的运用对应资源防止不必要的糟蹋。

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 的原因

1. Dataset 笼统满意云原生机器学习场景的功能优化和阻隔同享等多样需求：

• 场景化功能调优：经过 Dataset 可以针对不同拜访特色的数据集作相应的优化，比方模型练习场景通常是只读，而特征核算需求读写。
• 数据阻隔：Dataset 天然的经过 Kubernetes 的命名空间这种资源阻隔机制用来约束不同团队对集群中数据集的拜访权限，而且不同的数据集对应 JuiceFS 中不同的子目录（JuiceFS 企业版还支撑目录配额），这可以满意数据阻隔的需求。
• 数据缓存同享：关于一些不同团队都会频繁运用的揭露数据集，Fluid 支撑跨Kubernetes Namespace 的数据拜访，可以做到一次缓存，多个团队同享，这也满意了数据缓存同享的需求。

2. Runtime 场景化的核算资源优化：Dataset 是数据的通用笼统，而关于数据真正的操作，实践上由 JuiceFSRuntime 完成，所以 Runtime 的 CPU，Memory，网络和缓存 Worker 数量等资源装备势必会影响功能，这就需求针对 Dataset 的运用场景，对 Runtime 的核算资源进行优化装备。

3. 弹性分布式缓存：支撑丰厚的扩缩容战略，包含手动弹性、主动弹性弹性和守时弹性弹性，可以依据需求找到最优的弹性方案。

• 手动弹性：经过 Dataset 的可观测性，可以了解数据集的数据量和缓存 Runtime 需求的缓存资源，也可以依据运用拜访的并发度设置 Runtime 的 Replicas 数量（缓存 Worker 的数量），不用的时分可以随时缩容。
• 主动弹性弹性：依据数据目标进行主动弹性弹性。比方依据数据缓存量和吞吐量等目标进行缓存弹性弹性，可以制定当缓存百分比超越 80%，或许当客户端数量超越必定阈值的时分进行主动扩容。
• 守时弹性弹性：依据事务特性设置守时弹性弹性，可以完成无人参加的数据弹性扩缩容机制。

4. 主动的数据预热：防止在练习时刻并发拉取数据形成数据拜访竞争，还可以和弹性弹性合作，防止过早的创立缓存资源。

5. 数据感知调度才能：在运用被调度时，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 来增加数据带宽，这种动态扩容的才能是分布式存储现在无法满意的。

展望

Metabit 在 Fluid 的实践上走出了结壮的榜首步，面对这个不断立异和继续输出的技能结构咱们也在思考怎么发挥在更多合适的场景发挥其完备的功能。这儿简略聊聊咱们的一些小调查，抛砖引玉，供大家发挥。

1. Serverless 化可以供给更好的弹性：现在咱们经过自定义镜像的方法提高运用容器和Fluid组件的弹性效率，咱们也重视到在 ECI 上运用 Fluid 能更高效和简略的运用扩展弹性，一起下降运维杂乱度。这是一个在实践中值得去探索的方向。

2. 使命弹性和数据缓存弹性的协同：事务体系了解一段时刻内运用相同数据集的使命并发量，而且使命排队的进程中履行数据预热和弹性扩缩容；相应的当数据缓存或许数据拜访吞吐满意必定条件，触发排队使命从等待变成可用。

总结和致谢

Metabit Trading 在出产环境运用 Fluid 现已挨近一年半了，包含 JindoRuntime、JuiceFSRuntime 等，现在经过 JuiceFSRuntime 完成了高效的大规划量化研讨。Fluid 很好的满意了简略易用、安稳牢靠、多 Runtime、易保护以及让量化研讨员的运用感通明等好处。

Metabit Trading 的大规划实践协助咱们团队在运用公共云上积累了很好的认知，在机器学习和大数据场景下，不光核算资源需求弹性，与之合作的数据拜访吞吐也需求与之相匹配的弹性，传统的存储侧缓存因为本钱，灵敏，按需弹性的差异，现已很难满意当前场景的需求，而 Fluid 的核算側弹性数据缓存的理念和完成则十分合适。

这儿要特别感谢 JuiceData 的朱唯唯，Fluid 社区的车漾，徐之浩和顾荣老师的继续支撑。因为有他们的保护，社区内有活泼的评论和快速的响应，这对咱们的顺利 adoption 起到了关键的效果。

相关链接

[1] Fiuld

github.com/fluid-cloud…

[2] ACK

www.aliyun.com/product/kub…

作者介绍

李治昳，Metabit Trading – AI Platform Engineer，builder 、云原生技能 learner，曾任Citadel高级工程师。

李健弘， Metabit Trading – Engineering manager of AI Platform，专心于在量化研讨领域搭建机器学习渠道和高功能核算渠道，曾任 Facebook 高级工程师。

本文作者来自乾象出资 Metabit Trading，公司成立于2018年，是一家以人工智能为中心的科技型量化出资公司。中心成员结业于 Stanford、CMU、清北等闻名高校。现在，管理规划已打破 50 亿元人民币, 而且在2022年商场中性战略收益排名中名列前茅，体现亮眼。

本文转载来历：infoq
假如你对 Fluid 项目感兴趣，欢迎点击此处了解更多