提起实时数据产品，开车的朋友可能会想到实时路况，喜欢购物的朋友可能会想起阿里双十一的销售额大屏幕，而玩股票的朋友印入脑海的一定是实时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的使用示例。
第二部分是偏底层平台的（名字就不重要了 ：-））。它具有以下特征：
能为上层应用提供稳定的实时计算服务，能够不断的提供新的能力，满足业务需求；
