微博是一个广播社交网络平台，通过有趣的机制共享短期信息。微博用户注重订阅内容。在这种情况下，推荐系统可以很好地与订阅分发系统集成并相互促进。微博的两个关键基础：第一，建立用户关系，第二，内容沟通微博致力于优化这两点，促进微博的发展。
微博推荐开发过程改变了系统的方向，业务不断变化，目标重置，产品理念，架构和算法发生变化。本白皮书主要描述了推荐架构在此过程中的演变，并希望通过此机会探索业务与技术之间的关系，同时在产品目标，算法需求和技术开发方面为读者提供完整的开发环境。
通常，架构是在团队和业务环境中创建的，努力基于环境因素解决环境问题，结构由强大的功能组成，并且创建面向实现的效果。本白皮书详细介绍了微博建议的三个阶段，包括环境因素，架构配置和特性以及实施影响。
1独立1.0
1.1环境
影响结构形成的环境因素可分为内部环境因素和外部环境因素。内部因素主要与团队和成员有关，但外部因素主要在外部部门，整个公司或整个行业。
这个项目有很多项目，当时平均每个团队有5个并行开发项目。当然，最重要的因素是微博产品是快速生成器，微博需要在很多地方提供支持。同时，由于项目周期很短，调度紧急，很难有时间进行清理和抽象。典型产品包括微棒，微小组，微分布，微结构，用户和内容对齐。
基于以上原因，当我们面对单个项目时，我们使用熟悉的技术堆栈通过建立我们自己的理解来逐个构建我们的流程。
虽然开发过程中存在许多缺点新浪微博营销平台，但我们已为后续架构优化奠定了基础。结果如下。
在微博快速发展的过程中，微博满足了微博对推荐业务支持的要求，完成了20多个独立项目。
吴的框架诞生了，内部的高效计算框架诞生于此。
Web应用程序层的持续需求摘要，推荐的通用应用程序框架配置2楼2.0
我们介绍了一个独立的1.0。根据架构开发的方式，我们去了一个分支路口，一个是流行的LAMP架构，另一个是与广告和搜索相匹配的CELL架构。 LAMP架构数据策略是独立的，脚本语言是业务开发的主要语言，该项目是快速开发和迭代的首选。 CELL架构强调本地流程处理，数据和业务组合，自行开发的服务以及适用于高性能应用程序的数据库。毕竟，我们选择与两者兼容，并且我们倾向于拥有业务架构。为什么会这样？我们来看看当时的环境。
2.1环境
微博推荐2.0期间为2013年3月至2014年底。此期间的内部环境因素为：
今天，团队成员已经合作了很长时间，并就技术选择达成了一些共识。
团队产品专注于内容/用户/垂直课程推荐，场景分为源主页，正文页面和PC主页。这种集中不仅有助于统一建筑，还有助于获得技能。
外部因素包括：
该公司明确定位建议，提高关系绩效和内容沟通效率，并为推荐广告的技术探索，场景干预和用户体验提供基础。
在推荐的字段中，每个公司都有自己的架构输出，这是微博建议的重要指南。
2.2架构配置和功能
随着团队实施核心业务实施，工具和框架不断发展，2.0部署的目标正在变为现实。
1.技术目标
与1.0不同，仅仅实现业务需求不再是2.0的技术目标。要获得完整的推荐流程，您需要：
第一步是实施完整的推荐流程，包括候选人，调整，策略，演示，反馈和评估。
数据是第一个提取数据架构的数据。为了实现数据比较，效果是基于数据的，实现数据通道，反映反馈，实现数据着陆和执行业务需求。
提供一种方便干预算法的方法。
这不仅可以确保快速迭代和业务开发，还可以支持高效计算。
2.建筑
微博推荐2.0架构如图5所示。它不再是一个独立的系统，开发人员也无法使用类似的技术来解决类似的问题。该架构图主要包括以下部分：
应用层：主要负责推荐的策略和演示，其特点是充分利用脚本语言的特性来响应重复的要求。您可以在对齐后显示大多数推荐的内容，但必须在技术级别完成此IO密集型层，因为您需要合并，删除和重新定位前端产品策略。在技术选择框架中，开发最初基于Apache + mod_python并且创建了common_recom_frame。该框架面向能够成功实施推荐业务流程的二级开发人员。该框架的核心思想是提取项目，任务和数据的三层接口。该项目适用于每个推荐项目，每个推荐项目的推荐任务不同，一种管理的访问方法。两个规格同时设置。一种是集成推荐的接口，无论用户，内容或行业如何，另一种是通过保护不同协议数据库的访问方法来显着提高开发效率。 common_recom_frame框架的诞生基本上解决了产品的各种推荐策略要求，并走在了产品的前面。图5微博推荐2.0架构的示意图
计算层：主要消耗CPU，该层为算法提供干预方法，并执行支持算法模型迭代的推荐排序计算。在这个技术选择层，我们继承了原始的WOO协议框架，这是一个基于c/c ++开发的内部高效通信框架。当然，我已经做了很多扩展，并且我借用了上面提到的common_recom_frame思想来实现基于WOO框架的项目/工作/数据管理，为二级开发人员提供了更高效的开发工具。在您团队的开源项目中包含此工具：https://github.com/wbrecom/lab_common_so
数据层：主要负责推荐的数据流和存储。数据层的任务主要是解决数据的IN/OUT/STORE问题。 IN数据输入到系统，OUT是数据访问方法，STORE是数据存储方法。在进行数据层规划时，分析了微博推荐的数据特征，该属性可以分为静态和动态两大类。静态数据的定义如下：更新需要大量低频率和低并发性的数据，动态数据定义为：增量数据同时以高频率动态更新。因此，在静态和动态数据，RIN/R9接口，径向/流明，tmproxy /呼吸机或工具框架生成期间，唯一的IN/OUT/SOTRE的通用方向。下面说说扩展，RIN数据访问动态数据，支持通过Web服务接收数据，后端队列管理，消费者集群得到多服务框架ckestrel的补充，用户需要执行自己的业务开发您可以在线快速使用动态数据。 R9接口处理器访问静态数据推荐行为针对R9接口框架的Hadoop集群静态计算[MR Hive SQL和SPARK行为]通知管理和数据加载，解决了多个静态数据。动态数据使用许多redis群集，静态数据使用lushan群集来存储推荐数据。对于lushan，这个工具也包含在团队开源项目中：https://github.com/wbrecom/lushan。 tmproxy/ventilation为了解决OUT数据的问题，再加上通风访问中间件代理来处理静态和动态数据的推荐请求，后端数据减少了业务变化的影响。基本服务：推荐系统的基本服务主要包括监控，报警和评估系统，数据监控系统分为性能和影响监控两类，评估系统主要用于下级评估。在去之前有一定的期望和影响。
3.特点
优点是：
数据的集成方法，以提供完整的推荐流程支持
在快速实现业务功能的过程中，效果技术不断深化。
该算法得到了很好的支持。
首次使用您的数据的想法将帮助您全面比较您的影响并继续提高您的推荐效果。
密封系统易于放置，质量保证包含在测试中。
缺陷如下。
与推荐的核心有一定距离，并且与建议不完全一致。
推荐的策略算法完全传递给开发人员，不适合一般使用。
算法培训不包括在内，只是在线交付系统，因此构建完整的推荐系统是不够的。
2.3结果
微博推荐2.0的诞生产生了良好的效果。
微博的核心业务是通过诸如机构推荐，趋势用户推荐，趋势内容推荐，各种场景中的用户推荐，粉丝经济学，账户推荐等系统完成的。
为lab_common_so创建一个基本框架并执行开源
一个静态存储集群解决方案新浪微博营销平台，lushan，诞生了。
联阵框架的诞生极大地提高了企业生产的效率，也为开放社区做出了贡献。
3平台类型3.0
在前一节的2.0描述中提到的一个主要缺点是“与推荐的核心存在一定距离，并且与推荐不完全一致”。我们希望在建议3.0中修复它。为什么在满足业务需求时推荐的架构会继续发展？我们将向您展示微博推荐的平台风格3.0设计。让我们来看看环境。
3.1环境
从2014年底到现在的当前内部环境因素如下，微博建议3.0。
推荐产品没有扩展，它们更重要，并且重点从业务开发和迭代转向针对性能的技术迭代。
如果您以迭代方式提出新项目或业务，则会有许多重复性任务，重复任务，因为架构未得到解决。
外部因素包括：
该公司还从业务扩展转向效率优先，以改善用户体验和内容质量。
微博建议在推荐的技术链接的距离区域中存在一定距离，并且存在追赶状况。
3.2架构配置和功能
当前环境也可以反映3.0的技术目标。
1.技术目标
与2.0不同，全范围推荐过程不是3.0的目标。目标是：摘要在推荐过程中候选/对齐/训练/反馈的一般方法。
推荐算法，需要建立推荐系统算法的角度数据问题，接近算法策略
2.建筑
如图7所示，建议基于此开发2.0找到微博3.0体系结构，因为运行当前体系结构系统，我们维护了一个实际在框架2.0中使用的大型分层系统和工具。以下是一些要点：
两个标准：应用层的一个总体输出框架，所有这些都是在一个应用层中包含标准输入和输出参数的接口规范，与动态输入精益相关并且离线计算，这可以确定我们的结构因此，输入层工具R9接口规范是相互依赖的***不需要为分割级别的标准设置设置线串，例如数据/记录。
通过标准生成候选者的方法增加计算层：Artemis候选内容模块，项目候选用户模块，……应该只选择此方法来生成项目开发的候选者。
添加了一个名为EROS的战略平台来解决算法模型的问题。 EROS的主要特点是1）训练模型2）特征选择3）在线比较测试。
R9界面层和生成在线和离线候选精益增长的数据推荐了产生结果的一般策略。
图7微博推荐3.0的示意图
3.特点
它主要解释了它的优点：
它继承了原有的2.0特性并保持其优点。深入理解这些建议，并结合推荐的候选/对齐/训练算法的最重要解决方案
3.3结果
微博推荐3.0的诞生，结果如下：
微博推荐的核心业务逐步迁移到系统，算法数据作为提高效率的驱动因素。
技术来自业务并改善业务发展。业务发展是技术发展和相互影响的关系背后的驱动力。随着业务发展的技术还活着。
技术架构选择建议是目前找到最短路径然后迭代优化。将所有东西放在一起是不现实和不合理的。
推广框架和工具的最佳方式不是行政命令或待遇，但每个人都是参与者。与开源项目一样，每个人都是所有者，因此每个人都得到维护和使用。
本文来自投稿，不代表重蔚自留地立场，如若转载，请注明出处https://www.cwhello.com/164520.html
如有侵犯您的合法权益请发邮件951076433@qq.com联系删除
