第三个趋势随着现在传感器网络、物联网的发展，数据产生的速度越来越快，当然在互联网里面早就有物联网数据产生，使得实时大数据的技术慢慢开始得到更多的关注，我们预计明年有更多的应用。
怎么来处理实时数据和历史数据。提出了Lambda Architecture的架构。进入一个流数据系统进行检测分析，同时进入Hadoop，全量数据放在Hadoop对历史数据进行分析，两者结果做融合，然后应用程序访问这个做分析。今天为止没有哪个技术既能处理实时数据又能处理大量历史数据，所以提出这样一个混合的架构，这个混合架构受到很多人的追捧。这种架构实时数据流里面处理完之后仍掉了，只把结果放在里面，也就是我不能对实时数据进行随机的查询，这是第一个问题。我把随时数据和历史数据分离我怎么形成统一的视图，怎么最后拼接起来，这是比较难的事情。第三个这个Serving DB可以完成快速查询但是不能做统计分析。这三个弱点很快大家意识到了，很快大家想出一个办法，有一个项目，这个项目大家得到比较多的关注，现在雅虎采用这种实时数据分析。解决两个问题，把实时数据和历史数据全部拼接起来变成一张视图，它内部把实时数据离线的收集起来拼成一个视图分析。它解决快速采集的问题，但是它还不能完成复杂统计和挖掘的问题。比较理想架构我采用最好是我数据经过流处理以后我直接进入一个数据库，这个数据库可以完整把实时数据和历史数据拼接起来，这上面既做高速查询又能做迭代分析，这是比较理想的，这样我可以省去维护两套架构的麻烦，而且我既能对实时数据进行分析，又能对历史数据进行分析，这是比较理想的架构，现在大家想有什么实现的方法。我们做了一个尝试，我们尝试其实是在我们应用技术国内各个行业的时候发现普遍的问题，这个驱动来自于交通流的实时分析，如果我们部署整个机群的时候，他们希望看到早高峰晚高峰任何一个时刻每个路口的实时状况，一旦发生交通事故，某个地方产生拥堵会有连锁反应的，产生连锁反应我快速分析这种情况，这种情况用刚才的做法也不能实现，我们开发分布式的缓存，存在内存或者是SSD上的，当实时数据流到里面去的时候，我们先SparkStreaming，这是一个批次系统，可以短到一百毫秒，再小的现在还不能实现，本身框架比较长，这个进入Spark内存以后同时我在上面可以做非常多的实时的检测甚至是实时的挖掘，同时这个结果以及原有数据我们做一个SQL转化，转化成一个历史存储。过去我们可以放在内存里，但是内存容量不够我们全量数据可以放到SSD，我们支持快速插入，这样我可以把所有实时数据包括历史数据可以全部缓存到SSD上，这个机群可能是10个节点20个节点，你可以存放几年交通数据，这样我可以对历史数据和实时数据进行很完整的分析，这个转化也是非常快的我们支持高速的数据插入，这个数据持久性也得到保证，因为我在SSD上，即使掉线也没有问题。解决三个问题，第一个我可以有一个统计视图，不管是历史还是实时都有，我可以做任意复杂的分析。还有一个问题没有解决，如果我把这个数据给在线用户访问这个数据并发度不够，这个需要占用很多的CPU，一方面我们尽量降低查询的延时，另外我们需要扩大机群，这个很好解决交通行业面临的问题，这个问题蛮普遍的，不光是交通行业还有视频网站点击日志，我们可以用这个方式做分析，我们可以对传感器的数据，工厂里炼油厂传感器的数据进行快速的分析，而且传感器的数据全部在一张网里面。我们觉得在未来会发生较大的变化，也会有新技术实现这种理想的体系架构。
