撇开技术，初识实时数据处理

hello！艾瑞巴蒂！

今天俺给大家换换心情，撇开技术，聊聊实时数据处理的前世今生。

曾经有那么几年的光阴，整个业界（大数据）言必称Hadoop，撩个妹不懂点Hadoop都被人看不起。

当然，hadoop在海量数据处理上绝对是毫无争辩的霸主：

比如 百度用户短时间对侧边栏广告的点击数据就可以达到几亿，百度使用hadoop对这些庞大的日志数据每天做一次全量处理，分析出用户习惯等信息，单次处理的数据量达到GB甚至TB级别， 这在关系型数据库时代是不敢想象的。

再比如电商将用户前一天的行为轨迹数据进行分析，分析用户的购买意向，在用户下一次搜索商品时，就可以推荐用户搜索过或相关的商品。大家欣喜的发现电商变的如此聪明，竟然知道你想要买什么东西。 

可是慢慢大家发现有两个问题：

01

线上发布一个商品时，用户在第二天或者更晚时候才能搜索到这个商品

02

用户搜索并购买某个商品后，搜索系统在相当一段时间内依然会不遗余力的推荐此类商品

这时优秀的产品经理就去找研发说时差一天太长了，能不能缩短到1秒内，这样用户刚刚搜索过的商品，系统马上就能在下一次搜索时给予推荐，帅（逗）帅（逼）的研发一边端详着一张“老师”的艺术照一边吐出四字真言：实现不了。

可是总有些研发迫于产品的*威，琢磨将数个小时缩短至1秒钟的解决方案。但是hadoop的基础架构是典型的批处理模式，从数据准备，启动调度，作业运行最起码要几分钟，还不考虑数据抓取，数据重写，磁盘参与运算的时间，这就好比富士康生产IPHONE，需要将CPU、GPU、电池、屏幕、外壳等元件在不同的厂家生产好，运输到富士康的组装车间才能完成，少了任意一个元件都不能开始生产。

因此攻城狮就想能不能在数据产生的地方有一个程序去一直监控日志的产生，产生一行就发给计算系统直接处理，处理完之后直接写入数据库，每条数据从产生到写入数据库，在资源充足时可以在毫秒级别完成。不仅如此，还可以免去排序、数据压缩、复制等效率低的过程，省去磁盘读写的时间，直接在内存中完成。要知道，磁盘访问延迟约为内存访问延迟的十万倍。

不同于Hadoop的发展过程，经过了一段较漫长的探索和尝试，才迅速在生态圈和商业上有比较成功的应用。实时数据处理从概念产生到商业应用仅仅很短几年时间，就产生了一大批类似的产品和工具，用于解决面向庞大规模数据流的即时处理需求，乘着内存计算的春风，这些被称为“实时处理领域的Hadoop工具”在不同的企业和商业项目上相互借鉴并各具特色。但核心解决思路离不开“流式处理”的概念，大致都包含三个环节。

01

数据采集

将线上产品的数据进行简单处理后把数据推送到数据队列处理系统

02

数据队列处理系统

基于发布/订阅模式的模式，对 TB 级别的数据也能保证常数时间复杂度的访问性能，负责将消息传递给处理计算环节

03

处理计算

根据预先设定的算法对流过来的消息进行处理，生生不息

当然从分布式批处理到现在的流式计算中间的发展过程要复杂的多，只是目前来说，业务场景中需要低延迟，希望在秒级或者毫秒级完成分析、并得到响应，而且希望能够随着数据量的增大而分布式扩展的，采用流式计算的实时计算方案是最经济的。

实际上，这一类解决方案也恰好填补了数据量和处理时间的一个平衡矩阵。以RDBMS、hadoop、实时数据处理为代表的三大阵营在目前分析引擎的三个主流概念中找到自己合适的位置并发挥价值。

当然，一个实时数据处理完整的解决方案中，仅仅包含实时数据抓取、实时数据处理是不够的，如同大数据行业发展初期一直在强调的概念，数据最重要的是价值，如何展现数据，发挥数据的价值才是最关键的，这就需要结合业务需求，在实际的商业场景中进行应用了。