打造百亿级数据处理量的弹性调度容器平台
打造百亿级数据处理量的弹性调度容器平台
Docker 是当前最火热的开源项目之一，它重新定义了程序开发测试、交付和部署过程，可以做到「Build once，Run anywhere」。在上周的 DockerOne 社群分享会上，七牛云布道师陈爱珍分享了七牛云如何通过自主研发的容器调度框架打造易扩展、易部署、高自由度、高可用、高性能的数据处理平台。以下是对她分享内容的整理。　　陈爱珍 七牛云布道师7 年以上企业级系统运维管理经验，对大型分布式系统架构设计及运维有丰富的经验。现转向 DevOps ，容器相关技术领域。一、数据处理业务场景首先介绍一下七牛数据处理业务的背景。七牛云目前平台上有超过50万家企业客户，超过2000亿张，累积超过10亿小时的视频。 用户把这些图片和视频存储在七牛上后会有一些数据处理方面的需求，如缩放、裁剪、水印等。这些文件持续在线且数据种类多样，如果用户把这些文件在自己的基板上处理好后再上传到七牛，是非常不合算的事情。而七牛最先提供基于存储的数据处理功能方便用户去做数据处理，这些数据处理通常放在企业的客户端或服务器端来操作，对接上七牛云存储的数据处理接口后，即可对图片和音频进行丰富的实时转码功能，转码生成的新规格文件放在七牛提供的缓存层供App调用，不用占用存储空间，对企业来说不仅成本大大降低，还可提高开发效率。 下图为一个图片裁剪的数据处理示例：　　七牛的文件处理程序简称FOP(File Operation)，不同的文件处理操作使用不同的FOP。用户只需上传一个原文件就可以通过使用七牛的数据处理功能得到各种样式丰富的文件。下图为文件从上传存储到处理到分发的流程图：　　二、海量数据处理平台的挑战七牛云的海量数据成就了Dora十分强大的数据处理能力，目前七牛的数据处理服务已经日处理数近百亿次。面对这样海量的数据处理请求，原有的数据处理平台也面临着新的挑战：1、 日均请求量百亿级，CPU 密集型计算目前系统每天有近百亿的数据处理请求量，拥有近千台的计算集群，整个存量、增量都非常大。而数据处理集群中绝大部分的机器都是用来跑图片、音视频转码的，这些都是CPU密集型的计算，这意味着后台需要很多台机器，而且CPU的核数越多越好。在年底数据处理平台可能会在目前近千台的计算集群基础上翻好几倍，需要有快速物理扩展和高效智能管理的能力。2、 服务器负载不均衡，资源利用率不高实时在线处理的业务处理时间短，但是量大，需要大量的实例来应对高并发的情况。而异步处理的业务处理时间长，也需要分配足够的资源来。当实时业务并不繁忙而异步处理业务增长时，并不能使用分配给实时业务的资源， 这种静态资源分配机制带来的分配不合理问题，导致服务器负载不均衡，资源利用率不高。3、 突发流量不可测量， 大量冗余资源在新接入用户并不能完全正确的预测请求量，原来的模式是通过快速扩容机器并验证上线，需要一定的处理时间，对于这种非计划内的请求量需要准备大量的冗余资源来应对突发流量。4、 集群负载过重，不能自动按需扩展个别用户突增数据处理请求时导致集群负载压力过大，CPU处理变慢， 请求时间变长，请求任务堆积，影响其他业务，并不能在现有的资源基础上进行快速扩展，也不能根据实际的业务压力进行按需自动扩展集群实例。5、 用户自定义应用(P)质量及规模未知七牛除了提供官方的数据处理服务，也支持客户将自定义数据处理模块部署到七牛云存储的就近计算环境，避免远程读写数据的性能开销和流量成本，满足用户多方位的数据处理需求。但是各种UFOP运行在同一个平台上就可能会存在部分UFOP的质量问题或请求量过大而分配的资源不足导致影响平台上其他服务的正常运行。三、自研容器调度系统介绍为了解决以上问题，七牛基于资源管理系统Mesos自主研发了一套容器调度框架(DoraFramework)，通过容器技术打造了易扩展、易部署、高自由度的数据处理平台Dora。整体架构图如下所示：　各组件介绍：MESOS：由Zookeeper，Mesos Master，Mesos Agent 构成了基础的MESOS 数据中心操作系统，可以统一管理机房中的所有物理机，负责资源层面的调度，是二层调度系统最基础的运行环境 。DoraFramework： 业务层调度框架，通过DoraFramework使用 Mesos管理所有的物理机资源，完成业务进程的调度与管理。Consul：包含服务发现，健康检查和KV存储功能的一个开源集群管理系统，DoraFramework调度系统使用Consul的服务发现和健康检查机制提供基础的服务发现功能，使用KV存储功能来存储DoraFramework的metadata。Prometheus：一个开源的监控系统，实现机器级别，容器级别及业务系统级别的监控。Pandora： 七牛的内部的日志控制管理系统，负责生产环境所有日志的汇聚及处理。在这个架构中，我们选择通过容器技术实现跨机器实现弹性的实时调度。调度框架可以根据具体的业务负载情况动态的调度容器的个数， 很好的解决了静态配置导致的资源利用率不高的问题 。而容器秒启的特性也解决了当有大量突发请示进入，可以快速启动服务的问题。在网络方面，由于UFOP是用户部署运行的服务，并不知道用户是否有开启其他的端口使用，所以使用的是Bridge模式，需要对外使用端口的都需要通过NAT进行暴露，这样服务内部使用了什么端口并不会对外界环境造成影响 ，对平台环境做了非常好的安全隔离。数据处理平台的调度系统我们选择的是Mesos+自研容器调度框架(DoraFramework)。选择Mesos做为资源管理系统一个是因为Mesos的相对其他的容器调度系统更成熟，Kubernetes是2015 才发布可生产环境运行的版本，Docker Swarm则是2016年才发布，这两个产品的生产实践在调研时基本还没什么大型生产实践经验，而Mesos则已有七八年的，且资源管理方面已经在如苹果，等大型公司得到生产实践，稳定性比较好;第二个是因为Mesos支持调度成千上万的节点，以七牛目前已经达到近千台物理机的规模，且每年都在大幅度增长的情况，Meoso这种支持超大规模调度的资源管理框架更合适七牛的业务发展，七牛数据处理业务机器的规模每年都在大幅度的增长; 第三是因为Mesos的简单性，开放性及可扩展性，Mesos是一个开源的分布式弹性资源管理系统，整个Mesos系统采用了双层调度框架：第一层由Mesos收集整个数据中心的资源信息，再将资源分配给框架;第二层由框架自己的调度器将资源分配给自己内部的任务。Mesos自身只做资源层的管理，这种简单性带来的则是稳定性。而容器的调度框架则可以使用开源框架如Marathon/chronos或自主研发。Kubernetes虽然功能很丰富，但是也比较复杂，组件及概念都比较多，并且缺乏开放性和可扩展性，只能使用它提供的调度功能，而不能根据自身业务的情况定制调度框架，会造成对Kubernetes过于依赖的情况。为什么不选择Mesos的核心框架Marathon 而选择自研，出于三方面的考虑：1. Marathon有些方面不支持我们期望的使用姿势，比如不太好无缝对接服务发现;2. Marathon采用 scala 开发，出了问题不好排查，也不方便我们做二次开发;3. 如果选用 Marathon的话，我们上面还是要再做一层对 Marathon的包装才能作为Dora的调度服务，这样模块就会变多，部署运维会复杂。DoraFramework是七牛使用go语言自研的容器调度框架。DoraFramework实现了Mesos两层调度中业务进程的调度，是Dora调度系统中的核心组件，通过与Mesos和consul组件之间的交互， 对外提供API接口。架构图如下：　　DoraFramework主要功能介绍：& 自动化应用的部署& 服务注册与发现& 弹性调度容器数量& 负载均衡& 支持在指定机器上增加或减少实例& 支持高可用& 应用的版本和升级管理& 支持获取实例的状态及日志数据& 支持业务级别的监控& 支持实例的故障修复DoraFramework与 Marathon调度架构的对比：1. DoraFramework调度系统的服务注册与发现使用Consul实现， Consul是用于实现分布式系统的服务发现与配置，支持跨数据中心的内部服务或外部服务的发现， 对外提供DNS接口，而Marathon-lb并不支持跨数据中心的服务发现。2. Marathon是通过Marathon-lb所在节点的servicePort服务端口或VHOST来发现服务 ，要求网络模式必须为Bridge。因为Marathon-lb还负责负载均衡的功能，在大型的业务环境下，如果Marathon-lb出现异常，则会影响框架正确的服务发现。3. Dora调度系统可以做更精确的弹性调度。因为它不仅支持做资源使用层面的监控，还支持做业务级别的监控，在对实例进行调度时就可以根据实际的业务压力进行调度。4. Dora调度系统内的负载均衡组件是通过从Consul中获取到所有的可用实例的地址进行负载分发，并可以根据每个实例的业务负载情况进行更精确的分发。而Marathon-lb并没有业务层的监控数据。5. Consul提供系统级和应用级健康检查，可以通过配置文件及HTTP API两种方式来定义健康检查，并支持TCP，HTTP，Script，Docker和Timeto Live(TTL)五种方式做Check。Marathon的默认的Health Checks 只检查Mesos中的任务状态，当任务为running时，就被认为是health状态，这样不能做应用级的健康检查。Marathon通过REST API可以查看应用的健康状态， 但只支持TCP、HTTP和Command三种方式。6. Dora调度系统提供的监控栈在业务进程运行过程会汇总采集业务运行状况指标，如请求次数，请求延时等信息，业务进程对外暴露一个标准的http监控接口，监控接口的数据产出符合Prometheus监控数据格式。Prometheus通过配置Consul作为服务发现地址，会从Consul中获取需要收集监控数据的业务进程列表，从业务进程暴露的http监控接口pull监控数据。我们使用Consul做注册中心，实现服务的注册与发现。Consul自带key/value存储，可通过DNS接口做服务发现，且具体健康检查的功能，并支持跨数据中心的服务发现。API Gateway 可以通过 Consul提供的DNS接口查询到服务所有的可用实例的列表信息，并将请求进行转发。　　1)服务的自动注册和撤销新增微服务实例时，采取的原则是等待实例为运行状态后将实例的访问地址注册到Consul Client 的 Service Registration，并配置这个服务的健康检查，再将数据同步到 Consul Server的服务注册表中。对于减少实例时，采取的原则是先将实例从Consul Server的服务注册表中删除，等待冷却时间之后，再从通过调度系统将这个实例销毁。从而完成服务的自动注册和撤销。2)服务发现外在系统想访问服务时，可通过服务名称从Consul Server提供的DNS接口查询到当前服务在Consul Server中注册的所有健康实例的访问地址， 再将请求发送给实例。四、海量数据处理平台实践我们生产环境的配置管理采用的是Ansible，Ansible默认使用SSH进行远程连接，无需在被管节点上安装附加，可以批量系统配置、批量部署、批量运行命令等，非常适合七牛的大规模IT环境。而Playbooks 是一种简单的配置管理系统与多机器部署系统的基础，使用非常简单，且具有可读性，非常适合于复杂应用的部署。我们通过Ansible可以实现数据处理平台的一键式安装和删除，新增和删除节点，还包括对组件版本的升级及回退，以及生产环境的批量配置修改等操作，简化了复杂的运维配置管理工作。在实践中，选择一台主机做为中控机，安装Ansible，再配置这台中控机与所有远程主机的SSH互信，再在中控机上配置Playbook文件，即可对多台主机进行批量操作。对于简单的操作，可执行如下命令：$ansible-playbook main.yml -i hosts在main.yml里编辑所有需要做的操作，在hosts文件里写入所有需求操作的主机IP地址，即可完成对hosts文件里所有主机的批量操作。而对于复杂的操作，则可通过编写Playbook进行配置。roles里存放不同的角色任务，比如Mesos Master上执行的任务和Mesos Agent上执行的任务不同，则可放在不同的roles里，也可以把Mesos，Zookeeper，Consul放的不同的roles里。tasks里则是role里具体执行的任务，handlers则是tasks里触发执行的任务。template则是模板文件，比如我们需要个性Consul的默认配置文件，可以修改后的配置文件放在这个目录下，在执行时用这个文件替换默认的配置文件。在监控方面，数据处理平台拥有完整的监控体系，包括了主机监控，容器监控，服务监控，流量监控，日志监控。主机和容器的监控主要通过Prometheus的各种Exporter来做，采集到包括CPU，内存，网络以及磁盘的实时使用情况，服务监控和流量监控则通过七牛自己的监控程序进行监控，可以监控到服务的状态，存活性，句柄数，及所有处理命令的请求数，失败数等。日志监控则是通过七牛内部的日志平台Pandora系统进行监控，包括收集系统日志，容器日志和业务进程日志。通过修改开源的文件收集器Filebeat的output，将采集到的日志全部传送到七牛内部的日志监控系统Pandora进行日志监控。　　监控数据显示如下：　　以上就是七牛云数据处理平台基于容器技术实践的情况。目前七牛的数据处理平台具备零运维、高可用、高性能的数据处理服务能力，可让用户轻松应对图片、音视频及其他各类数据的实时、异步处理场景。七牛的数据处理业务系统不仅可以处理来自七牛云存储的数据处理请求，也支持来自非七牛云存储的数据处理请求，还可以直接处理来自七牛云分发Fusion的数据处理请求，用来提高CDN中间源数据的处理速度。而数据处理平台Dora则是一个开放的平台，不仅可以运行七牛自己的数据处理服务，也支持运行用户自定义的数据处理服务，并具备丰富的运维管理功能，可以使用户从繁杂的运维管理和架构设计中脱离出来，从而专注于实现数据处理单元。 七牛数据处理平台的业务支撑能力如下：　　Q&A问答Q：请问管理系统是基于什么开发的?这个系统会开源吗?A：Dora 的调度框架是基本 Go 语言开发的。目前不会开源，但提供私有部署。Q：刚开始看 Mesos 框架实现，请问自定义的 Scheduler 中如何调用自定义的 executor?A：Schesuler 跟 executor 这个都是按照 Mesos 最新的 V1 版的 HTTP API 去做的，这个没有不兼容的问题，只是 Mesos Go 版本的 SDK 有些老旧，更新也比较缓慢，这个地方我们自己根据需要做了些更改。Q：请问目前 Consul 集群是多大规模呢?有没有考虑 Consul 扩展的性能瓶颈呢?A：Consul 是在每个 slave 节点上会有一个 Consul 的 Agent ，我们一个机房有 200 多台专门用于数据处理的机器，所以 Consul 的集群规模也就这么大，单机房。对我们当前来说不存在瓶颈，因为我们对 Consul 的使用的场景相对单一简单：作为 Metadata 的可靠存储，Metadata 的更新其实并不是很频繁，这个我们参考过别人做过的一些性能测试和我们自己的一些测试，性能是满足需求的。另外一个功能就是服务发现与实例的健康检查，健康检查是由运行在每个机器上的 Consul Agent 负责的，均摊到每个机器上，其实单个机器上的实例数不会特别的多，所以这部分也没有太大的压力。当然了，这个也是跟业务规模相关的，假定哪天 Consul 的扩展性成我们的问题了，也说明我们的业务量特别特别的大了，我们也是很期望这一天到来的。Q：Dora 是否可以支持 MySQL 的自动伸缩扩容?A：Dora 系统的应用场景还是运行一些数据处理命令这类无状态的服务。MySQL 这类系统不适合直接跑在 Dora 这个里面，如果期望 MySQL 跑在 Mesos 上面的话，需要自己实现一个专门针对 MySQL 的调度器，因为 MySQL 实例的扩缩容，实例故障的修复都有 MySQL 自身特定的需求。我们公司 MySQL 这类有状态服务的容器化是由公司另一个容器平台实现的。MySQL 的用的是 Percona XtraDB Cluster 方案，我们利用另一个容器平台的 API 写了一个 Percona XtraDB Cluster 的调度器，把 Percona XtraDB Cluster 的大部分运维操作在容器平台上自动化了。Q：你们的 Ansible host 文件是动态生成的嘛?代码推送也是通过 Ansible 嘛?新增删除节点，以及回滚等操作是如何实现的?A：最开始实践的时候不是动态生成的，其实我们是可以从 Consul 中获取到当前集群里面的节点和节点的一些简单的配置信息，后面有考虑从 Consul 里面拿节点信息，动态生成用于 Ansible 灰度的 host 文件。代码推送也是使用的 Ansible，如果能和外网连接的机器，也可以使用 GitHub。因为我们的 Playbook 的角色是通过组件区分的，新增删除节点只需要修改 Host 文件，把相应的节点加入安装或删除相应的组件。如回滚操作：$ ansible-playbook rollback.yml -i hosts -e &hosts_env=XXX app_env=XXX version_env=XXX&参数说明：hosts_env：表示要回滚的主机组，如 Masterapp_env：表示要回滚的组件，如 ZooKeeperxxx_version：表示要回滚组件的版本号，如 v1.0.1.Q：Dora的调度策略是怎么样的?可否简单介绍一下。A：首先保证同一种数据处理命令的实例尽量均匀分散在不同的机器上，然后再是保证均衡每个机器上的负载。Q：Prometheus 目前是单机的，数据量大了怎么办?Prometheus 的监控数据是存在 InfluxDB 吗?A：目前我们是按业务拆分 server，数据量可以支撑。我们没有使用 InfluxDB，还是用的原生的 LevelDB。Q：这么大文件量，你们在存储技术方面有什么特别的处理吗?怎么实现高性能和海量存储之间均衡?A：七牛云存储的设计目标是针对海量小文件的存储，所以它对文件系统的第一个改变也是去关系，也就是去目录结构(有目录意味着有父子关系)。所以七牛云存储不是文件系统，而是键值存储，或对象存储。我们每个大文件都是切割成小文件存储下来的，元信息单独存放在数据库中，用户请求的时候通过业务层合并处理后返回。因此理论上磁盘只存储小文件，大文件存储和读取的性能主要在于文件切割和合并。
微信搜索并关注科技讯公众账号：kejixun 更多精彩，早知道！
↓【往下看，下一页更精彩】↓
14:43 更新
14:42 更新
14:41 更新
14:39 更新
14:39 更新
14:38 更新
14:36 更新
14:07 更新
14:06 更新
14:03 更新
&&科技讯版权所有&||||||摘要：【Docker 是当前最火热的开源项目之一，它重新定义了程序开发测试、交付和部署过程，可以做到「Build once，Run anywhere」。在上周的 DockerOne 社群分享会上，七牛云布道师陈爱珍分享了七】
Docker 是当前最火热的开源项目之一，它重新定义了程序开发测试、交付和部署过程，可以做到「Build once，Run anywhere」。在上周的 DockerOne 社群分享会上，七牛云布道师陈爱珍分享了七牛云如何通过自主研发的框架易扩展、易部署、高自由度、高可用、高性能的处理。以下是对她分享内容的整理。　　
陈爱珍 七牛云布道师
7 年以上企业级系统运维管理经验，对大型分布式系统架构设计及运维有丰富的经验。现转向 DevOps ，容器相关技术领域。
一、数据处理业务场景
首先介绍一下七牛数据处理业务的背景。七牛云目前平台上有超过50万家企业客户，图片超过2000亿张，累积超过10亿小时的视频。 用户把这些图片和视频存储在七牛上后会有一些数据处理方面的需求，如缩放、裁剪、水印等。这些文件持续在线且数据种类多样，如果用户把这些文件在自己的基板上处理好后再上传到七牛，是非常不合算的事情。而七牛最先提供基于存储的数据处理功能方便用户去做数据处理，这些数据处理通常放在企业的客户端或服务器端来操作，对接上七牛云存储的数据处理接口后，即可对图片和音频进行丰富的实时转码功能，转码生成的新规格文件放在七牛提供的缓存层供App调用，不用占用存储空间，对企业来说不仅成本大大降低，还可提高开发效率。 下图为一个图片裁剪的数据处理示例：　　
七牛的文件处理程序简称FOP(File Operation)，不同的文件处理操作使用不同的FOP。用户只需上传一个原文件就可以通过使用七牛的数据处理功能得到各种样式丰富的文件。下图为文件从上传存储到处理到分发的流程图：　　
二、海量数据处理平台的挑战
七牛云的海量数据成就了Dora十分强大的数据处理能力，目前七牛的数据处理服务已经日处理数近次。面对这样海量的数据处理请求，原有的数据处理平台也面临着新的挑战：
1、 日均请求量百亿级，CPU 密集型计算
目前系统每天有近百亿的数据处理请求量，拥有近千台的计算集群，整个存量、增量都非常大。而数据处理集群中绝大部分的机器都是用来跑图片、音视频转码的，这些都是CPU密集型的计算，这意味着后台需要很多台机器，而且CPU的核数越多越好。在年底数据处理平台可能会在目前近千台的计算集群基础上翻好几倍，需要有快速物理扩展和高效智能管理的能力。
2、 服务器负载不均衡，资源利用率不高
实时在线处理的业务处理时间短，但是量大，需要大量的实例来应对高并发的情况。而异步处理的业务处理时间长，也需要分配足够的资源来。当实时业务并不繁忙而异步处理业务增长时，并不能使用分配给实时业务的资源， 这种静态资源分配机制带来的分配不合理问题，导致服务器负载不均衡，资源利用率不高。
3、 突发流量不可测量， 大量冗余资源
在新接入用户并不能完全正确的预测请求量，原来的模式是通过快速扩容机器并验证上线，需要一定的处理时间，对于这种非计划内的请求量需要准备大量的冗余资源来应对突发流量。
4、 集群负载过重，不能自动按需扩展
个别用户突增数据处理请求时导致集群负载压力过大，CPU处理变慢， 请求时间变长，请求任务堆积，影响其他业务，并不能在现有的资源基础上进行快速扩展，也不能根据实际的业务压力进行按需自动扩展集群实例。
5、 用户自定义应用(UFOP)质量及规模未知
七牛除了提供官方的数据处理服务，也支持客户将自定义数据处理模块部署到七牛云存储的就近计算环境，避免远程读写数据的性能开销和流量成本，满足用户多方位的数据处理需求。但是各种UFOP运行在同一个平台上就可能会存在部分UFOP的质量问题或请求量过大而分配的资源不足导致影响平台上其他服务的正常运行。
三、自研容器调度系统介绍
为了解决以上问题，七牛基于资源管理系统Mesos自主研发了一套容器调度框架(DoraFramework)，通过容器技术打造了易扩展、易部署、高自由度的数据处理平台Dora。整体架构图如下所示：　
各组件介绍：
本文:网络整理 如有侵权 请通知邮箱:hmshd##qq.com[把##换成@]] 谢谢大数据实时推荐-不只是统计 - 为程序员服务
大数据实时推荐-不只是统计
随着大数据时代的来临，如何帮助用户从大量信息中迅速获得对自己有用的信息成为众多商家的重要任务，个性化推荐系统应运而生。个性化推荐系统以海量数据挖掘为基础，引导用户发现自己的信息需求，现已广泛应用于很多领域。传统的个性化推荐系统，采用定期对数据进行分析的做法来更新模型。由于是定期更新，推荐模型无法保持实时性，对用户当前的行为推荐结果可能不会非常精准。实时个性化推荐实时分析用户产生的数据，可以更准确地为用户进行推荐，同时根据实时的推荐结果进行反馈，更好地改进推荐模型。
腾讯大数据平台部和北京大学网络所崔斌教授研究组从2014年起开展大数据实时推荐研究，双方合作的论文连续两年在国际顶级会议SIGMOD发表：
TencentRec: Real-time Stream Recommendation in Practice SIGMOD
Real-time Video Recommendation Exploration
SIGMOD2016 。研究工作侧重解决实际应用中存在的问题，针对大数据实时推荐在精准、实时、海量等方面的挑战，提出了分布式可扩展的实时增量更新推荐算法，使推荐效果得到了明显的提升。所研究的方法已应用在包括视频、新闻等多个业务中，推荐效果得到显著提升。实时推荐系统现每天处理千亿条用户行为，支撑百亿级用户请求。
1. 大数据实时计算平台
腾讯大数据实时计算平台TRC[1]由实时数据接入TDBank、实时数据处理TDProcess、和分布式K-V存储TDEngine等部分组成，其中TDBank主要负责从业务侧接入实时数据，如用户行为数据、物品信息数据等;TDProcess基于Storm对实时流入的数据进行计算，并利用TDEngine存储计算结果，以供推荐引擎等使用。
TRC的主要框架如上图所示，有关TRC的文章已经有很多，这里不作详述，有兴趣的读者可以参考文章[1]获得详细描述。
2. 推荐算法实时化
基于Storm的实时计算能够针对海量流式数据进行有效的统计处理，然而流式计算在机器学习算法方面有着天然的劣势，而要完成大数据实时推荐，只是实时统计显然是不够的，我们希望能实现推荐算法的实时化更新计算。
流式实时计算在机器学习方面的局限性主要表现在两方面：首先，由于数据是以流的形式进入Storm平台计算，在任何时刻，我们都只有目前流入的数据，而没有传统的全局数据概念，而在全局数据上进行迭代计算正是许多机器学习算法需要的;其次，Storm平台是计算数据易失的，在海量数据背景下，如何保证模型的有效存储及更新维护成为一个挑战。
对于上述第二点不足，我们使用了TDE作为解决方案，TDE作为一个高容错、高可用性的分布式K-V存储，很好的满足了我们对计算数据的存储需求。而对于第一点不足，我们通过精细的设计，将原始的离线计算转化为增量计算，并实现了几类经典算法：
协同过滤算法，根据当前时间用户对物品的行为，实时更新物品间的共现数据和用户的兴趣分布数据，以计算物品间和用户间的相似度，进行基于物品或用户的协同推荐。
通过分析用户的实时行为数据，更新计算用户和不同物品间的内容相似度，以对用户进行推荐。
通过接收所有用户的实时行为数据，实时更新物品的热度，分析得到当前的热点物品，如实时热点新闻等，以对用户进行实时的推荐。
协同过滤矩阵分解算法，根据用户对物品的行为评分矩阵，将矩阵分解为用户和物品的特征向量，以预测用户对物品的喜好，来进行推荐。
下图为基于Storm实现的框架图，系统可以分为五层，数据接入层，数据预处理层，算法处理层，商品信息补充层，和存储层。数据接入层负责接收数据，预处理层负责根据历史数据对数据进行补全或者过滤等。算法处理层，是系统的主体部分，负责对数据进行分析处理，实现相关推荐算法的计算，将算法结果传入下一层。商品信息补充层负责对算法结果进行商品信息补全，这里补全是为了后续与离线模型结合或向用户推荐时，进一步对推荐结果做筛选的。最后一层是存储层，负责将结果存入存储部分，以供使用。
数据接入层
数据接入层负责接入数据，并且做简单的检查，对应TdbankSpout。通用推荐平台接收的数据共有五类，包括类别数据，行为权重数据，商品属性，用户属性，以及用户行为数据。
类别数据：
是各个商品的类别的描述和等级，用于基础数据统计
行为权重数据：
各个行为的权重，用于基础数据统计
商品属性：
各个商品的基本属性，基础数据统计
用户属性：
用户的基本属性，基础数据统计
用户行为数据：
记录了用户的行为，是系统主要要分析的数据。
数据预处理层
包括两个部分，一个是基础信息构建，对应的bolt是BaseInfoBolt，一个是对用户行为数据进行预处理，对应的是PretreatmentBolt。基础信息构建接受类别、行为权重、商品属性和用户属性四种数据，并存入相应的table。预处理bolt接受用户行为数据，根据用户群信息和历史数据对用户行为记录进行补全或者过滤等。
算法处理层
算法处理层是系统的主体部分，又可以分为数据统计部分和算法计算部分。数据统计部分包括用户详细信息统计，最近访问商品统计，人群行为数据统计，人群商品共现数据统计，场景Ctr统计等。
算法计算部分实现了CF，MF，Hot，CB等算法。这里对算法进行描述。
商品信息补全层
商品信息补充层负责对算法结果进行商品信息补全，这里补全是为了后续与离线模型结合或向用户推荐时，根据商品信息来对算法推荐结果进行筛选后对相应用户进行推荐，比如，根据商品价格和离线模型分析的用户财富层次等对推荐结果进行筛选，有些商品是vip免费的，可以对vip用户推荐，而对普通用户则要慎重考虑。
存储层是系统的最后一层，负责将推荐结果存入tde，tde是腾讯构建的一个内存k-v存储，对用户进行在线推荐时，从tde中取出推荐结果，与离线模型结合，对推荐结果进一步处理后推荐给用户。
2.2 实现优化策略
针对实现过程中遇到的问题和挑战，我们提出了几点优化策略以优化资源使用、提升效果。
分群计算：
在实际计算过程中，我们根据不同的用户群体对数据进行了划分，并在划分数据集上进行计算。用户群体可根据用户年龄、性别等进行划分，也可根据其他信息如职业、活跃度等进行划分。由于不同群体内的用户行为模式可能不同，在经过划分的数据集上进行计算，可以得到更准确的用户行为模式。
滑动窗口：
为了保证数据模型的实时性，某些情况下需要对历史数据进行“遗忘”，即只使用最近一段时间的数据来进行计算。为此，我们实现了滑动窗口，对于某个时间单位，我们维护近n个时间窗口的数据信息，这些窗口会实时滑动，丢掉最远的数据，保留最近的实时数据信息用于计算。
局部集成：
为了有效维护计算数据，我们使用了TDE作为数据外部存储，而在计算过程中与TDE的交互成为了计算开销不可忽视的一部分。为了减少与TDE的交互，降低资源使用，我们使用了局部集成策略，根据不同的计算特点，将数据先在worker内部做集成，然后再将局部集成结果合并到TDE。实践证明，这一策略有效降低了与TDE的交互，减少了资源使用。
多层Hash：
在计算过程中，会出现有多个worker需要写同一个Key-Value值得到情况，称之为写冲突，为了保证TDE的高可用性，我们使用了多层Hash策略来解决写冲突问题，减小了TDE在数据一致性上的负担。通过多层Hash策略，对同一个key的写操作将只发生在同一个worker上。
实时可扩展item-based CF
基于物品的协同过滤推荐[2](item-based CF)是亚马逊于2003年公布的推荐算法，由于其推荐效果较好且易于实现等特点，在工业界得到了广泛应用。这里我们以item-basedCF算法为例，解释实时推荐算法的具体实现[3]，有关其他算法的具体描述可参考论文[3]和[4]。
3.1 原始Item-basedCF
Item-based CF的基本思想是认为用户会喜欢和他以前所喜欢的物品相似的物品，其计算分为相似物品计算和用户喜好预测两部分，相似物品计算是整个算法的关键部分，用户喜好预测根据物品相似度加权预测用户对新物品的评分。
3.2 实时item-basedCF
在传统的推荐算法中，用户对物品的喜好评分由用户打分决定，而现实世界中，用户对物品的打分数据较少，大部分数据是用户行为数据，如浏览、点击等，这些用户行为具有不确定性，比如，用户点击一个物品详情页后关闭，可能表示用户喜欢该物品因为用户点击了详情页，也可能表示用户不喜欢该物品因为用户又关闭了详情页。这种情况下，我们只能从用户行为数据中去猜测用户的喜好。
为了降低对用户行为数据的错误理解造成的损失，我们对原始item-basedCF算法进行了改进。具体来说，我们为每个用户行为类型设置了评分权重，衡量不同行为表示的用户喜好的可靠性，如，对点击行为我们设定其评分权重为一分，而购买行为三分，因为用户的购买比点击更有可能说明用户喜欢该物品。对于一个物品，用户可能有多种行为，比如点击、购买、评论等，这时我们取权重最高的用户行为评分作为该用户对物品的喜好。
我们定义了用户对两个物品的共同评分用于计算物品相似度，如下：
通过将物品的共同评分设定为两个物品评分中较低的那个，我们限定了对行为错误估计的损失为两者的较小值。相应的，两个物品的相似度计算如下：
为了实现流式实时计算，实时更新物品的相似度，我们将上式计算分为了三部分，如下：
3.3 实时剪枝策略
在实际计算过程中，我们发现，由于数据量太大，用户的某一个行为会带来大量的物品需要重新计算。具体来说，我们一般认为用户在某一时间段中交互的物品相互之间相关，即可能相似，这个时间段可能是一天或者一个月，那么一个用户行为带来的物品评分更新，可能会造成数十甚至数百个物品对的相似度需要重新计算，而这些物品对很多可能是不那么相似的，即
随着近年来个性化服务的发展，推荐系统在实际应用中的价值也得到越来越多的认可，大数据实时推荐在推荐效果上的优秀表现，以及其巨大的发展空间，使其获得很多的关注。大数据实时推荐仍然有许多值得探索的地方，如实时矩阵分解、实时LR、实时深度学习等在线学习算法。
[1]“腾讯实时计算平台(TRC)系列之一：初识TRC”
[2]G. Linden, B. Smith, and J. York.
recommendations: Item-to-itemcollaborative filtering. In IEEEInternet Computing, 7(1):76–80, Jan. 2003
[3] Yanxiang Huang, Bin Cui, Wenyu Zhang, Jie Jiang,and Ying Xu. TencentRec: Real-time Stream Recommendation in Practice. [C]//Procof the 2015 ACM SIGMOD Conference. ACM, 8
[4]Yanxiang Huang, Bin Cui, Jie Jiang, Kunqian Hong, Wenyu Zhang, Yiran Xie.Real-time video recommendation. In SIGMOD 2016
via:腾讯大数据
关注大数据和大数据应用_大数据第一科技网
原文地址：, 感谢原作者分享。
您可能感兴趣的代码}