Structured Streaming-介绍-★

Dataflow模型-了解

事件时间:event-time,事情真正发生的时间
处理时间:process-time,表示事件/数据被系统处理的时间
如:
- 现在假设，你正在去往地下停车场的路上，并且打算用手机点一份外卖。选好了外卖后，你就用在线支付功能付款了，这个时候是11点55分。恰好这时，你走进了地下停车库，而这里并没有手机信号。因此外卖的在线支付并没有立刻成功，而支付系统一直在Retry重试“支付”这个操作。
- 当你找到自己的车并且开出地下停车场的时候，已经是12点05分了。这个时候手机重新有了信号，手机上的支付数据成功发到了外卖在线支付系统，支付完成。
- 在上面这个场景中你可以看到，支付数据的事件时间是11点55分，而支付数据的处理时间是12点05分
也就是上面的案例中
- 事件时间:event-time,事情真正发生的时间为 11点55分
- 处理时间:process-time,表示事件/数据被系统处理的时间为12点05分
- 而如果要计算当天上午的订单12点之前的订单,那么就应该考虑使用订单的事件时间来统计
- 而为了完成这个目标, 之前的技术是不行的，得使用Dataflow模型-

在Google 提出Dataflow模型-之前流式数据处理都会存在各种各样的难题/问题
如SparkStreaming就存在引入部分提出的如下问题:
- 1.实时数据不能使用SQL风格处理, 离线和实时处理API太多,太杂,没有统一
- 2.实时数据处理只能做到微批,很难做的毫秒, 延迟性高
- 3.较难处理复杂业务(如数据延迟…无法基于事件时间进行计算…)
在Google 提出Dataflow模型-之后
- Spark在2.0的时候就参考/借鉴该模型推出了StructuredStreaming想要解决这些问题
- 注意:大数据的发展离不开谷歌的论文
- 注意:StructuredStreaming是想着把上面的问题都给它解决掉
- 但是在Spark2.2.0的时候只解决了1和3.延迟性没有太多降低,底层还是微批
注意:
- StructuredStreaming在Spark2.0之后推出的,但是后续的更新不是太多
- 包括在2020年发布的Spark3.0新版本中都没有对StructuredStreaming做太多更新
- 因为Spark认为Spark的这些实时处理技术能够满足大部分的大数据应用场景
- 所以Spark没有继续在StructuredStreaming上花太多精力
- 所以目前StructuredStreaming在国内不是很流行
- 如果要做实时,事实的标准在国内还是Flink
- 但是SparkSQL在国内还是很流行的
- StructuredStreaming的学习主要还是加强一下DataFrame和DataSet的API
顺便给后续Flink做个铺垫