資料管線與資料完整性:有備份不等於能還原

· tech

#sre#data-engineering

📑 目錄

一個資料系統的可靠度,除了前面講的「服務不掛」,還有一層更根本的東西——資料本身不能不見、不能錯。這篇講兩件事:資料管線的可靠度,以及一個會顛覆你直覺的觀念:「有備份」不等於「能還原」。

資料管線:週期性管線的隱形陷阱

資料管線(pipeline)的可靠度,跟線上服務不太一樣。最常見的隱形陷阱,是週期性管線的積壓:資料量慢慢長大 → 單次處理時間變長 → 錯過排程視窗 → backlog 越積越多 → 下一輪一次要嗑超大批(thundering herd)→ 更慢。而且 pipeline 常常是多個 stage 串起來的,任何一個 stage 卡住或吐出壞資料,整條就卡住、或悄悄汙染下游

所以資料管線的可靠度,要顧的跟線上服務不同:資料新鮮度的 SLA(產出要多新)、每個 stage 都要監控(別等最後才發現中間爛了)、以及最關鍵的——冪等、可重跑(接我 Airflow 那篇):壞了能安全地重跑一遍、結果一致,而不是重跑就重複或炸掉。

「有備份」不等於「能還原」

接著是這篇最想讓你記住的一句話。大家對資料安全的直覺是「我們有備份,放心」——但這份安心,很可能是假的:

你以為的安全 每天都有備份 ✓✓✓ 「帳面上」很安全 真的要還原時… 真出事時翻車 備份檔本身壞了(從沒驗過) 還原程序沒人跑過 → 手忙腳亂 還原太慢 → 超過 SLA、資料回不來 沒演練過還原的備份 = 薛丁格的備份(不打開不知道死活) 重要的不是「備份」,是「恢復」—— 備份只是達到恢復的手段
「我們有備份」是最危險的安全感之一。備份檔可能早就壞了、還原程序可能沒人跑過、還原可能慢到趕不上 SLA——這些都要真的演練還原才會發現。所以真正該衡量的指標,是「能不能、在期限內、真的把資料救回來」,不是「有沒有備份」

資料完整性:假設每一層都會漏

還有一個反直覺的事實:資料遺失多半不是硬體壞,而是 bug 和人——一個 bug 把欄位寫錯、一次誤操作刪錯、上游一批壞資料靜靜汙染了整個下游。所以防禦不能只靠「備份硬體故障」,要深度防禦(defense in depth),疊好幾層:

威脅:bug · 誤刪 · 壞資料汙染下游 · 硬體壞 ① Soft delete 軟刪除先標記、延遲真刪 → 給後悔時間 ② Backup + Recovery備份 + 定期還原演練(不只是備份) ③ Early detection 早期偵測資料驗證 / 對帳 → 使用者發現前抓到 資料完整 ✓
深度防禦:軟刪除給你反悔的時間、早期偵測在資料靜靜爛掉時就抓到、備份+還原兜最後的底。精神是——假設任何一層都會失效,所以疊多層,而不是把身家壓在單一道防線上

反思

「有備份」是我看過最危險的安全感

備份給人一種很踏實的安心,但這份安心常常是假的——沒演練過還原的備份,是薛丁格的備份,不打開不知道是活的還死的。 備份檔可能默默損毀了半年、還原程序可能寫在某份沒人看的文件裡從沒被跑過、真要還原時可能慢到趕不上業務能忍受的期限。所以我現在聽到「我們有備份」,反射動作是問一句:「上次真的做還原演練,是什麼時候?還原花了多久?」 答不出來,那份安全感就是紙糊的。這跟 SRE 一貫的精神一致:別假設,去驗證——備份要定期真的還原一次,就像測試要定期真的跑一次。

資料遺失,多半不是硬體壞,是 bug 和人

一般人想到資料遺失就想到硬碟燒掉,但真實世界更常見的,是一個 bug 把整欄寫錯、一次手滑刪錯 table、上游一批髒資料無聲無息汙染了整條下游。這些用「硬體備援」擋不掉,只能靠深度防禦:軟刪除給後悔的時間、早期偵測(對帳、驗證)在使用者發現前就抓到、備份+還原兜最後的底。而且要假設每一層都會漏,才會疊得夠厚。這跟 連鎖失效那篇的悲觀是同一種——好的可靠度工程,都建立在「假設它會壞」而不是「希望它不壞」之上。

資料管線的可靠度,是資料工程的一半功夫

這章對我特別親切,因為資料管線正是我每天在做的事。它提醒我:一條 pipeline 的可靠度,遠不只是「今天有沒有跑成功」——是資料夠不夠新(新鮮度 SLA)、重跑會不會壞(冪等可重跑)、backlog 追不追得上、壞資料會不會靜靜汙染下游。我在 Airflow 那條線講的冪等、在 DDIA 講的可靠性,跟這章講的其實是同一件事:讓資料在各種故障之下,依然「一直都在、而且正確」。 服務掛了重啟就好,但資料錯了、丟了,往往是回不來的——所以資料的可靠度,值得比服務的可靠度更偏執一點。