|
近日，2016中国大数据技术大会（Big Data Technology Conference 2016）在京隆重举行。本次会议涵盖了大数据分析与生态系统、推荐系统等16场专题技术和行业论坛，来自中国科学院、蚂蚁金服、一点资讯等公司和机构的众多国内外大数据专家参会并发表演讲。
一点资讯大数据平台研发总监田超发表主题演讲 在大会现场，一点资讯大数据平台研发总监田超详细阐述了用户点击反馈背后的系统设计，并根据行业现有的种种问题，分享了一点资讯推荐系统背后大规模实时点击反馈系统的设计。 他指出，作为一家融合了搜索引擎和个性化推荐引擎技术的全网化内容平台，一点资讯可以根据用户不同使用场景、订阅频道下的点击反馈形成数据矩阵，对数据进行深层次挖掘，并通过大规模实时点击反馈系统和大规模机器学习进行智能推荐，引领兼具共性与个性的移动价值阅读潮流，使用户阅读体验不断提升。 以下是演讲节选： 大家下午好，我是来自一点资讯的田超，很高兴今天与大家分享一点资讯关于推荐系统后台的一些心得。
首先给大家介绍一下一点资讯的数据。目前，一点资讯的日活达4800万。与此同时，这里需要特别指出，一点资讯主动订阅用户数已达4700万。作为一家融合了搜索和个性化推荐的技术驱动型的全网化内容平台，与单纯搜集和反馈用户的历史浏览行为不同的资讯平台不同，我们更注重和鼓励用户主动表达，通过全网化的智能客户端，深度挖掘用户点击阅读背后的真实兴趣，不仅为大家带来有趣、有料也能提供有用、有品的价值内容。 实时点击反馈数据应用，让服务更智能化 熟悉搜索和推荐系统架构的朋友都知道，一直以来，这两种系统大都分工进行，但实际上在数据部分，二者存在很多可融合之处。这也是启发我们做出一套能够真正把搜索、推荐、广告等环节连接在一起，形成完整智能体验的推荐服务系统的基础。
一点资讯数据团队负责一点推荐平台背后的大规模机器学习基础设施的开发，推荐系统的后端主要是由基于用户画像的GBDT推荐平台和基于大规模离散LR的在线学习平台组成。今天我们会为大家介绍其中的一部分，也就是上图左边所示的大规模实时点击反馈平台的设计。 关于点击反馈的数据在每家后台系统上大概都有这样三部分的应用：第一部分是实时画像中的后验指标，包括了用户画像，内容画像和频道画像等；第二部分是实时的数据分析，让我们在做不同实验时，了解到不同人群、文章点击率的变化；第三部是在线的机器学习，后面我会详细介绍。 对于客户端来说，虽然推荐服务系统为我们带来很多便利，但同时也面临不少问题和挑战，下面我将从一点资讯的架构设计为例，为大家分别阐述五个方面的主要问题以及解决方式。 问题1：如何统一各种近似的实时Pipeline 第一个问题就是近似的pipeline大家怎么样去统一？做实时计算时，大家常常发现你的Storm、spark跑着各种各样相近但又不同的作业，这些作业中80%运算是相同的。这对系统实时更新、开发成本都会造成一定损耗。 在一点资讯内部，我们设计了一套叫Neo的点击反馈平台系统，统一了主要的实时点击反馈计算逻辑。 Neo系统的核心数据结构是一个Multi-Dimensional Matrix（多维矩阵），用以描述用户在各个维度和粒度的兴趣属性和基础属性两部分，可以在不同维度和数据粒度上进行各种聚合运算。其次，我们围绕着核心数据结构构造了整个运行时的framwork（框架），可以支持用户自定义自己的算子，也因此节省了对数据流的压力。 问题2：实时计算和离线计算的统一 第二个问题说怎样实时计算和离线计算的统一？ 实时计算与离线计算的统计是流式计算领域里的研究热点之一，对于我们的生产工作来说也有着比较重要的实际意义，市面上有一些开源和技术和论文包括Spark、SummingBird、Google DataFlow等都对如何实现自己的解决方案。 一点资讯采用的是Lambda architecture，对于核心计算逻辑有一套统一的数据结构抽象和计算算子抽象。我们本质上处理的是事件流在不同矩阵上以不同粒度聚合的问题，这里尤其是对于矩阵的Delta和Base之间的计算，我们给出了一套比较完整的抽象。这一套核心代码可以同时跑在Storm/JStorm， Spark、Mapeduce这样的平台上，使离线和在线计算相结合。 问题3：数据变化如何追踪与Debug 我们的平台除了思考上面所述的数据结构和计算模型进行统一之外，还考虑到了时间的因素。时间是一个非常重要的维度，对于我们的计算引擎也是一个挑战。总结来说，包括这几个问题：不同类型的Feature需要不同的淘汰策略，需要能够计算各种时间周期上的feature、需要能够知道数据历史变化的状态、数据分析需要追踪指标变化曲线。 对于这些问题，我们构建了比较完整的windowingmodel（窗口模型）的实时计算模型：在hbase上存储细粒度的delta数据，这一部分的数据是实时更新的，每次更新时计算pipeline（管道）会通过kafka写入一个WAL，有一个Pusher组件会监听这个WAL，并可以根据自定义的策略对不同的数据表采用不同的window计算模型；在pusher层面，支持各种时间窗口淘汰策略，包括Fixedwindow，session window，slidingwindow，decay，last value win等。 问题4：线上高性能存储引擎 一点资讯在高峰期产生的2M+QPS的读请求，和200K+的更新量，因此对我们线上的分布式存储系统会有比较高的性能要求，市面上线程的分布式存储方案都不能解决我们面临的问题。 因此我们开发了自己的分布式存储系统NeoDB，底层基于Rocksdb，上层使用定制的ThriftRPC接口，我们对系统层次做了很多的优化，包括把一些部分计算可以推到最底下节点上、减少Compaction的层次，控制Compaction对于读请求的影响、控制写放大，优化缓存命中率等。 问题5：如何监控和维护整个系统 最后一个问题怎么样做监控和维护整个系统。这里面涉及到一些问题，主要包括怎么对数据流lag做监控报警。对流式计算如何做profiling（分析），线上如何做负载均衡等。我们针对这些问题开发了两个系统，一个是我们开发了YMetric的监控系统。客户端兼容codahale metrics库，会将metric汇总发送到Kafka中，并由我们统一的Storm Pipeline进行聚合计算，结果存储在openTSDB之中。我们的这套系统支持多Metric的自定义计算、报警、Trending预测等。 另外一个系统是ycluster的线上服务，她有点像Apache Helix，但是我们做的更为简单易用，YCluster是一套基于Zookeeper的分布式负载均衡和机群管理系统，支持Multiple Service Namespace、Hash Sharding、Multiple Replica。同时我们基于YCluster做了Neo系统的Smart Client，通过这套Smart Client完成路由和负载均衡的工作，我们支持多种不同负载均衡的算法，包括简单的Random和Round-Robin、，同时我们做了一个叫做link Scheduler的负载均衡的算法，可以支持多数据中心中的本地优先调度，并支持相同副本的优先调度，从而大幅度提升了缓存命中率。 由于时间有限，今天我的分享就到这里，非常欢迎对推荐后台感兴趣的朋友与我有进一步交流，谢谢大家。 |
|
|
