f******2
发帖数: 2455 | 1 首先，本文不不是说Spark会死，而是说它的衰落会比预想的还有快，具体地说就是比
Hadoop被人抛弃还快（<5年，Hadoop的上升期）
Spark的问题就是核心引擎落后，核心部分就是个大的in－memory版Hadoop，完全抛弃
数据酷领域多年积累。这后面有很多问题暴露出来，例如，SparkStreaming就没法做真
正意义上的流处理。
如果没有VC的投入，上面这些问题可能还有机会解决（Berkeley从来不缺聪明的年轻人
，更何况是站在Spark经验教训的肩膀上作一些改善），但是现在的Spark已经是被资本
的助燃器推上轨道的火箭了（而且是巨型资本，换句话说就是重型发动机），没有办法
停下来思考什么是正确轨道，而是在自己的轨道冲下去。
德国的一群年轻人在一个教授（有IBM数据酷的长期背景）的带领下搞了个Flink，社区
非常活跃，而且成立了公司运作，估计会成为ElasticSearch这样一个欧洲发源，征服
美国的下一个大数据新宠。
立此存照。 |
h****r
发帖数: 2056 | 2 flink is based on scala as well, which makes its future doubtful.
hope it can be rewritten by c or java.
【在 f******2 的大作中提到】
: 首先，本文不不是说Spark会死，而是说它的衰落会比预想的还有快，具体地说就是比
: Hadoop被人抛弃还快（<5年，Hadoop的上升期）
: Spark的问题就是核心引擎落后，核心部分就是个大的in－memory版Hadoop，完全抛弃
: 数据酷领域多年积累。这后面有很多问题暴露出来，例如，SparkStreaming就没法做真
: 正意义上的流处理。
: 如果没有VC的投入，上面这些问题可能还有机会解决（Berkeley从来不缺聪明的年轻人
: ，更何况是站在Spark经验教训的肩膀上作一些改善），但是现在的Spark已经是被资本
: 的助燃器推上轨道的火箭了（而且是巨型资本，换句话说就是重型发动机），没有办法
: 停下来思考什么是正确轨道，而是在自己的轨道冲下去。
: 德国的一群年轻人在一个教授（有IBM数据酷的长期背景）的带领下搞了个Flink，社区
|
f******2
发帖数: 2455 | 3 错，flink主要codebase是java，scala那部分是两部分：用户语言binding，akka使用
因为核心是java，给广大java高手提供了广阔天地，大有作为的平台。这对于一个开源
型公司非常重要。因此社区运作好了绝对可以比spark后发先至。
我准备上去修个bug，个contributor当当。象goodbug这样的估计直接就是committer了
【在 h****r 的大作中提到】
: flink is based on scala as well, which makes its future doubtful.
: hope it can be rewritten by c or java.
|
B********r
发帖数: 397 | 4
【在 f******2 的大作中提到】
: 错，flink主要codebase是java，scala那部分是两部分：用户语言binding，akka使用
: 因为核心是java，给广大java高手提供了广阔天地，大有作为的平台。这对于一个开源
: 型公司非常重要。因此社区运作好了绝对可以比spark后发先至。
: 我准备上去修个bug，个contributor当当。象goodbug这样的估计直接就是committer了
|
d*******r
发帖数: 3299 | 5 flink 广告贴呀, 上 github 看了一眼, 确实主要是 Java 实现的 |
h****r
发帖数: 2056 | 6 成为java高手实在不是啥难事。10几年前java被称为猴子的语言，智商70就能学会，
目的就是为了易学易用，容易普及。现在居然被大家认为是高大上。要怪就怪最近
10几年学术界堕落得厉害，教的基础语言档次过低，phyton之流居然是Stanford CS
本科的主要教学语言，这实在是给科班出身将来的发展奠定的基础太差。
【在 f******2 的大作中提到】
: 错，flink主要codebase是java，scala那部分是两部分：用户语言binding，akka使用
: 因为核心是java，给广大java高手提供了广阔天地，大有作为的平台。这对于一个开源
: 型公司非常重要。因此社区运作好了绝对可以比spark后发先至。
: 我准备上去修个bug，个contributor当当。象goodbug这样的估计直接就是committer了
|
f******2
发帖数: 2455 | 7 从来就不觉得java高大上，但是我老对java的程度就是core java，很多工具都不知道
，所以就是一个三脚猫java程序猿
古老师估计各种高级武器都用过，所以到那里去propose些新武器的使用，估计里边的
人就把他拉成commiter了，我是想表达这个意思
【在 h****r 的大作中提到】
: 成为java高手实在不是啥难事。10几年前java被称为猴子的语言，智商70就能学会，
: 目的就是为了易学易用，容易普及。现在居然被大家认为是高大上。要怪就怪最近
: 10几年学术界堕落得厉害，教的基础语言档次过低，phyton之流居然是Stanford CS
: 本科的主要教学语言，这实在是给科班出身将来的发展奠定的基础太差。
|
f******2
发帖数: 2455 | 8 不是广告，看看第21页决定这个架子搭得比spark稳
http://www.slideshare.net/mobile/stephanewen1/apache-flink-over
【在 d*******r 的大作中提到】
: flink 广告贴呀, 上 github 看了一眼, 确实主要是 Java 实现的
|
h****r
发帖数: 2056 | 9 Java的各种所谓高级武器也都简单易用，只需要你肯学。
Flink抛弃了RPC，采用了akka，这个可是scala写的东西。Flink只是core用java而已。
【在 f******2 的大作中提到】
: 从来就不觉得java高大上，但是我老对java的程度就是core java，很多工具都不知道
: ，所以就是一个三脚猫java程序猿
: 古老师估计各种高级武器都用过，所以到那里去propose些新武器的使用，估计里边的
: 人就把他拉成commiter了，我是想表达这个意思
|
h****r
发帖数: 2056 | |
|
|
B********r
发帖数: 397 | 11 确实，看了文档看来用的是akka，不过就疑惑为啥不直接用scala写,能省好多事
【在 h****r 的大作中提到】
: Java的各种所谓高级武器也都简单易用，只需要你肯学。
: Flink抛弃了RPC，采用了akka，这个可是scala写的东西。Flink只是core用java而已。
|
r********n
发帖数: 7 | 12 楼主会这么说应该对两个项目本身和项目背后的团队都不是很了解吧。Spark并不是一
个in-memory Hadoop。关于这个，可以参见我Quora的回答： https://www.quora.com/
How-does-Apache-Spark-work/answer/Reynold-Xin
Flink以前名字叫做Stratosphere，其实和Spark一样也有五年的历史了，但是一直不温
不火的。成熟度比Spark差了很远，参与Flink社区的人不到Spark的五分之一。
个人意见：Flink之所以不温不火的一个原因就是用了太多数据库的传统设计，反而忽略
了这些设计对实际应用的阻碍。很多这些设计在SQL query上是很有价值的，但是对于
general program却可能得不偿失。
比如说Flink一直比较崇尚从头到尾的declarative，希望你把整个程序从头到尾的都用
他的框架来写。比如一个简单的while/for loop，本来编程语言里面已经有内置的loop
了，但是他却强迫用户利用他框架内置的loop的API。这样子的下场是程序员如果要用
这个框架，反而需要去学习更多的东西。
另外一个例子是内存管理。Flink的内存管理其实没有什么特别的，在Spark内部也有一
个把Java object serialize了当做bytes存储的模式，但是Spark可以支持把东西存储
成bytes，也可以支持把东西存储成Java object本身。虽然存储成Java object本身代
价比较高，但是在很多应用下却大大方便了用户，使得用户更简易的编程。如果Spark
从一开始就强迫用户必须把数据按照bytes来储存，很多现有的Spark算法可能实现程度
就要高好几个台阶。
我个人觉得Spark这种更分层的设计从长远来说是更有活力和价值的。RDD本身就是一个
特别general的physical execution engine，然后在RDD之上通过Spark SQL实现了
DataFrame和SQL，适合structured data processing。因为DataFrame和SQL带给了
engine本身更多的信息，所以可以实现一个更好的optimizer来优化实行。这个详细请
参见我们SIGMOD 2015的论文： https://databricks.com/blog/2015/04/13/deep-dive
-into-spark-sqls-catalyst-optimizer.html
Flink从去年开始有了一个明显的趋势，就是学习Spark。很多他们本来觉得特别好的设
计，他们现在都开始推翻，改成Spark的模式（比如说loop，action）。Road map的设
计其实可以用一句话来概括：“赶紧加上我们还没有但是Spark有的。”代码里面Scala
的数目也越来越多，很多新的代码都是完全用Scala写的，抛弃了原来的Java。
说“学习”其实是比较客气的话。仔细对比一下的话你会发现今年加入到Flink里面的
代码其实有很多和Spark的十分相似。有一小部分他们会在注释里面写明是“参照”
Spark实现的（比如说ALS），有很多就直接原封不动的拷贝过去之后改了改函数和变量
名（比如说analyzer, optimizer, code generator），有点类似本科生作业作弊的感
觉。我本人贡献给Spark的一些代码就被他们原封不动的给绊倒了他们的代码库里面。
甚至有些地方在API里面还会有他们忘记删掉的“Spark”出现。有时候我看了这些也觉
得比较搞笑，有一些我自己知道是错误的设计，但是因为时间关系暂时放在了Spark代
码里面，准备以后改掉，不过没多久这些错误的设计就出现在了Flink代码里面。不好
意思负面的东西说多了。
对于Spark设计我目前最大的不满其实是RDD这个层面只是非常接近physical，但并不是
完全physical的（有一部分pipelining的优化）。如果重新设计Spark的话，我会主张
做出一个完全physical的layer。不过这个主要是出于代码纯粹性的考虑，对上层实现
其实没有多大影响。以后基于DataFrame/SQL，Spark还会有很多优化的空间。传统数据
库的设计其实很简单，大多数在analytics上也比较过时了。数据库领域最近几年在
analtyical query processing性能优化上有很多新颖的想法（比如说Hyper, X100, C-
Store/Vertica，DB2 BLU），我们会选择性的在Spark上实现。我最近写了一个新的
design doc，目前还没有公开，预计接下来一两个礼拜会发布出来，欢迎楼主指教。 |
h****r
发帖数: 2056 | 13 赞，虽然回避了一些问题，但有不少干货。
只是你们严重依赖akka或者说scala这种不成熟，不严格，还没高潮就已开始有土崩瓦
解之势的
欧洲学院派语言，造成spark的前途充满很强的不确定性，实在让相当多的企业界的用
户不太敢
信任，毕竟没有几个公司愿意冒风险在production里用可能很快就没有后续维护的open
source product。
com/
忽略
loop
【在 r********n 的大作中提到】
: 楼主会这么说应该对两个项目本身和项目背后的团队都不是很了解吧。Spark并不是一
: 个in-memory Hadoop。关于这个，可以参见我Quora的回答： https://www.quora.com/
: How-does-Apache-Spark-work/answer/Reynold-Xin
: Flink以前名字叫做Stratosphere，其实和Spark一样也有五年的历史了，但是一直不温
: 不火的。成熟度比Spark差了很远，参与Flink社区的人不到Spark的五分之一。
: 个人意见：Flink之所以不温不火的一个原因就是用了太多数据库的传统设计，反而忽略
: 了这些设计对实际应用的阻碍。很多这些设计在SQL query上是很有价值的，但是对于
: general program却可能得不偿失。
: 比如说Flink一直比较崇尚从头到尾的declarative，希望你把整个程序从头到尾的都用
: 他的框架来写。比如一个简单的while/for loop，本来编程语言里面已经有内置的loop
|
H****S
发帖数: 1359 | 14 最好也别用Java generics，欧洲学院派愚蠢设计，还有type erasure问题。Java从5开
始就是反人类的节奏。
open
【在 h****r 的大作中提到】
: 赞，虽然回避了一些问题，但有不少干货。
: 只是你们严重依赖akka或者说scala这种不成熟，不严格，还没高潮就已开始有土崩瓦
: 解之势的
: 欧洲学院派语言，造成spark的前途充满很强的不确定性，实在让相当多的企业界的用
: 户不太敢
: 信任，毕竟没有几个公司愿意冒风险在production里用可能很快就没有后续维护的open
: source product。
:
: com/
: 忽略
|
d****i
发帖数: 4809 | 15 你这个也太扯了，Java的泛型就是从C++ template而来，何来愚蠢？ type erasure不
是问题，有反射就可以解决了。
【在 H****S 的大作中提到】
: 最好也别用Java generics，欧洲学院派愚蠢设计，还有type erasure问题。Java从5开
: 始就是反人类的节奏。
:
: open
|
B********r
发帖数: 397 | 16 赞！学习了
com/
忽略
loop
【在 r********n 的大作中提到】
: 楼主会这么说应该对两个项目本身和项目背后的团队都不是很了解吧。Spark并不是一
: 个in-memory Hadoop。关于这个，可以参见我Quora的回答： https://www.quora.com/
: How-does-Apache-Spark-work/answer/Reynold-Xin
: Flink以前名字叫做Stratosphere，其实和Spark一样也有五年的历史了，但是一直不温
: 不火的。成熟度比Spark差了很远，参与Flink社区的人不到Spark的五分之一。
: 个人意见：Flink之所以不温不火的一个原因就是用了太多数据库的传统设计，反而忽略
: 了这些设计对实际应用的阻碍。很多这些设计在SQL query上是很有价值的，但是对于
: general program却可能得不偿失。
: 比如说Flink一直比较崇尚从头到尾的declarative，希望你把整个程序从头到尾的都用
: 他的框架来写。比如一个简单的while/for loop，本来编程语言里面已经有内置的loop
|
c******o
发帖数: 1277 | 17 奇怪的是，我现在见到的和spark/aws 可以竞争的居然是（果然是） google的东西。
bigquery/google workflow.
这两个其实是 Dremel/FlumeJava/Millwheel
我们的一部分已经重移植到上面了，便宜还简单。。。
这个限于我们的use case, BI |
c******o
发帖数: 1277 | 18 牛人好。
你是https://github.com/rxin
么？
com/
忽略
loop
【在 r********n 的大作中提到】
: 楼主会这么说应该对两个项目本身和项目背后的团队都不是很了解吧。Spark并不是一
: 个in-memory Hadoop。关于这个，可以参见我Quora的回答： https://www.quora.com/
: How-does-Apache-Spark-work/answer/Reynold-Xin
: Flink以前名字叫做Stratosphere，其实和Spark一样也有五年的历史了，但是一直不温
: 不火的。成熟度比Spark差了很远，参与Flink社区的人不到Spark的五分之一。
: 个人意见：Flink之所以不温不火的一个原因就是用了太多数据库的传统设计，反而忽略
: 了这些设计对实际应用的阻碍。很多这些设计在SQL query上是很有价值的，但是对于
: general program却可能得不偿失。
: 比如说Flink一直比较崇尚从头到尾的declarative，希望你把整个程序从头到尾的都用
: 他的框架来写。比如一个简单的while/for loop，本来编程语言里面已经有内置的loop
|
c******o
发帖数: 1277 | 19 他是反讽。。
【在 d****i 的大作中提到】
: 你这个也太扯了，Java的泛型就是从C++ template而来，何来愚蠢？ type erasure不
: 是问题，有反射就可以解决了。
|
l*****i
发帖数: 13 | 20 Spark的在2012年刚耳闻的时候，惊艳的地方在于内存计算和REPL，当时做machine
learning的同事在公司内部推广这个的时候，我们做engineer的就觉得没什么用，错过
了很多
之后稍微细读spark发现宣传的核心其实是设计核心的一方面的表现，通过Spark的数据
核心RDD的partition/compute/dependency实际可以很容易包装为独立的应用逻辑，比
如现在的graph和dataframe, 然后再去基于新的RDD引入新的优化和应用。并且实际
RDDlazy的特性使得转换不一定对应一个真正的task，所以声明和计算是分离的，扩展
空间很大。Spark的极限远不是楼主说的这个。
另外可能spark确实做不了楼主所说的“真正的streaming”(这个不确定，看12楼的
rxin这些founder和大committer了)，但没有一个系统真正能把高性能，可靠和真正的
streaming做好。Storm在保证可靠和性能的时候也只能以batch来处理一个提交单位，
否则就要出现大量的commit或者不保证transactional.
也许google的Spanner + F1 组合比较好地解决了transactional update和
analytically
scan的问题，但应该也没有解决batch update的问题，否则也不会专门有个图引擎
pregel了
Yahoo也是内部同时提供了storm和spark平台来解决不同定义域的问题。
【在 f******2 的大作中提到】
: 首先，本文不不是说Spark会死，而是说它的衰落会比预想的还有快，具体地说就是比
: Hadoop被人抛弃还快（<5年，Hadoop的上升期）
: Spark的问题就是核心引擎落后，核心部分就是个大的in－memory版Hadoop，完全抛弃
: 数据酷领域多年积累。这后面有很多问题暴露出来，例如，SparkStreaming就没法做真
: 正意义上的流处理。
: 如果没有VC的投入，上面这些问题可能还有机会解决（Berkeley从来不缺聪明的年轻人
: ，更何况是站在Spark经验教训的肩膀上作一些改善），但是现在的Spark已经是被资本
: 的助燃器推上轨道的火箭了（而且是巨型资本，换句话说就是重型发动机），没有办法
: 停下来思考什么是正确轨道，而是在自己的轨道冲下去。
: 德国的一群年轻人在一个教授（有IBM数据酷的长期背景）的带领下搞了个Flink，社区
|
|
|
h****r
发帖数: 2056 | 21 对能力相对平平的 framework architect（不针对application architect）来说，
gut feeling是个危险的东西，更多的时候变成了wishful thinking。
【在 H****S 的大作中提到】
: 最好也别用Java generics，欧洲学院派愚蠢设计，还有type erasure问题。Java从5开
: 始就是反人类的节奏。
:
: open
|
H****S
发帖数: 1359 | 22 我拜托你语文好好练练行不？看清楚我回答的上下文先。是谁create的Scala，又是谁
create的Java generics？
【在 d****i 的大作中提到】
: 你这个也太扯了，Java的泛型就是从C++ template而来，何来愚蠢？ type erasure不
: 是问题，有反射就可以解决了。
|
f********x
发帖数: 99 | 23 顶一个！！！
com/
忽略
loop
【在 r********n 的大作中提到】
: 楼主会这么说应该对两个项目本身和项目背后的团队都不是很了解吧。Spark并不是一
: 个in-memory Hadoop。关于这个，可以参见我Quora的回答： https://www.quora.com/
: How-does-Apache-Spark-work/answer/Reynold-Xin
: Flink以前名字叫做Stratosphere，其实和Spark一样也有五年的历史了，但是一直不温
: 不火的。成熟度比Spark差了很远，参与Flink社区的人不到Spark的五分之一。
: 个人意见：Flink之所以不温不火的一个原因就是用了太多数据库的传统设计，反而忽略
: 了这些设计对实际应用的阻碍。很多这些设计在SQL query上是很有价值的，但是对于
: general program却可能得不偿失。
: 比如说Flink一直比较崇尚从头到尾的declarative，希望你把整个程序从头到尾的都用
: 他的框架来写。比如一个简单的while/for loop，本来编程语言里面已经有内置的loop
|
h****r
发帖数: 2056 | 24 C++ template 和 Java generics 是有本质不同的。一个是static polymorphism, 另
一个是run time type transparency。
【在 d****i 的大作中提到】
: 你这个也太扯了，Java的泛型就是从C++ template而来，何来愚蠢？ type erasure不
: 是问题，有反射就可以解决了。
|
N*****m
发帖数: 42603 | 25 bigquery/flumejava/millwheel只能在google cloud上跑吧
【在 c******o 的大作中提到】
: 奇怪的是，我现在见到的和spark/aws 可以竞争的居然是（果然是） google的东西。
: bigquery/google workflow.
: 这两个其实是 Dremel/FlumeJava/Millwheel
: 我们的一部分已经重移植到上面了，便宜还简单。。。
: 这个限于我们的use case, BI
|
s*****1
发帖数: 15 | 26 Spark的对手除了Flink，还有Ignite，都在Apache旗下取了个电光石火的名字 |
c******o
发帖数: 1277 | 27 是的
【在 N*****m 的大作中提到】
: bigquery/flumejava/millwheel只能在google cloud上跑吧
|
s********k
发帖数: 6180 | 28 我靠，厉害，这个帖子把reynoldxin 大神本人砸出来了
com/
忽略
loop
【在 r********n 的大作中提到】
: 楼主会这么说应该对两个项目本身和项目背后的团队都不是很了解吧。Spark并不是一
: 个in-memory Hadoop。关于这个，可以参见我Quora的回答： https://www.quora.com/
: How-does-Apache-Spark-work/answer/Reynold-Xin
: Flink以前名字叫做Stratosphere，其实和Spark一样也有五年的历史了，但是一直不温
: 不火的。成熟度比Spark差了很远，参与Flink社区的人不到Spark的五分之一。
: 个人意见：Flink之所以不温不火的一个原因就是用了太多数据库的传统设计，反而忽略
: 了这些设计对实际应用的阻碍。很多这些设计在SQL query上是很有价值的，但是对于
: general program却可能得不偿失。
: 比如说Flink一直比较崇尚从头到尾的declarative，希望你把整个程序从头到尾的都用
: 他的框架来写。比如一个简单的while/for loop，本来编程语言里面已经有内置的loop
|
N*****m
发帖数: 42603 | 29 说明还是要大鸣大放啊
【在 s********k 的大作中提到】
: 我靠，厉害，这个帖子把reynoldxin 大神本人砸出来了
:
: com/
: 忽略
: loop
|
n*****3
发帖数: 1584 | 30 本版 藏龙卧虎 啊
以后要多来这请教了
【在 s********k 的大作中提到】
: 我靠，厉害，这个帖子把reynoldxin 大神本人砸出来了
:
: com/
: 忽略
: loop
|
|
|
c**********s
发帖数: 22 | 31 大牛解释的很全。
您提到了physical layer，能否说说这个和tachyon的关系。我的理解tachyon就是把这
个storage layer abstract出来。
com/
忽略
loop
【在 r********n 的大作中提到】
: 楼主会这么说应该对两个项目本身和项目背后的团队都不是很了解吧。Spark并不是一
: 个in-memory Hadoop。关于这个，可以参见我Quora的回答： https://www.quora.com/
: How-does-Apache-Spark-work/answer/Reynold-Xin
: Flink以前名字叫做Stratosphere，其实和Spark一样也有五年的历史了，但是一直不温
: 不火的。成熟度比Spark差了很远，参与Flink社区的人不到Spark的五分之一。
: 个人意见：Flink之所以不温不火的一个原因就是用了太多数据库的传统设计，反而忽略
: 了这些设计对实际应用的阻碍。很多这些设计在SQL query上是很有价值的，但是对于
: general program却可能得不偿失。
: 比如说Flink一直比较崇尚从头到尾的declarative，希望你把整个程序从头到尾的都用
: 他的框架来写。比如一个简单的while/for loop，本来编程语言里面已经有内置的loop
|
M*****R
发帖数: 650 | 32 I think Storm is different. Yes, the trident API of Storm is similar to
Spark streaming, but the core Storm API
is not batch-based.
【在 l*****i 的大作中提到】
: Spark的在2012年刚耳闻的时候，惊艳的地方在于内存计算和REPL，当时做machine
: learning的同事在公司内部推广这个的时候，我们做engineer的就觉得没什么用，错过
: 了很多
: 之后稍微细读spark发现宣传的核心其实是设计核心的一方面的表现，通过Spark的数据
: 核心RDD的partition/compute/dependency实际可以很容易包装为独立的应用逻辑，比
: 如现在的graph和dataframe, 然后再去基于新的RDD引入新的优化和应用。并且实际
: RDDlazy的特性使得转换不一定对应一个真正的task，所以声明和计算是分离的，扩展
: 空间很大。Spark的极限远不是楼主说的这个。
: 另外可能spark确实做不了楼主所说的“真正的streaming”(这个不确定，看12楼的
: rxin这些founder和大committer了)，但没有一个系统真正能把高性能，可靠和真正的
|
M*****R
发帖数: 650 | 33 大牛怎么看Spark Streaming？这个和Storm，Samza哪个更有前途一些？
RDD基于coarse-grained memory access pattern，这个好像和streaming应用不合拍啊。
com/
忽略
loop
【在 r********n 的大作中提到】
: 楼主会这么说应该对两个项目本身和项目背后的团队都不是很了解吧。Spark并不是一
: 个in-memory Hadoop。关于这个，可以参见我Quora的回答： https://www.quora.com/
: How-does-Apache-Spark-work/answer/Reynold-Xin
: Flink以前名字叫做Stratosphere，其实和Spark一样也有五年的历史了，但是一直不温
: 不火的。成熟度比Spark差了很远，参与Flink社区的人不到Spark的五分之一。
: 个人意见：Flink之所以不温不火的一个原因就是用了太多数据库的传统设计，反而忽略
: 了这些设计对实际应用的阻碍。很多这些设计在SQL query上是很有价值的，但是对于
: general program却可能得不偿失。
: 比如说Flink一直比较崇尚从头到尾的declarative，希望你把整个程序从头到尾的都用
: 他的框架来写。比如一个简单的while/for loop，本来编程语言里面已经有内置的loop
|
