Tomofun 的資料基礎建設及演化 — Part 1
在數據充斥的時代，想像一下數據就像是公司的燃料，而資料工程師的工作就是確保這燃料能源源不斷、有效運轉。為實現這一目標，數據基礎建設成為不可或缺的要素。這包括建立穩健的數據湖，有效組織和分類各種數據類型，以及確保數據存儲和查詢的流暢性。一個良好組織的數據基礎建設不僅有助於提升數據發現的效率，還能避免數據孤島的問題。
什麼是數據基礎建設 (Data Infrastructure)？
數據基礎建設就像是公司的內部運輸網絡，負責收集、搬運、整理和保管各種數據。這包括了把數據從數據源收集出來，裝進數據倉儲 (Data Warehouse)、數據湖 (Data Lake) 裡，經過資料整理後，經由管道 (Data Pipeline) 將它們有序地送到需要資料的地方。
本系列文章將會介紹 Tomofun 三個階段的數據基礎建設演化過程，分上下兩篇，此篇將聚焦在 Tomofun 第一代至第二代的原因、痛點，下篇將會著重在第二代至第三代的演化過程。
現在，我們就來看看在 Tomofun，我們是如何建立一個數據基礎建設，讓公司能夠迅速且有效地應對日益增長的數據需求。
解析 Tomofun 數據基礎建設演化過程
從 Tomofun 創立至今為止，我們經歷了三個階段的數據基礎建設的演化。從第一代的簡易版 Data Warehouse 架構，第二代的 Data Lake 架構，至即將在 2024 年啟用的第三代的 Data Lakehouse 架構。
而在這幾個階段的演化過程中，每個階段都有各自的優劣跟挑戰：
接下來，我們將詳細介紹 Tomofun 在第一至第二階段數據基礎建設的演化過程，以及我們在資料應用上遇到的挑戰。
第一代 (– 2018) Data Warehouse
在資料建置初期，由於資料運用的需求主要來自產品本身，而商業分析的需求相對較小，故 Tomofun 的第一代資料架構採用的是較單一的形式，並且由後端進行初步的資料整合處理。
資料由產品端的伺服器 (Server) 送進來後，會先存放到後端的 MySQL 資料庫，為了讓資料的取用不會影響到產品的效能，BI 團隊會再將資料透過快照 (Snapshot) 的方式複製到 BI 的 MySQL 資料庫，而第三方資源則是透過 API 呼叫的方式直接寫入 BI 的資料庫，接著依據商業分析的需求連接 Tableau 製作可視化儀表板或是需求導向的分析。
Bottlenecks
但隨著資料量日益增長，來自各個團隊的分析需求越來越多。Tomofun 初期的資料架構遇到了以下的問題：
- Query <> Tableau 運算效能差
- 資料搬移很花時間
- 關聯式資料庫儲存的資料型態缺乏彈性
【#挑戰一#】Query <> Tableau 運算效能差
由於 Tableau 是採用 Live table 的方式 (不是 Extract table)，直接連到我們的 BI 資料庫，中間沒有任何的中繼表。這導致每次在使用 Tableau 時，都必須在查詢語法中將原始資料進行大量的加總運算，以致拖慢整個資料使用的效能。
此外，傳統型關聯式資料庫也有以下幾項特點，在面對大量資料時會影響查詢的效能：
- 運算與儲存資源共享
- 非 Memory-centered 的搜尋引擎
- Single-node 數據系統
MySQL 在 Data pipeline 的定位上是屬於資料庫，而不是單純的查詢引擎，故數據存儲和索引的效率可以顯著影響查詢性能。如果 MySQL 數據庫沒有適當地進行索引，或者數據分佈沒有被優化，這可能導致查詢性能下降。
當資料量很大時，儲存在 RAM 中的數據快取可能會變得非常龐大，並且可能會因為受到每秒多次的請求，導致瓶頸和性能問題。MySQL 的一個限制在於它不是一個 Memory-centered 的查詢引擎，這可能進一步加劇了查詢緩慢的問題。
MySQL 是一種單節點數據庫系統。面對大量的數據，可能需要依賴手動程式，將數據分散在多個節點上等。然而，大多數的解決方案都是手動的，這使應用程序的編碼變得非常複雜。在查詢跨越多個節點訪問數據時，性能增益方面的優勢因而受阻。
【#挑戰二#】資料搬移很花時間
除了查詢效能差，我們也遇到了資料搬移的問題。資料搬運的效能會與資料量、資料結構、資料索引、語法有很大的關係。
相較於 Data Lake 提供更大的彈性，MySQL 通常有較高的管理和維護複雜度，在遷移過程中，可能需要對資料進行轉換和轉碼。當目標資料庫使用了不同的寫入和索引策略，工程師也會需要調整這些策略以確保資料一致性。隨著要處理的資料型態越來越多、量越來越大，Tomofun 的資料工程師們在資料搬移上花費的功夫越來越多。
【#挑戰三#】關聯式資料庫儲存的資料型態缺乏彈性
MySQL 只能存取結構化後的資料。但由於我們的資料源來自各種第三方平台、其他團隊的檔案，我們會需要處理並存取很多非結構化的資料，因此關聯式資料庫的存儲限制，促使我們重新思考替代資料庫的可能性。
基於上述遇到的限制，Tomofun BI 團隊在2019年導入了 Data Lake 的架構，以應對日趨複雜的資料源及分析。
第二代 (2019 – 2023) Data Lake
在第二代的數據基礎建設中，BI 團隊採用了Amazon Web Service (AWS) 的搭建 Data Lake (數據湖) 的大數據架構。數據湖的架構具有以下特點，能幫助我們解決部分第一代數據架構所遇到的問題：
- 資料儲存與計算分離：所有資料存取在 Data Lake 中，查詢引擎使用Athena，使運算資源、成本與查詢引擎分開。
- 資料儲存型態多樣：Data Lake 可以存取結構化 / 半結構化 / 非結構化的 原始資料。
- 資料儲存成本較低：在儲存大量的資料時，Data Lake 儲存成本相對傳統型資料庫較低。
- 查詢引擎的優化：透過 Partition 的儲存方式及分散式的平行計算，使資料在查詢上更有效率。
- Schema-on-Read : 相較於 Schema-on-write 為主的 MySQL DB，在 Data Lake 的架構中，我們不需要事先去定義資料結構與型態，就能將資料倒進 Data Lake 中，因此可以省去許多資料導入及搬移的時間。
在第二代的資料架構中，我們除了使用 AWS 的服務外，也優化了既有資料處理流程，並導入新工具 PopSQL 作為 SQL IDE 的工具。
【#焦點一#】資料處理流程優化
針對資料處理流程，BI 團隊做了以下的優化：
- 資料流程加入 Transformation 階段
- 針對資料的存放進行 Parquet、Partition 的處理
- 使用 Athena 作為主要的查詢引擎
在第二代資料架構中，我們為了因應更多元的數據源，將 Ingestion 後的資料改存放到 BI Data Lake 上，並獨立出 Transformation 的步驟，除了用 SQL 對資料進行整合以外，我們也對資料做更細緻的處理，例如：Parquet 格式化、清洗、Schema 轉換等等，實現 ELT (Extract, Load, Transform) 的資料處理方式。
清洗過後的資料，我們會針對大型的資料進行 Partition 的設計。依據資料的大小及彈性，BI team 制定特定的標準進行數據的邏輯劃分，以取得存取效率及成本之間的最佳平衡。
在資料取用上，我們也改用了 AWS Athena 作為我們的查詢引擎。Athena 的平行處理的能力，大幅增加每次查詢資料的效率。
什麼是 Partition?
在數據湖中，Partition 指的是根據特定標準進行的數據的邏輯劃分。通過將數據劃分為 Partition，可以將查詢的範圍縮小到僅包含相關數據的子集，從而最小化需要處理的數據量。分區常用的標準包括日期、地理位置或分類屬性。這種結構機制提高了資料湖處理大量多樣數據的能力，從而實現更快速、更有針對性的分析。
【#焦點二#】導入 SQL IDE 工具
為了更方便做到 SQL 指令的管理，我們也導入了 PopSQL 這個 SQL IDE 介面作為 SQL 語法開發的主要工具。任何 BI team 用來作為分析、儀表板用途的 SQL 語法，都會保存在 PopSQL 上，以確保組內在語法撰寫邏輯上的一致性與透明性。
此外，我們也使用其簡易的視覺化功能，使開發者能在查詢語法被正式使用前，查看資料抓取的正確性。
【#焦點三#】Tableau Live table -> Extract table
透過改變 Tableau 的使用方式，將 Live table 的連接改成 Extract table 的連接，使 Tableau 上的儀表板在更新或開啟時，不會因為要重新計算 SQL 指令而效率變差。
因此，我們將儀表板需要使用到的 SQL 指令進行第一次的資料擷取，再將擷取到的資料上傳到 Tableau 的資料源 (Datasource) 中，再經過 Tableau 內建的排程器定時將擷取 (Extract) 的資料進行更新，再由 Tableau 的工作簿 (Workbook) 進行解讀，呈現最終的視覺化圖表。
Bottlenecks
儘管 BI 團隊導入了先進的 Data Lake 資料架構，並且透過這個架構解決了舊架構遇到的問題，但 BI 團隊也持續地在做優化。依據 Tomofun 日益增長的數據需求，第二代數據架構也面臨到了新的挑戰：
- 難以更新在數據湖中的資料：Athena 不支援在執行查詢時刪除或取代檔案的內容，因為 Athene 是查詢引擎並且沒有 DML (Data Manipulation Language) 介面，所以 Athena 難以針對一個既有的資料集新增或刪減資料。
- 資料品質與控管變得至關重要：大數據環境下，數據量巨大，可能來自不同的來源、以不同的格式存在。在這種情況下，資料品質會變得相對難以兼顧。如何有效率地去檢核品質並有效地管理，確保這些大量數據的準確性和一致性，進而提升分析效果，是大數據架構中的一個挑戰。
- 數據安全控管與隱私： 大數據環境中的數據安全和隱私是一個重要考慮因素。大量數據的存儲和傳輸可能面臨風險，需要採取有效的安全措施，確保數據不受到未授權訪問或損害。
- 較難達成即時性要求： 在某些應用中，即時性是關鍵的需求。有效的數據管理確保實時數據的即時性，以滿足業務的即時分析和反饋需求。但大數據架構中，數據量巨大，即時處理大量數據需要相應的計算和存儲能力。大數據環境中的數據源也相當異質，整合這些異質數據源以實現即時性將會是一個複雜的問題。
自 2024 年後，BI 團隊將推出第三代的資料架構 — Data Lakehouse，相關細節有待下篇貼文的介紹。
