資料世界再次動搖。自從Hadoop出現以來，人們就將工作負載從資料倉庫轉移到了嶄新的資料湖上。不久之後，2010年開源的Spark成為了資料湖上的標準處理引擎。

現在，我們看到了逆向趨勢，回到了資料倉庫。隨著這種趨勢的發展，DBT已幾乎成為在現代雲原生資料倉庫上進行轉換的事實上的標準。使用DBT，人們發現他們可以以更少的工程師和更少的維護來更快地建立資料管道。

> https://getdbt.com

我預測這種趨勢只會持續下去，有一天，DBT在使用者數量，工作數量以及在資料領域的重要性方面將比Spark大。三個論點：

如今，至少在我們看到的客戶中，DBT的採用速度比Spark快。DBT可以面向更廣泛的受眾。如果您知道SQL，就可以開始使用DBT。使用Spark，您需要Scala或Python背景。並不受分散式計算的威脅。資料市場現在更大。越來越多的公司希望對資料進行有趣的處理，如果您從今天開始，DBT會提供一個更加流暢的切入點。

但是為什麼呢？為什麼DBT會獲得如此多的採用？為什麼現在呢？讓我們從第二個問題開始，因為時間就是一切。

為什麼現在？

有很多原因為什麼現在對DBT這樣的工具來說是個好時機。

Spark填補了一個不再存在的空白

Spark背後的整個前提是RDD。關於RDD的論文就是這樣開始的：“我們提出了彈性分散式資料集（RDD），這是一種分散式記憶體抽象，它使程式設計師能夠以容錯的方式在大型叢集上執行記憶體中計算。”顯然需要在多臺計算機上進行大量的記憶體計算。單機記憶體有限，唯一可行的叢集規模計算選擇是基於MapReduce的Hadoop。眾所周知，MapReduce佔用大量磁碟IO，並沒有真正捕捉到周圍所有RAM的價值。

> https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final138.pdf

Spark完美地填補了那個空白。突然之間，您的許多大資料處理都可以非常高效地完成。而且Spark擁有一種非常好的功能性方法來定義您的操作，因此，至少與MapReduce程式碼相比，您的語法簡潔而簡短。

但老實說，那空白還在嗎？如今，我們所有人都在雲中一起購買基礎架構。購物可能會很有趣，即使對於“標準”例項也是如此：

> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/memory-optimized-instances.html

如果記憶體不足，您現在可以使用諸如AWS Batch或Kubernetes之類的服務輕鬆地在多臺計算機上分配工作負載。您不需要具有分散式應用程式。如果編寫許多小型應用程式，則可以使用標準python程式碼輕鬆擴充套件。

我們與客戶進行的大多數合作，我們95％的工作都是相對較小的python工作，也許對於5％我們可以使用Spark提供的繁重工作。太好了但是，Spark不再是重中之重。這只是我們工具箱中的另一個工具。“啊，這個不能執行單個節點？最好在這裡使用Spark”。我們建立了Datafy，不再需要擔心任何這些。我們只是告訴Datafy執行一項作業，需要多少個節點，以及多少記憶體。然後Datafy在幕後為我們做一些Kubernetes魔術。不管我計劃100個小型python作業還是5個大型spark作業。它會自動縮放kubernetes節點，啟動它所需的Pod，然後再次縮小。這節省了雲成本，並且使我不必擔心基礎架構。我可以專注於資料工作。

資料工程師長期短缺

我聽到你說：“克里斯，Spark比今天的RDD多得多”。沒錯藉助Spark，您現在可以執行流技術，ML甚至SQL。它已成為一個非常完整的工具箱。而且許多資料工程師都喜歡它。包括我。就是這樣，有時候我會感到孤獨。

許多資料科學家更喜歡使用Python及其豐富的ML庫生態系統。順便說一句，您聽說過GPU處理嗎？資料分析師實際上在過去幾年中實際上忽略了。它們要麼在Tableau中建立儀表板或用拖放工具構建ETL管道。教他們程式碼只是幾個橋樑太遠了。他們需要更接近家的東西。

今天的資料倉庫比2010年強大得多。

成熟的不僅僅是雲計算基礎架構。2020年的資料倉庫與內部部署的昂貴，難以維護的整體裝置完全不同。所有大型雲提供商都提供強大的產品，特別是Google Bigquery使上手變得超級方便。它功能齊全，效能卓越，得到廣泛支援，最重要的是，它是按需付費的純價格。您按掃描的TB付費。這使進入的門檻大大降低。您無需再投入大量資金來建立資料倉庫。儘管顯然，資料倉庫仍然不便宜。但是都沒有執行Databricks群集。價格差異是2010年的一個爭論。不是2020年。可擴充套件性絕對不再是問題。除了Bigquery之外，像Snowflake這樣的公司在市場上也產生了巨大的吸引力，並證明了它們可以大規模執行。

為什麼選擇DBT？

那裡的所有成分都會破壞市場。那麼，為什麼DBT獲得如此大的吸引力？我認為這是對的：

他們在“顯然”的好主意上很好地執行得很好。

使用DBT，您可以使用SQL建立資料管道。您可以構建模組化管道，並透過變數和宏引用資料模型的其他部分。這個想法我在業界至少見過5次。總是將某種膠帶式解決方案組合在一起以計劃一堆SQL作業。老實說，我們也構建了其中一些解決方案。但是，我們從未真正將它生產成更大的產品並將其推向市場。這顯然是個好主意。但是DBT實際上是在執行該操作的。對他們表示敬意。

他們在市場上擁有令人難以置信的勢頭

他們已經在上個月宣佈了B系列。距離其A輪融資還有7個月了。他們得到了安德森·霍洛維茨（Andreessen Horowitz）和紅杉資本（Sequoia Capital）等一些最著名的風險投資公司的支援。他們最大的競爭對手（我知道）是Dataform，該公司剛剛被Google Cloud收購。Dataform已經落後了。這隻會使他們更加利基化。如果您使用的是GCP，那就太好了。但是我認為Google沒有任何計劃讓Dataform在Redshift，Synapse或Snowflake上大放異彩。

他們在工程方面很強

作為資料工程師，我總是對那些聲稱可以消除複雜性的工具持懷疑態度，而現在“每個人都可以透過3個簡單的步驟來構建資料產品”。通常，這些產品都是具有超凡脫俗的外觀或具有光澤UI的拖放式產品，在銷售演示中給人留下深刻的印象。但是它們確實會讓您在維持生產這些龍的那一天哭泣。

DBT是不同的。在DBT中，您可以輕鬆地使用變數，可以構建模組化程式碼，可以新增單元測試，可以將所有程式碼提交到git並輕鬆地將DBT整合到CI / CD管道中。它甚至會為您生成一個文件站點，包括沿襲。

> https://docs.getdbt.com/docs/building-a-dbt-project/documentation/

所有這些事情對業務人員來說都很無聊，但是作為工程師，他們讓您更有信心，您可以在生產中實際支援DBT工作負載，並且可以圍繞它構建健康的釋出流程。

這就是為什麼我們也很快將DBT整合到Datafy的原因。計劃DBT與計劃spark或python作業沒有什麼不同。這是一個可以構建，部署和執行的Docker容器。該docker容器恰好包含SQL程式碼，而不是Python或Spark程式碼。

所以Spark死了嗎？

一點也不！我認為，如果您有需要大量繁重工作的大資料工作量，並且擁有可為您構建管道的工程師，Spark是一個很好的工具。Spark仍然比SQL更具表現力，與SQL相比，Spark對處理方式的控制更多。

通常，資料環境一直在變化。技術來了又去。這是一種對您的組織有意義並且對您的團隊有用的方式來組合它們的問題。然後，您將能夠從資料中獲得見解，這就是為什麼我們在這裡，對嗎？Spark，Python，DBT和許多其他工具只是我們工具欄中的工具。僅用螺絲刀或錘子就無法制造出偉大的汽車。

我確實認為，因為進入DBT的壁壘低得多，並且比SQL瞭解Spark的人更多，所以DBT最終會被更多的採用。它使資料分析更加民主化。我們已經將其拖出財務部門，現在將其拖離IT部門。有一天，分析實際上將存在於業務部門中。想象一下。