搬移程式到資料端 (move code to data)

應用軟體工程師 (application developer) 與資料工程師 (data engineer) 的工作內容，關鍵差距在哪？我認為，前者做的工作多半是 move data to code ，而後者則做的則多半是 move code to data 。

我跟別人打了一個賭。

我與業務同事一起去拜訪客戶要銷售 MDS ，而我在對客戶的資料工程師做簡報時，談了 move code to data 這個概念。事後，業務對我表示，這個概念她已經聽了兩次了，完全沒有聽懂，勸我修改簡報的內容。我跟業務說：「來打賭吧。你之後可以找機會與客戶連絡，你不妨在連絡時，問問客戶的反應，如果他們說 move code to data 是很無聊的東西，不知道我在講什麼，就是你贏了，我會乖乖改簡報。反之，…。」

對許多的軟體工程師來講，算是常識的事情是：CPU 的速度 >> IO 的速度，差距可以高達百萬倍以上。正因如此，程式運行所花費的時間，常常是 IO 佔了極高的比例。比方說，網銀轉帳，它如果有資料要從遠端的資料庫取得，從資料庫拉取這些資料所花費的時間、還有資料計算完畢後透過網路把結果送到我們的瀏覽器所花的時間，這些都是 IO 的時間，而 IO 時間會在程式消耗的總時間裡佔據一個相當高的比例。

由於 IO 對於程式運行的效率影響甚巨，如果可以減少 IO 的時間，對於效能的提昇會有極大的改進。也正因如此，快取機制 (cache mechanism) 、網路傳輸協定 (network protopol) 、還有資料壓縮 (data compression) 等等機制，直到今日，都還一直不斷地創新。這些技術，每隔幾年就會推出新的，畢竟改進 IO 的效能一直都是剛性需求。

然而，一旦當資料的量，動不動就是以幾百G (gagabytes) 為單位在計算時，傳統的作法，即從資料庫搬移資料到程式端，運算完之後再寫回資料庫的 move data to code 作法，就非常地不適用了。在資料量極大的前提之下，如果還是用 move data to code 的作法來做，IO 的時間遠超過 CPU 運算時間的現象會非常明顯，此外，效能也會差到無法忍受。

這時，不妨讓我們來回顧一個哲學層次的問題：「什麼是運算可以在機器上發生的前提條件？」運算 (computation)，比方說，1 + 2 = 3 ，這樣子的運算要可以發生在機器上，它有一個隱而不現的前提：資料與程式碼必須在同一台機器上。以上述的例子來，程式碼是 + 的部分，而資料是 1, 2 的部分。

要滿足前提的話，除了傳統的作法之外，還有另一種可行的編程方式，那就是「搬移程式到資料端」(move code to data)。其實，這種作法至少已經有兩種算是常見的案例了：

• 在大數據的 Hadoop 應用，寫 MapReduce ，就是一種搬移程式到資料端。

• 在傳統的資料倉儲應用，寫複雜的 SQL 來生成報表，也是一種搬移程式到資料端。

在 AI 的領域，所謂的資料庫內分析 (in-database analytics) 也是一樣套用「搬移程式到資料端」的概念。與其從關聯式資料庫裡把大量的資料拉取出來之後，再用 R 語言、Python 語言去做迴歸運算、機器學習，浪費大量的 IO 時間，還不如延展 SQL 的語法，讓使用者可以直接在資料庫裡，把迴歸運算與機器學習利用 SQL 來加以實現。

應用軟體工程師也需要懂的特例

應用軟體工程師的工作，多半與 move code to data 無關，但是也有例外：「遇到 N+1 問題的時候」。

什麼是 N+1 問題呢？應用軟體工程師若使用 Ruby on Rails 之類的開發框架來輔助產生 SQL 來取代手刻 SQL，由於 SQL 是由 Ruby on Rails 自動生成的，它預設不會刻意去做效能的最佳化，這時就會有 N+1 問題發生。舉例來講，如果要做的操作是從學校 (school) 這個資料庫裡，取出某個班級 (class) 的所有學生 (student) 的資料，並且對每個學生的數學成績做開根號乘以十。自動生成的 SQL 有可能會是這樣子做：

1. 產生 1 個 SQL 查詢去取得某班所有的學生的資料，假設得到 N 筆學生的資料

2. 產生 N 個 SQL 查詢去取得每個學生的數學成績。

一旦考慮到 IO 非常慢的這個事實之後，上述自動生成的 N+1 個 SQL 自然是相當地低效率。高效的作法，則是只產生一個 SQL 查詢，它內含了 join ，所以可以只用一個 SQL 查詢，就做完步驟１與步驟 2 的工作，即只用一個 SQL 查詢就取回所有學生的數學成績。

什麼，身為應用軟體工程師的你，超愛處理這種特例，那你要不要考慮改行去做資料工程師？(笑～)