Liwei Lin

@zhouyan8603 不管是 spark streaming, 还是 structured streaming, 都可以先做一步 pageid, uid 的聚合，再往外写。structured streaming 的 memory table 确实需要有个过期机制（比如只记录最近三天、或一周的所有用户），否则 oom。 上面说的是精确记录 distinct(id) 的做法。如果不需要精确记录（比如可以接受误差在 5% 以内），那么可以考虑用基于概率的算法，占用空间非常小。比如一些概率算法的索引：http://blog.csdn.net/bagba/article/details/51822189。

@zhouyan8603 (1) Structured Steaming 基于 Dataset/DataFrame API, Spark Streaming 基于 RDD API，所以 Structured Steaming 能用 SQL 操作实时的 streaming 数据，而且性能会高些，这些都是 Dataset/DataFrame 带来的收益。 (2) 所以应用场景的话，如果需要 SQL 支持，或者比现有 Spark Streaming 更高的性能，可尝试 Structured Streaming。...

@lwwcl1314 考虑三点： 1. 给定 HDFS 上的输入文件 f，那么 MapReduce 无论失败几次、重做几次，最终的结果 r 是一致的； 2. Spark Streaming 就是保证了每条源头数据都唯一的划分到一个块数据里，每个块数据都唯一的划分到一个 batch 里； 3. 然后对于一个 batch，失败几次就对着源头数据再重做几次（就像 MapReduce 对着 f 多次重做一样），就可以保证本 batch 的结果与本 batch 的源头数据是一一对应的。 不重复，是因为每条源头数据都唯一划分一个 batch...

cloudera 的这篇文章是针对 Apache Kafka 的情况作了具体的讲解，也推荐大家都看看。 赞 @lwwcl1314 ~

@jacksu 基本都是用 Visio 画的，:-)

@luphappy 这个需要具体看一下 driver 端打印的日志，退出一般是报 Exception 了，可以根据具体的 Exception 来看；有可能还需要到报错的 executor 端去看日志。 可否贴一下报错信息？

@winwill2012 OK 的。附上原文链接与作者名，然后把链接 post 到这里就可以了。

@zwzm85 思考的很细致，赞。确实这里是有些问题的，这些细小数据就没有保障了；最主要的原因还是在于上游不能支持重放。

@luphappy 你好，请问你的 Yarn 是什么版本？有可能跟这个有关： [YARN-3103: AMRMClientImpl does not update AMRM token properly](https://issues.apache.org/jira/browse/YARN-3103) 另外，用 yarn cluster 方式部署试试看；通常 Streaming 的程序不会部署为 yarn client。

@wangwenting (1.a) 我们线上还是分应用，对于一点不能丢的都是从可重放的数据源读数据（如 HDFS，Kafka）等，可以丢一点的就开 WAL 或 RAM_2 双机热备； (1.b) 是的，不可重放的数据源不论是 WAL 还是 RAM_2 双机热备都有丢数据的风险，保险的还是靠可重 放数据源。 (2) exactly-once 主要是指 Streaming 内部的处理，end-to-end 的 exactly-once 还需要上游数据源支持（可重放）、下游数据接收支持（事务）。如果写到非事务的存储里，则保证 at-lease-once；其实多加一列 batch-id，其实也能保证 exactly-once，比如 batch-id =10, count =...