為何 Data engineering 不等於 Software engineering ?
我向來主張 Data team 並不是 IT team，不適合用IT的方式做管理，必須因地制宜。最近我看了一篇我認為是關於這個議題很精闢的剖析，這篇就重點做摘要:
Software engineering 聚焦於打造應用，而Data engineering專精於Data pipelines，然而兩者之間的差異在於 :
1. Pipeline不同於一般軟體的應用，沒有直接的價值，有價值的是上面承載的數據
若數據能滿足用戶需求，就算是單純的拷貝複製貼上也行 (而不需要中間的處理) ，相對的，一般軟體應用的價值往往比較外顯，可以直接與終端用戶互動
2. Pipeline先天與內外部其他組成，存在高度相依性，因此充滿變數與不穩定。下游Pipeline的可靠程度，取決於上游數據源的可靠程度
相對的，一般軟體應用則容易模組化，成為個別獨立的元件，易於管理與放大
3. 數據集通常是透過Pipeline以漸進的方式累積而來，而不是平行獨立組合而成，造成前後與當時的情境相依，且往往不可重現
相對的，一般軟體應用則強調stateless、container、microservices，可以在任何環境與情境下重啟，仍可得到一樣的結果
Agile的方法不適合直接套用於Pipeline開發，因為 :
1. 對於用數據的人而言，唯有數據是完整、真確、穩定，才有價值
若硬套用MVP的方法學，會導致破碎的數據被交付 (即Prototype)，反而會造成下游應用大亂，像是用數據的人前後的insight矛盾、說詞反覆，損及信任，且先前所建立的實驗與報表要重新再來過，導致沒必要的重工
2. 開發pipeline的effort跟欄位數量無關，並不是欄位越少，開發的effort就越小
- 這是因為若欄位涉及多來源交叉運算，則複雜度就不一定
- 其他因子也會影響：batch or streaming、能否fit在RAM內?
3. 數據集Dataset的建造與維護成本，卻是跟數據的量成正相關
- 變更或砍掉特定row的值，對於分析用Analytical的數據集，比起Transactional DB，往往成本高昂
- 數據集有一個特性：先天存有有巨大的慣性 (the inertia of data) 任何下游的應用與高度相依性都會阻撓上游的變動
- 更新數據集(Updating datasets) 跟 更新pipeline code (Redeploying pipeline code)是兩回事：packaging & containerization無助於降低更新數據集的複雜程度與effort
4. Data pipeline 難以 Unit test
- 因為數據高度相依的特性，造成建立具有代表性的測試環境往往成本高昂
- 造成Pipeline的測試通常都是以直接上production進行 (deploy & run it)
- Pipeline在開發的當下，需要對數據源做出特定的假設，但數據源往往之後都會產生品質變化，造成Data bugs
- Pipeline程式可無誤的跑 (Program bugs) =/= Data是真確的 (Data bugs)
- 一般軟體的 Unit test 處理的問題是「does this function work as intended? 這個功能是否符合當初的期待?」
- 但Pipeline若要進行 Unit test，則必須建造真確性足以代表數據源的 test data，但這個複雜度往往遠高的於軟體的 Unit test
5. 因為高度的相依性，下游pipeline必須仰賴上游數據/pipeline的穩定，下游的開發仰賴上游開發時得到的insight
- 造成Pipeline開發往往是依序線性的，難以同時分散給多人平行展開
- 即便對數據源以Data contract做品質的規範跟約束，長期而言，因為對上游數據提供方沒有incentive，往往難以持續遵守
總結
因為以上的複雜度 (eg. 難以unit test、以直接部署當作測試、高度相依與高度不穩定、難以平行展開) 造成Pipeline開發的feedback loop比起一般軟體開發更為漫長，若沒有察覺兩者間細微的差異，假裝數據工程和軟體工程是同一回事，很有可能會得到降低生產力的結果。