大数据架构与批流融合

近期跟客户和团队内部多次谈及大数据架构和批流一体化的事情，有一些粗浅的认识，做一下简单记录。

1、传统大数据架构：

BI一般被认为是大数据分析应用的前身，随着大数据的兴起，开始用大数据的手段和框架替代BI里面的CUBE等组件实现分析等功能，这也是大数据应用的最开始被接受的部分。

2、Lambda架构：

Lambda架构现行主流的大数据架构。Lambda采用了批流分离的思路，实时流和离线批处理分别考虑。实时流依照流式架构，保障了其实时性，而离线则以批处理方式为主，保障了最终一致性。Lambda架构，主要包含三层，批处理层, 实时处理层和响应查询的服务层。批处理层通常用Hadoop一类的离线引擎处理，实时处理层一般用Apache Storm, Apache Spark 等。对于实施处理层来的结果，可以交由 HBase, ES存储，对于批处理层来的结果，可以交由 Apache Impala, Hive 存储。越来越多人质疑Lambda架构存在的问题，比如流和批的结果不一致引起的数据口径的问题、数据源变化引起的开发量增大的问题、存储量激增的问题。

3、Kappa架构：

也不知道kappa啥时候转型做大数据了。其实我理解kappa，所有数据都走实时路线，一切都是流。并且以数据湖作为最终存储目的地。事实上还是以 lambda为基础，只是将批处理层去掉，剩下所有数据都走实时路线，一切都是流。并且以数据湖作为最终存储目的地。事实上还是以 lambda为基础，只是将批次处理层去掉，剩下实时处理层和 服务层。这种架构非常适合IOT，实时处理和响应是王道。

4、另外一种思路

就是批流合一，提供一套统一的架构 API 来执行批 和 流 的操作。说起批流融合，这里面Spark 和 Flink 都是比较出色的。两者都有相对比较成熟的生态系统。是下一代大数据引擎最有力的竞争者。据说，据说啊，Spark 的生态总体更完善一些，在机器学习的集成和易用性上暂时领先。Flink 在流计算上有明显优势，核心架构和模型也更透彻和灵活一些。在易用性方面两者也都还有一些地方有较大的改进空间。接下来谁能尽快补上短板发挥强项就有更多的机会。

还有一些细节，比如新出来的Apache Pulsar，这个小东西好像被寄予厚望，一会儿说pulsar是计算存储分离分层分片是替代Kafka的下一代分布式消息系统，一会儿说pulsar可以作为批流融合的存储。这些还有待验证和观察！

无论如何，没有不过时的技术，更没有一劳永逸的架构，我们始终处在技术变革的漩涡之中。没有绝对正确，只有相对合适，不能被动的适应技术，应该让技术去服务业务。