Notes of Chapter 2 A Data Workflow Framework in Principles of Data Wangling
一、資料價值的傳遞
1. 間接：人為
由一群富有知識以及經驗的人，將現有的資料以他們的理解框架詮釋過後，傳遞給組織以幫助決策，例如保險業的風險評估模型。
2. 直接：自動
藉由程式開發的資料處理流程，自動將資料餵給數據驅動的系統，例如 Netflix 上的推薦系統。
要能做到資料傳遞的自動化，必須要先能人為做到。書中提到人在這當中擔任的角色，主要是確認「資料裡面有什麼」以及「資料的品質是否合格」。另外，我認為人也擔任了一個發散再歸納的角色，必須在面對各種情境的時候，一一找到對應的解決方案，然後歸納經驗並程式化。程式出錯時再回去修正邏輯，藉由這樣反覆來回修正，一步步優化資料處理流程，最終始能做到自動化。
而作者將這樣的過程，拆為三個階段並敘述各階段目的：
1. Raw Stage
吃資料、資料探索及描述。
2. Refined Stage
設計能符合所有資料的處理流程、執行分析、建模及預測。
3. Production Stage
建立 Production 等級的資料品質、建立例行性報表以及自動化資料產品/服務。
將資料處理流程由 IT 自動化，有兩個優點：
- 符合數據治理（Data Governance）的基本原則，中央統一處理。
- 提升資料使用的效率，IT 準備好材料，由其他部門廣泛地重複使用。
而放到實際環境中主要面臨兩個問題：
- 需要大量的資料處理時間。
- 人數的不對等，時常只有少數的幾個 IT 面對大量的分析人員。
在做資料價值傳遞時首要必須考量的兩個點：
- 傳遞出來的價值要是能夠被執行的。
- 盡可能地提升資料處理流程的效率。
二、Raw Stage
- 主要動作：吃資料
- 主要輸出：描述資料、評估資料可用性
1. 吃資料
資料傳遞的方式由簡單到複雜：
(1) Email, FTP, 共享網路的資料夾
(2) Alteryx, Talend, Informatica Cloud
- 優點：非工程師也有能力做設定及維護
(3) Sqoop, Flume, Kafka：
- 優點：可取得更即時、資料粒度更細的資料
- 缺點：軟體開發及維護成本
資料儲存的方式從不彈性到彈性：
(1) Relational Database 關聯式資料庫：將資料存入預先定義好架構的地方 schema-on-write。
(2) NoSQL 資料庫：讓資料以較有彈性的方式存入，例如有 MongoDB, Cassandra。
(3) Distributed Filesystem 分散式檔案系統：讓使用者能夠自由新增、修改、複製、移動資料，並針對個別資料給予不同權限，不需要事先定義好結構 schema-on-read，例如有 HDFS, Amazon S3。
來自不同合作夥伴的資料，一般在 Raw Stage 會分別存在不同的資料集，並在 Refined Stage 將這些資料以統一的標準及格式做整理。
2. 資料探索及描述
在描述資料時，有幾個關鍵面向：
(1) Structure 結構
- 每筆紀錄的欄位是否相同？相同 CSV，不相同適用 XML 跟 JSON。
- 每個欄位是單一值還是多值？
- 每個欄位的資料型態
- 文字編碼、是否被 Hash、時區、日期時間格式、幣別
(2) Granularity 粒度
- 每筆紀錄的主體，例如每個顧客在每間店的交易、每間店每天的營收、每區每週的營收。
(3) Accuracy 正確性
- 資料品質：正確性 & 一致性
- 常見的資料不正確問題：產品編碼不全、不同產品共用同一個產品編碼、產品編碼過期、拼錯字、沒有正確分類、數值異常過大過小、日期時間格式不一致、資料筆數異常過多過少、電話格式、地址格式、Email 格式。
(4) Temporality 時間性
- 資料什麼時候被蒐集？
- 每筆紀錄被建立之後是否還會更新？是否有更新的時間戳記？
- 如何判定資料是舊的？紀錄有衝突時是否能用時間戳記判斷何為真？
(5) Scope 範圍
- 每筆紀錄的主體包含了什麼特徵？不包含什麼特徵？
- 每個欄位與外部資料的關聯性？
- 欄位之間彼此是否一致？例如生日跟年齡，交易商品金額加總後與交易總金額。
- 是否有遺失的資料？是隨機性遺失或是系統性遺失？
- 每筆紀錄的主體是否有重複的資料？是否改變了資料粒度？是否在分析前需要去除重複？
- 每筆紀錄是否為同質性的資料？如果不是，異質性資料之間的關聯性是？
三、Refined Stage
- 主要動作：設計並準備精煉過後的資料、特定的分析、建模及預測
- 主要輸出：能夠立即運用至各種分析的資料、有用的資訊及洞見
1. 設計精煉的資料
在 Refined 階段，在各個關鍵面向可能遇到的問題及解決方法：
(1) Structure 結構
在各個分析及視覺化工具中，皆以 table 作為主要輸入，必要時須將 Raw Data 轉換成 table。在建模及預測時，則需將類別型變數做轉置的動作。
(2) Granularity 粒度
用不同資料粒度儲存同一個資料集，視需求儲存多個版本能夠幫助直接的分析。
(3) Accuracy 正確性
處理欄位內錯誤資料的基本三個方式：
- 刪除有錯誤資料的紀錄
- 保留有錯誤資料的紀錄，但標示不正確
- 用預設值或是推估的值取代錯誤的值
一般常見的錯誤會出現在欄位之間彼此衝突，而解決這個衝突最常用的方法是利用時間戳記來判斷。也有一些情境用其他標記來判斷會更適合，例如軟體的版本版號。
(4) Scope 範圍
設計資料的範圍時，要確認資料擁有需求的欄位，例如假設客戶相關的資料分散在很多張 table 裡面，就可以視需求把他們併在一起。
2. 特定的分析、建模及預測
特定的分析一般以報表、簡報或是 Dashboard 來呈現，用以回答過去或是現在的問題；而建模及預測則用來回答未來的問題，或是用以了解結果與各個特徵之間的關聯性。
四、Production Stage
當 Refined Stage 中特定的分析、建模及預測，被需求單位認為是需要持續更新追蹤結果的時候，就需要將這些一次性的應用系統化，用一個固定的流程去開發、排程、監控這些資料的結果。
1. 建立優化後的資料
相對於 Refined Stage 設計精煉的資料，Production Stage 則需要針對更特定的分析需求，去優化資料格式、簡化資料，讓資料能夠更正確、有效率地支持各種分析。
2. 建立例行性的資料服務
建立例行性的資料服務，仰賴持續地監控資料流程，並確保在結構、粒度、正確性、範圍都能維持穩定的品質。當新的資料持續地進來，按照同一個邏輯去轉換資料時，難免會有舊的邏輯與新的資料不符合的情形發生，例如新資料的正確性出問題、有欄位被移除或是變空值、重複的資料、資料部分遺失等等。這些邏輯的來回修正，都是優化資料流程必要的動作。
五、Pei 心得
在接收、處理各種資料到開發資料服務時總會遇到不同的狀況，能有一群經驗豐富的作者寫成一個架構，用較全面性的視角來看，覺得有被提醒到不少事情，像是描述資料的文件應該包含什麼面向，確認資料時應該確認哪些點。除此之外，對整個資料服務的架構有了比較明確的階段性定義，可以知道目前自己手上的東西在哪一個階段，什麼應該往 Production 進行，什麼應該保留在 Refined 的階段，每個階段依該發揮什麼功能等等。可以有的 action 包括：
- 列出所有資料來源並建立文件描述資料
- 建立每一段資料流程的確認項目
- 列出所有資料服務並確認所處階段