伴鱼技术团队

Technology changes the world

伴鱼开放平台 上线了! 源于实践的解决方案,助力企业成就未来!

前言

在伴鱼,我们在多个在线场景使用机器学习提高用户的使用体验,例如:在伴鱼绘本中,我们根据用户的帖子浏览记录,为用户推荐他们感兴趣的帖子;在转化后台里,我们根据用户的绘本购买记录,为用户推荐他们可能感兴趣的课程;等等。

特征是机器学习模型的输入。如何高效地将特征从数据源加工出来,让它能够被在线服务高效地访问,决定了我们能否在生产环境可靠地使用机器学习。为此,我们搭建了特征系统,系统性地解决这一问题。目前,伴鱼的机器学习特征系统运行了接近 100 个特征,支持了多个业务线的模型对在线获取特征的需求。

下面,我们将介绍特征系统在伴鱼的演进过程,以及其中的权衡考量。

...

阅读全文 »

前言

本文记录了伴鱼 AI 平台团队这周做的一件投入-产出比极高的小事:通过 Flink 算子状态Redis Pipelining 的简单结合,把 FlinkRedis 大规模写入的效率提高了 7 倍。

问题背景

在伴鱼,算法工程师处理好的离线特征存储在 Hive 表中,伴鱼 AI 平台团队维护的 Flink 特征管道在 DolphinScheduler 引擎的调度下,定期将 Hive 中的离线特征批量导入基于 Redis 的在线特征仓库,为在线 ModelServer 提供低延迟的特征访问。由于离线特征的数量非常大,我们希望能优化特征管道对 Redis 的大规模写入,缩短写入的耗时。

...

阅读全文 »

背景

在伴鱼,服务器每天收集的用户行为日志达到上亿条,我们希望能够充分利用这些日志,了解用户行为模式,回答以下问题:

  • 最近三个月,来自哪个渠道的用户注册量最高?
  • 最近一周,北京地区的,发生过绘本浏览行为的用户,按照年龄段分布的情况如何?
  • 最近一周,注册过伴鱼绘本的用户,7日留存率如何?有什么变化趋势?
  • 最近一周,用户下单的转化路径上,各环节的转化率如何?

为了回答这些问题,事件分析平台应运而生。本文将首先介绍平台的功能,随后讨论平台在架构上的一些思考。

...

阅读全文 »

伴鱼离线数仓建立,与伴鱼的业务一起快速发展,从一条业务线,到多条业务线。在演进的过程中,有很多总结和沉淀的内容。本篇文章主要介绍伴鱼离线数据仓库的发展历史,在发展过程中遇到的各种问题,以及针对问题的解决方案。

...

阅读全文 »

背景

随着伴鱼课程业务需求和用户量的快速增长,涉及到实时和延时任务的场景也越来越多。例如课程录制、课程视频转码、课程视频上传以及相关的课程视频分析、老师学生行为分析、语音识别、情绪识别等算法离线预测任务等。这些任务都需要大量的计算、存储、网络等资源,而且不同的场景对任务的执行时间,调度策略又有不同的要求。如果由业务方来各自管理机器资源并且监控每个任务的状态,累积的维护成本会非常高,而且不方便统一管理。从整体来看,在资源有限的情况下,简单的调度逻辑已无法同时满足全部的任务需求。我们需要一个能进行任务调度、任务编排、异构资源管理、任务监控的分布式任务调度解决方案。但是如何在合理高效管理任务的前提下去做到节约资源成本,就成了我们需要面对的一个问题。

以录制任务为例,为了满足高峰期的需求,有二十多台 64Core 128G Memory 的物理机全天运转提供服务。然而实际上大部分时间机器资源都是闲置的,只有在用户上课时才会有任务执行,但为了用户体验和实时类课程录制,又不能临时减少机器数量。在类似业务的背景下,我们对系统功能要求进行了整理,并对业界开源项目和第三方产品进行了调研。

...

阅读全文 »

日常工作中,数据开发工程师开发上线完一个任务后并不是就可以高枕无忧了,时常会因为上游链路数据异常或者自身处理逻辑的 BUG 导致产出的数据结果不可信。而这个问题的发现可能会经历一个较长的周期(尤其是离线场景),往往是业务方通过上层数据报表发现数据异常后 push 数据方去定位问题(对于一个较冷的报表,这个周期可能会更长)。同时,由于数据加工链路较长需要借助数据的血缘关系逐个任务排查,也会导致问题的定位难度增大,严重影响开发人员的工作效率。更有甚者,如果数据问题没有被及时发现,可能导致业务方作出错误的决策。此类问题可统一归属为大数据领域数据质量的问题。本文将向大家介绍伴鱼基础架构数据团队在应对该类问题时推出的平台化产品-数据质量中心(Data Quality Center, DQC)的设计与实现。

...

阅读全文 »

在伴鱼发展早期,出现了一系列实时性相关的需求,比如算法工程师期望可以拿到用户的实时特征数据做实时推荐,产品经理希望数据方可以提供实时指标看板做实时运营分析。这个阶段中台数据开发工程师主要是基于「Spark」实时计算引擎开发作业来满足业务方提出的需求。然而这类作业并没有统一的平台进行管理,任务的开发形式、提交方式、可用性保障等也完全因人而异。

伴随着业务的加速发展,越来越多的实时场景涌现出来,对实时作业的开发效率和质量保障提出了更高的要求。为此,我们从去年开始着手打造伴鱼公司级的实时计算平台,平台代号「Palink」,由「Palfish」 + 「Flink」组合而来。之所以选择「Flink」作为平台唯一的实时计算引擎,是因为近些年来其在实时领域的优秀表现和主导地位,同时活跃的社区氛围也提供了非常多不错的实践经验可供借鉴。目前「Palink」项目已经落地并投入使用,很好地满足了伴鱼业务在实时场景的需求。

...

阅读全文 »

前言

本文是「算法工程化实践调研」系列的第 4 篇,介绍来自 DoorDash 在 2020 年 6 月发布的技术博客 Meet Sibyl – DoorDash’s New Prediction Service – Learn about its Ideation, Implementation and Rollout [1]。它介绍了预测服务 Sibyl(希腊神话中著名的女先知)的架构和发布过程。

架构

一个典型的机器学习预测服务要做的事情很简单:将模型加载好,根据请求信息,获取相关特征,将特征输入匹配的模型,得到预测结果并返回。

那么,我们能不能搭建一个预测服务,它能一致地处理所有的预测请求,并确保总能低延迟地返回预测结果呢?DoorDash 的预测服务 Sibyl 用下图这个简单的架构实现了这个需求。

high-level-flow

...

阅读全文 »

前言

本文是「算法工程化实践调研」系列的第 3 篇,介绍来自 Uber 在 2018 年 10 月发布的技术博客 Michelangelo PyML: Introducing Uber’s Platform for Rapid Python ML Model Development [1]。它介绍了 Uber 机器学习平台(以下简称平台)为了提高基于 Python 的迭代效率,而进行的一个有趣的演进。

性能 vs 迭代效率

我们在 Uber 机器学习平台实践一文中提到,平台早期着重于提高模型训练和预测的性能,而较少考虑迭代效率。

因此,对于平台内置支持的模型(XGBoost、GLM、回归等),算法工程师可以很容易地使用平台进行超大规模训练、在线和离线预测。然而,对于平台尚未内置支持的模型,例如最新发表的研究成果(Google BERT 等),则必须等到平台在特征工程、模型训练、模型部署和模型服务等多个环节均支持该模型,才能开始模型的线上评估。

这就带来一个问题。如果工程师花费了很多力气,终于用 Java / Scala 在平台层面支持了新模型,而模型上线后,模型评估的结果不佳,需要弃用该模型,那么前面的功夫就就都白费了。

...

阅读全文 »

前言

本文是「算法工程化实践调研」系列的第 2 篇,介绍来自 Uber 在 2017 年 9 月发布的技术博客 Meet Michelangelo: Uber’s Machine Learning Platform [1]。它介绍了机器学习平台 Michelangelo(意大利文艺复兴时期伟大的绘画家、雕塑家、建筑师和诗人)的各个组件的职能,第一次细致地向大家描述了机器学习平台应有的全貌。

现状和问题

Uber 有众多业务线,其中包含许多使用 ML 的场景,例如:共享出行 App 需要用算法预测乘客的到达时间、送餐 App 需要用算法为用户按照个人喜好为餐馆排序、客服中心需要用算法减少人工客服的介入,等等。多个业务线为了快速满足使用 ML 的需求,很自然地采了烟囱式的架构,逐渐产生了系统难以维护、模型难以上线等问题,亟需统一的解决方案来涵盖 ML 的全流程。

...

阅读全文 »