Cheng Wei Chen | 艦長

前言 嗨，大家好，我是艦長！ 歡迎來到 Data Observability 系列文的第 8 篇。 本文要實現上一篇的承諾，接下來真的要開始談「資料可觀測性」（Data Observability）。 Data Observability，它是一個新興的 Buzzword？還是已經成為 Data 圈的常見實踐？本文我們先不過度深入，先從這關鍵字的趨勢來認識它。 網路關鍵字趨勢 首先我們先從 Google Trends 開始，看看這個關鍵字的搜尋趨勢。 打開 Google Trends，輸入「Data Observability」，從圖中可以發現在 2019 年以前，這個詞幾乎無人關注，直到 2020 年12月才開始有了起色，然後維持一個小眾的熱度，最後到了 2025 終於熱度有明顯的上升。 （圖片擷取自 Google Trends。） 從這樣的圖表看來，Data Observability 仍是一個相對新的關鍵字，依然在發展中的階段。 如果我們將它跟其他關鍵字一起比較，會更能看出這件事。 誰在談論這個關鍵字？ 既然關鍵字熱度有在提升，那下一步來猜猜看是誰在推廣（炒作）這個關鍵字。 未看先猜，你的答案裡面一定有各種服務供應商對吧！ 確實如此，畢竟供應商的商業嗅覺是敏銳的，有能夠賣錢的關鍵字，當然要衝一波。 首先很早期喊出 Data Observability 的是 Monte Carlo Data這間新興的服務供應商，目前可以找到比較早開始談資料可觀測性的文章，很多都來自這間公司。 當然，過去專注在 Monitoring 及 Metrics 的廠商也不會放過機會，因此像是 Datadog 也有跟上。以及本來就擁有包山包海各種解決方案的 IBM 也有一些動作。 （IBM 也有一個網頁在介紹 Data Observability。） Data 圈的一些知名服務供應商，例如 Splunk 就有網頁在介紹 Data Observability；而像是 Snowflake、Databricks、Cloudera，雖然他們自己沒有在談 Data Observability（多半是談 Observability），但倒是有一些想要搶 Data Observability 市場的新供應商，會嘗試將自己跟他們連結，例如 Acceldata 就有 “Data Observability and Support for Hadoop” 或 “Acceldata Data Observability for Snowflake Optimization” 這樣的文章。...

前言 嗨，大家好，我是艦長。 歡迎來到系列文的第 7 篇。過去 6 篇，我鋪了很多梗，讓大家可以更多認識軟體圈與 Data 圈的差異，點出原來 Data 圈關心的產品就是 Data 本身。 這篇文我們繼續拉回一個不分軟體圈和 Data 圈的議題「為什麼我們需要可觀測性？」 軟體圈有監控，但還是會發生客戶比你更早打電話來反應：「欸，你們的服務，今天是不是怪怪的？」 而 Data 圈也同樣有做資料監控，可是 Data User 還是會跑來跟你說：「欸，這份報表的數字怪怪的喔！」 所以到底是為什麼，明明我們已經有做了許多努力，卻無法解決品質問題？ 監控：見樹不見林的被動查核 前一篇文章中，我們有談到資料工程、資料監控。我覺得其實工程與監控這兩者都是基礎建設，也就是本來就該做的基本任務。 你本來就需要資料工程搭建資料管線去處理 Data，你的資料管線本來就該有基本的監控、告警與日誌功能。同樣你寫的軟體與線上服務，本來就該做好應有的 Error handling、Log 及監控告警等。 然而過去以來我們多半都是用一種「被動」的態度在處理「監控」。 因為有了 A，所以要加上 B 監控。 因為發生了 C，所以要加上 D 監控。 因為老闆說要 E，所以加上 F 監控。 也就是被動的檢核，「基於已知的問題，設定規則來檢查」。 並不是說監控（被動的檢核）就沒有用處，它當然很有用，它能幫我們發現與紀錄一些明確的問題，不然為什麼大家要在各種任務上，建立各種檢核表、SOP、檢核點。但它也有所侷限，容易形成一種局部、單點的查核。 可觀測性：提升系統資訊透明度的主動思維 而本系列文想要介紹的「資料可觀測性（Data Observability）」，則是受到近年（有人說是約 2010 年）開始在 IT 圈浮出水面之關鍵字「可觀測性（Observability）」的影響，約於 2019 年開始有人談論的題目。 有些文章會將可觀測性定義為，建立一套機制，讓我們可以透過主動觀測目標系統的「外部輸出」（例如：Logs, Metrics, Traces），以此有效的推斷、理解該系統的「內部狀態」，並且除錯那些「未知的問題」。 （謎之音：怎麼聽起來有點玄？） 我覺得這個定義點出「可觀測性（Observability）」最主要的重點是，讓我們建立一種「主動觀測」的思維。而這與 DevOps 提倡的提升「資訊透明度」是相符合的。 也就是過去我們也有做監控、有收集 Log、收集 Metrics，但是我們並沒有主動的去運用這些「監控資料」。 而自從進入可觀測性 1.0 的時代之後，我們開始對「監控」加入了主動性，即是我們不只做過去的那些收集 Logs、收集 Metrics、設立告警 Rules 的基本建設。我們還加上 Traces，並且讓這所有的「監控資料」串連並關聯在一起供隨時查閱。...

前言 大家好，我是艦長。 如同前幾篇文章鋪的梗，既然 Data User 最在意的就是 Data，而且會非常重視資料品質，甚至被逼到在使用 Data 之前，不得不自己再檢查一次品質、再做一次資料清洗。那麼顯然這是一個老問題，那麼針對老問題過去是不是已經有做了什麼事嘗試解決它呢？ 前人都種了哪些樹？ 在 Data 圈也有發展許多關於 Data 的方法論與實踐，其中與資料品質有關的至少有四個關鍵字。 資料工程 Data Engineering：建構穩定、高效的 Data Pipeline，是重要的 Data 基礎工程。好比上一篇文章中的淨水廠及自來水管線。 資料監控 Data Monitoring：確保 Data infra、Data Pipeline 及相關流程的正常運行，設置特定的規則與告警規則，自動偵測資料的變動、偏差與異常。用比喻來說，可以想像是在水系統中的各處設置了多個檢測站定時觀測水壓、水質與水量等多項指標。 資料品質 Data Quality：遵循一套規範及方法論，定義品質標準，去定義、衡量與改善 Data 本身的品質。如同政府機關設立了一份飲用水水質標準，定義吻合什麼品質標準的水才能作為飲用水。 資料治理 Data Governance：遵循一套規範及方法論，為企業建立管理 Data 的規範、政策、流程與權責。這就像是成立一個水資源管理局，制定用水規範、權責劃分與安全政策，甚至前一項比喻的飲用水之水質標準就是由這裡制定的。 關鍵字 內容 比喻 資料工程 (Data Engineering) 建構穩定、高效的 Data Pipeline，是重要的 Data 基礎工程。 淨水廠及自來水管線。 資料監控 (Data Monitoring) 確保 Data infra、Data Pipeline 及相關流程的正常運行，並設置特定的規則與警報，自動偵測資料的變動、偏差與異常。 在水系統中的各處設置了多個檢測站定時觀測水壓、水質與水量等多項指標。 資料品質 (Data Quality) 遵循一套規範及方法論，去定義、衡量與改善 Data 本身的品質。 政府機關設立飲用水水質標準，定義吻合什麼品質標準的水才能作為飲用水。 資料治理 (Data Governance) 遵循一套規範及方法論，為企業建立管理 Data 的規範、政策、流程與權責。 成立一個水資源管理局，制定用水規範、權責劃分與安全政策。 從這四項 Data 圈經常可聽見的關鍵字，不難發現 Data 圈過去已經有從多個層面嘗試做很多事情。...

前言 大家好，我是艦長。 系列文連續鋪梗已經進入第五篇了，在上一篇我們比較了軟體圈與 Data 圈在看待 Data 時的根本差異，這一篇我們繼續聊 Data，用一個經典的比喻，來跟大家聊聊：為什麼想要取得高品質的 Data，是一件如此困難的事情？ 如何取得一杯乾淨的水 在 Data 圈，為了說明資料品質，有一個常見的比喻——「如何取得一杯乾淨的水」。 想像一下，如果我想要實現水龍頭一打開就能取得一杯可以直接生飲的水，我該怎麼做才好？ （謎之音：那就先裝一台 XX 牌高級濾水器不就好了 XD） 我知道一定有人會吐嘲說還不簡單，就裝一台濾水器不就好了，只要錢夠多，你要裝多高級的濾水器都行。誒，你這樣說也沒有錯啦，但這樣我這比喻故事就說不下去了 XDDDD 所以讓我修正一下問題——從水源上游開始一直到位於最下游為止，如果想要讓不同位置、不同用途的人，都可以一打開水龍頭就取得他所需的水，我們該怎麼做才好？ 好了，這次多了一些條件： 我們需要照顧從上游、中游到下游，於不同位置取水者的需求。 不同的人，對於水的需求（要求）不一定相同。 （好啦，我知道如果嚴謹討論，這些條件還是不夠完善，但就先放我一馬？） 如果大家有學過自然科學，或帶小孩去參加科博館之類的活動，其實多少都概略知道現代人的自來水系統。 水源來自上游的集水區，例如水庫。 接著水會被送到淨水廠。 經過淨水廠處理過的水，被送入自來水公司的地下管線。 最後，才進入各建築物的水系統，可以一開水龍頭就取水。 當然，現在家家戶戶還會自己加裝濾水器，做到打開濾水器的出水口就能直接飲用。 這整趟水系統，就像是 Data 圈處理 Data 的歷程： 集水區：即是各式各樣的 Data Source，是我們收集、累積、儲存 Source Data 的地方。 淨水廠與自來水管線：則是我們各式各樣的 Data Pipeline，這些 Pipeline 不只是將 Data 從 A 搬到 B，同時就像淨水廠會有沈澱、過濾、消毒的步驟，Data 圈也會透過 Data Pipeline 對 Source Data 做資料清洗、轉換的動作，讓下游的 Data 更貼近 Data User 需要的模樣。 各建築物的水系統：經過處理後的 Data，依然會需要地方儲存（或暫存），甚至就像為了供應頂樓加蓋的那一戶人家有足夠的水壓，還要額外加裝加壓器，所以除了集水區的 Data infra，你也需要為了末端的 Data User 準備他們所需的 Data infra 與 Pipeline。 家家戶戶的濾水器：即便淨水廠已經幫我們清潔過一次自來水，但你依然不敢直接生飲對吧？因為你會懷疑水在自來水管線或自家建物水管的運輸過程中可能有受到污染；因此在 Data User 真正開始使用 Data 前，多半還要自己花費工夫再清理與轉換一次 Data，甚至要自己檢驗 Data 品質。 如果不是為了飲用，日常民生用途的水，我們可以接受使用水龍頭一打開的自來水；Data 也是如此，就像金融業之於錢，電商之於庫存，同樣都叫做 Data，但有些 Data 我們的要求就是比較高，要求數字一定要正確，反之在其他情境或用途，就不一定需要這麼高的標準。 透過前面的比喻，大家應該都能理解我想要表達的內容。...

軟體圈與 Data 圈眼中的 Data 大家好，我是艦長。 在前兩篇文章的鋪梗中，我分別從軟體圈與 Data 圈的視角，分享了兩個圈子各自 User 關心的產品重點。 這一篇繼續延續鋪梗，我想把這兩個視角並陳比較，這兩個圈子在面對「Data」這件事時，有什麼差異。 話不多說，直接上表格。 關注點 Data 圈視角 軟體圈視角 產品 Data is the Product Software is the Product 產品內容 資料、報表、數據集本身 應用程式、軟體功能 資料準確性 絕對要求，是產品的核心價值 確保輸入/輸出結果正確即可 資料時效性 極度重視，直接影響資料分析價值 依功能需求而定，可接受快取延遲 資料結構 重視其清晰度與一致性 屬於後端實作細節，可接受各種妥協 就如上一篇文章說的，對於 Data User 而言，Data 本身就是產品；但對於軟體圈來說，很多時候 Data 只是軟體操作過程中的一次輸入與輸出。 因此對於 Data User 而言，Data 當然必須是又快、又好，最好還能又便宜。因為他所需要的就是那個 Data 本身，因此對於 Data 的準確性、時效性、完整性、可性度的要求就會很高。 而對於軟體圈而言，Data 就像是做料理過程中必須使用的部分食材或料理工序，它只佔了整道菜餚（使用者體驗）的一部分而已。所以食材可以很醜，例如 Table column name 是按編號建立的 col1、col2、col3，反正最終端上桌的菜餚，客人也看不出原貌；食材可以不新鮮，好比鮮度不夠的魚就用油炸處理，鮮度不夠的 Data，只要在 UI 上標示最多只能查詢前一天的消費紀錄。 小結 第四篇只是做一個簡單的比較，所以文章比較短。 從前面的比較中，可以看到不同圈子對待 Data 的方式不同。一個將 Data 視為必須精雕細琢的藝術品；另一個只是將 Data 視為達成功能的原料之一。...

前言 大家好，我是艦長。 前一篇文章聊了軟體圈，本文我想簡單聊聊我所看到的 Data 圈，似乎 Data User 想要的東西跟軟體圈的 User 不太一樣。 Data 圈的使用者，只關心 Data 如果非得用一句話來總結，我會說：Data 的使用者，他們真正在意的只有一件事，就是「Data」本身。 這句話聽起來像是廢話，但請讓我用一個你可能不陌生的場景，來解釋背後的涵義。 想像一下，你是公司營運部門的主管，你早上九點要跟大老闆開會，報告上一季新產品的銷售狀況。你打開 BI Dashboard，想看一下最新的「產品轉換率」與「各通路營收佔比」。 這時候，你腦袋中想的多半是： 「這些數字到底準不準？」 「資料有更新到最新嗎？」 「為什麼 A 通路的營收看起來怪怪的？」 （本圖片由 Gemini 生成。） 而你多半不會去想： 「背後處理這批資料的 Data Pipeline 是用 Airflow 還是 Dagster 處理排程任務的？」 「底層的資料倉儲是 BigQuery 還是 Snowflake？」 「這中間是不是跑了一個很複雜的 Spark 任務來做資料處理？」 對你來說，你根本不關心 Data 是怎麼來的。你不在乎 Data Team 為了產出這張報表，究竟是蓋了一條全自動化的 Data pipeline，還是一路純手工接力把 Data 做出來。你只關心，當你打開 BI Dashboard 時，可以拿到正確的數字與報表去跟老闆說明。 所以如果 BI Dashboard 上的數字有錯誤、過期或無法給出解釋，那對你來說，這批 Data 恐怕就是沒有價值的；畢竟錯誤的 Data 可能會導致老闆做出錯誤的商業決策。 然而工程師們可能會說，雖然 Data 有問題，但它們依然是 Data Team 的 Data Engineer 與 Data Analyst 在那座造價不菲的 Data infra，透過多條複雜的 Data pipeline 所產出；這也是花費了很多成本與心血，怎麼可以說是沒有價值？...

前言 大家好，我是艦長。 你現在閱讀的是 Data Observability 系列文，此系列文的內容是依據我 2025 在 DevOpsDays Taipei 2025 分享的 25 分鐘短講「資料可觀測性 Data Observability」，將簡報內容逐一拆解為多篇短文。 前一篇文章我們聊到「如何妥善管理與應用 Data」並不只是一個純粹的技術議題，作為開場讓大家知道其實 Data 有很不技術的一面。（謎之音：都是人的問題！） 在本系列文繼續聊更多 Data 的話題之前，今天我想要做一個比較，我們先回到軟體開發領域，看看軟體圈都在意些什麼事情。 一切都是為了替使用者帶來「價值」 如果你問軟體工程師，你們在開發軟體時，都在意些什麼？為什麼你會選擇採用某些軟體工程的實踐方法？你都在考量些什麼？ 前述這些問題，你可能會得到許多不同的答案像是「為了寫出乾淨的程式碼」、「為了打造可擴展的軟體架構」、「想要導入最新的軟體技術」、「為了確保服務穩定」……。 讓我們再繼續追問，那為什麼要「寫出乾淨的程式碼」、「打造可擴展的軟體架構」、「導入最新的軟體技術」、「確保服務穩定」? 有 Sense 一點的軟體工程師可能就會回答你——為了替使用者帶來價值！ （謎之音：你確定軟體工程師會這樣回答你？） 乾淨的程式碼、良好的軟體架構與系統架構、高可靠性的服務⋯⋯這些都是「手段」或「產出」，而做這些事情的結果，對軟體開發團隊來說，當然就是為了讓團隊交付給客戶的軟體，是有品質的、高可靠的、可以滿足使用者需求的，是能夠為使用者帶來價值的。（謎之音：然後客戶樂意付錢，公司賺大錢！） 那麼既然我們聊到「價值」兩個字，到底裡面包含了什麼？ 我自己覺得這是一個大哉問，因為每個使用者想要的價值不同，但多半會有一些常見的層面。 軟體在工程面的品質：也就是軟體有沒有出現令人傻眼的 Bug？會不會突然閃退？軟體背後的雲端平台是否可靠？能否因應大量暴增的使用者連線？是否有後門資安漏洞？ 軟體的功能是否滿足需求：軟體功能再強大，但無法滿足使用者需求都是白搭。像是廠商宣稱軟體可以做到無痛的自動雲端更新，隨時保持在最新的版本，但客戶說不好意思我們家禁止連上外網；又或者是使用者想要一個可愛溫馨風格的UI，然後廠商端提供的卻是高冷賽博龐克風格UI。 軟體圈都做了些什麼？ 前面聊完了價值，最後來看一看軟體圈做了哪些事情，是不是都是圍繞著價值呢？ 首先，基本上我們可以說軟體工程的各種實踐，都跟幫助團隊能持續產出高品質、符合需求的軟體脫離不了關係。 像是我們會在意軟體架構 (Software Architecture)，從 Monolithic 、SOA 到 Microservices。 又或者是程式碼的可維護性，我們有 Clean Code、SOLID 原則⋯⋯。 為了讓軟體有一個可靠的運行環境，讓環境管理更穩定，我們有虛擬化技術、容器化技術與 Cloud、Serverless、 Infrastructure as Code、GitOps⋯⋯ 當然別忘了還有大鍋粥 DevOps、SRE、Platform engineering。 軟體圈有各種不同的關鍵字，分別在不同層次幫助團隊可以更快、更穩定的將價值交付到使用者手中。 小結 好了，字數差不多了，我們就在此快速做一個小結。 今天這篇短文其實也是一個鋪梗，我想要讓大家思考一下，軟體圈從古至今的這些方法論、實踐、Keywords 都在做些什麼，都在關心哪些議題，以及解決了什麼問題。 然後順著這個梗，延伸想要問一個問題——「那在軟體圈，我們為 Data 做了些什麼？」 我們有針對程式碼、Infrastructure、軟體開發交付流程、軟體測試、軟體安全性⋯⋯做了很多事情，但是 Data 呢？針對 Data，軟體圈有做了什麼事情呢？是不是相較前面提到的那幾項，稍微生疏一些呢？（當然也可能只是我個人對此生疏，其他資深的軟體工程師對於 Data 也很熟稔。）...