理想上的技術棧要可以達成下列兩個要求：

1. 讓開發人員充分表達意圖的抽象層
2. 該抽象層可以讓電腦充分發揮效能

以程式語言來舉例：從 1. 來講的話，Python 會受歡迎，是很合理的事，畢竟只論語言設計的簡潔、語法的一致性，確實是 Python 勝出。從 2. 來講的話，JVM 的市佔率始終一直很高，也是自然的結果。

而當一位工程師面對資料處理問題時，關鍵的技術棧決策，常常是 MapReduce vs SQL 的決策。到底該選哪一個才對呢？

我大多數的時候都選 SQL 。而許多為了這個技術棧決策爭扎不已的工程師聽了我的解釋之後，也覺得選 SQL 是很合理的選項。

MapReduce

先快速地帶過一下，工程師可能會傾向 MapReduce 的理由：

1. MapReduce 以 Spark 為例，可以用 Java 寫、用 Python 寫、用 Scala 來寫。對於多數的後端工程師來講，命令式的編程語言還是比宣告式的 SQL 親切地多，似乎更容易表達開發人員完整的意圖。
2. MapReduce 適合 scale out ，當資料量極大，超過一台的機器可以負荷時，顯然是讓電腦充分發揮效能的最佳解決方案之一。

SQL 92 也許表達能力有限，但是你可以使用 SQL 2003

這邊來談一下 ANSI SQL 標準。許多人所認知的 SQL ，還有許多 SQL 教科書，SQL 考題，訓練課程會談的 SQL ，通常就只到 SQL 92 。SQL 92 的下一版 ANSI SQL 則是 SQL 1999 ，再下一版是 SQL 2003。

SQL 表達能力的宗廟之美、百官之富，卻是在 SQL 1999 之後，才開始扺達巔峰，因為後來的 SQL 又陸續新增了：

1. Grouping Sets
2. Lateral Join
3. Window Functions
4. json 的處理函數

在 2003 年的時候，多數的資料庫除了 Oracle 之外，很可能還追不上 SQL 2003 的標準。換言之，就算你會寫 Window Function ，你用的 MySQL 也不支援。然而，現在已經是 2023 年了，上述提到的四個功能，絕大多數的 RDBMS 都有支援了。

MapReduce 可以 scale out ，但是你不一定有那麼多的資料。

在 2004 年，Google 剛發表 MapReduce 論文的時代，在那個時間點，運算無法塞入單一一台機器是很容易發生的事。在那個時代，最好的硬體與今日完全不能相比， scale up 非常困難，資料量一大，就只剩下 scale out 的選項。如果說，在那個年代，要處理的總資料量是 1 T 左右，幾乎不用懷疑，首選 MapReduce 。

以今日的技術來講，首先，1T 根本是 scale up 就可以搞定的資料量。再來，其實只有極少數的公司，會有超過 1T 的資料。

這邊可以試算給大家看：

1. 以一間典型的中小企業為例，它有 1000 個客戶
2. 假設每位客戶每天都下一個新訂單，並且每一個新訂單都有 100 項品項。
3. 以 2. 來講，這個頻率算很高了，但是，整間公司一天仍然無法新產生超過 1M 的資料。
4. 照上述的數字，需要 3 年才能產生 1G 的資料。

其它對 SQL 的質疑？

有幾項對於優先選擇 SQL 的質疑非常地有力：

1. 該怎麼組合大量的 SQL 呢？
2. 如果說，應用案例，剛好需要動態地去生成 SQL ，比方說，要 union 三個不同的 SQL query 呢？
3. 該怎麼整合版本控管軟體呢？

如果有上述的需求，不是還是一樣要用其它的程式語言嗎？那還不是不能只用 SQL ，如果這樣子的話，優先選擇 SQL 真的會是最簡單的解決方案嗎？

針對這些質疑，我們會在後續的章節一一提出解決方案。

其它資源

1. 對 dbt 或 data 有興趣 👋？歡迎加入 dbt community 到 #local-taipei 找我們，也有實體 Meetup 請到 dbt Taipei Meetup 報名參加
2. 歡迎訂閱 PruningSuccess 電子報，主要談論軟體開發、資料處理、資料分析等議題。