本文记录了伴鱼 AI 平台团队这周做的一件投入-产出比极高的小事：通过 Flink 算子状态和 Redis Pipelining 的简单结合，把 Flink 往 Redis 大规模写入的效率提高了 7 倍。
在伴鱼，算法工程师处理好的离线特征存储在 Hive 表中，伴鱼 AI 平台团队维护的 Flink 特征管道在 DolphinScheduler 引擎的调度下，定期将 Hive 中的离线特征批量导入基于 Redis 的在线特征仓库，为在线 ModelServer 提供低延迟的特征访问。由于离线特征的数量非常大，我们希望能优化特征管道对 Redis 的大规模写入，缩短写入的耗时。
伴鱼离线数仓建立，与伴鱼的业务一起快速发展，从一条业务线，到多条业务线。在演进的过程中，有很多总结和沉淀的内容。本篇文章主要介绍伴鱼离线数据仓库的发展历史，在发展过程中遇到的各种问题，以及针对问题的解决方案。
随着伴鱼课程业务需求和用户量的快速增长，涉及到实时和延时任务的场景也越来越多。例如课程录制、课程视频转码、课程视频上传以及相关的课程视频分析、老师学生行为分析、语音识别、情绪识别等算法离线预测任务等。这些任务都需要大量的计算、存储、网络等资源，而且不同的场景对任务的执行时间，调度策略又有不同的要求。如果由业务方来各自管理机器资源并且监控每个任务的状态，累积的维护成本会非常高，而且不方便统一管理。从整体来看，在资源有限的情况下，简单的调度逻辑已无法同时满足全部的任务需求。我们需要一个能进行任务调度、任务编排、异构资源管理、任务监控的分布式任务调度解决方案。但是如何在合理高效管理任务的前提下去做到节约资源成本，就成了我们需要面对的一个问题。
以录制任务为例，为了满足高峰期的需求，有二十多台 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 用下图这个简单的架构实现了这个需求。
本文是「算法工程化实践调研」系列的第 3 篇，介绍来自 Uber 在 2018 年 10 月发布的技术博客 Michelangelo PyML: Introducing Uber’s Platform for Rapid Python ML Model Development [1]。它介绍了 Uber 机器学习平台（以下简称平台）为了提高基于 Python 的迭代效率，而进行的一个有趣的演进。
我们在 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 的全流程。
本文是「算法工程化实践调研」系列的第 1 篇，翻译 Eugene Yan 的技术博客 Feature Stores - A Hierarchy of Needs [1]。
出于开发伴鱼特征平台的需要，我最近阅读了很多关于特征平台的实践文章，但总有「一叶障目，不见泰山」之感——每个公司的算法工程化现状不尽相同，导致解决方案的侧重点不同，在架构上的区别也很大。正如我的前同事佘昶在他 2019 年的一篇文章中，到位地总结：我们缺乏一个系统性地思考特征平台的框架。[2]
幸运的是，Eugene 的博客正好提供了这样一个思考框架，并将这个思考框架用于分析当前的各个特征平台上。我在征得 Eugene 的同意后，全文翻译，以飨中文读者。以下是译文。