你了解实时计算吗？

实时计算是什么？

请看以下的图：

我们以热卖产品的统计为例。看下传统的计算手段：

1. 将用户行为、log等信息清洗后保存在数据库中.
2. 将订单信息保存在数据库中.
3. 利用触发器或者协程等方式建立本地索引，或者远程的独立索引.
4. join订单信息、订单明细、用户信息、商品信息等等表，聚合统计20分钟内热卖产品，并返回top-10.
5. web或app展示.

这是一个假想的场景，但如果你具有处理相似场景的经验，应该会体会到这样一些问题和难处：

1. 水平扩展问题（scale-out）
   
   显然。如果是一个具有一定规模的电子商务站点，数据量都是非常大的。而交易信息由于涉及事务。所以非常难直接舍弃关系型数据库的事务能力。迁移到具有更好的scale-out能力的NoSQL数据库中。

   
   
   那么，一般都会做sharding。

   历史数据还好说，我们能够按日期来归档，并能够通过批处理式的离线计算，将结果缓存起来。
   可是，这里的要求是20分钟内。这非常难。
   
   

2. 性能问题
   
   这个问题。和scale-out是一致的。如果我们做了sharding。由于表分散在各个节点中，所以我们须要多次入库，并在业务层做聚合计算。
   
   问题是，20分钟的时间要求，我们须要入库多少次呢？
   10分钟呢？
   5分钟呢？
   实时呢？
   并且，业务层也相同面临着单点计算能力的局限。须要水平扩展。那么还须要考虑一致性的问题。
   所以，到这里一切都显得非常复杂。
   
   
3. 业务扩展问题
   
   如果我们不只要处理热卖商品的统计。还要统计广告点击、或者迅速依据用户的訪问行为推断用户特征以调整其所见的信息。更加符合用户的潜在需求等，那么业务层将会更加复杂。

或许你有更好的办法，但实际上，我们须要的是一种新的认知：

这个世界发生的事，是实时的。
所以我们须要一种实时计算的模型。而不是批处理模型。
我们须要的这样的模型。必须能够处理非常大的数据。所以要有非常好的scale-out能力，最好是，我们都不须要考虑太多一致性、复制的问题。

那么，这样的计算模型就是实时计算模型，也能够觉得是流式计算模型。

如今如果我们有了这样的模型。我们就能够愉快地设计新的业务场景：

1. 转发最多的微博是什么？
2. 最热卖的商品有哪些？
3. 大家都在搜索的热点是什么？
4. 我们哪个广告，在哪个位置。被点击最多？

或者说。我们能够问：

这个世界，在发生什么？

最热的微博话题是什么？

我们以一个简单的滑动窗体计数的问题，来揭开所谓实时计算的神奇面纱。

如果，我们的业务要求是：

统计20分钟内最热的10个微博话题。

解决问题，我们须要考虑：

1. 数据源
   这里，如果我们的数据。来自微博长连接推送的话题。
   
   
2. 问题建模
   我们觉得的话题是#号扩起来的话题，最热的话题是此话题出现的次数比其他话题都要多。

   
   比方：@foreach_break : 你好,#世界#,我爱你。#微博#。
   “世界”和“微博”就是话题。

   
   
   

3. 计算引擎
   我们採用storm。

   
   
   

4. 定义时间

怎样定义时间？

时间的定义是一件非常难的事情。取决于所需的精度是多少。
依据实际，我们一般採用tick来表示时刻这一概念。

在storm的基础设施中，executor启动阶段，採用了定时器来触发“过了一段时间”这个事件。

例如以下所看到的：

(defn setup-ticks! [worker executor-data]
  (let [storm-conf (:storm-conf executor-data)
        tick-time-secs (storm-conf TOPOLOGY-TICK-TUPLE-FREQ-SECS)
        receive-queue (:receive-queue executor-data)
        context (:worker-context executor-data)]
    (when tick-time-secs
      (if (or (system-id?
 (:component-id executor-data))
              (and (
                  查看全文