2019-06-09同样都是微批处理，为什么spark streaming 就不能处理微秒，而structure streaming就可以 1 6
2019-05-27我不确定有没有完全理解问题..
我想大概是因为，输出时间所对应的窗口可以故意设置的比输出时间稍微早一点，这样可以对数据延迟有一定的抗性。不然例子中的1:09分的数据就没机会被使用了。
不过相应的，这样的机制似乎终究是个妥协，妥协的越大，实时性就越差。 3
2019-05-29watermark，process time - event time > watermark则直接丢失，process time - event time
< watermark则接收数据处理，更新结果表。 2
2019-05-27spark structure streaming有没有类似flink的sideOutput机制？支持超过watermark的事件被处理到 2
2020-01-14关于思考题……据说是有水印机制，跟踪数据的事件时间，阈值内的延迟数据将会被聚合，比阈值更延迟的数据将被删除，在内存中留有一个中间状态。若有不对，请指正；不过推荐看一下这篇文章《Spark 2.3.0 Structured Streaming详解》，相当于官网翻译：https://blog.csdn.net/l_15156024189/article/details/81612860 1
2019-09-101、Structured Streaming是基于事件事件处理，而不是处理事件，所以，延迟接收的数据，是能被统计到对应的事件时间窗口的
2、设定数据延迟的窗口时间阈值，通过判断阈值来决定延迟数据是否需要纳入统计；这个阈值的设定可以避免大量数据的延迟导致的性能问题 1
2019-06-20用过才知道，这个东西目前坑还挺多 1
2019-06-19最后的思考题只知道flink有一个watermark机制可以保证 1- 2019-06-18各个类的继承关系最好画一个图，不然在这几个章节打转搞得有点晕 1
2019-06-04withWatermark函数第一个参数是 数据表中的时间戳字段的字段名，第二个参数是延迟的时间阈值 1
2019-05-27一般是处理滞后一定时间的数据，超过了这个时间范围，就会舍弃 1
2019-05-27我知道在flink中可以通过watermark来处理这样的场景，在Structured Streaming中应该也是这样的方式来处理吧。 1
2019-05-2710分钟统计一次，按照处理时间分1:00-1:10，1:10-1:20；所以单词的处理时间位于第二个区间会被第二次统计到；如果按照事件时间，sql里time>1:00 and time<1:10就可以把单词归类到第一个区间，这么理解对吗，老师？ 1- 2019-11-26各位大佬好，流式处理应该消息应该只被消费一次吧，waterMark机制可以确保在1:20输出，什么情况下在1:10输出了对应的结果呢？求解。
2019-07-27我用那个withWaterMark限制时间窗口进行思考题中的数据过滤时候，就感觉怪怪的，有时候放弃掉，有时候就怎么都不放弃，一直不太理解这块内容
2019-06-26structure streaming相当于一直在更新输出一个表，这个表有事件时间信息，所以可以按事件时间处理；spark streaming只能按处理时间来的rdd处理，缺少一个汇总
2019-05-29输出模式支持呀。
完全模式和更新模式哈。
2019-05-29我觉得可能是通过冗余计算上一个时间窗口中的数据来实现的。
局限性就是不支持迟到太久的数据
2019-05-29程序在1:10处理的是1:09之前生成的数据，往后推10分钟，那1:20处理的是1:19之前生成的数据
2019-05-29老师, 我最近遇到个问题还望帮忙提点一下:
1. 需求: 统计实时订单量(类似)
2. 通过maxwell读取binlog数据同步到kafka
3. spark-streaming处理kafka里面的数据
4. spark-sql定义不同的实时报表
这样做的时候, 对于不同sql定义的报表我就懵了,
假如昨天需求方写了10个SQL放到数据库, 然后我们启动流计算, 提交job到spark, 那么10个实时的报表就开始变动起来了
但是今天需求方说, 这里还有两个指标需要统计一下, 就给我了2条SQL,
(先说明下前提, maxwell把mysql的数据提取出来提交到了一个kafka的topic里面)
疑问点出来了:
1. 如果从新提交一个2条sql的job, 就得独立消费kafka数据, 否则数据有遗漏, (相当于一条河流, 做了多个截断), 与其对比的是: 在之前提交10个SQL的job中, 先写好SQL来源是动态从某个数据库某张表取出来的, 然后数据流来了直接共享server进行计算, (相当于一条河流一次截断, 多个筛选, 复用了job的提交和kafka消费这一步), 不知道后者是否可行, 或是有什么坑?
2. 假如选择了问题1 的第一种情况, 且假如重复消费很消耗新能, 然后我想到了替代方案,不同的数据库binlog放到不同的kafka的topic中, 计算出结果之后再聚合, (这样做缺点是不是就是开发程序非常麻烦呢)?
目前存在如上两个疑问, 我目前觉得第一个问题的第二种情况比较靠谱, 希望可以求证, 或者我原本思考方向就是错的, 还望老师帮忙指点一下展开