戳蓝字“读字节”关注我们哦
ps:心疼砸大笔银子在spark上的ibm和cloudrea一秒钟
首先对于Apache Beam能有多大的本事先不论，就从提问中的观点，对spark和flink的微批模式在实际应用过程当中的理解就有误。
为什么呢？道理很简单，实时计算不是目的，而是手段，目的才是最重要的! spark之所以选择微批而不是流，就是在兼顾一定实时性的同时，还能保证一定的可靠性，同样flink的保存点也是一个的道理，更何况spark还能让实时流计算符合spark rdd计算模型。
那有人就会问微批的速度不如实时快，从我实践的大数据流式计算项目中的证据，我可以明确的提出来一个反驳的观点，实时计算架构问题瓶颈不仅会出计算本身的算法上，更多时候会堵塞在存储i/o上，也就是说从哪里寻找既能实时写入(100ms以内)，又能提供最优的流式连接算法和查找，还要能支持每天百G以上的实时数据持久化通道。kafka做不到，kafka加上流连接，入库结果就到亚秒级了，况且kafka不涉及随机查询，必须找其他nosql支持，但是随机查找范围根本无法控制，你不可能在流库连接的时候保证只需查最高效的就近数据，更无法保证分布式环境所需数据都是在本地完成流连接。因此实时计算很容易出现背压，导致发送端的数据溢出，必须做本地溢出持久化和恢复。
因此根本找不到所谓支持实时计算的存储系统，那么做海量数据的实时计算(100ms以内)就是个悖论。只能在内存中做实时分析，但是内存数据库支撑的数据量是不仅有限，而且受制于算法模型的效率。
微批处理不仅可靠，而且对于临时写入和读取，也具备批量高性能io，甚至好过一条条记录的流式写入。所以不要随意夸大任何的新技术。大多数新技术都是在前辈的贡献基础之上继续发展的。
如果觉得写得不错，那就点个赞或者“在看”吧，多谢阅读。
文章均为“读字节”原创，转载务必注明来源。
点这里👇关注我
