TVBS數據架構大解密 (1) — 前世今生
自2020年起，TVBS開始探索能撐起公司長期發展的現代化數據架構。在這之前，基礎架構成本高、缺乏軟體工程最佳實踐、耦合的Data Pipelines和四散各地的商業轉換邏輯，一直是TVBS在舊數據架構維運上的挑戰。
面對挑戰過程當中，我們逐漸發現「讓更多同仁更輕易地與更多元的數據做更多樣的互動」、「降低技術隔閡」和「Bring Code To Data」是在架構設計決策上能帶領我們前往更適合TVBS的3個原則。
遵循著3個原則，我們最終採用ELT數據處理作法，帶來優勢是其架構單純容易維護，接軌越趨成熟的現代數據棧(Modern Data Stack, MDS)生態圈，使團隊可以更專注地在一致共用的數據平台上，統一以SQL進行數據轉換和機器學習建模等高附加價值活動上，打破團隊成員間技術隔閡。
WHO IS TVBS?
從電視節目製作起家，TVBS是一家成立至今30多年的大型媒體公司，並在2013年成立新媒體事業部，正式拓展數位版圖。過去10年耕耘，在YouTube、Facebook和Instagram等社群影音平台都有TVBS的身影，而且在iOS、Android和Web三大平台上也都有相關數位產品，知名IP(Intellectual Property)包括：
- 《女人我最大》
- 《食尚玩家》
- 《TVBS新聞》
- 《健康2.0》
- 《地球黃金線》
- 等…
TVBS也於2020年開始進行敏捷和DevOps轉型，實際做法像是：
- 重新組織團隊結構
- 導入Scrum
- 導入容器化技術，現代化應用程式
- 使用基礎設施即程式碼(Infrastructure as Code, IaC)工具
- 等…
聚焦於數據相關議題，TVBS每個月有超過2000萬的不重複使用者進站，產生上億筆的網站瀏覽行為數據，光是一天就需要處理TB層級的數據，如何快速、穩定、有效利用成本地進行數據轉換是TVBS持續關注的面向。因此，自2020年起TVBS也同時開始探索新一代數據架構的可能性。
《TVBS數據架構大解密》系列第一篇文章，我們要來談TVBS是怎麼從舊有數據架構的挑戰中歸納出３項重要原則，據此建構現代化數據架構，最終帶來4項競爭優勢。
舊數據架構的包袱與羈絆
過時的系統架構會使得管理維護變得困難且繁瑣。這些系統需要耗費大量人力和資源，使得組織在適應新技術和市場變化時都會變得緩慢。當資源被綁在了舊系統上而不能用於更有前景的項目時，最終公司很有可能就會失去了原有的競爭優勢。回顧TVBS舊數據架構時我們也發現了類似的挑戰。
TVBS過去的數據架構是由Google Cloud上的VM、Cloud SQL和Tableau Online所組成。
首先，VM負責將數據從Google Analytics, Facebook, Google Search Console等外部系統取出並轉換，處理完後再載入Cloud SQL；接著，針對更深入的跨系統數據整合和分析需求，VM會再次從Cloud SQL取出數據並進行多輪處理，然後把中繼數據載回Cloud SQL；最後，Tableau則會串接Cloud SQL以滿足商業分析報表需求。而整個Data Pipelines排程機制則是由安裝於VM的Jenkins所負責。
技術架構面
整個舊數據架構和Data Pipelines設計中有以下幾個挑戰：
承擔過多職責的VM
該台VM不僅是個共用工作站，過去所有數據團隊成員都在同台VM上開發，它還扮演著數據處理樞紐的角色，更負責Data Pipelines排程。集三千職責於一身的VM可能會導致一系列的問題，像是
- 不同任務間的資源競爭問題
- 共用工作站的安全疑慮
- 單點故障(Single Point of Failure)問題等
Coupled Data Pipelines
過去在開發時常以一條共用Data Pipeline處理《食尚玩家》、《地球黃金線》、《健康2.0》等多個IPs相似的商業分析需求。
從系統面向思考，這會造成故障傳播，降低系統可靠度。舉例來說，當《食尚玩家》相關數據來源有不可預期的錯誤而導致Data Pipelines執行失敗時，其它IPs會接連被影響到。不僅如此，Data Pipelines的靈活性(flexibility)和擴展性(scalability)也會因此受限。換句話說，任何Data Pipelines設計變動都可能牽一髮而動全身，需要與眾多利害關係人討論才能決定。
從公司層級思考，Coupled Data Pipelines則會讓明明是面對不同市場挑戰的多個IP彼此間產生不必要的相依性，拖慢市場反應速度。
缺乏軟體工程Best Practices
過去在滿足商業分析需求時，比較常聚焦於單項分析任務上，而忽略了「建構數據架構」該有的軟體工程Best Practices，如版本控制、持續整合、持續部署和數據品質測試等。維護上即便知道哪些環節可以優化，但還是難以有信心的進行系統和Data Pipeilnes的重構。最終拖累了團隊開發效率和數據品質的提升。
四散各地的商業邏輯
以往缺乏統一的程式語言來開發數據轉換邏輯，有些是以Python開發，有些則以SQL開發，甚至有些是被嵌入於Tableau的計算欄位(Calculated Fields)當中。四散於各地的商業轉換邏輯難以維護，團隊會額外需要花更多心力在釐清Data Pipelines全貌上
組織團隊面
除了技術架構面外，組織團隊在過去的運作上也遇到了幾項挑戰：
團隊成員間的技術隔閡
過去剪不斷、理還亂的Data Pipelines，在數據工程師和其它團隊成員間築起了一道技術高牆，使得其它團隊成員如Product Owner、Scrum Master、前、後端、App工程師，難以理解如何從數據產生洞察，進而阻礙技術領域知識傳播和學習，降低組織運作效率。
組織仰賴單一數據團隊
TVBS目前為止已有1400多位員工，數據橫跨多個部門以及多個系統如YouTube、Facebook、網站、Apps、Google Ad Managers等。僅仰賴「單一團隊」維護並開發ETL Data Pipelines和產生數據洞察，會造成組織在運作效率上的瓶頸，難以快速地從數據中產生價值。
3 FIRST PRINCIPLES
面對舊數據架構的包袱和羈絆，TVBS在建構新一代數據架構時常思考「有哪些重要的原則是我們需要時時謹惕自己的？」自2020年開始，TVBS在思索不同數據架構設計時，發現有3個原則都圍繞著每次在架構設計討論當中：
- 讓更多同仁更輕易地與更多元的數據做更多樣的互動
- 降低技術隔閡
- Bring Code to Data
讓更多同仁更輕易地與更多元的數據做更多樣的互動
眼尖的讀者可以發現，這句話其實就是數據民主化(Data Democratization)的延伸：
更多同仁
新一代數據架構和應用，不僅僅要能讓目前數據相關同仁參與，還要能讓多元背景的TVBS同仁如前、後端工程師、行銷、編輯等參與其中。
更輕易地
不僅僅要能讓更多同仁參與其中，新一代數據架構和應用還要能讓各同仁「更輕易地」參與。也就是說，行銷、編輯、iOS、Android工程師等同仁應該要能使用他們熟悉的工具就與數據輕易地互動。
更多元的數據
新一代數據架構要能比以往蒐集並整合多方異質數據來源，建構以IP為核心的全方為數據視角。
更多樣的互動
不同職能的同仁在新一代數據架構中與數據互動時，要能使用到適合的工具與服務與數據平台中的數據互動。譬如說，商業分析師要能使用如Google Sheet和Looker Studio的工具，以簡易函數、點擊和拖、拉等方式產生商業洞察；另一方面，分析工程師和數據科學家則可以使用SQL和Python，進行機器學習建模、數據處理等；而開發網站和應用程式的工程師則要能取用到Data相關APIs，以完成數位產品中的數據應用等。值得關注的是，新一代數據架構要能一致化地、跨情境地滿足上述的數據應用。
降低技術隔閡
探索數據架構設計的過程當中，我們認為學習曲線較高的工具和技術會造成未來跨職能團隊協作上的阻礙。舉例來說，若團隊選用Apache Spark作為其中一個數據處理框架，那麼當前、後端工程師想要參與Data Pipelines開發時就必須學會該怎麼使用它，甚至還要學習雲端服務商所提供的相關服務如AWS Glue, GCP Dataproc等。長期來看，選擇學習曲線較高的工具和技術會造成工程師間的技術隔閡，不利於跨職能團隊的建立。因此，我們相信簡化數據架構設計、統一並挑選技術難度較低的技術工具，能有效降低技術隔閡，促進跨職能團隊的建立。
Bring Code to Data
標題源自過去大型分散式運算系統的最佳實踐：在大型分散式運算系統中數據轉換的「程式碼」往往遠小於「數據」本身，因此當兩者位於不同機器時，「將程式碼移至數據所在機器」的效益會遠高於反向操作。
經過團隊內部一連串研究和討論，我們相信類似概念也同樣適用於現代Data Pipelines設計上：比起「在各種執行環境中反覆抽取數據並進行轉換」，我們偏好「將多個異質系統的數據盡可能原封不動地載入一致共用的數據平台，並接著在單ㄧ數據平台內進行轉換」。這樣做的好處是避免數據搬移所造成的資源浪費，以及降低數據架構複雜度。
ELT作法帶來的4個競爭優勢
在Data Pipelines設計上主要有兩大流派：ETL vs. ELT。兩者之間的異同可以參考以下兩篇文章：
- dbt Labs: ETL vs ELT: Unpacking the key differences
- Fivetran: ETL vs. ELT: Choose the right approach for data integration
遵循著「讓更多同仁更輕易地與更多元的數據做更多樣的互動」、「降低技術隔閡」和「Bring Code To Data」3個原則，我們最終選擇ELT為主要數據架構設計作法：
首先，我們會將分散在各系統的數據來源，透過現成的服務與工具，盡可能原封不動地送往數據平台，也就是數據抽取(Extraction)和數據匯入(Load)；接著在數據平台裡進行數據轉換(Transformation)；最後，不同背景的數據消費者就能據此建構自己所需的數據應用，如營運報表、統計分析、機器學習建模等。
導入ELT作法後，我們發現它替TVBS帶來以下4個競爭優勢：
- 成熟生態圈
- 架構單純易維護
- 專注於高附加價值活動上
- 有效打破技術隔閡
成熟生態圈
圍繞著ELT作法而生的現代數據棧(Modern Data Stack, MDS)生態圈已在國外發酵多時(相關歷史脈絡可以參考這篇)，也有多家國外數據新創公司據此建立起自家商業模型，日漸成熟(相關公司清單可以參考這裡)。
成熟的生態圈可以讓我們站在巨人的肩膀上，快速打造適合TVBS的現代數據架構。
架構單純易維護
藉由將Extraction-Load與Tranformation去耦合，組織可以利用MDS生態系所提供的現成服務和工具，更快速地完成Data Pipelines設計與開發。
在Extraction-Load步驟，多數工具都有提供豐富的連接器如Facebook, YouTube, Instagram, TypeForm等，透過直觀的UI操作流程快速地從來源系統擷取數據並匯入BigQuery。
在Transformation步驟，數據轉換邏輯皆以dbt實作，這麼做有助於確保團隊在使用工具和方法時能夠保持一致性和標準化，進而降低錯誤和混淆的可能性，以及更輕鬆地共享資源、協作和溝通。不僅如此，dbt提供的自動化測試、持續整合、持續部署等功能，也有助於團隊更容易地維護相關Data Pipelines，最終更快速地交付品質更好的數據。
專注於高附加價值活動上
改用ELT作法後，團隊成員不必學會原始數據來源系統的互動方式才能取得所需數據，只需使用現成工具與服務即可。因此，團隊成員能更加專注在「數據轉換」階段，也就是從一開始先解決原始數據的錯誤、填補缺失值等，接著在單一數據平台整合來自四面八方的數據來源，如Facebook, Instagram, Google Search Console, Google Analytics等，最終根據商業情境和分析需求產生商業洞察，機器學習建模，預測模式建立等。
轉注於數據轉換階段，不僅能有效提升數據的品質，還能提升企業決策能力品質，促進創新和商業成長。
有效打破技術隔閡
從thoughworks在2022年3月所公布的科技產業大趨勢中，SQL仍然是主導著Data Pipelines開發的程式語言。無論我們在數據工具或平台多麽先進，SQL仍是最常被選擇作為數據處理的共同標準。不僅如此，大多數軟體工程師在生涯的某個階段都有可能使用過它。
藉由先將數據集中在數據平台上，再一致以SQL結合dbt處理數據，能有效打破技術隔閡。具體來說，對於網站開發和App開發的工程師而言，不必額外學習Python程式語言或是Spark計算處理框架等學習曲線較陡峭的工具，就有機會參與Data Pipelines的討論、設計甚至是開發，最終縮短「數據工程師」和「應用程式開發工程師」間的距離；
另一方面，原本使用SQL和試算表工具的數據分析師，也能在短時間學會dbt，參與Data Pipelines討論、設計和開發，最終縮短「數據工程師」和「數據分析師」的距離。值得一提的是，在兩者之間的新興職位「分析工程師」也就在這樣的脈絡下誕生。(詳情可以參考dbt Labs的What is analytics engineering?)
我們相信「打破團隊成員間的技術隔閡」，能加快「跨職能團隊的建立」。而「跨職能團隊」聚集了不同領域的專業知識和經驗，通常具有以下好處：
- 有助於促進創新和創意的產生
- 在單一團隊內獨立地解決複雜問題，有助於組織更快速地做出反應和調整
- 提升團隊整體能力，促進個人成長和發展
- 可以在決策過程中考慮到不同觀點，有助於降低決策風險
下一篇系列文章《TVBS數據架構大解密(2) — Modern Data Stack》我們會來開箱TVBS在現代數據架構上是怎麼挑選相關技術服務與工具的，及其所帶來的實際效益。
全文已取得TVBS同意，特別感謝數位開發中心的夥伴們
