共计 4325 个字符，预计需要花费 11 分钟才能阅读完成。
背景
乾象投资 Metabit Trading 成立于 2018 年，是一家以人工智能为外围的科技型量化投资公司。核心成员毕业于 Stanford、CMU、清北等高校。目前，治理规模已冲破 30 亿元人民币。
Metabit 非常重视根底平台的建设，有一支弱小的 Research Infrastructure 团队。团队试图突破在单机上进行研发的壁垒，利用云计算进行更高效、平安的工具链研发。
01 量化的钻研都在做什么
作为一家成立工夫不久的量化投资机构，咱们在对根底存储平台进行选型时，会受到这样两方面的因素的影响：公司成立的工夫比拟短，没有太多技术上的历史累赘，在做技术抉择时，更偏差于应用更古代的技术栈；同时，量化投资中应用到的机器学习场景中的个性也会影响到技术的抉择。
上图是咱们钻研场景中和机器学习关联最严密的策略钻研模式的简化示意图。首先，在模型训练之前须要对原始数据做特征提取。金融数据的信噪比特地低，如果间接应用原始的数据进行训练，失去的模型乐音会十分大。原始数据除了行情数据，即大家常常会看到的市场上的股价、交易量之类的数据，也包含一些非量价的数据，比方研报、财报、新闻、社交媒体等之类的非结构化数据，钻研人员会通过一系列的变换提取出特色，再进行 AI 模型训练。
模型训练会产出模型以及信号，信号是对将来价格趋势的判断；信号的强度意味着策略导向性的强度。量化研究员会依据这些信息去优化投资组合，从而造成交易的实时仓位。这个过程中会思考横向维度（股票）的信息来进行危险管制，例如某一行业的股票不要适度持仓。当仓位策略造成之后，量化研究员会去模仿下单，而后失去实时仓位对应的盈亏信息，从而理解到这个策略的收益体现，以上就是一个量化钻研的残缺流程。
量化钻研业务特点
钻研需要产生大量突发工作：高弹性
在策略钻研的过程中，量化研究员会产生策略想法，他们会通过试验去验证本人的想法。随同着钻研人员新想法的呈现，计算平台就会产生大量的突发工作，因而咱们对计算的弹性伸缩能力的要求很高。
钻研工作多样化：灵活性
从下面的例子能够看到，整个流程涵盖了十分多不同的计算工作，例如：
- 特征提取，时序数据上的计算；
- 模型训练，经典的机器学习的模型训练场景；
- 投资组合优化，会波及到最优化问题的工作；
- 策略回测，读入行情的数据，再对策略的体现去做模仿撮合，失去仓位对应的体现。
整个过程工作的品种是十分多样化的，对计算的要求也很不一样。
钻研内容须要爱护：模块化，隔离
研究员的投研内容是公司的重要 IP（知识产权）。为了爱护这些知识产权，公司的钻研平台会将每个策略钻研环节形象成蕴含规范输入输出和评估形式的模块。例如对模型的钻研，输出规范的特征值，输入预测的信号和模型。通过对模块之间进行隔离，钻研平台能够无效爱护 IP 的安全性。在进行存储平台建设时，须要针对模块化这个需要做相应的设计。
量化钻研数据特点
大量工作的输出来自于雷同的数据 ，比方上文提到的回测，量化研究员须要对历史策略去做大量的回测，同样的仓位应用不同的参数去测试，察看它们体现；或者特征提取，常常有一些根底特色和新特色的组合，其中大量的数据是来自于雷同的数据源。
以 A 股的股票为例：A 股市场十年的分钟 K 线历史行情，5000/2 股票 240 分钟 250 天 10 年 8 字节 *20 列 =240GB，整体 10 年的数据量大概是 240G。
如果应用更细力度的数据，数据量就会更大，一般来说原始数据不会超过 100TB 的范畴。在大数据时代这算不上是特地大的数据量， 然而当大量的计算工作去同时去拜访这些数据，这种场景就对数据存储的有一些要求 。
另外，量化投研过程中随同着大量的突发工作，钻研团队心愿能将这些工作的后果存储起来，因而会产生大量 archive 数据，但这些数据的拜访频率很低。
量化钻研计算工作特点
基于以上特点，如果以传统的机房形式，是很难去满足咱们的计算需要，因而把计算搬到云计算平台对咱们来讲是一个绝对适合的技术抉择。
第一，突发工作多，弹性十分大 。上图是咱们某个集群近期的运行实例数据。能够看到在多个时间段里，整个集群实例都是被打满的状态，然而同时整个计算集群的规模也会有 scale 到 0 的时候。量化机构的计算工作和研究员的研发的进度是有很大关联的，波峰波谷的差距会十分大，这也是离线钻研工作的特点。
第二，“技术爆炸”，很难精确预估何时会产生算力需要 。“技术爆炸”是科幻小说《三体》的概念，对应到咱们这就是咱们的钻研模式和算力的需要会产生飞跃式提高，咱们很难精确预估算力需要的变动。咱们在 2020 年年初的时候，钻研的理论用量和预估用量都十分小，然而当钻研团队提出的一些新的钻研办法思路之后，会在某个霎时忽然对算力产生十分大的需要 。而容量布局是在建设传统机房的布局时候十分重要的一件事件。
第三，古代 AI 生态，简直是搭载在云原生平台上的 。咱们做了很多翻新的技术尝试，包含当初十分风行的 MLOps，将整套 pipeline 串联起来，再去做机器学习训练的流水线；当初很多的分布式的训练任务的反对，都是面向云原生去做了很多的开发工作，这也使得咱们把整个计算工作放到云上成为一个很天然的抉择。
02 量化平台存储需要
依据下面业务和计算的需要，能够比拟容易的去推导进去咱们对存储平台的需要。
- 计算与存储不平衡 。上文提到计算工作会有很大的突增，计算量会很容易会达到十分高的程度。而热数据的增长量并没有那么快，这就意味着咱们须要去做存算拆散。
- 为热数据，比方行情的数据，提供高吞吐的拜访 。上百个工作同时拜访数据，对它吞吐要求十分高。
- 为冷数据提供低成本存储 。量化钻研须要大量 archive 数据，也要为这些数据提供绝对低成本的存储。
- 文件类型 / 需要多样性即 POSIX 兼容性 。咱们有很多不同的计算工作，这些计算工作对文件的类型的需要是十分多样的，例如 CSV、Parquet 等，有一些钻研场景还有更灵便的定制开发的需要，这就意味着在选型的时候不可能对文件存储形式做严格限度，因而 POSIX 的兼容性对于存储平台选型是一个很要害的考量因素。
- IP 爱护 ：数据共享与数据隔离。咱们 IP 爱护的需要，不仅是计算工作上须要做这样的隔离，在数据上也是须要反对这样的隔离能力；同时对行情数据这类绝对公开的数据，还须要反对研究员的获取形式是便捷的。
- AI 生态 ，在云的平台下来做各种工作的调度。这也是较为根底的一个应用需要，因而存储上也是须要对 Kubernetes 做很好的反对。
- 模块化即两头后果存储 / 传输 。计算工作模块化的场景，导致咱们会对两头后果的存储跟传输也有需要。举个简略的例子，在特色计算过程中会生成比拟大量的特色数据，这些数据会立即用于被训练的节点上，咱们须要一个两头存储介质去做缓存。
03 存储计划选型
非 POSIX 兼容计划
最后，咱们尝试了很多对象存储的计划，也就是非 POSIX 的计划。 对象存储有很强的扩容能力，而且老本十分的低，然而对象存储的问题也很显著。最大的问题就是没有 POSIX 兼容性 。对象存储的应用形式跟文件系统有比拟大的区别，如果把对象存储间接作为接口面向研究员，对他们来讲应用有很大的难度，便利性也有很大的限度。
除此之外，很多云厂商的对象存储有申请限度。例如，阿里云会对整个帐号的 OSS 带宽做限度。对于一般的业务场景这通常是能够承受的，然而突发性工作会在刹时产生十分大的带宽需要，仅仅应用对象存储很难去撑持这类场景。
另一个计划是 HDFS，咱们在 HDFS 下面并没有做太多测试。首先，咱们所采纳的技术栈对 Hadoop 没有太强的依赖；同时，HDFS 对 AI 训练的产品的反对并没有特地突出，而且 HDFS 没有残缺的 POSIX 兼容性，这对咱们的应用场景会有一些限度。
云上 POSIX 兼容计划
上文中提到的业务特点决定了咱们对 POSIX 兼容性有很强的需要，而且技术平台是基于私有云来进行的， 因此咱们将存储选型的范畴确定为：云上兼容 POSIX。
云厂商会提供一些计划，比方像阿里云的 NAS，AWS EFS 之类；另外一类是像阿里云的 CPFS 计划，AWS 的 FSx 计划。这两类文件系统的吞吐是与容量强绑定的，当容量越大的时候，吞吐会越大，跟 NAS 的存储性质是间接相干的。 这样的计划，在面对小量的热数据的时候不太敌对，须要额定的优化能力达到比拟好的体现 。另外 CPFS 或者阿里云上的极速型 NAS，对低延时的读取很敌对，但毛病是老本比拟高。
就各自官网展现的价格，咱们做了个比照。各类高性能 NAS 产品的老本大略是 1500-2000 元 /TB/ 月，JuiceFS 整体的老本会低很多，因为 JuiceFS 的底层存储是对象存储。JuiceFS 的老本分成这样几个局部：对象存储的存储费用；JuiceFS 云服务的费用；以及 SSD 缓存产生的老本。 综合来看，JuiceFS 的整体老本远低于 NAS 和其余计划的老本 。
在吞吐方面，晚期做了一些测试，当节点数量比拟少的时候，间接用 CPFS 跟做 JuiceF 比照，同时读取性能不会有很大的差别。 然而当节点数变大之后，因为 NAS 类文件系统有带宽限度，读取工夫整体都拉长了，而 JuiceFS 只有做好缓存集群的部署，能够十分轻松的撑持下来，并且没有太大的开销，下图场景是部署了总带宽约为 300Gb 左右的集群 。
除了老本和吞吐以外，在技术选型时，JuiceFS 对上文提到的性能 Full POSIX、权限管制、Qos、Kubernetes 都可能比拟好的反对；
值得一提的是 JuiceFS 的缓存集群能力，它可能实现灵便的缓存减速。最开始时，咱们应用计算节点做本地缓存，这是一个挺常见的做法。存算拆散之后，心愿计算节点有一些数据能够本地化，JuiceFS 这方面性能的反对是比较完善的，对于空间的占用、百分比的限度等都做得很欠缺。咱们部署了独立的缓存集群去服务一些热数据，只有在应用之前去做缓存预热就能够了。在应用过程中，咱们发现不同的计算集群资源的利用率差异很大，集群中有一些大带宽的机器，大部分时候都是用来做单节点的计算，这也就意味着机器的网络的资源基本上是没有怎么用到，而且还有一些闲置的磁盘，因而就在这些机器下来部署了缓存节点，把闲置的网络带宽给利用了起来。最终使得咱们在同一个集群中，实现了一个带宽十分大的缓存集群。
目前，JuiceFS 被用在了以下生产场景：
- 计算工作数据文件系统，被利用于热数据输出；
- 日志 / artifact 输入；
- Pipeline 数据直达：数据特色生成之后，须要直达到模型训练中，训练过程中也会有数据直达的需要，Fluid 和 JuiceFS 作为两头的缓存集群来应用。
将来，咱们将持续摸索云原生、AI 技术，用以进行更高效、平安的工具链研发和根底技术平台建设。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)
