本文是「算法工程化实践调研」系列的第 1 篇，翻译 Eugene Yan 的技术博客 Feature Stores - A Hierarchy of Needs [1]。
出于开发伴鱼特征平台的需要，我最近阅读了很多关于特征平台的实践文章，但总有「一叶障目，不见泰山」之感——每个公司的算法工程化现状不尽相同，导致解决方案的侧重点不同，在架构上的区别也很大。正如我的前同事佘昶在他 2019 年的一篇文章中，到位地总结：我们缺乏一个系统性地思考特征平台的框架。[2]
幸运的是，Eugene 的博客正好提供了这样一个思考框架，并将这个思考框架用于分析当前的各个特征平台上。我在征得 Eugene 的同意后，全文翻译，以飨中文读者。以下是译文。
什么是算法工程化？一图胜千言 [1] ——算法工程化关注如何搭建 ML 基础架构（白色和灰色的模块），使得 ML 算法（蓝色模块）落地，发挥作用。
ML 算法落地难，几乎是每一个智能驱动的公司都要面临的挑战，伴鱼也不例外。为了系统性地解决这个问题，我在 2021 年初加入伴鱼，开始组建 AI 中台团队。我希望团队能够「仰望星空，脚踏实地」——大量阅读业界的最新实践，博采众长，应用于公司的 AI 中台建设，去攻克投资-回报比最高的方向，更好地服务于公司业务的增长。在这个过程中，我希望把阅读到的业界的算法工程化实践通过「调研」的方式和大家一起分享。
目前，「调研」系列已经包括以下文章：
欢迎大家讨论、交流，对我们团队感兴趣的还可以看看我们的求贤贴 😁。
[1] https://developers.google.com/machine-learning/crash-course/production-ml-systems
最近，我们遇到了两个场景：
仔细分析不难发现，二者的本质都在于「维护微服务间的静态依赖关系」。等等！在调用链追踪系统中，我们不是已经获得了接口级别的依赖关系吗？为什么不能直接用那边的数据？目前伴鱼调用链追踪系统中维护的依赖关系在三个方面无法满足上述需求：
随着伴鱼业务和用户的快速增长，公司运营活动的形式也越来越丰富，从活动的大类上总结有（包括但不限于）：团购活动、排行榜&拉票活动、红包雨活动、预售秒杀活动、抽奖活动等，这些运营活动对于提升转化、用户留存和高用户活跃度等会起到重要作用，因而运营活动占用了增长部门非常多的研发资源。
其中，形如：“用户 A 完成了 W 动作发放 X 奖励（或者触发某种逻辑）”这样形式的需求会比较常见。在初期承接的过程中，各自活动独立开发，有许多重复的开发量，并且即使是重复的部分仍然需要测试同学的介入，各方都有很大的资源投入，并且还会导致整体流程会很长，通常一个活动开发联调和测试时间需要两周左右。所以，高效可复用地进行运营活动是 ROI 非常高的一件事情。
前言中提到了活动中经常出现形如：“用户 A 完成了 W 动作发放 X 奖励”这样形式的需求，如下图所示，我们将满足这种语法的需求定义为一个任务：
在 理论篇 中，我们介绍了伴鱼在调用链追踪领域的调研工作，本篇继续介绍伴鱼的调用链追踪实践。在正式介绍前，简单交代一下背景：2015 年，在伴鱼服务端起步之时，技术团队就做出统一使用 Go 语言的决定。这个决定的影响主要体现在：
2019 年，公司内部的微服务数量逐步增加，调用关系日趋复杂，工程师做性能分析、问题排查的难度变大。这时亟需一套调用链追踪系统帮助我们增强对服务端全貌的了解。经过调研后，我们决定采用同样基于 Go 语言搭建的、由 CNCF 孵化的项目 Jaeger。当时，服务的开发和治理都尚未引入 context，不论进程内部调用还是跨进程调用，都没有上下文传递。因此早期引入调用链追踪的工作重心就落在了服务及服务治理框架的改造，包括：
context 的命令行工具部署方面：测试环境采用 all-in-one，线上环境采用 direct-to-storage 方案。整个过程前后大约耗时一个月，我们在 2019 年 Q3 上线了第一版调用链追踪系统。配合广泛被采用的 prometheus + grafana 以及 ELK，我们在微服务群的可观测性上终于凑齐了调用链 (traces)、日志 (logs) 和监控指标 (metrics) 三个要素。
下图是第一版调用链追踪系统的数据上报通路示意图。服务运行在容器中，通过 opentracing 的 sdk 埋点，Jaeger 的 go-sdk 上报到宿主机上的 Jaeger-agent，后者再将数据进一步上报到 Jaeger-collector，最终将调用链数据写入 ES，建立索引，即图中的 Jaeger backends。
本文将调用链追踪系统的设计维度归结于以下 5 个：调用链数据模型、元数据结构、因果关系、采样策略以及数据可视化。我们可以把这 5 个维度当作一个分析框架，用它帮助我们在理论上解构市面上任意一个调用链追踪系统，在实践中根据使用场景进行技术选型和系统设计。如果你对调研相关系统很感兴趣，也欢迎参与到 Database of Tracing Systems 项目中，一起调研市面上的项目，建立起调用链追踪系统的数据库。
阅读本文并不要求读者具备任何调用链追踪系统相关的理论知识或实践经验，读者具备一定的微服务架构的概念或实践经验即可。期望读者看完这篇文章以后，能掌握调用链追踪系统的核心设计维度，理解其中的设计权衡，并能使用这些维度来分析市面上的新老调用链追踪系统实现，甚至帮助到自己在生产实践中根据使用场景进行技术选型和系统设计。
本文介绍一种内存列存数据格式：Apache Arrow，它有一个非常大的愿景：提供内存数据分析 (in-memory analytics) 的开发平台，让数据在异构大数据系统间移动、处理地更快。同时，比较特别的是这个项目的启动形式与其他项目也不相同，Arrow 项目的草台班子由 5 个 Apache Members、6 个 PMC Chairs 和一些其它项目的 PMC 及 committer 构成，他们直接找到 ASF 董事会，征得同意后直接以顶级 Apache 项目身份启动。
本文从以下几个方面来介绍 Arrow 项目：
注：Arrow 即可以指内存列存数据格式，也可以指 Apache Arrow 项目整体，因此下文中将用 「Arrow」 表示格式本身，「Arrow 项目」表示整体项目。
波塞冬，是伴鱼活动运营解决方案的总称，包含活动规则体系、h5 可视化开发平台等，名称来源于古希腊神话，波塞冬是海洋和所有水系的管理者，寓意为 palfish 发展提供超能力。
随着伴鱼业务的高速发展，大量促增长的活动接踵而来， 原有的研发模式暴漏出一系列问题，如后端逻辑混杂、复用度低、维护成本高，前端灵活性差、效率低，为了提升公司运营效率，我们急需探索一套符合公司现状的技术体系，为公司的业务高速发展提供平台支撑。
万物终有源，要解决掉面临的问题，我们从整个研发、运营链路出发寻找答案。研发链路上在前后端分离的技术大背景下，我们的目标是要最大化的实现后端服务复用、前端页面复用，对运营而言是能够快速灵活的对活动策略、展示作出修改，来查验各种活动对业务的作用效果，基于以上思考，我们抽象了波塞冬平台的业务模型。
PingCAP 团队的论文《TiDB: A Raft-based HTAP Database》入选 VLDB 2020，这是对 TiDB 数据库阶段性成果的肯定，非常为国内数据库技术的快速发展而感到高兴。由于关于 TiDB 数据库在高可用、水平扩展和 ACID 事务的实现方案很久以前就已经公布出来了，对于这些主题大家都比较熟悉，所以就不再赘述了，下面主要谈谈论文中关于如何实现数据强一致性且资源隔离的 HTAP 数据库的一些启发和感想。
大家都知道数据库分为 OLTP 和 OLAP 类型，那么数据库为什么要分成这两类型呢？
首先，OLTP 和 OLAP 是定义数据处理方式的，这是两个差异特别明显的工作负载，OLTP 操作是涉及数据少，但是实时性和事务要求高，并发量大；OLAP 操作是实时性和事务要求低，但是涉及数据量大，并且查询模式不固定，很难通过索引来覆盖。其次，早期的数据库是没有 OLTP 和 OLAP 类型之分的，在一个数据库（主要为关系数据库）里进行 OLTP 和 OLAP 类型的数据相关的操作，后来数据量慢慢变大，直接在关系数据库中同时处理 OLTP 和 OLAP 类型的请求开始力不从心，更坏的情况可能还会影响到 OLTP 类型的请求，所以针对 OLAP 场景设计了更符合其工作负载的 OLAP 类型数据库，通过将 OLTP 类型的数据同步到 OLAP 类型的数据库，然后再进行 OLAP 类型的操作。