- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
Clobotics 是一家将计算机视觉和机器学习技术应用于风电以及零售行业的企业。在风电行业,Clobotics 利用无人机对风力发电机叶片进行检查,显著降低了对人工作业的依赖。在零售领域,公司通过分析捕获的包装商品图像来提供基于实时数据的洞察,以增加销售额并减少运营成本.
存储方面,Clobotics 原本直接使用云 SDK,而部分系统则使用了内部的封装器,没有形成统一的存储层,同时还面临多云架构、海量小文件、兼容性方面的挑战。改造存储层的过程中, Clobotics 对 Ceph、SeaweedFS 和 JuiceFS 等文件系统方案进行了比较,最终选择使用 JuiceFS.
JuiceFS 支持接入几乎所有主要公有云平台,并能有效处理大量小文件的存储问题。其完全的 POSIX 兼容性允许我们在 JuiceFS 上实现整个数据流程,显著降低技术工程的工作量和成本.
目前,在 Clobotics 内部,风电和零售两个业务场景都已经接入 JuiceFS,涉及到业务访问,数据标注和模型训练场景,后续仍在扩展新的场景接入.
Clobotics 有两大业务模块,风电与零售。 下图是我们的技术架构图,在基础设施层面,我们采用了标准化的服务组件,包括配置中心(如 Apollo)、服务注册中心(如 Nacos)、以及监控、日志与告警系统等,这些系统主要依赖于业界广泛认可的开源组件,如利用 Elasticsearch 与 Grafana 进 行日志与监控数据的可视化展示,以及 Prometheus 作为监控指标的收集工具.
进一步向上,是通用服务层,其核心在于对各类资产数据的集中管理,涵盖了多领域,如风电行业的风机、零售行业的门店与超市,以及我们自有资产如无人机、零售用冷柜等。此外,IAM(身份认证与访问管理)系统负责用户权限的分配与管理,确保系统安全.
针对数据处理过程中不可避免的实时、准实时及批处理需求,我们设计并实施了统一的工作流与调度中心。此中心融合了 Apache Airflow 等开源组件,以应对批处理场景;同时,针对 Airflow 无法完全覆盖的特定需求,我们自行开发了定制化的服务以增强调度能力。在公共服务层面,我们特别抽离了 AI 模型服务,旨在实现 AI 能力的共享与复用.
我们的核心数据类型包括各类采集的图片,这些图片在规格、像素清晰度上差异显著。每月新增约 5000 万张原始采集图片,涵盖风电与零售两大领域,数据特点如下:
海量小文件: 风电场景下的图片原始文件可达十余兆,即便经过压缩处理,其体积依然不容忽视。此类图片在标注过程中需逐一细致查看,考虑到网络传输效率与标注工作的流畅性,我们采取了“Tile Image”技术,即将大图切分为类似地图瓦片的小图,以提高加载速度与查看效率。然而,这一方法也导致了文件数量的激增,特别是最底层的小图,其体积虽小但数量庞大。零售场景,我们每月需处理约 200 至 300 万个切图命令,高峰时可达 500 个以上.
二十多种类型模型训练:涵盖通用与垂直领域,迭代周期各异(周、月、季度),确保模型能够适应不同场景的需求.
元数据性能要求高:如 CSV 和 JS 文件,它们是 AI 模型训练过程中不可或缺的数据输入格式。此外,模型文件作为线上服务的关键组成部分,需频繁更新与迭代,且体积较大,对存储性能提出了更高要求.
针对新增数据的管理:随着新站点的不断加入,需定期更新或刷新这些数据,这一过程中会产生额外的 I/O 操作。同时,报告生成后需临时存储在特定位置,以便用户后续下载或分享.
版本管理:这是是我们不可忽视的一环,特别是针对原数据和图片数据集。在零售场景中,客户需求的快速变化要求我们对数据集进行精细化的版本控制。而在风电场景中,为实现对不同叶片叶形的精细化管理,数据集的切分与版本管理亦需更加细致 。
我们采用了多云存储解决方案,包括 Azure Blob Storage、阿里云 OSS、Google Cloud Storage(GCS)、Amazon S3,以及单机版或小集群模式的 MinIO。主要是源于不同客户环境的适应性需求.
由于不同客户所选择的云服务商各异,我们需要不断进行适配工作,以支持不同技术栈(如.NET、Go、Python、C++、Java等)下的数据访问需求,这无疑增加了架构的复杂性与运维的挑战。除此以外,由于风电与零售等业务平台在功能与场景上的差异性,我们不得不面对一定程度的重复开发工作,这对初创企业的研发资源构成了不小的压力.
再者,跨云架构,在进行数据标注、模型训练等操作时,需从多个云存储服务中拉取数据,这不仅增加了数据迁移的复杂性,还可能因频繁的数据读取而产生不必要的成本。因此,如何在保证数据一致性与安全性的同时,优化跨云数据存储与访问策略,成为我们亟待解决的问题.
鉴于我们场景的数据特点和以及多云架构给数据存储带来的挑战,我们重新审视并思考如何构建一个更为轻量、灵活的存储层架构。这一架构需要灵活应对不同业务场景下的数据存储需求,同时确保在引入新的云存储服务时,能够以极低的成本甚至无成本的方式实现快速接入.
在最初的选型过程中,我们充分考量了市场上主流及开源的存储解决方案。经过深入调研,我们首先将 HDFS 排除在外,尽管它在国内众多公司中被广泛应用。但针对我们的需求,其设计初衷更偏向于处理大数据量高吞吐的场景,而非我们面临的文件数量众多且需定期清理数据的情况。HDFS 的 NameNode 在文件数量激增时会承受巨大压力,且数据删除操作成本较高,加之其 POSIX 兼容性不足,因此不符合我们的要求.
Name | POSIX-compatible | CSI Driver | Scalability | Operation Cost | Document |
---|---|---|---|---|---|
HDFS | No | No | Good | High | Good |
Ceph | Yes | Yes | Medium | High | Good |
SeaweedFS | Basic | Yes | Medium | High | Medium |
GlusterFS | Yes | Not mature | Medium | Medium | Medium |
JuiceFS | Yes | Yes | Good | Low | Good |
随后,鉴于当前多数公司倾向于在 Kubernetes 上进行服务部署与运维,CSI Driver 成为了我们评估存储解决方案时的必要考量因素。我们当前的数据量仅为 700TB,并以较低的增长率增长,因此可扩展性并非我们的首要关注点。运维成本却是我们必须严格控制的,作为一家创业公司,我们希望在基础设施上尽量减少人力投入,以便集中资源于核心业务.
在评估 Ceph 时,我们发现其安装与部署相对简便,但运维成本较高,特别是在容量规划与扩容方面存在挑战,Ceph 的文档虽然丰富,但组织有一些杂乱,增加了上手难度.
SeaweedFS 作为一个表现不俗的开源项目,因同事有相关的运维经验而进入我们的视野,但最终还是因其运维成本较高及文档完善度不足而被放弃;GlusterFS 则因其轻量级的运维与扩容特性获得了一定关注,尽管自建存储层会带来一定的运维成本上升,但总体仍在可接受范围内.
最终,我们选择了 JuiceFS。JuiceFS 以其完全的 POSIX 兼容性和对云原生环境的支持吸引了我们的注意。在运维成本方面,JuiceFS 主要依赖于轻量级的元数据引擎,如 MySQL 或 Redis,这些均是我们现有技术栈中的组成部分,无需额外引入新组件,从而大大降低了运维复杂度。此外, JuiceFS 的文档清晰易懂,对于新手而言也能快速上手.
在选定 JuiceFS 作为我们的存储层解决方案后,我们的整体存储架构已逐步构建并优化至当前形态。在此我仅聚焦于我们实际应用的几个关键环节进行详细说明.
首先,在模型训练环节, FUSE 模块发挥着核心作用。模型训练需处理大量数据,且这些数据通常存储于云端,我们利用高性能的实体机搭配充足显卡资源,以满足模型训练的计算与调度需求。而所有模型训练任务均集中于单一高性能机器上执行。因此,我们采用 Fuse 挂载的方式,将云端不同存储源的数据同步至本地目录,形成本地可访问的存储空间。这一过程中,我们处理的最大单个训练数据集达到百万级别,数据稳定性高,主要用于零售场景下的快速识别模型训练.
其次,在资源管理与访问控制环节, CSI Driver 的应用则主要体现在以 Mount Pod方式进行。此方式简化了部署流程与Pod的组织结构,同时,通过内部调度器的精细控制,有效避免了不同Pod 间资源访问的冲突与并发读写问题。初期虽偶有死锁现象,但通过优化数据集管理与访问调度策略,现已实现高效的并发控制.
至于 S3 Gateway,其意外地成为我们选型 JuiceFS 后的又一重要收获。原本我们计划构建独立的文件服务以共享内部文件,但需面对复杂的权限与时效性问题。而 S3 Gateway 不仅提供了基于角色的权限控制,满足了我们的基本需求,还通过 Security Token 机制实现了对共享链接时效性的精细管理,有效防止了数据被恶意抓取的风险.
使用 JuiceFS 后所获得的收益如下:
在使用 JuiceFS 时,我们采取了以下几点策略以优化数据存储和管理:
独立实例架构便于数据隔离与合并:我们优先采用独立的实例架构,使用不同的元数据引擎来精确管理各种数据存储需求。这种方法比构建统一的大型存储集群更能减少复杂性和管理难题。考虑到不同客户数据间的隔离需求和不同通用场景下的数据合并挑战,我们将数据根据特性和用途分配到各自独立的实例中。这不仅便于针对特定领域如实验数据进行快速访问,也降低了数据恢复的难度和成本。在模型训练中,增加冗余节点和重试机制帮助快速恢复训练,减少对训练周期的影响.
数据集版本管理与隔离:我们通过多层目录结构和特定命名规范来管理数据版本,以应对零售等场景中商品包装频繁更新的挑战;并通过统一编码的前缀管理系统,确保在模型训练或数据读取时能够迅速定位到所需数据集的特定版本;同时,采用多层目录下的子节点排列组合,实现对不同数据集版本的高效管理与快速组合,提高了数据处理的灵活性和效率.
优化数据预热流程:目前,我们采取的方法是将 JuiceFS 挂载至本地,并通过拷贝方式将数据转移至模型训练的本地目录中,这一方式在初期实施时即被识别为效率较低。鉴于 JuiceFS 已提供诸如 caching 和 prefetch 等高级功能,我们计划深入调研并充分利用这些内置功能,以实现数据的智能缓存,从而更有效地管理数据集,提升数据访问速度.
跨地域数据访问的优化:在特定场景下,我们需访问位于欧洲的数据,而由于数据保护政策限制,这些数据不得被传输至欧洲以外地区。然而,临时访问是被允许的。当前,我们采用内部部署的 CDN 解决方案来应对这一需求,以控制成本并避免使用可能不够经济的原厂 CDN 服务。展望未来,我们期望能够利用 JuiceFS 的缓存机制,实现短时数据的共享与高效访问,以进一步优化跨地域数据处理的流程.
部署多个 JuiceFS 实例:我们将进行深入的调优与优化工作。通过精细调整配置参数、优化资源分配以及监控性能表现,我们旨在进一步提升系统的整体效能与稳定性,确保 JuiceFS 能够持续高效地支持我们的业务需求.
最后此篇关于Clobotics计算机视觉场景存储实践:多云架构、POSIX全兼容、低运维的统一存储的文章就讲到这里了,如果你想了解更多关于Clobotics计算机视觉场景存储实践:多云架构、POSIX全兼容、低运维的统一存储的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我正在运行一个辅助角色,并检查 Azure 上托管的存储中是否存在数据。当我将连接字符串用于经典类型的存储时,我的代码可以正常工作,但是当我连接到 V2 Azure 存储时,它会抛出此异常。 “远程服
在我的应用程序的主页上,我正在进行 AJAX 调用以获取应用程序各个部分所需的大量数据。该调用如下所示: var url = "/Taxonomy/GetTaxonomyList/" $.getJSO
大家好,我正在尝试将我的商店导入我的 Vuex Route-Gard。 路由器/auth-guard.js import {store} from '../store' export default
我正在使用 C# 控制台应用程序 (.NET Core 3.1) 从 Azure Blob 存储读取大量图像文件并生成这些图像的缩略图。新图像将保存回 Azure,并将 Blob ID 存储在我们的数
我想将 Mlflow 设置为具有以下组件: 后端存储(本地):在本地使用 SQLite 数据库存储 Mlflow 实体(run_id、params、metrics...) 工件存储(远程):使用 Az
我正在使用 C# 控制台应用程序 (.NET Core 3.1) 从 Azure Blob 存储读取大量图像文件并生成这些图像的缩略图。新图像将保存回 Azure,并将 Blob ID 存储在我们的数
我想将 Mlflow 设置为具有以下组件: 后端存储(本地):在本地使用 SQLite 数据库存储 Mlflow 实体(run_id、params、metrics...) 工件存储(远程):使用 Az
我的 Windows 计算机上的本地文件夹中有一些图像。我想将所有图像上传到同一容器中的同一 blob。 我知道如何使用 Azure Storage SDKs 上传单个文件BlockBlobServi
我尝试发出 GET 请求来获取我的 Azure Blob 存储帐户的帐户详细信息,但每次都显示身份验证失败。谁能判断形成的 header 或签名字符串是否正确或是否存在其他问题? 代码如下: cons
这是用于编写 JSON 的 NeutralinoJS 存储 API。是否可以更新 JSON 文件(推送数据),而不仅仅是用新的 JS 对象覆盖数据。怎么做到的??? // Javascript
我有一个并行阶段设置,想知道是否可以在嵌套阶段之前运行脚本,所以像这样: stage('E2E-PR-CYPRESS') { when { allOf {
我想从命令行而不是从GUI列出VirtualBox VM的详细信息。我对存储细节特别感兴趣。 当我在GUI中单击VM时,可以看到包括存储部分在内的详细信息: 但是到目前为止,我还没有找到通过命令行执行
我有大约 3500 个防洪设施,我想将它们表示为一个网络来确定流动路径(本质上是一个有向图)。我目前正在使用 SqlServer 和 CTE 来递归检查所有节点及其上游组件,只要上游路径没有 fork
谁能告诉我 jquery data() 在哪里存储数据以及何时删除以及如何删除? 如果我用它来存储ajax调用结果,会有性能问题吗? 例如: $("body").data("test", { myDa
有人可以建议如何为 Firebase 存储中的文件设置备份。我能够备份数据库,但不确定如何为 firebase 存储中的文件(我有图像)设置定期备份。 最佳答案 如何进行 Firebase 存储的本地
我最近开始使用 firebase 存储和 firebase 功能。现在我一直在开发从功能到存储的文件上传。 我已经让它工作了(上传完成并且文件出现在存储部分),但是,图像永远保持这样(永远在右侧加载)
我想只允许用户将文件上传到他们自己的存储桶中,最大文件大小为 1MB,仍然允许他们删除文件。我添加了以下内容: match /myusers/{userId}/{allPaths=**} { al
使用生命周期管理策略将容器的内容从冷访问层移动到存档。我正在尝试以下策略,希望它能在一天后将该容器中的所有文件移动到存档层,但事实并非如此在职的。我设置了选择标准“一天未使用后”。 这是 json 代
对于连接到 Azure 存储端点,有 http 和 https 两个选项。 第一。 https 会带来开销,可能是 5%-10%,但我不支付同一个数据中心的费用。 第二。 http 更快,但 Auth
有人可以帮我理解这一点吗?我创建了Virtual Machine in Azure running Windows Server 2012 。我注意到 Azure 自动创建了一个存储帐户。当我进入该存
我是一名优秀的程序员,十分优秀!