从零开始设计基于AKKA的实时数据产品

提起实时数据产品，开车的朋友可能会想到实时路况，喜欢购物的朋友可能会想起阿里双十一的销售额大屏幕，而玩股票的朋友印入脑海的一定是实时K线图。数据最大的价值就是用来做决策，那么实时数据的应用场景就是需要实时做决策的地方——前面路况不好时，你会随机应变的换一条路走；阿里的大屏幕数字增长不利的，可能会去看看是不是服务器又被挤垮了；股票涨到你的心理价位了，你会立刻卖掉。这些场景的特点就是，情况实时变化，而你需要根据这个情况随机应变，随时决策。金融的实时交易和对冲系统、O2O的实时运营系统以及未来的机器人所依赖的智能AI系统等等，都将会是实时计算系统非常好的应用场景。

从12年加入百度移动云开始，我就一直与移动互联网的数据分析和数据产品打交道。随着移动互联网的发展，场景化的需求的爆发，特别是经历过某打车公司的实时运营系统之后，我坚信实时数据产品一定会随着行业的快速发展，逐渐成为产品设计和产品运营中不可或缺的组成部分。很快，我遇到了基于AKKA的实时计算系统，并有幸跟随大牛草原老师学习这个系统的特性，合作了公司自己的实时计算系统CHANA。目前CHANA这个系统已经开始实际应用到具体的业务中——不仅有实时统计分析的结果，还有直接跟业务结合的实时计算服务输出。

从零开始，我对AKKA一无所知

初次接触AKKA的时候，除了知道它可以用来做实时计算系统之外，我对它一无所知。此前我接触过的实时计算框架中，Storm有过短暂的尝试，Sparkstreaming只是听说过。这两位同基于AKKA的实时计算系统有什么异同呢？这是我的第一个问题。不了解系统的特性，意味着你对将来基于这套系统的产品失去掌控力。因此，我的首要任务，是充分理解基于AKKA的这套实时计算系统的特性。

经过搜索网上的资料，然后我跟工程师请教之后，初步明白了AKKA的特性。基于AKKA的实时计算系统最大的特征在于它的Actor。任何一个变化中的对象，在AKKA系统中都可以抽象成一个实体，这个实体就是Actor。一个Actor相当于一个计算单元，它会实时的记录当前对象状态的变化。通过对这个Actor状态变化的时间序列进行持久化（实时存储），我们不仅可以得到对象当前的状态，还可以随时查询对象的历史状态。当有一个用户进入系统的时候，就有一个对应的Actor来记录这个用户的状态——下了一个应用、做了一次登录等。Actor会时刻记录用户的最新状态，并将其每次状态的变化都存储起来，直接用户退出。当用户再次进来的时候，我们会直接恢复之前这个Actor的状态，继续随着用户的状态更新。

AKKA就是个实时的状态记录和更新系统，这点与Storm等分布式实时计算系统不太一样——Storm们并不会保存用户的状态，只是不断的计算“流”过来的日志。这个特性，非常适合移动互联网下的场景化需求。因为在移动互联网时代，用户的状态也会实时变化，需求也随之变化。此时我们需要实时的根据用户当前需求的变化，来提供相应的服务和反馈，这就是我在第一段中提到的典型的实时计算应用的场景了。

初识AKKA，开始需求调研

作为一款先在公司内部应用的系统，了解公司内部的业务需求便是接下来最重要的事情了。经过对公司内部不同业务线同事的调研，我发现一个非常大的问题。公司内部的业务线人员基本上对这个系统一无所知，包括了比较高级别的管理人员。于是在后面的沟通中，我开始不断的安利AKKA的各种特性，普及这个系统的基础知识。大约一个星期之后，我发现要让业务线了解这个项目，仅仅是口头传输信息不够具象，大家都能没有这个时间与精力去理解这个系统。

因为我自己是产品经理，用产品说话是我擅长的事情。于是第一个产品的目标就来了：设计一个实时数据产品，能够让公司内部的业务线人员能够对AKKA这套系统有一个比较直观的认识。带着这个需求我开始调研市面上的各种实时数据分析系统：Googla Analytics、Talkingdata等第三方统计工具的实时模块、实时内容分析系统Chartbeat，甚至还看了BBC的实时新闻推送系统Trending。最开始，我希望这款产品能够非常简单、直观的让大家明白AKKA的特性。因此希望通过调研从市面上，比较成熟的实时数据产品中，找到比较适合的产品原型。

在调研的过程中，我也不断跟业务线交流，随时把各种想法同大家沟通。最终一个以Google Trends为基础的实时Trending系统的想法逐渐在我脑中成熟。Trends类的产品在国内应用非常广泛。百度指数、一淘商品搜索指数等产品几乎是市场人员手中的不可或缺的工具。作为一家APP分发商，热门APP的下载趋势是一个比较容易被理解的产品形态，而且离业务线的实际应用场景也非常的近。

产品定位：用户级和战略级

给业务线呈现的产品以Trending为原型已经基本确定，但是这还只是第一步。一旦Trending开发上线，完成我们的目标，让业务线能够对整个系统特性有所了解。那么业务线有关实时计算的需求，就会纷至沓来，此时我们的平台要以什么样的角色来承接这些需求，又以什么产品来满足这些需求呢？

经过先前的调研，了解到公司内的业务线对实时计算的需求目前来看，主要可能有两种：

需要实时统计的结果数据，来对业务做决策：
- 场景1：产品首页的卡片排序，需要针对用户实时浏览情况，来做个性化的排序；
- 场景2：PUSH产生的浏览和点击行为，需要实时计算，及时的调整PUSH策略；
- 场景3：新APP首发等活动，有效时间紧在2-3天，时效性较强，需要比较实时的查看数据及时的调整首发策略。

需要实时计算的API来嵌入到业务的一些应用场景中，这个应用的场景就需要我们不仅仅是作为一个计算系统，而需要介入到业务中，利用实时计算系统生成的结果，来提供面向用户的产品。比如热门类型的榜单排序、同用户当前实时状态有关的信息集合推送与呈现等。

再抽象一下，其实都是对数据API的需求，前者是直接实时统计结果的API，后者是对实时统计结果再进行一层计算的API。所以这个时候，我考虑整个实时计算系统对外输出的产品形态就是各种类型的API，亦即Data as a Service 数据即是服务。我们的第一款数据产品Trending就是第一批API的使用方。

在这种背景下，我们的系统最终是为C端用户服务，因此产品的定位必须是一个用户产品。对公司来说，从以离线计算为基础的天级别的决策，进化到以实时计算为基础的秒级别的决策，是一个重大的决策方式和决策链条的改变。前者是一个中心化的决策机制，后者是一个去中心化的决策机制。因此，这款产品一定是一个公司战略级别的产品。

设计一款产品，定位极其重要。

定位成用户级产品，意味着我们的用户不仅仅是公司内部的这几百好人。未来还可能会有几千、几万甚至十万、百万、千万级别的用户。这个时候我们的系统需要有能力支持这么打用户量的计算能力，不论是稳定性还是可扩展性都必须要非常的强大。此外，直面用户意味着我们不能只是埋头做底层系统，还需要以不断的同业务保持沟通，获取源源不断的用户需求，并将其产品化，那么迭代速度就不能太慢。

随着公司在移动互联网上发展的深入，开始越来越关注用户场景化的需求，实时计算系统能够成为公司战略的保障。此外，一个战略级的产品，意味着它会比较超前，理解的人会比较少，因此我们更不能只是埋头做系统，而是要时时刻刻将我们的能力通过可视化的方式展现给大家，让公司能够听到、读到、看到，并最终理解这个系统——你强，还得让大家知道你强，并且知道你强对大家有什么好处。

产品计划：Trending与CHANA

在这种定位思路下，我将产品分为两个部分：

第一个部分是偏业务应用型的Trending产品。它具有以下特征：

业务导向，需要随着业务的变化进行快速反应，以周为单位快速迭代；
开发者中心，展示自己的实时计算平台的能力，为应用方提供各类API的使用示例。

第二部分是偏底层平台的（名字就不重要了：-））。它具有以下特征：

能为上层应用提供稳定的实时计算服务，能够不断的提供新的能力，满足业务需求；
能够接入多种数据源进行实时处理。

实际上底层平台的产品规划主要依靠团队的架构师来做。于产品经理来讲，主要是要提供一些业务的应用方向，方便架构师对底层平台进行架构设计。在这个项目中，产品对平台的要求分用户和能力，在用户上是希望能支撑更大用户量级的用户产品。在能力上是希望能够接入多种数据源，将实时计算能力变成API输出，且输出结果能够实时查询。

同架构师以及项目经讨论之后，我们将整个的项目框架确定：

实时数据产品的项目框架

同时在架构师草原老师的建议下，我们整个项目的名称定为CHANA（中文刹那的拼音：-））。

制定Roadmap

产品的定位和整体的项目框架确定以后，我们需要制定一下整个项目的Roadmap。因为项目本身具有比较明显的平台属性，考虑到平台本身的研发过程会比较长，所以我们的Roadmap需要以年为单位来进行制定。

在应用层，主要的里程碑就是各种发布了。而发布什么，需要具体每个季度根据业务的目标的改变而制定，因此我们在应用层只做一个季度的Roadmap。在第一季度，我们的目标就是完成Trending的产品设计，并且在公司内正式上线。

Trending产品的框架如下：

实时数据产品的产品框架

在第一期的发布中，我们希望Trending产品能够比较好的展示当前平台的能力，一方面能够提供实时数据统计结果的API，另外一方面能够提供一个基于当前实时统计结果进行计算之后的API。在一开始，我们选择统计应用的下载次数作为实时统计的一个结果，而根据这个统计结果，我们还提供实时的热门下载的排行榜。这个排行榜不同于我们现在在各类应用商店看到的24小时排行/日周月排行。他是一个变化的榜单，根据设计者定义的不同时间尺度和算法，能够在一天之内提供多次变化，让在不同时间推广、发布的应用能够在不同的时间段内上榜，提高了应用的曝光率。此外，为了在业务上更具有参考意义，我们还加入了地理位置和应用类别（应用、游戏、网游、单机等）的维度，让榜单更可用。这些实时统计的结果和计算之后的榜单，都会在我们的前端页面中实时呈现，作为我们实时计算能力的综合展现平台，也是未来的开发者中心的雏形。

而在平台层，我们希望在一年过去之后，最好能够满足百万级用户量级的计算，拆解成每一期的目标则是在第一阶段实现以应用（包名）为基础的实时计算，量级在万；第二期则要实现以内容（URL）为基础的实时计算，量级约在十万；第三期则要实现以用户（UID/UDID）为基础的实时计算，量级约为百万。此外还有持久化、实时查询以及多数据源接入等能力的研发，来保证应用层拥有更多的能力去满足业务的应用场景。

最后，我们要根据整个Raodmap来确定需要的各种资源。在资源不足的时候，需要根据现有资源去调整Roadmap。具体的项目进度我这里就不列出来了。毕竟每个公司能够获得的资源不一样，项目的进度也会有千差万别。基本的目标定好了，怎么操作就看公司与个人的喜好了。

产品设计、项目管理、产品发布

具体到了产品的设计和项目的管理方面，就看各自公司、团队的习惯了。

作为一个偏平台的项目，我们的在项目管理上会有比较有特点的是双线进发——一方面是Trending以周为迭代周期，会随着业务需求的变化和快速响应，另一方面CHANA的平台层会在架构师的带领下，有着以季度为单位的迭代周期和长远的发布目标。如何平衡这两者的节奏，是比较困难的。

另外在偏业务的数据产品中，如何与业务划分界限——能够提供业务所需的能力，又不会被业务需求频繁的变动所牵制，保持自己平台的独立发展特性，也是一个非常困难的部分。很多数据产品，做着做着就变成业务线的附庸，同业务线结合过于紧密而失去了独立发展的能力，最终导致平台的发展也变成业务的附庸。这样就会让整个项目从平台变成业务系统，是得不偿失的。

因为这两个问题在不同的背景下会非常不同，我在这里仅以自己的经历，来提供一些经验。

平衡节奏方面：应用层只用在平台上已经比较成熟的技术和能力，只打磨用户产品，不做技术创新。

在产品设计的初期，产品经理就要同架构师进行非常深入的沟通，深入的去了解产品的特性，当前的问题以及未来可以发展的方向。应用型产品应用的，一定是平台层比较稳定的技术。当时Trending上线时，就用的是上一个季度整个实时计算平台已经比较成熟的一些技能能力和结果。因此，Trending在设计初期，就可以完全放心的使用这些API。这也是为什么我们会让平台层以季度为目标去迭代。

平衡业务方面：避免与业务紧密耦合，所有数据服务以API的形式提供，平台始终保持独立开发。

避免与业务紧密耦合主要是指的保持平台的独立开发。因为业务线的KPI一定是业务增长，对平台要求的变化会非常快，这样最终平台就做成了一个业务系统。一旦平台不能不断的提供新的能力给应用层，那么应用层的发展也会停滞，导致整个项目最终失败。这也是为什么我在开始设计这款产品的时候，提出我们所有的数据服务以API的形式提供，主要是考虑到平衡灵活性与独立性，这也是为什么CHANA这样一个偏底层平台的项目中，会有一个跟业务紧密结合的Trending——它就是为业务而生，灵活快速是它的特点。同时Trending作为业务需求的沉淀，可以为平台提供发展的方向，同时让平台新的能力有一个展示和测试场景，促进平台发展。

因为线上的业务涉及到公司内部数据，因此这里我展示下设计过程中的两个设计稿（其实都是过程稿，最终产品的形态跟截图有一些出入）：