说到Flink不得不先说一下大数据。
这几年大数据的飞速发展，出现了很多热门的开源社区，其中著名的有 Hadoop、Storm，以及后来的 Spark，他们都有着各自专注的应用场景。Spark 掀开了内存计算的先河，也以内存为赌注，赢得了内存计算的飞速发展。Spark 的火热或多或少的掩盖了其他分布式计算的系统身影。就像 Flink，也就在这个时候默默的发展着。
在国外一些社区，有很多人将大数据的计算引擎分成了 4 代，当然，也有很多人不会认同。我们先姑且这么认为和讨论。
首先第一代的计算引擎，无疑就是 Hadoop 承载的 MapReduce。这里大家应该都不会对 MapReduce 陌生，它将计算分为两个阶段，分别为 Map 和 Reduce。对于上层应用来说，就不得不想方设法去拆分算法，甚至于不得不在上层应用实现多个 Job 的串联，以完成一个完整的算法，例如迭代计算。
由于这样的弊端，催生了支持 DAG 框架的产生。
因此，支持 DAG 的框架被划分为第二代计算引擎。如 Tez 以及更上层的 Oozie。这里我们不去细究各种 DAG 实现之间的区别，不过对于当时的 Tez 和 Oozie 来说，大多还是批处理的任务。
接下来就是以 Spark 为代表的第三代的计算引擎。第三代计算引擎的特点主要是 Job 内部的 DAG 支持（不跨越 Job），以及实时计算。
随着第三代计算引擎的出现，促进了上层应用快速发展，例如各种迭代计算的性能以及对流计算和 SQL 等的支持。Flink 的诞生就被归在了第四代。这应该主要表现在 Flink 对流计算的支持，以及更一步的实时性上面。当然 Flink 也可以支持 Batch 的任务，以及 DAG 的运算。
或许会有人不同意以上的分类，我觉得其实这并不重要的，重要的是体会各个框架的差异，以及更适合的场景。并进行理解，没有哪一个框架可以完美的支持所有的场景，也就不可能有任何一个框架能完全取代另一个，就像 Spark 没有完全取代 Hadoop，当然 Flink 也不可能取代 Spark。
如今最火的就是Spark和Flink。Spark和Flink的主要差别就在于计算模型不同。Spark采用了微批处理模型，而Flink采用了基于操作符的连续流模型。因此，对Apache Spark和Apache Flink的选择实际上变成了计算模型的选择，而这种选择需要在延迟、吞吐量和可靠性等多个方面进行权衡。
Spark
对于以下场景：
复杂的批量处理（Batch Data Processing），偏重点在于处理海量数据的能力，至于处理速度可忍受，通常的时间可能是在数十分钟到数小时。
基于历史数据的交互式查询（Interactive Query），通常的时间在数十秒到数十分钟之间。
基于实时数据流的数据处理（Streaming Data Processing），通常在数百毫秒到数秒之间。
目前都有比较成熟的处理框架，第一种情况可以用Hadoop的MapReduce来进行批量海量数据处理，第二种情况可以Impala进行交互式查询，对于第三中情况可以用Storm分布式处理框架处理实时流式数据。以上三者都是比较独立，各自一套维护成本比较高，而Spark的出现能够一站式平台满意以上需求。
Spark适用和不适用的场景：
- Spark是基于内存的迭代计算框架，适用于需要多次操作特定数据集的应用场合。需要反复操作的次数越多，所需读取的数据量越大，受益越大，数据量小但是计算密集度较大的场合，受益就相对较小。
- 内存hold不住的场景，在内存不足的情况下，Spark会下放到磁盘，会降低应有的性能
- 数据量不是特别大，但是要求近实时统计分析需求，如果有高实时性要求的流式计算业务，就不太适合了，例如实时性要求毫秒级
- 由于RDD设计上的只读特点，所以Spark对于待分析数据频繁变动的情景很难做（并不是不可以），比如题主例子里的搜索，假设你的数据集在频繁变化（不停增删改），而且又需要结果具有很强的一致性（不一致时间窗口很小），那么就不合适了。还有像web服务的存储或者是增量的web爬虫和索引，就是对于那种增量修改的应用模型不适合。
- 流线长或文件流量非常大的数据集不适合。你会发现你的内存不够用，集群压力大时一旦一个task失败会导致他前面一条线所有的前置任务全部重跑，然后恶性循环会导致更多的task失败，整个sparkapp效率极低。就不如MapReduce啦！
Flink
Flink就是为流式计算而生的，就连Batch最终也是转化成了streaming，也就是说Flink的一切都是stream。
Flink有一下优点：
- Flink的流处理引擎只需要很少配置就能实现高吞吐率和低延迟。
- Flink 的 checkpointing 机制保证了即时在故障发生下也能保障状态的 exactly once 语义。
- Flink 支持在时间窗口，统计窗口，session 窗口，以及数据驱动的窗口，窗口可以通过灵活的触发条件来定制，以支持复杂的流计算模式。
- Flink streaming 在运行时有着天然的流控，自带反压功能——慢的数据 sink 节点会反压（backpressure）快的数据源（sources）。
- Flink 的容错机制是基于 Chandy-Lamport distributed snapshots 来实现的。这种机制是非常轻量级的，允许系统拥有高吞吐率的同时还能提供强一致性的保障。
- Flink 在 JVM 中实现了自己的内存管理。应用可以超出主内存的大小限制，并且承受更少的垃圾收集的开销。
- Flink 具有迭代计算的专门支持（比如在机器学习和图计算中）。增量迭代可以利用依赖计算来更快地收敛。
- Flink 批处理程序会自动地优化一些场景，比如避免一些昂贵的操作（如 shuffles 和 sorts），还有缓存一些中间数据。
- DataStream API 支持了数据流上的函数式转换，可以使用自定义的状态和灵活的窗口。
- Flink 栈中提供了很多高级 API 和满足不同场景的类库：机器学习、图分析、关系式数据处理。当前类库还在 beta 状态，并且在大力发展。
- Flink 与开源大数据处理生态系统中的许多项目都有集成。Flink 可以运行在 YARN 上，与 HDFS 协同工作，从 Kafka 中读取流数据，可以执行 Hadoop 程序代码，可以连接多种数据存储系统。
