实时计算的概念很难定义，每个人对这四个字的理解可能都不同。个人观点主要分为两块：数据的实时入库和数据的实时计算。

数据实时入库的时候，一般都需要对原始数据做一定的处理再入库。能在这个步骤计算尽量在这里完成。 这个类似数据的预算后入库，然后提供直接读取服务。对用户的延时性上最好。

然而有一些对数据的计算并不能通过预算解决全部问题，比如搜索。这篇主要讲实时计算的应用场景，技术架构、实现细节以后写。

实时计算比较常在数据分析类应用中出现，由于数据分析时刷选条件多样性与多变性，使数据无法预算，所以只能通过后期的实时计算。

Facebook的实时系统中大量应用到了hadoop、hbase。

他们的项目需求主要有：
1. Elasticity（伸缩性）

2. High write throughput（高写吞吐量）

3. Efficient and low-latency strong consistency semantics within a data center（单个data center内高性能、低延迟的强一致性）

4. Efficient random reads from disk（disk的高性能随机读）

5. High Availability and Disaster Recovery（高可靠性、灾后恢复能力）

6. Fault Isolation（错误隔离）

7. Atomic read-modify-write primitives（read-modify-write原子操作）

8. Range Scans（范围扫描）

Facebook对HBase、HDFS做了大量优化，但毕竟是基于MapReduce(IO是硬伤)，再优化也无法达到互联网应用级别的响应延时。用户搜索“2011手机” 又选择了属性：智能机、直板，想看这个月满足这些条件的交易在不同省份的分布。如果过个10s以上才返回数据分析结果，我都不好意思说自己是做互联网的。

上面的是Facebook实时分析系统的需求，我们的实时计算系统的主要需求如下：

1、海量数据
2、提供各类计算
3、支持任何条件的搭配
4、实时响应(秒级)
5、结果精确

所以我们需要放弃MapReduce的思想，自己设计新的计算架构。 乍一看需求，和搜索很类似。的确，实时计算中大量用到了搜索技术。

与搜索的主要区别：

目的不同：搜索的目的是排序、实时计算的目的是汇总计算
结果不同：搜索返回的是list、实时计算返回的是计算的精确结果
读取数据不同：搜索可以根据权重取topN的数据做排序、实时计算需要获取所有满足条件的数据做计算。

想象一个应用场景(假设我需要的属性都能获得)：

1、我想知道昨天访问我博客的访问量 —> 这个很简单，根本不需要实时计算
2、我想知道昨天来自每个省份对我博客的访问量 —> 这个也简单，我提前把每个省的访问量都预算好就行了
3、我想知道昨天来自每个省份不同性别的访问量分布 —> 这个也不难，也就36*2 = 72条记录，我也提前预算好了。
4、我想知道昨天来自每个省份不同性别不同年龄的访问量分布 —-> 有点够呛，不过也不难 ，继续预算
5、我想知道昨天来自每个省份不同性别不同年龄不同职业的访问量分布 —> 数据量开始膨胀，预算时间也开始变久，数据已经快上亿级别了。而且你会发现，很多组合的预算都是没有意义的，比如 “上海+女+99岁+狙击手”、“西藏 + 女 + 屠夫” 这样的查询组合根本不可能有数据。
6、我想知道昨天来自每个省份不同性别不同年龄不同职业不同名族的访问量分布 —> 不考虑预算了，数据量早就上亿了，而且很多计算都是没有意义的。So 实时计算的作用发挥了。

总结下：

当数据量很大，同时发现无法穷举所有可能条件的查询组合 或者 大量穷举出来的条件组合无用的时候是实时计算最佳的应用场景。

猜你喜欢：

Zoie实现实时搜索的原理

Facebook技术体系窥探之基础组件

海量数据实时计算随笔

Facebook技术体系窥探之P级数据

用好Cache，优化应用

无觅