对大数据处理技术栈的简单思考

今天上午主要在处理数据流的问题，下午和晚上学习了新的数据序列化方法：protobuf。

处理数据流的背景是这样的：数据通过千万级别的终端请求收集上来，传到一个总的Kafka集群，我们组作为一个group id去选择性消费我们需要的数据，然后存入我们组内自己的小型Kafka集群中，接着小组内的各个人根据自己的需要去取数据，有的做监控，有的做在线策略评估，有的做离线分析等。

由于离线分析这部分跑的是Spark程序，我需要将流式数据结构化的存到Hive上，以供离线分析使用。而问题在于，各种数据是通过一条总线进来的，我需要根据数据性质的不同将其分流，然后持久化的存到各个不同的Hive表中。所以，很多时间和工作浪费在了这个地方。

我在想，到底什么是离线分析？既然数据本身是流式数据，那么监控和在线评估肯定是流式处理的。而离线分析，就是以小时，天，或者周，也就是时间跨度稍长的，对数据的各个纬度的统计分析。我们目前均是跑Spark脚本程序进行统计分析，因为它灵活。但有一个巨大的问题是程序高度依赖各数据字段，当字段稍有改变，或者需求稍有改变时，就得再修改程序。环节之间，耦合度太高。

想到昨天的麒麟系统，这样一想，在这样的场景下真的是很有用。如果能在现有Hadoop集群上布一层麒麟，基本一般性的统计报表是能满足的。还有更多的需要，则可以针对性的写Spark脚本了。

然后protobuf这个谷歌出品的序列化方法还是很厉害的，快，且节省空间。特别是在大数据处理和存储的时候，才能愈发感受到其强大之处。唯一的不足在于序列化以后人不可读，不像json，它被编码成二进制格式了。

最后总结一下我目前对大数据处理技术栈的一些简单思考：

1.Kafka消息中间件对于降低数据上下流之间的耦合度很有帮助，这个利器是必须需要的。

2.Hadoop，Spark，Hive，Hbase这四个组件是基础，必须要有。

3.Flink用于处理流式计算，其窗口计算能力很OK，优势在于其实时CEP规则策略系统。

4.Kylin是一套报表分析系统，基于Hadoop之上的，也是需要的。

5.然后就是高性能的web restful api，其后台是redis集群，存储采用protobuf序列化以后的，更节省内存空间。

6.还有各大基础分布式数据库：ES，MongoDB，Cassandra，关键在于这些分布式数据库与大数据分析系统的整体兼容与打通，这个很重要。