總結Hadoop20年的歷史及相關的一切
每當我進入RPG視頻遊戲中的圖書館時 ，我都會忍不住去看每一個書架，以更好地掌握遊戲的宇宙。有誰記得《上古捲軸》中的"帝國的簡史上古捲軸"？
大數據，特別是Hadoop生態系統，誕生於15年多一點的時間裡，其發展方式很少有人能夠預料到。
自從Hadoop誕生和開放原始碼以來，它已經成為存儲和處理PB級數據的首選武器。圍繞它已經形成了一個廣泛而充滿活力的生態系統，有數百個項目，而且它仍然在許多大公司中使用，即使其他幾個基於雲的專有解決方案現在正在與它競爭。通過這篇文章，我旨在快速回溯Hadoop生態系統這15年¹的發展歷程，解釋它在過去十年中是如何成長和成熟的，以及大數據生態系統在過去幾年中是如何不斷發展的。
因此，請系好安全帶，進行為期20年的時間旅行，我們的故事開始於2003年，在舊金山南部的一個小鎮。
免責聲明：我最初的計劃是用提到的公司和軟體的標誌來說明這篇文章，但由於TDS禁止廣泛使用標誌，我決定用隨機的圖片和無用的瑣事來保持娛樂性。試著回憶一下我們當時在哪裡，做了什麼，這很有趣。
2003-2006:開始
始於2003年: iTunes, Android, Steam, Skype, Tesla.
始於2004年:Thefacebook, Gmail, Ubuntu, World of Warcraft.
始於2005年:Youtube, Reddit.
始於2006年:推特, 藍光.Waze, Oblivion.
這一切都開始於本世紀初，當時在山景城的一家已經不算小的創業公司，名為谷歌，正試圖為整個已經不算小的網際網路建立索引。他們不得不面對兩個主要的挑戰，但在這樣的規模下還沒有解決。
如何在成千上萬的磁碟上存儲數百兆字節的數據。
甚至是數據不可用？
如何以有效和有彈性的方式並行計算，以處理所有這些機器上的所有數據？
在所有這些機器上處理所有這些數據？
為了更好地理解為什麼這是一個困難的問題，考慮一下，當你有一個有一千台機器的集群時，平均總是至少有一台機器停機²。
從2003年到2006年，谷歌發布了三篇研究論文，解釋了他們的內部數據架構，這將永遠改變大數據行業。第一篇論文是在2003年發表的，題目是"谷歌文件系統".第二篇論文是在2004年發表的，題目是"MapReduce。簡化大型集群上的數據處理"，根據谷歌學術的數據，從那時起已經被引用了超過21000次。第三篇論文於2006年發表，題目是"BIgtable結構化數據的分布式存儲系統"。即使這些論文對Hadoop的誕生至關重要，但谷歌並沒有參與其誕生本身，因為他們保留了原始碼的所有權。然而，這個故事背後的故事是非常有趣的，如果你沒有聽說過Jeff Dean和Sanjay Ghemawat，那麼你一定要閱讀本文.
同時，Hadoop之父，一位名叫Doug Cutting的雅虎員工，他已經是Hadoop的創造者。 Apache Lucene(搜尋引擎庫的核心是 淘寶網和 彈性搜索)的創造者，當時他正在進行一個高度分布式的網絡爬蟲項目，名為 Apache Nutch.和谷歌一樣，這個項目需要分布式存儲和計算能力來實現大規模。
在閱讀了谷歌關於谷歌文件系統和MapReduce的論文後，Doug Cutting意識到他目前的方法是錯誤的，並從谷歌的架構中得到啟發，在2005年為Nutch創建了一個新的子項目。 他以他兒子』的玩具(一隻黃色的大象)。 Hadoop.這個項目從兩個關鍵部分開始：Hadoop分布式文件系統（HDFS），以及MapReduce框架的實現。與谷歌不同，雅虎決定將該項目作為Apache軟體基金會的一部分進行開源，從而邀請所有其他主要的科技公司使用並為該項目做出貢獻，並幫助他們縮小與鄰居的技術差距（雅虎總部位於桑尼維爾，緊鄰山景城）。正如我們將看到的，接下來的幾年超過了預期。當然，谷歌也做得相當好。
2007-2008:Hadoop的早期採用者和貢獻者
始於2007年: iPhone, Fitbit, Portal, Mass Effect, Bioshock, The Witcher.
始於2008年:蘋果應用商店、安卓市場、Dropbox、Airbnb、Spotify、谷歌瀏覽器。
很快，其他面臨類似體積問題的公司開始使用Hadoop。在過去的日子裡，這意味著一個巨大的承諾，因為他們必須自己安裝和管理集群，而且寫一個MapReduce作業不是在公園裡散步（相信我）。雅虎試圖在編寫MapReduce作業時減少複雜性，其結果是 Apache Pig是一個ETL工具，能夠將自己的語言（Pig Latin）翻譯成MapReduce步驟。但很快其他人也開始為這個新的生態系統作出貢獻。
2007年，由23歲的馬克-扎克伯格領導的一家年輕但發展迅速的公司Facebook，在Apache許可下開源了兩個新項目。 Apache Hive和 Apache Cassandra一年之後。Apache Hive是一個能夠將SQL查詢轉換為Hadoop上的Map-Reduce作業的框架，而Cassandra是一個寬列存儲，旨在以分布式方式大規模訪問和更新內容。Cassandra不需要Hadoop來運作，但隨著MapReduce的連接器被創建，它迅速成為Hadoop生態系統的一部分。
與此同時，一家不太知名的公司Powerset正在開發一個搜尋引擎，他從谷歌的Bigtable論文中得到啟發，開發了 Apache HBase這是另一個依靠HDFS進行存儲的寬列存儲。Powerset很快就被微軟收購了，用來啟動一個新的項目。
最後但並非最不重要的是，另一家公司在Hadoop的快速採用中起到了決定性作用。亞馬遜。通過啟動亞馬遜網絡服務，即第一個按需雲，並迅速通過彈性MapReduce服務增加對MapReduce的支持，亞馬遜允許初創企業輕鬆地將他們的數據存儲在s3上，即亞馬遜的分布式文件系統，並在上面部署和運行MapReduce作業，而無需管理Hadoop集群的麻煩。
2008-2012:Hadoop供應商的崛起
始於2009年:比特幣, Whatsapp, Kickstarter, Uber, USB 3.0.
始於2010年: iPad, Kindle, Instagram.
始於2011年:Stripe, Twitch, Docker, Minecraft, Skyrim, Chromebook.
使用Hadoop的主要痛點是設置、監控和維護Hadoop集群所需的大量努力。很快，第一家Hadoop供應商Cloudera在2008年成立，Hadoop之父Doug Cutting很快加入。Cloudera提出了一個預先包裝好的Hadoop發行版，稱為CDH，以及一個集群監控界面Cloudera Manager，最終使得安裝和維護Hadoop集群以及其配套軟體如Hive和HBase變得容易。之後不久，Hortonworks和MapR也出於同樣的目的成立。Datastax在2010年成立時，Cassandra也得到了它的供應商。
很快，大家都同意，儘管Hive是一個處理巨大ETL批次的偉大的SQL工具，但它並不適合交互式分析和BI。任何習慣於標準SQL資料庫的人都希望它們能夠在幾毫秒內掃描一個有一千條記錄的表，而Hive卻需要幾分鐘（這就是你讓大象做老鼠的工作的結果）。這時，一場新的SQL戰爭開始了，這場戰爭至今仍在激烈進行（儘管我們會看到，從那時起，其他人已經進入了這個領域）。谷歌再次間接地對大數據世界產生了巨大影響，它在2010年發布了第四篇研究論文，名為"Dremel：網絡規模數據集的互動分析".這篇論文描述了兩個主要的創新：一個是分布式交互查詢架構，它將激發我們在下文中提到的大多數交互式SQL；另一個是面向列的存儲格式，它將激發幾個新的數據存儲格式，比如說 Apache Parquet由Cloudera和Twitter聯合開發的，和 Apache ORC由Hortonworks和Facebook聯合開發的 ，。
受Dremel的啟發，Cloudera為了解決Hive的高延遲問題，並使自己在競爭對手中脫穎而出，於2012年決定啟動一個新的開源SQL引擎，用於交互式查詢，名為 阿帕奇小惡魔.同樣，MapR也啟動了自己的開源交互式SQL引擎，名為 Apache Drill而Hortonworks決定，他們寧願努力使Hive更快，也不願從頭開始創建一個新的引擎，並開始了 Apache TezHive是MapReduce的第二版，並將Hive改編為Tez，而不是MapReduce。有兩個原因促使他們做出這個決定：第一，他們的規模比Cloudera小，沒有足夠的人力來採取與他們相同的方法；第二，他們的大多數客戶已經在使用Hive，他們寧願讓它工作得更快，也不願意切換到另一個SQL引擎。正如我們將看到的，很快就出現了許多其他的分布式SQL引擎，而 "人人都比Hive快 "成為了新的座右銘。
2010-2014年：Hadoop 2.0和Spark革命
始於2012年:UHDTV，Pinterest，Facebook達到10億活躍用戶，Gagnam Style視頻在Youtube上達到10億次瀏覽。
始於2013年:愛德華-斯諾登泄露NSA文件, React, Chromecast, 谷歌眼鏡, Telegram, Slack.
當Hadoop正在整合併增加一個新的關鍵組件時。 YARN(Yet Another Resource Manager)作為其官方的資源管理器，這個角色之前是由MapReduce笨拙地完成的，當這個開源項目 Apache Spark開始以前所未有的速度獲得牽引力。
很快就可以看出，Spark將成為MapReduce的一個很好的替代品，因為它有更好的功能，更簡單的語法，而且在許多情況下比MapReduce快得多，特別是由於它能夠在RAM中緩存數據。與MapReduce相比，唯一的缺點是一開始不穩定，隨著項目的成熟，這個問題逐漸消失。它與Hive也有很好的互操作性，因為SparkSQL是基於Hive的語法的（實際上，他們一開始就借用了Hive的詞法/解析器），這使得從Hive遷移到SparkSQL相當容易。它在機器學習領域也獲得了巨大的吸引力，因為之前在MapReduce上編寫機器學習算法的嘗試，如 Apache Mahout(現在已經退役了）很快就被Spark的實現所超越了。
為了支持Spark的快速發展並使其盈利，其創建者在2013年成立了Databricks。從那時起，它的目標是使每個人都能進行大規模的數據操作，通過提供許多語言（Java、Scala、Python、R、SQL甚至.NET）的簡單而豐富的API以及與許多數據源和格式（csv、json、parquet、jdbc、avro等）的本地連接器。值得注意的是，Databricks採取了與他們的前輩不同的市場策略：Databricks沒有提出Spark的內部部署（Cloudera和Hortonworks很快將其添加到自己的平台上），而是選擇了純雲平台的報價，從AWS（這是當時最流行的雲）開始，其次是Azure和GCP。九年後，我們可以肯定地說，這是一個明智之舉。
同時，其他正在崛起的科技公司也開源了處理實時事件的新項目，如 Apache Kafka Linkedin製作的分布式消息隊列，以及Apache Storm Twitter製作的分布式實時計算引擎³。這兩個項目都是在2011年開源的。另外，在這一時期，亞馬遜網絡服務正變得像以前一樣流行和成功。Netflix在2010年的驚人增長，主要是由亞馬遜的雲計算實現的，這一點就可以說明問題。雲計算的競爭者終於開始出現，微軟Azure在2010年開始普遍使用，谷歌雲平台（GCP）在2011年開始使用。
2014-2016年達到頂峰⁴。
始於2014年:Terraform, Gitlab, Hearthstone.
始於2015年。Alphabet, Discord, Visual Studio Code.
從那時起，作為Hadoop生態系統一部分的項目數量繼續成倍增長。它們中的大多數在2014年之前就開始開發，其中一些也在那之前成為開源項目。項目的數量開始變得混亂，因為我們達到了這樣的程度：對於每一個需求，都有多個軟體解決方案存在。更多的高級項目也開始出現，比如。 Apache Apex(現在已經退役）或 Apache Beam(主要由Google推動)，旨在提供一個統一的接口來處理各種分布式後端上的批處理和流處理，如Apache Spark、Apache Flink或Google的DataFlow。
我們還可以提到，由於Airbnb和Spotify的出現，我們終於開始看到好的開源調度器進入市場。調度器的使用通常與使用它的企業的業務邏輯相聯繫，而且它也是一個相當自然和直接的軟體編寫，至少在開始時是這樣。然後你就會意識到，要保持它的簡單和易於他人使用是一項非常困難的任務。這就是為什麼幾乎每家大的科技公司都編寫並（有時）開源了自己的軟體。然而，從來沒有一個廣泛的共識，認為其中一個是非常好的選擇，大多數公司堅持自己的。幸運的是，2015年左右，Airbnb開源了 Apache Airflow，而Spotify則開源了Liuge⁵，這兩個調度器在其他公司中迅速達到了很高的採用率。特別是，Airflow現在可以在SaaS模式下的 谷歌雲平台和 亞馬遜網絡服務.
在SQL方面，出現了其他幾個分布式數據倉庫，旨在提供比Apache Hive更快的互動查詢能力。我們已經談到了Spark-SQL和Impala，但我們還應該提到Presto在2013年由Facebook開源的 "數據倉庫"，在2016年被亞馬遜重新命名為雅典娜在2016年被亞馬遜重塑為他們的SaaS產品，並在其原始開發者離開Facebook後被Fork，它的原始開發者在離開Facebook後被Fork為在專有方面，也發布了幾個分布式SQL分析倉庫，如谷歌的BigTable在2011年首次發布，亞馬遜的Redshift在2012年和Snowflake創立於2012年。
要獲得作為Hadoop生態系統的一部分被引用的所有項目的列表，其中引用了150多個項目.
2016-2020年 容器化和深度學習的崛起，以及Hadoop的衰落
始於2016年:Occulus Rift, Airpods, Tiktok.
始於2017年:Microsoft Teams, Fortnite.
始於2018年:GDPR, 劍橋分析公司的醜聞,。
2019年開始:迪斯尼+, 三星Galaxy Fold, Google Stadia
在接下來的幾年裡，一切都在不斷加速和相互聯繫。要跟上大數據市場中新技術和新公司的名單變得越來越困難，因此，為了簡短起見，我將談談在我看來對大數據生態系統影響最大的四個趨勢。
第一個趨勢是數據基礎設施向雲端的大規模遷移，HDFS被亞馬遜S3、谷歌存儲或Azure Blob存儲等雲存儲所取代。
第二個趨勢是容器化。你可能已經聽說過Docker和Kubernetes了。 碼頭是一個容器化框架，於2011年推出，從2013年開始迅速流行。在2014年6月，谷歌開源了它的內部容器編排系統 Kubernetes(a.k.a. K8s)，該系統立即被許多公司採用，以建立其新的分布式/可擴展架構的基礎。Docker和Kubernetes使公司能夠部署新型的分布式架構，更加穩定和可擴展，適用於許多用例，包括基於事件的實時轉換。Hadoop花了一些時間來追趕docker，因為在Hadoop中啟動Docker容器的支持是在2018年的3.0版本到來。
第三個趨勢，如前所述，是用於分析的完全管理的大規模並行SQL數據倉庫的崛起。現代數據棧 "和2016年首次開源的dbt的崛起很好地說明了這一點。
最後，影響Hadoop的第四個趨勢是深度學習的出現。在2010年下半年，每個人都聽說過深度學習和人工智慧：AlphaGo在圍棋比賽中擊敗了世界冠軍柯潔，這是一個里程碑，就像20年前IBM的深藍在西洋棋中擊敗卡斯帕羅夫那樣。這一技術飛躍已經完成了奇蹟，並承諾會有更多的奇蹟，如自動駕駛汽車，通常與大數據有關，因為它需要壓縮大量的信息，以便能夠訓練自己。然而，Hadoop和機器學習是兩個完全不同的世界，它們很難在一起工作。事實上，深度學習推動了對大數據新方法的需求，並證明了Hadoop並不是適用於一切的工具。
長話短說：從事深度學習的數據科學家需要兩樣東西，而Hadoop當時還不能提供。他們需要GPU，而Hadoop集群節點通常沒有GPU，而且他們需要安裝最新版本的深度學習庫，如Tensorflow或Keras，這在整個集群中很難做到，尤其是當多個用戶要求同一庫的不同版本時。Docker很好地解決了這個問題，但Docker對Hadoop的整合花了不少時間，而數據科學家們現在就需要它。因此，他們通常更願意用8個GPU生成一個虛擬機，而不是使用一個集群。
這就是為什麼當Cloudera在2017年進行IPO時，他們已經將開發和營銷重點放在了他們最新的軟體上，即 數據科學工作檯，這不是基於Hadoop或YARN，而是基於Docker和Kubernetes的容器化，並允許數據科學家將他們的模型與自己的環境作為一個容器化的應用程式進行部署，而不會有安全或穩定性問題的風險。
這還不足以阻止他們的衰退。2018年10月，Hortonworks和Cloudera合併，只剩下Cloudera這個品牌。2019年，MapR被惠普企業（HPE）收購。2021年10月，一家名為CD&R的私人投資公司以低於初始價格的股票價格收購了Cloudera。
不過，Hadoop的衰落並不意味著它的死亡，因為許多大公司仍然在使用它，特別是在內部部署方面，而且所有圍繞它建立的技術都在使用它，或者至少是它的一部分。創新也仍在進行中。例如，新的存儲格式被開源了，如 Apache Hudi最初於2016年在Uber開發。 Apache Iceberg2017年在Netflix開始，以及 Databricks的Delat Lake在2019年將其開源。有趣的是，這些新文件格式背後的主要目標之一是為了規避我提到的第一個趨勢的後果。Hive和Spark最初是為HDFS構建的，而 HDFS所保證的一些性能特性在向S3等雲存儲的遷移中丟失了，這導致了效率的降低。但我不會在這裡討論細節，因為這個特定的主題需要另一篇完整的文章。
2020-2023年的現代
於2020年開始:COVID-19大流行。
2021年開始:Log4Shell漏洞，Meta，Dall-E。
2022年開始:烏克蘭戰爭, Midjourney, 穩定的擴散。
如今，雲中的Hadoop部署大多被Apache Spark或Apache Beam⁶應用所取代（大多在GCP上），而Databricks、亞馬遜的Elastic Map Reduce（EMR）、Google Dataproc/Dataflow或Azure Synapse則從中獲利。我還看到許多年輕的公司直接瞄準了 "現代數據棧 "的方法，圍繞SQL分析倉庫，如BigQuery、Databricks-SQL、Athena或Snowflake，由無代碼（或低代碼）的數據攝取工具提供，並以dbt.com組織。 其中』似乎根本不需要Spark這樣的分布式計算工具.當然，那些仍然喜歡內部部署的公司仍然在使用Hadoop和其他開源項目，如Spark和Presto，但被轉移到雲端的數據比例每年都在增加，我認為目前沒有理由改變這種情況。
隨著數據產業的不斷成熟，我們也看到更多的元數據管理和目錄工具被建立和採用。在這個範圍內，我們可以提到 Apache Atlas，由Hortonworks在2015年開始。Amunson，由Lyft在2019年開源的，以及Datahub，在2020年由Linkedin開源。許多私營技術初創公司也出現在這一領域。
我們也看到了圍繞新的調度器技術建立的初創公司，如 Prefect, Dagster 和 Flyte，它們的開源資源庫分別於2017年、2018年和2019年啟動，並且正在挑戰Airflow目前的霸權地位。
最後，Lakehouse的概念已經開始出現了。Lakehouse是一個平台，結合了數據湖和數據倉庫的優勢⁷。這使得數據科學家和商業智能用戶可以在同一個數據平台內工作，從而使治理、安全和知識共享更加容易。由於Spark在SQL和DataFrames之間的多功能性，Databricks很快就在這個產品報價上定位了自己，他們在Snowflake之後以 Snowpark和 Azure Synapse 以及最近的谷歌公司的BigLake。在開源方面。 Apache Dremio自2017年以來提供了一個Lakehouse架構。
2023年 - 誰能告訴我們未來會是什麼樣子？
自從這一切開始以來，大數據領域的開源項目和初創公司的數量一直在逐年增加（只要看一下 2021年景觀就可以看到它已經變得多麼龐大）。我記得在2012年左右，有些人預測新的SQL戰爭會結束，真正的勝利者最終會出現。這還沒有發生。所有這一切在未來將如何發展是很難預測的。還需要幾年的時間才能塵埃落定。但是，如果我不得不做一些胡亂的猜測，我將做出以下預測。
- 正如其他人已經指出的正如其他人已經指出的那樣，現有的主要數據平台（Databricks、Snowflake、BigQuery、Azure Synapse）將繼續改進並增加新的功能，以縮小彼此之間的差距。我希望看到每個組件之間有越來越多的連接，還有像SQL和Python這樣的數據語言。
- 在未來幾年，我們可能會看到新項目和新公司的數量放緩，儘管這更多地是由於新的網絡泡沫破裂後缺乏資金（如果這曾經發生），而不是由於缺乏意願或想法。
- 從一開始，主要缺乏的資源就是熟練的勞動力。這意味著對大多數公司來說⁸，在性能問題上投入更多的錢，或遷移到更有成本效益的解決方案，而不是花更多的時間去優化它們。特別是現在主要分布式倉庫的存儲成本已經變得非常便宜。但也許在某些時候，供應商之間的價格競爭對他們來說會變得更加難以維持，價格也會上升。即使價格不漲，企業存儲的數據量也在逐年增加。 以及與之相關的低效率成本。也許在某個時候，我們會看到一個新的趨勢，人們開始尋找新的、更便宜的開源替代品，一個新的類似Hadoop的周期將再次開始。
- 從長遠來看，我相信真正的贏家將是雲計算供應商，谷歌、亞馬遜和微軟。他們所要做的就是等待和觀察風向的變化，等待時機，然後收購（或簡單地複製）最有效的技術。每一個被整合到他們的雲中的工具都會使用戶的事情變得更加容易和無縫，特別是在涉及到安全、管理、訪問控制和成本管理時。只要他們不犯重大的組織性錯誤，我不認為現在有誰能追上他們。
總結
我希望你喜歡和我一起進行的這次記憶之旅，並希望它能幫助你更好地理解（或簡單地記住）這一切是如何開始的。我試圖使這篇文章對每個人來說都很容易理解，包括非技術人員，所以不要猶豫，與那些有興趣了解大數據來源的同事分享它。
最後，我想強調的是，如果沒有開源和知識共享的神奇力量，人類在人工智慧和大數據方面的知識和技術永遠不會發展得這麼快。我們應該感謝谷歌，他們最初通過學術研究論文分享了他們的知識，我們也應該感謝所有將其項目開源的公司。在過去的20年裡，開源和免費（或至少是廉價）獲取技術一直是網際網路經濟創新的最大動力。20世紀80年代，一旦人們能夠買得起家用電腦，軟體創新就真正起飛了。3D列印也是如此。 它已經存在了幾十年，並在2000年隨著自我複製機器的到來而諸如，樹莓派的到來推動了DYI運動的發展。
開源和輕鬆獲取知識應該永遠被鼓勵和爭取，甚至比現在更多。這是一場永無止境的戰鬥。一場這樣的戰鬥，也許是最重要的一場。 這些天在人工智慧方面正在發生的事情.大公司確實為開源做出了貢獻（例如谷歌的TensorFlow），但他們還學會了如何使用開源軟體作為金星捕蠅器吸引用戶進入他們的專有生態系統，同時將最關鍵的（和最難複製的）功能放在專利後面。
對人類和世界經濟來說，我們繼續儘可能地支持開源和知識共享工作（如維基百科）是至關重要的。政府、公民、公司以及最重要的投資者必須明白這一點：增長可能是由創新驅動的，但創新是由與大眾分享知識和技術驅動的。
"做你必須做的事。"做你必須做的事，做你可能做的事"（這句話寫在巴黎人道教堂的牆壁上）。
腳註
¹ : 如果算上谷歌的前傳，甚至是20年，所以才有這個標題。
²：也許在2022年，我們在硬體可靠性方面取得了足夠的進展，使這一點不那麼真實，但這絕對是20年前的情況。
³ : 在2016年。 Twitter開源了Apache Heron (似乎仍處於Apache的孵化階段）來取代Apache Storm。
⁴: 雙關語意。
⁵ : 在2022年。 Spotify決定停止使用Luigi，轉而使用Flyte
⁶:我認為Apache Beam主要用於GCP和DataFlow。
⁷: 正如Databricks所說Lakehouse將數據湖的靈活性、成本效益和規模與數據倉庫的數據管理和ACID交易相結合。
⁸:當然，我在這裡說的不是像Netflix和Uber那樣規模的公司。
本文由聞數起舞翻譯自《2003–2023: A Brief History of Big Data》
原文連結 https://towardsdatascience.com/2003-2023-a-brief-history-of-big-data-25712351a6bc