流技术的未来：Apache Flink

问题导读
1.为何会产生流技术？
2.流技术需要解决那些问题？
3.Flink有哪些优势？

关注最新经典文章，欢迎关注公众号


从历史上看，大多数生成大量数据的公司别无选择，只能丢弃它，因为存储它的成本很高，而且处理它是不可想象的。 随着Hadoop和Cassandra等首批大数据存储技术的出现，这种情况发生了变化。 如今可以存储数据，但处理它仍然是一项艰巨的任务，因此新技术开始出现在这项工作中：Pig，Hive，最重要的是Spark。

一旦处理问题得到解决，公司就会意识到存储这么多数据,随着时间的推移逐渐失去价值。 这导致流技术解决方案的出现，主要是Spark Streaming和Storm，后又出现：Apache Flink。

• 流
• 处理
• 存储
• 丢弃
  

这些流式传输框架必须对新的挑战做出响应，到目前为止（批处理）流需要真正的解决问题：

• 数据链数据的转换和处理必须考虑到这个数据将无限期到达的事实，即，不可能等待读取所有行然后统计单词并计算它们（使用典型示例）。
• 在任何服务停机的情况下，我们需要机制来确保流数据中没有一个丢失。现在有必要分离处理的采集部分，在设计平台时要特别注意这方面。
• 我们的程序需要能够确保最大的数据返回时间。 此外，关于上述点，背压效应也起作用，即，我们的处理链必须能够足够快地处理数据以确保处理链的第一级的非饱和。
• 如果任何节点发生故障，我们的框架必须确保每个事件只处理一次。 这种必要条件习惯性地需要昂贵的同步和错误控制机制。 虽然对于所有应用都不是必需的，但它可能对某些类型的实现造成严重问题，例如两次录制的警报，或者更糟糕的是，未记录的警报！
  

Spark Streaming和Storm已经为这些问题（或大多数问题）提出了答案，似乎Flink提供了最佳解决方案而没有丧失容量和处理速度。



毫无疑问，Flink最大的惊喜是它的应用程序编程接口（API）用于管理时间事件：非常容易理解，同时也非常强大。 它已经引入了滑动窗口，触发器或键控流等语言术语。 它还本身管理应该用于命令事件的参考时间等方面：事件生成的时间？ 什么时候收到？ 或者正在处理？ Flink使开发人员可以在它们之间进行选择。

这种抽象使得开发应用程序非常容易，这些应用程序管理必须考虑时间的事件。