▌第一部 資料工程



第1章 我還想要更懶惰

需求概述

既有的作法：試算表流水生產線

相對合理的設計

軟體開發

業務報表

專案的後續與感想



第2章 現代資料棧（Modern Data Stack）

可程式化工具

資料基礎建設

資料基礎建設的發展階段

應用現代資料棧還有其它優點嗎？

選SQL 而非MapReduce

ELT 取代ETL

函數式資料轉換

理想的解決方案：現代資料棧

之後的章節



第3章 View Layer（視覺化層）：Metabase

自助式資料服務的必要條件

Metabase 安裝

Metabase 自動分析

Metabase 基礎操作

Metabase 進階操作

Metabase 圖表/ 視覺化

Metabase 互動儀表板與嵌入式分析

Metabase 自動化（Automation）

本章小結



第4章 Transformation Layer（資料轉換層）：dbt 與SQL

三個常見的SQL 難題與對應作法

dbt 安裝

DuckDB 安裝

dbt 基本操作

dbt 資料建模

dbt 進階操作

本章小結



第5章 Transformation Layer：SQL 概論

SQL 起步

SQL 進階語法

SQL 效能改進

本章小結



第6章 EL 與ETL

EL 是普遍的需求

ETL 仍然是重要的選項

EL 工具

Meltano 簡介

dlt 簡介

ETL 設計原則

ETL 開發實務

本章小結



第7章 資料可靠性（Data Reliability）

除錯方法論

dbt 套件- Elementary

dbt test

Recce

兩難問題的因果分析

本章小結



第8章 即時資料（Real Time Data）

不同的應用、不同的即時

變更資料擷取（Change Data Capture）

資料倉儲內的Lambda 視圖

簡易資料湖與查詢引擎

本章小結



第9章 將複雜度往下移動

機敏資料

隨著時間而變動的資料

即時資料的查詢延遲

本章小結



第10章 資料工程的挑戰

資料工程的思考：搬移程式到資料端

資料工程的思考：簡單與可擴展性的並存之道

隱而不現的資料工程問題

採用新技術時的準備

本章小結



▌第二部 資料分析



第11章 ChatGPT 作為一種資料分析工具

什麼是資料分析？

什麼是ChatGPT？

應用ChatGPT 的後設技巧（Meta-skill）

資料分析活用ChatGPT

進階議題：形式語言學的應用

本章小結



第12章 管理與統計

管理實務

量化與統計學的連結

貝氏定理（Bayesian Theorem）

Z 檢定

費米估算（Fermi Estimation）

信賴區間

蒙地卡羅法

線性模型

探索式資料分析（EDA, Exploratory Data Analysis）

本章小結



第13章 各領域的資料分析

引導決策的指標

可信度

編碼

本章小結



▌第三部 管理實務



第14章 資料團隊

結果優先vs 流程優先

複雜度轉換：往下層移動

三種常見的資料團隊組織架構

資料團隊的發展

資訊的價值

向上管理vs 向上資訊管理

逆向工作

本章小結



第15章 變革管理

評估新技術

向上溝通：原理

向上溝通：從現在到未來

從想法到行動

本章小結



結語 寫給想要更懶惰的人



?

序



　　▌我是在浪費我的時間



　　我有十八年寫Java 的經驗。跟你們講這件事，並不是要強調我很有經驗，而是要告訴各位：我是在浪費我的時間。（編按：如果改用Clojure 寫的話，同樣的程式用1/3 不到的時間就有機會寫完。）–Rich Hickey（Clojure 語言發明人）



　　在2019 年以前，我並沒有好好地研究過BI（Business Intelligence）又或是資料分析（Data Analysis）、資料工程（Data Engineering）等相關問題，大部分的職涯是在新創公司當Backend/Full Stack Engineer。有一回，我得到一個工作機會，以約聘雇的身分，到一家位於台北市內湖區的科技公司上班，幫業務部開發一套軟體系統。這家公司的軟體是L 開頭的，就叫它L 社吧。



　　找我去的人，是L 社業務部的BI 主管。面談的那一天，他簡單地講了他的需求，講得也模模糊糊的，事後來看，他只講了整個系統的10% 不到的需求。我聽完就先回答了對該需求的看法，然後，順便展示了一下之前寫的程式。



　　「你下個禮拜可以來上班嗎？」面露「祟拜神色」的BI 主管問道。



　　唉，我這個人其實非常地誇不得，我居然就這樣子貿然地答應了一個專案，也沒有確切的把握，該專案是否有在我的能力範圍之內。



　　到了這個專案完成之後，我才了解，我所解決的問題，嚴格地來講，是資料工程與資料分析的問題。



　　由於當年我真的不懂BI、資料分析、資料工程，所以我只應用了應用軟體開發（Application Programming）的技巧來硬做。由於沒有充分地利用當時已經存在最好的技術，我花了整整180 天，才勉強抵達終點。如果現在讓我重做一次，60 天就可以做完。



　　上述的這個故事，重點並不是要講我很有經驗，而是，我是在浪費我的時間。



　　▌更靈活的工具與方法論



　　多數資料團隊應用的工具是：Tableau、Power BI、FineReport 這種集成式的軟體。上述的軟體非常強大，就像Microsoft 的Office 365 一樣。



　　然而，我們有時候需要更靈活的工具：我們希望我們的工具可以像Linux Shell 一樣，有許多小的零組件，一個零組件只做好一件事，比方說：awk、sed、tr、sort、cat、?，卻可以靈活地組合起來，而且，容易自動化。



　　本書要談論的現代資料棧（Modern Data Stack），這套工具與方法論就像是Linux Shell 一般地靈活、容易自動化、可以提昇數倍的產出。



　　▌改變現況



　　如果你唯一的工具只有鐵槌，那你看到的每個東西大概都長得像是釘子。– 諺語



　　前面提到我在專案中的失敗，其實正是一個錯誤應用「熟悉工具」的案例。



　　我用熟悉的應用軟體開發方法，去解決資料工程的問題，結果當然事倍功半。



　　而這也顯現了一個更普遍存在的模式：現代資料棧（Modern Data Stack）是一個由多種領域知識交織而成的解法，它不只是程式設計或資料分析單一領域的產物，而是軟體開發、資料工程、資料分析等跨領域知識的結合。



　　正因如此，來自不同背景的角色——像是產品經理、商業分析師、資料分析師或資料工程師——往往容易基於自己的經驗而忽略某些看起來不熟悉的解決方案。他們可能會覺得這些方法「不屬於他們的領域」或是「看起來太奇怪了」，從而錯失採用的機會。



　　除了既定視角的理由之外，還有各式各樣的執行面理由，可以讓現代資料棧這個解決方案難以被採用：



　　• 時程問題：專案的時程往往很趕，而對技術沒有一定了解的管理階層通常不會安排空白的時間，讓團隊去好好調查研究，有哪些可能的技術選項可以納入考慮。



　　• 技術債：資料團隊可能已經有一套既有的資料處理架構了，就算發現新的解決方案可能會帶來質的改進，想到要把過去已經完成的資料管線重做，就覺得導入新的解決方案異常的困難，因為很難停下手邊所有的事，並且空出一段時間去一口氣打掉過去所有的資料管線，重新建置。



　　• 決策權：基層的員工就算看出了新的解決方案的價值，如果說服不了整個團隊、或是上級，也往往無法導入新的解決方案。



　　• 風險：既有的作法往往經歷了時間的考驗，雖然不優雅，通常可以處理各式各樣的特殊情況。如果對於新的解決方案沒有充分的掌握之前，很可能導入到一半，才發現，特殊情況難以處理，因而陷入進退維谷的風險。



　　上述就是產業常見的現況，就算有了更好的解決方案，也未必可以付諸實施。而本書的使命就是改變現況。本書要帶著讀者一覽資料工程、資料分析領域的種種挑戰，從問題出發做種種的討論，希望可以讓讀者可以帶著確信、果斷地踏出改變的第一步。



　　▌導讀



　　本書分成三部分：資料工程、資料分析、管理實務，分別探討了以下三個主題：



　　1. 資料工程師，要應用什麼樣子的軟體與方法論，可以快速地做出高品質的資料基礎建設，以利後續的資料應用？



　　2. 想要將資料分析應用於組織的實務工作，第一步該如何踏出？資料分析師常用的技巧、理論基礎有哪些？在面對全新類別的問題時，可以回顧哪些經典的資料分析案例，以設法得到解題的靈感？



　　3. 當某個組織希望開始積極應用資料以提昇經營效率時，該如何建立有效的資料團隊？有什麼組織架構的選項？有什麼發展路徑可以依循？此外，當讀者有志於在組織導入新的解決方案時，應該怎麼做才能確實地一步一步前進，而不是一次又一次地向上級報告之後，一切又回歸原狀？

　

　　▌線上資源及程式語法



　　本書所提及的線上資源網址以及程式語法，另有放一份在GitHub 提供參考：github.com/dbt-local-taipei/dbt-book-02

?