【推荐系统】深度解析京东个性化推荐系统演进史

2017 年 12 月 8 日 产业智能官 人工智能头条

在电商领域，推荐的价值在于挖掘用户潜在购买需求，缩短用户到商品的距离，提升用户的购物体验。

京东推荐的演进史是绚丽多彩的。京东的推荐起步于2012年，当时的推荐产品甚至是基于规则匹配做的。整个推荐产品线组合就像一个个松散的原始部落一样，部落与部落之前没有任何工程、算法的交集。2013年，国内大数据时代到来，一方面如果做的事情与大数据不沾边，都显得自己水平不够，另外一方面京东业务在这一年开始飞速发展，所以传统的方式已经跟不上业务的发展了，为此推荐团队专门设计了新的推荐系统。

随着业务的快速发展以及移动互联网的到来，多屏（京东App、京东PC商城、M站、微信手Q等）互通，推荐类型从传统的商品推荐，逐步扩展到其他类型的推荐，如活动、分类、优惠券、楼层、入口图、文章、清单、好货等。个性化推荐业务需求比较强烈，基于大数据和个性化推荐算法，实现向不同用户展示不同内容的效果。

为此，团队于2015年底再次升级推荐系统。2016年618期间，个性化推荐大放异彩，特别是团队开创的“智能卖场”，实现了活动会场的个性化分发，不仅带来GMV的明显提升，也大幅降低了人工成本，大大提高了流量效率和用户体验，从而达到商家和用户双赢，此产品获得了2016年度的集团优秀产品。为了更好地支撑多种个性化场景推荐业务，推荐系统一直在迭代优化升级，未来将朝着“满屏皆智能推荐”的方向发展。

推荐产品

用户从产生购买意向，到经历购买决策，直至最后下单的整个过程，在任何一个购物链路上的节点，推荐产品都能在一定程度上帮助用户决策。

多屏多类型产品形态

多类型主要指推荐类型覆盖到多种类型，如商品、活动、分类、优惠券、楼层、入口图、文章、清单、好货等。在移动互联时代，多屏场景非常普遍，整合用户在多屏的信息，能使个性化推荐更精准。多屏整合的背后技术是通过前端埋点，用户行为触发埋点事件，通过点击流系统进行多屏的行为信息收集。这些行为数据通过实时流计算平台来计算用户的兴趣偏好，从而根据用户兴趣偏好对推荐结果进行重排序，达到个性化推荐的效果。京东多屏终端如图2所示。

图2　京东多屏终端

推荐系统架构

整体业务架构

推荐系统的目标是通过全方位的精准数据刻画用户的购买意图，推荐用户有购买意愿的商品，给用户最好的体验，提升下单转化率，增强用户黏性。推荐系统的业务架构如图3所示。

图3　推荐系统的业务架构

系统架构。对外提供统一的HTTP推荐服务，服务京东所有终端的推荐业务。
模型服务。为了提高个性化的效果而开发的一系列公共的个性化服务，用户维度有用户行为服务和用户画像服务，商品维度有商品画像，地域维度有小区画像，特征维度有特征服务。通过这些基础服务，让个性化推荐更简单、更精准。
机器学习。算法模型训练阶段，尝试多种机器学习模型，结合离线测评和在线A/B，验证不同场景下的算法模型的效果，提高推荐的转化率。
数据平台。数据是推荐的源泉，包括数据收集和数据计算。数据虽然是整体推荐架构的最底层，却是非常重要的，因为数据直接关系到推荐的健康发展和效果提升。

个性化推荐架构

在起步初期，推荐产品比较简单，每个推荐产品都是独立服务实现。新版推荐系统是一个系统性工程，其依赖数据、架构、算法、人机交互等环节的有机结合。新版推荐系统的目标，是通过个性化数据挖掘、机器学习等技术，将“千人一面”变为“千人千面”，提高用户忠诚度和用户体验，提高用户购物决策的质量和效率；提高网站交叉销售能力，缩短用户购物路径，提高流量转化率（CVR）。目前新版推荐系统支持多类型个性化推荐，包括商品、店铺、品牌、活动、优惠券、楼层等。新版个性化推荐系统架构如图4所示。

图4　新版个性化推荐系统架构

个性化推荐系统架构图中不同的颜色代表不同的业务处理场景：数据处理部分（最底层绿色模块），包括离线数据预处理、机器学习模型训练，以及在线实时行为的接入、实时特征计算。推荐平台（蓝色模块），主要体现响应用户请求时推荐系统的各服务模块之间的交互关系。推荐系统核心模块：

推荐网关。推荐服务的入口，负责推荐请求的合法性检查、请求分发、在线Debug 以及组装请求响应的结果。
调度引擎。负责推荐服务按策略调度及流量分发，主要根据配置中心的推荐产品的实验配置策略进行分流，支持按用户分流、随机分流和按关键参数分流。支持自定义埋点，收集实时数据；支持应急预案功能，处理紧急情况，秒级生效。
推荐引擎。负责推荐在线算法逻辑实现，主要包括召回、过滤、特征计算、排序、多样化等处理过程。
个性化基础服务。目前主要个性化基础服务有用户画像、商品画像、用户行为、预测服务。用户画像包括用户的长期兴趣、短期兴趣、实时兴趣。兴趣主要有性别、品牌偏好、品类偏好、购买力等级、自营偏好、尺码颜色偏好、促销敏感度、家庭情况等。商品画像主要包括商品的产品词、修饰词、品牌词、质量分、价格等级、性别、年龄、标签等。用户行为主要获取用户近期行为，包括用户的搜索、点击、关注、加入购车、下单等。预测服务主要是基于用户的历史行为，使用机器学习训练模型，用于调整召回候选集的权重。
特征服务平台。负责为个性服务提供特征数据和特征计算，特征服务平台主要针对特征数据，进行有效的声明、管理，进而达到特征资源的共享，快速支持针对不同的特征进行有效的声明、上线、测试以及A/B实验效果对比。

个性化技术（橙色模块），个性化主要通过特征和算法训练模型来进行重排序，达到精准推荐的目的。特征服务平台主要用于提供大量多维度的特征信息，推荐场景回放技术是指通过用户实时场景特征信息反馈到推荐排序，在线学习（Online-Learning）和深度学习都是大规模特征计算的个性化服务。

个性化推荐系统的主要优势体现为支持多类型推荐和多屏产品形态，支持算法模型A/B实验快速迭代，支持系统架构与算法解耦，支持存储资源与推荐引擎计算的解耦，支持预测召回与推荐引擎计算的解耦，支持自定义埋点功能；推荐特征数据服务平台化，支持推荐场景回放。

数据平台

京东拥有庞大的用户量和全品类的商品以及多种促销活动，可以根据用户在京东平台上的行为记录积累数据，如浏览、加购物车、关注、搜索、购买、评论等行为数据，以及商品本身的品牌、品类、描述、价格等属性数据的积累，活动、素材等资源的数据积累。这些数据是大规模机器学习的基础，也是更精确地进行个性化推荐的前提。

数据收集

用户行为数据收集流程一般是用户在京东平台（京东App、京东PC网站、微信手Q）上相关操作，都会触发埋点请求点击流系统（专门用于收集行为数据的平台系统）。点击流系统接到请求后，进行实时消息发送（用于实时计算业务消费）和落本地日志（用于离线模型计算），定时自动抽取行为日志到大数据平台中心。算法人员在数据集市上通过机器学习训练模型，这些算法模型应用于推荐服务，推荐服务辅助用户决策，进一步影响用户的购物行为，购物行为数据再发送到点击流，从而达到数据收集闭环。

离线计算

目前离线计算平台涉及的计算内容主要有离线模型、离线特征、用户画像、商品画像、用户行为，离线计算主要在Hadoop上运行MapReduce，也有部分在Spark平台上计算，计算的结果通过公共导数工具导入存储库。团队考虑到业务种类繁多、类型复杂以及存储类型多样，开发了插件化导数工具，降低离线数据开发及维护的成本。数据离线计算架构如图5所示。

图5　数据离线计算架构

在线计算

目前在线计算的范围主要有用户实时行为、用户实时画像、用户实时反馈、实时交互特征计算等。在线计算是根据业务需求，快速捕捉用户的兴趣和场景特征，从而实时反馈到用户的推荐结果及排序，给用户专属的个性化体验。在线计算的实现消息主要来源于Kafka集群的消息订阅和JMQ消息订阅，通过Storm集群或Spark集群实时消费，推送到Redis集群和HBase集群存储。数据在线计算框架如图6所示。

图6　数据在线计算架构

关键技术

推荐系统涉及的技术点比较多，考虑到篇幅有限，这里重点介绍个性化推荐中比较重要的部分。

用户画像

京东大数据有别于其他厂商的地方就是京东拥有最长的价值链和全流程的数据积累。京东数据的特征非常全面，数据链记录着每个用户的每一步操作：从登录到搜索、浏览、选择商品、页面停留时间、评论阅读、是否关注促销，以及加入购物车、下订单、付款、配送方式，最终是否有售后和返修，整个用户的购物行为完整数据都被记录下来。通过对这些用户行为及相关场景的分析，构建了京东用户画像，如图10所示。

其中不仅有用户的年龄、性别、购物习惯，更有根据其购物行为分析出的大量数据，例如是否已婚，是否有孩子，对促销是否敏感等。另外，实时用户画像可以秒级分析出用户的购买意图，以及实时兴趣偏好。京东推荐用户画像技术体系如图11所示。

用户画像在京东各终端的推荐产品中都有应用，618推出的智能卖场是用户画像的典型应用场景。智能卖场的产品包括发现好货、个性化楼层、秒杀、活动、优惠券、分类、标签等。以秒杀为例，推荐结果会根据当前用户的用户画像中的画像模型（性别、年龄、促销敏感度、品类偏好、购买力）进行加权，让用户最感兴趣的商品排在前面。

用户画像也是场景推荐的核心基础。以东家小院为例，根据用户的历史行为汇聚出很多场景标签，按当前用户的画像模型，调整场景标签的排序。如用户选择“包治百病”标签，会按用户画像中的性别、年龄、品类、促销敏感度等画像模型进行推荐商品的重排序。

图10　用户画像示意图

图11　京东推荐用户画像技术体系

特征服务平台

特征就是一种属性的描述，特征是个性化推荐的基础，常用的特征分为单边特征和双边特征。单边特征是指对象本身的属性描述，如商品的颜色；双边特征是指两个对象交互程度的描述，如某用户最近一小时浏览的品牌与候选集中品牌的匹配程度。从特征生成的场景来说，分为离线特征和实时特征。离线特征是通过算法模型提前生成，实时特征是通过实时计算的方式生成的。特征的质量直接影响推荐的效果、特征计算的性能，同时影响个性化推荐的处理能力。另外，共享和复用特征可以提高算法的迭代速度并节约人力成本。

特征服务管理平台主要针对特征数据和特征计算，进行有效声明和管理，进而达到特征资源的共享和复用。特征服务平台能快速满足针对制定不同的特征进行有效的声明、上线、测试以及A/B实验效果对比的需求，做到特征的可维护、可说明、可验证。特征服务平台的主要功能如下：离线特征的定制化使用，在线特征的定制化使用，由定制化特征产生新的特征，部分特征、模型在线申明，不同特征效果快速A/B。特征服务平台架构如图12所示。

图12　特征服务平台架构

场景特征回放技术

推荐的一般处理逻辑是每次请求会召回一批商品，然后根据用户的行为数据和用户模型计算出每个商品的特征。算法模型会根据每个商品的特征计算出每个商品的得分，最后选出得分最高的几个商品推荐给用户。

线上计算特征这种行为是一次性的，不会被记录下来。因此在线下训练模型的时候，如果想利用上述的特征，就需要在线下机器上再次计算一遍这些特征。遗憾的是，线下计算出来的特征往往不能和线上特征完全相同，这就导致了模型训练的效果较差。场景特征回放示意图如图13所示，推荐业务调用推荐引擎，推荐引擎将场景特征通过特征回放服务记录下来，推送至大数据平台，机器学习根据场景特征数据重新训练算法模型，进而影响推荐引擎中的排序，形成一个场景闭环推荐，达到更准确的个性化推荐。

图13　场景特征回放示意图

场景特征回放技术架构如图14所示，场景特征回放技术实现过程如下。线上特征一般是一系列的数值，我们将这些特征按照一定的规则组装成一个字符串，然后将特征使用HTTP的POST方法异步发送到服务端。

图14　场景特征回放技术架构

服务端使用Openresty接收这些HTTP请求，并把HTTP请求中的特征数据落地到本地磁盘文件中。Openresty是一种高性能的Web服务器，能够承受很高的QPS，并且具有很高的稳定性，它的这两点特性保障了服务的稳定。

数据抽取系统把服务器集群磁盘上的数据抽取到临时仓库。

数据抽取系统对数据进行压缩和过滤处理，然后推送到Hive表中。不同类型的请求会放到不同的分区中，更加方便算法工程师使用这些数据。

个性化推荐系统是一个系统工程，依赖产品、数据、架构、算法、人机交互等进行场景推荐，本节重点从这几个维度阐述了京东的个性化推荐系统。推荐系统随着业务发展和社会生活方式的改变而进行不断升级，经历了从PC时代到移动互联时代，从关联推荐走向个性化推荐，从纯商品推荐到多类型推荐的转变。个性化推荐系统已经实现了千人千面。诚然，个性化的效果也有待提升，有些体验类的问题也在逐步完善。目前正在进行或有待提高的方面包括：算法方面丰富知识图谱、深度学习广泛应用；推荐系统方面会更好地支持海量召回、高维特征计算、在线学习，推荐更实时，更精准；产品方面已向“满屏皆智能推荐”方向迈进。最后，希望个性化推荐系统能让购物变得简单，变得更人性化、更丰富、更美好。

作者简介：fisherman，时任推荐部门推荐系统负责人，负责推荐部门的架构设计及相关研发工作。Davidxiaozhi，时任推荐部门推荐系统架构师，负责推荐系统的架构设计和系统升级。

编者按：文章摘自《决战618：探秘京东技术取胜之道》，本书从前端的网站、移动入口到后端的结算、履约、物流、供应链等体系，系统展示了京东全新的技术成就。同时，也涵盖了京东正在充分运用大数据、人工智能等先进技术对所有技术体系架构进行整体改造，使其始终保障技术的先进性的方法，以及京东对未来科技发展的积极探索和展望。

深度解密京东登月平台基础架构

来源：CSDN云计算

“

近日，京东发布登月机器学习平台，并在京东云上线，正式对外提供人工智能服务。登月机器学习平台的上线代表着京东人工智能技术从应用级服务到基础算法的全面对外开放，实践着京东RaaS（零售即服务）的发展策略。今天我们邀请了AI与大数据部的工程师为大家深度解密京东登月平台基础架构。

”

从2016年9月开始，京东AI基础平台部基于Kubernetes和Docker构建机器学习平台的底层架构，后续逐步完善和优化了网络、GPU管理、存储、日志、监控、权限管理等功能。目前集群管理的容器实例数量有5K+，至今已上线运行了20多个AI前向服务（50多个API），同时为后向训练提供支持，在618大促中表现高效稳定。

架构

登月平台的基础架构以Docker+Kubernetes为中心，底层基础设施包括CPU、GPU、FPGA计算资源，IB、OPA高速互联网络以及多样化的文件系统，之上是机器学习框架和算法库，最上层是业务应用。管理中心包括权限管理、任务管理、流程管理、监控中心、日志中心。

平台整体设计思想是Kubernetes调度一切，应具有以下特性（为了方便起见所有的inference类型的应用我们称为App，所有training类型的应用我们称为Job）：

高可用、负载均衡。大量的inference App运行在容器中，需要保证App能够稳定高效的对外提供服务。

应用打包与隔离。研究人员、开发人员将自己的代码打包成image，方便的进行CI/CD，透明的将自己的App运行于平台中。

自动扩容/缩容，training/inference用同一批机器调度。白天有许多活跃的用户，平台应该扩展更多inference App，而到了晚上，应该将更多的资源分配给training Job。

作为大数据调度平台。平台不仅可以原生的调度Tensorflow/Caffe/XGBoost/MXNet等机器学习、深度学习工具包，也应该将Hadoop/Spark系列的大数据生态系统调度在Kubernetes中。

支持丰富的硬件资源类型。根据不同的App，Job类型，应该使用不同的硬件资源以提高加速比，平台不仅需要支持CPU、GPU，还应该支持FPGA，InfiniBand，OPA等专用高速计算资源。

最大化利用整个集群资源。显而易见，对于平台来说已经不再区分是inference App还是training Job，所有的计算资源都统一在一个大的资源池中。

推行数据隔离架构，保证数据安全。通过网络优势将数据和计算进行分离，提供更高级别的数据access权限。

多租户安全保证。平台接入公有云，需要支持multi-tenancy的架构，不同的用户共享计算资源的池子，但是彼此在网络级别、文件系统级别、Linux内核级别都相互隔离。

登月平台架构

网络

Kubernetes自身不具备网络组件，需要使用第三方网络插件实现。前期我们调研了Flannel、Weave、Calico三种容器网络，并做了性能对比测试。由于Flannel、Weave都是overlay网络，均采用隧道方式，网络通信包传输过程中都有封包拆包处理，因此性能大打折扣；而Calico基于BGP路由方式实现，没有封包拆包和NAT，性能堪比物理机网络。

另外，Calico是纯三层的数据中心解决方案，主机之间二层通信使用的是物理机的MAC地址，避免了ARP风暴。除了路由方式，Calico也支持IPIP的隧道方式；如果使用BGP方式，需要机房的网络设备开启BGP功能。

公有云上需要解决的一个重要问题就是多租户网络隔离，我们使用了Kubernetes自身的NetworkPolicy和Calico的网络策略实现。给每个用户分配一个单独的Namespace，Namespace内部的Pod间可以通信，但Namespace之间的Pod不允许通信。Kubernetes的NetworkPolicy只支持对“入流量”（ingress）作限制，而Calico的网络策略作了更多的扩展，支持对“出流量”（egress）作限制，而且还具备更精细的规则控制，如协议、端口号、ICMP、源网段、目的网段等。

大部分容器网络给容器分配的IP只对集群内部可见，而登月平台上很多前向服务对外提供RPC接口，需要将容器IP暴露到集群外部。经调研之后选用了Cisco开源的Contiv项目，它的底层原理是用OVS打通了容器的跨主机通信，我们使用的是它的VLAN模式，相对于基于隧道技术实现的overlay网络来说，这是underlay网络，它不是构建于物理机的网络之上，而是与物理机位于同一网络层面，这种网络的性能接近于物理网络。

存储

Kubernetes本身不提供存储功能，而是通过存储插件与第三方存储系统实现，Kubernetes支持二十多种存储后端，我们选用了Glusterfs。

Glusterfs是面向文件的分布式存储系统，架构和部署都很简单，社区版已经足够稳定，它的特点是：弹性、线性横向扩展、高可靠。Glusterfs在架构上消除了大多数文件系统对元数据服务的依赖，取而代之的是以弹性哈希算法实现文件定位，优化了数据分布，提高了数据访问并行性，极大地提升了性能和扩展性。

Kubernetes的Volume支持静态分配和动态分配两种方式。静态分配指的是由管理员手动添加和删除后端存储卷，动态分配则是使用Kubernetes的StorageClass结合Heketi服务实现。Heketi是Glusterfs的卷的管理服务，对外提供REST接口，可以动态创建、销毁Glusterfs Volume。

Glusterfs虽然性能很好，却不适合存储海量小文件，因为它只在宏观上对数据分布作了优化，却没在微观上对文件IO作优化。登月平台上大多数前向服务都是图像识别应用，需要将图片和识别结果保存下来，用作训练数据，进行算法的迭代优化。我们在调研之后采用了SeaweedFS作为小文件存储系统。

SeaweedFS的设计思想源于Facebook的Haystack论文，架构和原理都很简单，性能极好，部署和维护也很方便。SeaweedFS对外提供REST接口，结合它的filer服务可实现目录管理，我们在此基础上实现了批量上传和下载功能。SeaweedFS具有rack-aware和datacenter-aware功能，可根据集群的拓扑结构（节点在机架和数据中心的分布情况）实现更可靠的数据冗余策略。目前登月平台上很多图像服务已经接入SeaweedFS，每天存储的图片数量达到600万张，存储量以每天30G的速度增长。

因为多数计算任务都会使用HDFS，所以HDFS也是登月平台必不可少的存储组件。为了提高数据读写速度，我们引入Alluxio作为HDFS的cache层，跟直接读写HDFS相比，性能提升了几十倍。

在文件系统的多租户隔离方面，使用Kerberos和Ranger对HDFS作安全管理，Kerberos提供了身份验证，Ranger提供了权限校验。而Glusterfs的Volume使用mount方式挂载到容器中，本身就可将用户限定在特定卷中，因此可变相支持多租户隔离。

GPU资源管理

平台当前使用的Kubernetes 是1.4版本，当时社区还没有加入对多GPU的支持，我们就自己开发了多GPU管理，包括：GPU探测与映射，cuda driver管理与映射，GPU健康检查和状态监控，GPU-aware调度等。GPU-aware调度可根据GPU型号、显存大小、空闲的GPU数量等条件合理地调度应用程序，以保证资源利用率最大化。

负载均衡

登月平台的前向服务对外提供的通信接口有RPC和HTTP两种。RPC服务可以通过注册中心和RPC Client实现负载均衡，HTTP服务使用的是Kubernetes 社区的ingress组件实现负载均衡。Ingress的本质是对Nginx作了封装。用户只需将Ingress规则配置到Kubernetes里，指定服务的Host、Path与Kubernetes的Service之间的映射关系，然后Ingress-controller实时监控规则的变化，并生成Nginx配置文件，将Nginx程序reload，流量就会被分发到Serivce对应的Pod上。

CI/CD

我们选用Gitlab+Jenkins+Harbor作为持续集成/部署的组件。开发者将代码提交至Gitlab，由Jenkins触发编译、打包的规则，并生成Docker镜像push到Harbor上。当用户执行上线操作后，镜像被拉取到Kubernetes集群的Worker节点上，启动容器。平台使用Harbor搭建了私有仓库和mirror仓库，为了加速拉取镜像的速度，在不同机房作了复制仓库。

日志

在日志采集方面，我们采用了业界普遍的解决方案EFK：容器将日志打到标准输出，由docker daemon落盘存到宿主机的文件里，然后经Fluentd收集，发给Kafka，再经Fluentd转发到Elasticsearch，最后通过Kibana展示给用户作查询和分析。之所以中间加了Kafka，一是对流量起到削峰填谷的作用，二是方便业务方直接从Kafka上消费日志导入第三方系统处理。

监控

我们采用的是Heapster+Influxdb+Grafana监控组件。Heapster定期从每个Node上拉取Kubelet暴露出的metric数据，经过聚合汇总之后写入Influxdb，最终由Grafana展示出来。Heapster提供了Container、Pod、Namespace、Cluster、Node级别的metric统计，我们对Heapster作了修改，加入了Service级别的metric聚合，以便用户从应用的维度查看监控。

Kubernetes调度Spark

重点说一下Spark on Kubernetes。该开源项目由Google发起，旨在将Spark能够原生的调度在Kubernetes中，和YARN、Mesos调度框架类似。

业界有一种比较简单的做法，就是将Spark Standalone模式运行在Docker中，由Kubernetes进行调度。

该做法具有以下缺点：

Standalone本身就是一种调度模式，却跑在另一种调度平台中，架构上重叠拖沓。

Standalone模式跑在Kubernetes中经过实际测试，很多机器学习任务性能会有30%以上的衰减。

需要预先设定Worker的数量，Executor进程和Worker进程跑在同一个Container中，相互影响。

无法完成多租户的隔离。在同一个Docker中Worker可以启动不同用户的Executor，安全性很差。

为了解决上述问题，Kubernetes需要原生支持调度Spark，架构图如下：

Native Spark on Kubernetes架构

从Kubernetes的角度出发，把Driver和Executor分别Container化，完成原生调度，架构清晰。

继承了Docker的计算资源隔离性，并且通过Kubernetes的Namespace概念，可以将不同的Job从网络上彻底隔离。

可以保持多版本并行，Spark-submit提交任务的时，可根据用户需求定义不同版本的Driver和Executor。

从Cluster模式的角度来观察Spark on Kubernetes，显而易见的结论是，我们已经不再有一个所谓的“Spark Cluster”，取而代之的是Kubernetes调度了一切，Spark Job可以无缝地与其他应用对接，真正形成了一个大的调度平台。

当前的社区的版本是非生产环境下的，我们团队为此做了大量的benchmark测试，稳定性测试等等。为了支持更多的需求，如multi-tenancy，python job，我们修改了部分代码，维护了京东的一套版本。

计算与数据分离

在Hadoop生态圈，数据本地性一直被津津乐道。但是在容器化、云的领域，大家都在推崇存储中心化，数据和计算分离，现在有越来越多的公司正在将存储和计算相分离，这主要是得益于网络带宽的飞速发展。不说专有网络，就说通用的25G网络，还有RDMA和SPDK等新技术的使用，让我们具备了存储计算分离的能力。

从架构的角度看有如下意义：

1、多租户场景，数据安全性得到保证，实现物理上的隔离。
2、部署机房可以灵活多变，计算资源和存储资源可以分机房部署。当然，如果需要性能保证，可以加入中间件例如Alluxio。
3、平台可以方便的部署在用户网络，而不改变其数据结构。例如联通、工商银行等。

对于Tensorflow/Caffe/MXNet框架来说，Glusterfs可以直接满足需求。而对于Spark框架，我们直接用HDFS和Spark相分离的计算架构，经过大量的Benchmark，10G网络下LR，KMEANS，Decision Tree，Native Bayes等MLlib算法，数据分离与数据本地性对比，性能损失在3%左右。这样一来，所有的机器学习/深度学习框架都可以统一架构，将计算和存储相分离。

Kubernetes作为容器集群管理工具，为应用平台提供了基于云原生的微服务支持，其活跃的社区吸引了广大开发者的热情关注，刺激了容器周边生态的快速发展，同时为众多互联网企业采用容器集群架构升级内部IT平台设施，构建高效大规模计算体系提供了技术基础。

AI基础平台部是一个专注、开放的team，致力于打造安全高效的机器学习平台架构，为登月算法平台提供底层支持，研究方向主要为Kubernetes，AI算法工程化，大数据系统虚拟化等方向。

感谢Intel公司在Spark on k8s，BigDL等领域为我们提供了有力支持和宝贵经验。

范振，哈尔滨工业大学硕士，京东AI与大数据部软件开发工程师。2014年加入京东，从事基础平台架构、开发工作；是CDN项目，DDOS二期项目、反比价项目、机器学习平台基础平台项目的负责人；主导设计、开发了以上项目，在高性能服务器、大数据领域有着丰富的经验和视野。

马殿军 ，南开大学硕士，京东AI与大数据部软件开发工程师。擅长分布式系统、虚拟化技术；目前主要负责AI平台研发部的容器集群管理平台建设。

人工智能赛博物理操作系统

AI-CPS OS

“人工智能赛博物理操作系统”（新一代技术+商业操作系统“AI-CPS OS”：云计算+大数据+物联网+区块链+人工智能）分支用来的今天，企业领导者必须了解如何将“技术”全面渗入整个公司、产品等“商业”场景中，利用AI-CPS OS形成数字化+智能化力量，实现行业的重新布局、企业的重新构建和自我的焕然新生。

AI-CPS OS的真正价值并不来自构成技术或功能，而是要以一种传递独特竞争优势的方式将自动化+信息化、智造+产品+服务和数据+分析一体化，这种整合方式能够释放新的业务和运营模式。如果不能实现跨功能的更大规模融合，没有颠覆现状的意愿，这些将不可能实现。

领导者无法依靠某种单一战略方法来应对多维度的数字化变革。面对新一代技术+商业操作系统AI-CPS OS颠覆性的数字化+智能化力量，领导者必须在行业、企业与个人这三个层面都保持领先地位：

重新行业布局：你的世界观要怎样改变才算足够？你必须对行业典范进行怎样的反思？
重新构建企业：你的企业需要做出什么样的变化？你准备如何重新定义你的公司？
重新打造自己：你需要成为怎样的人？要重塑自己并在数字化+智能化时代保有领先地位，你必须如何去做？

AI-CPS OS是数字化智能化创新平台，设计思路是将大数据、物联网、区块链和人工智能等无缝整合在云端，可以帮助企业将创新成果融入自身业务体系，实现各个前沿技术在云端的优势协同。AI-CPS OS形成的数字化+智能化力量与行业、企业及个人三个层面的交叉，形成了领导力模式，使数字化融入到领导者所在企业与领导方式的核心位置：

精细：这种力量能够使人在更加真实、细致的层面观察与感知现实世界和数字化世界正在发生的一切，进而理解和更加精细地进行产品个性化控制、微观业务场景事件和结果控制。
智能：模型随着时间（数据）的变化而变化，整个系统就具备了智能（自学习）的能力。
高效：企业需要建立实时或者准实时的数据采集传输、模型预测和响应决策能力，这样智能就从批量性、阶段性的行为变成一个可以实时触达的行为。
不确定性：数字化变更颠覆和改变了领导者曾经仰仗的思维方式、结构和实践经验，其结果就是形成了复合不确定性这种颠覆性力量。主要的不确定性蕴含于三个领域：技术、文化、制度。
边界模糊：数字世界与现实世界的不断融合成CPS不仅让人们所知行业的核心产品、经济学定理和可能性都产生了变化，还模糊了不同行业间的界限。这种效应正在向生态系统、企业、客户、产品快速蔓延。

AI-CPS OS形成的数字化+智能化力量通过三个方式激发经济增长：

创造虚拟劳动力，承担需要适应性和敏捷性的复杂任务，即“智能自动化”，以区别于传统的自动化解决方案；
对现有劳动力和实物资产进行有利的补充和提升，提高资本效率；
人工智能的普及，将推动多行业的相关创新，开辟崭新的经济增长空间。

给决策制定者和商业领袖的建议：

超越自动化，开启新创新模式：利用具有自主学习和自我控制能力的动态机器智能，为企业创造新商机；
迎接新一代信息技术，迎接人工智能：无缝整合人类智慧与机器智能，重新
评估未来的知识和技能类型；
制定道德规范：切实为人工智能生态系统制定道德准则，并在智能机器的开
发过程中确定更加明晰的标准和最佳实践；
重视再分配效应：对人工智能可能带来的冲击做好准备，制定战略帮助面临
较高失业风险的人群；
开发数字化+智能化企业所需新能力：员工团队需要积极掌握判断、沟通及想象力和创造力等人类所特有的重要能力。对于中国企业来说，创造兼具包容性和多样性的文化也非常重要。

子曰：“君子和而不同，小人同而不和。” 《论语·子路》云计算、大数据、物联网、区块链和人工智能，像君子一般融合，一起体现科技就是生产力。

如果说上一次哥伦布地理大发现，拓展的是人类的物理空间。那么这一次地理大发现，拓展的就是人们的数字空间。在数学空间，建立新的商业文明，从而发现新的创富模式，为人类社会带来新的财富空间。云计算，大数据、物联网和区块链，是进入这个数字空间的船，而人工智能就是那船上的帆，哥伦布之帆！

新一代技术+商业的人工智能赛博物理操作系统AI-CPS OS作为新一轮产业变革的核心驱动力，将进一步释放历次科技革命和产业变革积蓄的巨大能量，并创造新的强大引擎。重构生产、分配、交换、消费等经济活动各环节，形成从宏观到微观各领域的智能化新需求，催生新技术、新产品、新产业、新业态、新模式。引发经济结构重大变革，深刻改变人类生产生活方式和思维模式，实现社会生产力的整体跃升。