共计 4559 个字符，预计需要花费 12 分钟才能阅读完成。
公司简介
杭州知衣科技有限公司是一家以人工智能技术为驱动的国家高新技术企业，致力于将数据化趋势发现、爆款开掘和供应链组织能力标准化输入，打造智能化服装设计的供应链平台。知衣成立于 2018 年 2 月，同年取得千万美金 A 轮融资；2021 年实现由高瓴创投、万物资本事投的 2 亿人民币 B 轮融资，同年入围“杭州市准独角兽企业榜单”。
知衣凭借图像识别、数据挖掘、智能举荐等核心技术能力，一直降级服务体系，自主研发了知衣、知款、美念等一系列服装行业数据智能 SaaS 产品，为服装企业和设计师提供风行趋势预测、设计赋能、样式智能举荐等外围性能，并通过 SaaS 入口向产业链上游拓展，提供一站式设计 + 柔性生产的供应链平台服务。目前已服务 UR、唯品会、绫致、赫基、太平鸟、海澜之家、森马等数千家时尚品牌和平台。
计划架构
以后知衣在阿里云上的整体计划架构如下，大抵分为产品层、服务层、数据层以及大数据平台。
- 产品层：知衣目前有多款 APP 利用，如主打产品 知衣 、加强设计合作的 美念 等。除此之外，咱们还提供定制化 API 向第三方凋谢数据接口服务和以图搜图的性能。从数字选款到大货成品交付的一站式服装供应链平台也是外围的能力输入。
- 服务层：相干产品的前后端系统都曾经实现容器化，部署在阿里云的 ACK 容器服务集群
- 数据层：次要保留原始图片、业务零碎产生的业务数据、以及 OLAP 数据分析服务
<!—->
- 对象存储 OSS：保留原始图片，构建服装行业十亿级别样式库
- 数据库 MySQL：OLTP 业务数据
- HBase：以 KV 格局拜访的数据，如商品详细信息、离线计算榜单等数据
- 特征向量库：由图片辨认抽取的向量再通过荡涤后保留在阿里达摩院开发的 Proxima 向量检索引擎库
- ElasticSearch：用于点查及中小规模数据的指标统计计算。设计元素标签超过 1000 个，标签维度次要有品类、面料、纹理、工艺、辅料、格调、廓形、领型、色彩等
<!—->
- 大数据平台
<!—->
- 日志服务 SLS：用于缓存通过图片辨认后的海量向量数据。SLS 还有一个基于 SQL 查问的告警能力，就是若向量数据没有进来会触发告警，这对于业务及时发现问题十分有用。
- 离线数仓（DataWorks + MaxCompute）：通过 DataWorks 集成缓存了图片特征向量的日志服务作为数据源，而后创立数据开发工作对原始特征向量进行荡涤（比方去重等）保留在 MaxCompute，再通过 DataWorks 将 MaxCompute 荡涤后的向量数据间接写入 ElasticSearch 的 Proxima
- 数据挖掘 & 算法举荐：部署在 ACK 里的一些 Python 工作，次要做举荐相干的内容，比方用户特色 Embedding 计算、基于用户行为的样式图片的举荐、相似性博主的举荐等
- 图片辨认服务：目前图片辨认服务次要还是部署在 IDC 机房，5~6 台 GPU 服务器对图片进行批量辨认
大数据计划演进
知衣的大数据计划也是通过不同的阶段一直的演进，满足咱们在老本、效率和技术方面的谋求，实质上还是服务于业务需要。
阶段一：IDC 自建 CDH 集群
咱们的业务零碎一开始就部署在阿里云，同时在 IDC 机房部署了 10 台服务器搭建 CDH 集群，构建 Hive 数仓。计算过程是先将云上生产环境数据同步到 CDH，在 CDH 集群进行计算后将计算结果再回传到阿里云上提供数据服务。
自建 CDH 集群尽管节俭了计算费用，然而也带来不少问题。最次要的就是运维比较复杂，须要业余的人员进行集群的运维治理。呈现问题也是在网上到处搜寻排查起因，效率比拟低。
阶段二：DataWorks + MaxCompute 替换 CDH 集群
为了升高运维复杂度，咱们将计算工作迁徙到 MaxCompute，间接基于 DataWorks 做工作编排调度。
阶段三：ElasticSearch 构建即席查问
知款聚焦于疾速发现时尚趋势灵感，集成了社交平台、品牌秀场、批发及批发市场、淘系电商、时尚街拍五大图源，海量的设计灵感参考，帮忙服装品牌及设计师疾速精确地预判时尚风向，把握市场动态。其中趋势剖析板块就须要对某个季度下各种组合条件下的设计因素标签进行统计分析，并输入回升、降落以及饼图等指标。这也是咱们数据量最大的查问场景，扫描剖析的数据量量级会靠近百万。
阿里云托管版 ElasticSearch 相比拟开源版本最大长处就是开箱即用免运维，特地的就是反对达摩院的 Proxima 向量检索引擎，非常适合咱们业务的多维查问和统计分析场景。前面会在图片辨认开展讲述 Proxima 向量引擎。
图片辨认
咱们的外围性能场景是以图搜图，前提是须要对海量的图片库数据进行辨认。咱们以离线的形式对图片库的所有图片进行机器学习剖析，将每一幅图形象成高维（256 维）特征向量，而后将所有特色借助 Proxima 构建成高效的向量索引。
模型训练
图片辨认之前须要训练模型。由业余的服务行业背景的人员对图片库进行标注，而后线下部署的 GPU 集群从阿里云对象存储 OSS 批量拉取已标注的图片进行训练。为了升高标注的老本，咱们采纳了被动学习（Active Learning）办法，即基于一部分已标注的图片由机器学习训练出一个模型，而后对未标注的图片进行预测，让人工对预测后果再次进行确认和审核，再将标注的数据应用监督学习模型持续进行模型训练，逐渐晋升模型成果。
批量图片辨认
模型生成当前打包到 Docker 镜像，而后在 GPU 节点上运行容器服务就能够对海量的服装图片进行辨认，提取出高维的特征向量。因为提取的特征向量数据量很大且须要进行荡涤，咱们抉择将特征向量先缓存在阿里云日志服务 SLS，而后通过 DataWorks 编排的数据开发工作同步 SLS 的特征向量并进行蕴含去重在内的荡涤操作，最初写入向量检索引擎 Proxima。
因为一次批量辨认图片的工作量很大，线下的 GPU 服务器计算性能有瓶颈，所以咱们就借助云上弹性的 GPU 资源做计算资源的补充。线下 GPU 和云上 GPU 组成一个计算资源池，独特生产同一批须要进行图片辨认的计算工作，效率大大晋升。云上咱们购买的是 GPU 抢占式实例，个别是按量价格的 2~3 折，能够进一步降低成本。
单次图片辨认
咱们以在线 serving 的模式在 web 前端提供单次单张图片辨认性能，比方用户上传一张图片，通过模型的推理输入如下后果。
以图搜图
构建好服装图片的特征向量库，咱们就能够实现以图搜图的性能。当用户上传一张新图片的时候，咱们用之前的机器学习办法对其进行剖析并产出一个表征向量，而后用这个向量在之前构建的向量索引中查找出最类似的后果，这样就实现了一次以图片内容为根底的图像检索。抉择适合的向量检索引擎十分重要。
Faiss
Faiss (Facebook AI Similarity Search) 是 Facebook AI 团队开源的向量检索库引擎。初期咱们也是抉择 Faiss 部署分布式服务，在多台 GPU 服务器上部署特征向量搜寻匹配服务，将搜寻申请散发到每台 GPU 子服务进行解决，而后将 TOP N 的类似后果数据汇总返回给调用方。
在应用 Faiss 的过程中，咱们也遇到了理论的艰难。当然这并不是 Faiss 自身的问题，而是须要投入更多人力开发运维分布式系统能力匹配业务需要。
- 稳定性较差：分布式 GPU 集群有 5~6 台，当某一台机器挂了会拉长整个接口响应工夫，业务的体现就是搜图服务等很久才有后果返回。
- GPU 资源有余：咱们采纳的是最根底的暴力匹配算法，2 亿个 256 维特征向量须要全副加载到显存，对线下 GPU 资源压力很大。
- 运维老本高：特色库分片齐全手动运维，治理比拟繁琐。数据分片分布式部署在多个 GPU 节点，增量分片数据超过 GPU 显存，须要手动切片到新的 GPU 节点。
- 带宽争抢：图片辨认服务和以图搜图服务都部署在线下机房，共享 300Mb 机房到阿里云的专线带宽，批量图片辨认服务占用大带宽场景下会间接导致人机交互的图搜响应工夫缩短。
- 特定场景下召回后果集有余：因为特色库比拟大，咱们人工将特色库拆成 20 个分片部署在多台 GPU 服务器上，但因为 Faiss 限度每个分片只能返回 1024 召回后果集，不满足某些场景的业务需要。
Proxima
Proxima 是阿里达摩院自研的向量检索引擎（https://developer.aliyun.com/…），实现了对大数据的高性能相似性搜寻，也集成在咱们之前在用的阿里云托管版的 ElasticSearch。性能和性能上与 Faiss 相比各有千秋，次要是针对 Faiss 应用上的艰难，ElasticSearch + Proxima 帮忙咱们解决了。
- 稳定性高：开箱即用的产品服务 SLA 由阿里云保障，多节点部署的高可用架构。到目前为止，极少碰到接口超时问题
- 算法优化：基于图的 HNSW 算法不须要 GPU，且与 Proxima 集成做了工程优化，性能有很大的晋升（1000 万条数据召回只须要 5 毫秒）。目前业务倒退特征向量曾经增长到 3 亿。
- 运维成本低：分片基于 ES 引擎，数据量大的状况下间接扩容 ElasticSearch 计算节点就能够
- 无带宽争抢：以图搜图的服务间接部署在云上，不占用专线带宽，图搜场景下没有再呈现超时查问告警
- 召回后果集满足业务需要：Proxima 也是基于 segment 分片取 Top N 类似，聚合后再依据标签进行过滤。因为 segment 较多，能搜寻到的数据量就比原先多很多。
技术架构降级瞻望
OLAP 剖析场景优化迭代
随着数据量的一直增长以及业务需要的一直变动，OLAP 剖析场景越来越简单，对算法和技术计划选型要求越来越高。举个业务场景的例子
10 万博主公布的图片数量有 1 亿多，用户能够对博主进行关注订阅，关注下限是 2000 个博主。用户关注的 2000 个博主对应的图片量级会在 200 万左右。须要对用户关注的图片进行实时多条件统计分析（每个用户关注博主不同）
以上例子在应用 ElasticSearch 实现查问的时候须要 9 秒，显然不满足业务须要。那有没有更好的计划呢？近期在调研完 Clickhouse 之后，对数据进行预处理产生大宽表再查问，查问时延曾经升高到 2 秒以内，很好的满足了业务需要。阿里云托管版的 Clickhouse 开箱即用，升高业务试错老本，帮忙咱们疾速响应业务需要。
标准数据建模和数据治理
目前 DataWorks 次要是用来做数据集成和任务调度，也有些大量的基于规定判断数据品质，团队外部的约定更多的是文档化的开发标准，不足一些无效工具的辅助。随着业务场景越来越简单，集成的数据源越来越丰盛，数据开发人员也越来越多，制订全副门对立的开发标准十分必要。DataWorks 的数据建模通过工具和流程建设数据规范，能够实现结构化有序的对立治理。数据治理模块能够通过配置查看项检测不合乎数据标准的开发流程，基于多项治理项的衰弱分度量我的项目衰弱度以及治理功效。目前咱们正在联合本人的业务试用数据建模和数据治理，期待能帮忙咱们更好的治理数据，实现数据价值的最大化。【倡议替换数据建模和数据治理的图】
图搜计划进阶单干
在服装行业畛域图片辨认和以图搜图是咱们的外围竞争力。阿里云机器学习 PAI 也提供了类似图匹配的图像检索解决方案（https://help.aliyun.com/docum…）只须要配置原始图像数据，无需标注就能够在线构建模型，这点对咱们来说比拟有吸引力，后续能够思考进行测试比照，开展在服装图片建模畛域的单干。
