2019-06-12终于进入beam了，讲得这些宏观概念以及举的例子都很清晰，很有收获。
从课表上看后面有关beam的还有13讲，感觉前面的铺垫太长，为了在这个专栏上维持数据处理的完整性，好多框架都拿出来泛泛谈一下，熟悉的人不需要，不熟悉的人也只能了解个大概皮毛，到不了能实战的程度。希望老师未来能出个针对某一个具体框架的深度学习课程。作者回复: 谢谢你提出的宝贵建议！作为讲师这个角色，确实我还是有很多地方需要改进的。因为写专栏的时候，除了写Spark这个具体的数据处理引擎，其它的内容当时觉得还是必要的基础知识。
1 9
2019-06-12老师你好，看了介绍beam是集成流处理和批量处理模型形成一套统一的模型，而且可以跑在多个runner上，我在想如果有很好的兼容性那可能会牺牲些性能，beam的程序是否可以和原生的runner上写的代码一样的性能那？如果我下层绑定了runner，我何必再用beam？beam的适用场景是不是很窄了那？作者回复: 谢谢你的提问！这个问题问得很好！
其实这个问题的本质还是Beam在整个数据处理框架中扮演着一个什么样的角色。
首先为什么不是所有的大数据处理引擎都可以作为底层Runner呢？原因是因为并不是所有的数据处理引擎都按照Beam的编程模型去实现相应的原生API。
我以现在国内很火的Flink作为底层Runner为例子来说一下。在Flink 0.10版本以前，Flink的原生API并不是按照Beam所提出的编程模型来写的，所以那个时候Flink并不能作为底层Runner。而在Flink 0.10版本以后，Flink按照Beam编程模型的思想重写了DataStream API，这个时候如果我们用Beam SDK编写完数据处理逻辑就可以直接转换成相应的Flink原生支持代码。
当然你说的没错，因为不是直接在原生Runner上编写程序，在参数调整上肯定会有所限制。但是Beam所提倡的是一个生态圈系统，希望不同的底层数据处理引擎都能有相应的API来支持Beam的编程模型。
这种做法的好处是对于专注于应用层的工程师来说，它解放了我们需要学习不同引擎中原生API的限制，也解放了我们需要花时间了解不同处理引擎的利弊。对于专注于开发数据处理引擎的工程师来说，他们可以根据Beam编程模型不断优化自身产品，这样会导致更多产品之间的竞争，从而最终对整个行业起到良性的促进作用。 8
2019-06-14这章在 Streaming 101/102 中有更多讲解，可以作为reference
https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102作者回复: 谢谢分享！
2- 2019-06-12是否可以把Beam应该可以称为大数据处理的高级语言。虽然直接使用高级语言编写会产生一定的性能损耗，但屏蔽了各个底层平台的差异，提供了统一的逻辑抽象，提高了开发效率。如果一个场景既需要离线处理，也需要实时处理，那么就需要两种不同的计算平台（比如采用lambda架构）。此时采用beam可以解决同样逻辑多个平台开发的问题吧
作者回复: 谢谢你的留言！我是很赞成你的说法的。这其实就好比SQL。我们学习SQL是学习它的语法从而根据实际应用场景来写出相应的SQL语句去解决问题。而相对的，如果觉得底层使用MySQL很好，那就是另外的决定了。写出来的SQL语句是不会因此改变的。
2 
2019-07-07基于元素个数触发的窗口计算，统计交易数据，假如有很多个元素计数都为1，实际也没触发统计，这对当前时间窗口的统计就比实际差很多了，这种情况要怎么解决或者说适合什么场景呢，老师！作者回复: 谢谢提问！这个问题挺好的，在文章中我为了说明基于个数的触发器所以举出这样一个例子，在实际应用中并不一定适用。就如你所说，我们不能假设每个交易商品都会超过1，或者说每个窗口中都会有超过1个交易数据。
在实际中具体怎么设计触发器肯定还是要按照自己的需求来的，像这种基于个数的触发器，可能更适合寻找top k这样一些场景。 1
2019-06-13我们开始也是被底层开发困扰，每个指标都要写代码，然后发现了kylin ,基本只关注模型和纬度了作者回复: 谢谢分享！
1
2019-11-09在业务系统中， 有非常复杂的业务逻辑计算， Beam 编程模型的引入会达到什么效果呢？
2019-06-18有针对kafka Stream 的支持吗? Kafka Stream 本身也提供对 WWWH的概念的支持。作者回复: 谢谢你的提问！支持的，Beam有专门的KafkaIO。
2019-06-12还是那个理念：让工程师更专注与业务逻辑，而不要把精力和时间放到底层的实现上去！
还是有利有弊吧！作者回复: 你说得没错，都是有所取舍的。