2012年以前，大多數企業的數據倉庫主要還是構建在關系型數據庫上，例如Oracle、Mysql等數據庫之上。但是隨着企業數據量的增長，關系型數據庫已經無法支撐大規模數據集的存儲和分析，這種情況在一線互聯網公司尤為明顯，也是當時急需要解決的問題。
隨着2012年Hadoop技術框架的成熟和穩定，一線互聯網公司紛紛使用Hadoop技術棧來構建企業大數據分析平台，隨后兩年基於大數據的應用如雨后春筍一樣涌現，比如千人千面的推薦系統、精准定向程序化交易的廣告系統、互聯網征信、大數據風控系統。時間到了2015年，Hadoop技術棧已然成為了建設數據倉庫的首選項，對盲目跟風的企業來講，有條件會上Hadoop集群、沒有條件創造條件也要上Hadoop集群，那一年我聽說過節點數最少的是一家做奢侈品的互聯網公司，它們用3個物理機部署了一套數據倉庫。
與此同時，隨着Hadoop技術在企業大規模的深入應用，人們對Hadoop MapReduce框架越來越無法容忍，因為MapRecude在運行過程中會大量操作磁盤，對於復雜的計算任務來講，動不動就是幾個小時，甚至更長時間。然而大數據領域並沒有革命性的框架來解決MapReduce慢的問題，人們只能一邊抱怨一邊想辦法優化MapReduce的性能，然而效果並不是很理想。
直到2015年Spark技術框架的成熟，人們終於找到了替代MapReduce的新選擇，這是一個將數據放到內存中計算的新框架，是一個比MapReduce快100倍的計算框架，對於擁有大數據量的企業來講，真的是久旱逢甘霖，大家一股腦的沖進了Spark的懷抱，至此，大數據數據處理開了Spark時代。
有必要一提的是，Spark除了替代MapReduce以外，還帶來了Spark Streaming，專門用來解決流式（實時）計算的問題。雖然當時市場有Apache Storm/Alibaba Jstorm等成熟的流式計算框架，但很快被Spark Streaming淘汰了，個人覺得打敗Storm的主要原因就是Spark Streaming提高了數據處理的吞吐量和Spark on yarn的運行方式（Storm需要單獨部署一套集群）。
時間到了2018年，Spark迎來了新的挑戰者，那就是Apache Flink。Apache Flink與生俱來的流式計算處理能力，大大提高了數據處理的實效性，除了實效性的提升，Apache Flink還實現了exactly-once語義（一條數據只處理一次）、State管理。
作為計算領域最先進的技術框架，Apache Flink一路攻城拔寨，氣勢如虹。隨着2018年年底阿里巴巴收購Flink的母公司，Flink China在中國開始了大規模的Flink技術推廣。唾手可得中文文檔、深入淺出公開視頻、阿里巴巴的最佳實踐，加快了Flink技術在中國市場的迅猛落地。
到了2019年的今天，人們出門必談Flink，如同2015年，那時人們出門必談Spark。
面對技術的快速迭代，不禁唏噓，雖然MapReduce拼命的完善自己的生態，但是面對Spark的到來，依然毫無一戰之力。同樣，即使Spark生態圈已經如此完善，覆蓋了離線計算、實時計算、機器學習、圖計算等等諸多領域，面對Flink的到來，也在節節敗退。
相對MapReduce基於磁盤的計算模式，Spark基於內存的計算方式是革命性的創新；相對Spark批量/微批的計算模式，Flink使用了流式計算的模式貼近了數據產生的本源；在它們各自的時代里，它們都代表了先進的生產力，都是以摧枯拉朽之勢，雷霆萬鈞之力擊垮對手。然而面對新的技術革新，它們都是那么弱小，不禁想起了劉慈欣《三體》中的有一句話，毀滅你，與你何干？