Spark已死？DBT會替代？

banq發表於2022-02-02
Spark

資料世界再次發生變化。自從 Hadoop 出現以來，人們就將工作負載從他們的資料倉儲轉移到了新的閃亮的資料湖中。沒過多久，2010 年開源的 Spark 就成為了資料湖上的標準處理引擎。
現在我們看到一個反向趨勢，回到資料倉儲。隨著這一趨勢，DBT 幾乎已成為在現代雲原生資料倉儲上進行轉換的事實上的標準。使用 DBT，人們發現他們可以用更少的工程師和更少的維護更快地構建資料管道。
我預測這種趨勢只會持續下去，總有一天，DBT 將在使用者數量、工作數量和在資料領域的重要性方面超過 Spark。
 

Spark 填補了一個不再存在的空白
Spark 背後的整個前提是 RDD。彈性分散式資料集 (RDD)是一種分散式記憶體抽象，允許程式設計師以容錯的方式在大型叢集上執行記憶體計算。
顯然是需要在多臺機器上進行巨大的記憶體計算，因為單個機器的記憶體是有限的，唯一可行的叢集規模計算的選擇是Hadoop，它是基於MapReduce的。MapReduce是出了名的重度磁碟IO，並沒有真正捕捉到所有閒置的RAM的價值。
Spark完美地填補了這一空白。突然間，大量的大資料處理都可以高效地完成。而且，Spark採用了一種非常好的函式式方法來定義你的操作，所以你的語法很簡單，至少與MapReduce程式碼相比是如此。
但說實話，這個空白還在嗎？這些天來，我們都在雲中一起選購我們的基礎設施。
如果這還不夠記憶體計算，你現在可以使用AWS Batch或Kubernetes等服務輕鬆地將你的工作負載分佈在多臺機器上。
你不再需要有一個分散式的應用程式，而你可以使用標準的python程式碼輕鬆地進行擴充套件。
 
我們的客戶95%的工作都是相對較小的python工作，也許有5%的工作我們可以使用Spark提供的重任。這很好。但是，Spark已經不是最重要的了。它只是我們工具箱中的另一個工具。
"啊，這個不能執行單節點？最好在這裡使用Spark"。
我們已經建立了Datafy，不需要再擔心這些問題。我們只是告訴Datafy要執行一個作業，需要多少個節點，多少記憶體。然後Datafy會在幕後為我們做一些Kubernetes的魔法。
它並不關心我是安排100個小的python作業還是5個大的spark作業。
它自動調整Kubernetes節點的規模，啟動它所需要的pods，然後再次調整規模。這節省了雲端計算成本，也讓我不用擔心基礎設施的問題。我可以專注於我的資料工作。
 

今天的資料倉儲比2010年的時候要強大得多。
這不僅僅是雲端計算基礎設施的成熟。2020年的資料倉儲與內部部署的昂貴、難以維護的單體完全不同。所有大的雲端計算供應商都有強大的產品，尤其是谷歌Bigquery，讓你的入門變得超級方便。它功能齊全，效能高，得到廣泛支援，最重要的是，它是純粹的現收現付定價。你按掃描的TB付費。這使得進入的門檻降低了很多。你不需要再投資一大堆錢來建立一個資料倉儲。雖然，顯然，資料倉儲仍然不便宜。但執行Databricks叢集也不便宜。價格差異在2010年是一個論據。在2020年就不是了。而且，可擴充套件性也絕對不是一個問題了。除了Bigquery，像Snowflake這樣的公司在市場上創造了巨大的吸引力，並證明他們可以大規模地執行。
 

為什麼是DBT？
為什麼DBT獲得瞭如此多的關注？以下是我認為他們做得對的地方。

  • 他們很好地執行了一個 "明顯 "的偉大想法。

有了DBT，你就可以使用SQL構建你的資料管道。你可以建立模組化的管道，並透過變數和宏引用你的資料模型的其他部分。這是一個我在工業界至少見過5次的想法。總是有一些膠布解決方案被放在一起，以安排一堆SQL工作。說實話，我們也做過一些這樣的解決方案。但是，我們從來沒有真正意識到要把這個產品化為更大的東西並推向市場。這顯然是一個偉大的想法。但DBT實際上是在執行這個想法。為他們點贊。
  • 他們在市場上有一個令人難以置信的勢頭

他們上個月已經宣佈了他們的B系列。他們得到了一些最著名的風險投資公司的支援，如Andreessen Horowitz和紅杉資本。他們最大的競爭對手（據我所知）是Dataform，它剛剛被谷歌雲收購。Dataform已經落後了。這隻會使他們更成為一個小眾的參與者。如果你是在GCP上，那就太好了。但我不認為谷歌有任何計劃讓Dataform在Redshift、Synapse或Snowflake上發光發熱。
  • 他們在工程方面很強

作為一個資料工程師，我總是對那些聲稱他們可以消除複雜性，現在 "每個人都可以在3個簡單步驟中建立一個資料產品 "的工具有點懷疑。通常情況下，這些都是類似於excel的產品，或者是帶有閃亮使用者介面的拖放式產品，在銷售演示中給人留下深刻印象。但是，當你需要在生產中維護這些龍的時候，它們確實會讓你哭泣。
DBT則不同。在DBT中，你可以輕鬆地使用變數，你可以構建模組化的程式碼，你可以新增單元測試，你可以將所有的程式碼提交給git，並輕鬆地將DBT整合到你的CI/CD管道中。它甚至可以為你生成一個文件網站，包括世系。
  

那麼，"Spark "已經死了？
一點也不！我認為Spark是一個很好的工具，如果你有大資料工作負載，需要大量的繁重工作，並且你有工程師為你建立管道，那麼Spark就是一個很好的工具。我認為，如果你有大資料工作負載，需要大量的繁重工作，而且你有工程師可以為你建立管道，那麼Spark是一個偉大的工具。Spark仍然比SQL更有表現力，而且你對Spark中的處理方式的控制要比SQL多得多。
一般來說，資料環境是不斷變化的。技術來了又走。這是一個以一種對你的組織有意義的方式將它們結合起來的問題，而且這種方式對你的團隊也有好處。然後你就能從資料中獲得洞察力，這就是我們在這裡的原因，對嗎？Spark、Python、DBT和其他許多工具都只是我們的工具帶中的工具。沒有一輛偉大的汽車是隻用一把螺絲刀或只用一把錘子建造的。
我確實認為，因為DBT的入門門檻很低，而且知道SQL的人比知道Spark的人多得多，所以DBT最終會被更多人採用。它使資料分析更加民主化。我們已經把它從財務部門拖出來了，現在我們正在把它從IT部門拖出來。有一天，分析學將真正生活在業務部門。想象一下吧。

 

相關文章