分類: Data Engineering

【Data Lakehouse】數據架構的演變：從 Data Warehouse 到 Data Lake 再進化到最新的 Data Lakehouse

Jumping1 則迴響
  1. 前言
  2. 第一代數據架構 – Data Warehouse
    1. 特色
    2. 缺點
  3. 第二代數據架構 – Data Lake + Data Warehouse
    1. 特色
    2. 缺點
  4. 最新的數據架構 – Data Lakehouse
    1. Data Lakehouse 的優點
  5. Data Lakehouse 仍然有優化的空間
  6. 結論
  7. 個人感想
  8. 參考資料

前言

最近對於 Data Lakehouse 滿感興趣也很看好它，覺得 Data Lakehouse 有機會成為將來數據架構的主流，而最早提出 Data Lakehouse 這個專有名詞的目前看起來是 2020~2021 年 Databricks, UC Berkeley 和 Stanford University 所共同撰寫的一篇論文「Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics」，因此這次文章我整理了論文中提到的數據架構變遷歷史與原因，以及 Data Lakehouse 究竟有哪些優缺點、解決了哪些現在各大企業所面臨的問題。

第一代數據架構 – Data Warehouse

特色

  • 從關聯式資料庫中取得「結構化資料」
  • 屬於 schema-on-write（寫入時就得先定義好欄位）

缺點

  • 計算和儲存兩者一體，且可能是僅有一台地端機器，導致資料管理困難、費用高昂
  • 僅能儲存結構化資料，影片及音訊等數據無法儲存和查詢

隨著資料集的規模與類型快速增長，第一代數據架構已漸漸無法負荷，於是業界出現了第二代的 Two-tier 數據架構「Data Lake + Data Warehouse」。

閱讀更多»

如何使用 Python 套件管理工具「uv」取代 pip 來加速 Docker Image 的建立

Jumping1 則迴響
  1. 前言
  2. 什麼是 uv？
  3. uv 的使用方法
    1. 本機
    2. Dockerfile
  4. 實測檔案
    1. Dockerfile Using pip
    2. Dockerfile Using uv
    3. requirements.txt
  5. Linux Ubuntu 上進行 docker build
    1. 使用 pip = 87.6 秒
    2. 使用 uv = 33.3 秒
  6. GCP Cloud Shell 上進行 docker build
    1. 使用 pip = 20.1 秒
    2. 使用 uv = 11.7 秒
  7. 總結

前言

在 Build Docker Image 的時候，通常最花時間的都是安裝套件，為了突破這個效能瓶頸，這次決定嘗試使用 uv 來取代 pip 進行 Python 套件的安裝。

什麼是 uv？

uv 是一個以 Rust 撰寫的 Python 套件管理工具，號稱比 pip 還要快 10-100 倍，國外也有相關實測，像是 Streamlit 在 2024 年 7 月就有發 blog 表示他們用 uv 取代 pip 後速度提升了 55%（如圖 1）。

（2025/05更新）
近期發現開始有開源專案的官網文件也已經預設是使用 uv 來安裝，例如 Prefect（如圖 2）。

之前我也有在本機實測過，確實有非常顯著地提升了效能，而這次我打算將 uv 運用在 Docker 上，讓 Docker image 的建立時間能大幅縮減。

圖 1：Streamlit 用 uv 取代 pip 後速度提升了 55%
圖 2：開源專案 Prefect 的官網也已經預設是使用 uv 來安裝

uv 的使用方法

閱讀更多»

優化 R Docker image 的建立與部署：套件安裝速度提升與節省空間技巧

Jumping發表留言
  1. 前言
  2. 建立 Docker image 時遇到的瓶頸
  3. Step 1：優化安裝套件的速度
    1. 改用 Precompiled 版本的套件 -> 安裝速度提升 8.6 倍
  4. Step 2：優化 Docker image size
    1. 用 r-ver 取代 tidyverse -> 節省 image size 約 2.8 倍
    2. 使用 Multi-stage Builds：兩階段相同 image -> 沒有太大改變
    3. 使用 Multi-stage builds：第二階段改 ubuntu -> 成功縮減 2 倍 image size
  5. 總結
  6. 後記

前言

近期遇到有部分 R Script 執行時佔用太多 VM 記憶體，所以打算把 R 打包成一個 Docker image，讓他可以在 GCP Cloud Run 上面跑，解放 VM 的資源。

首先我建立了一個基於 tidyverse 的 Dockerfile，安裝常用的兩個套件，並讓這個 image 可以由外部提供一個 JOB_NAME 參數，來動態指定要執行的檔案。
（選擇 tidyverse 的原因是使用 r-base 時會遇到無法安裝 bigrquery 的問題）

FROM rocker/tidyverse:4.4.1

RUN R -e "install.packages(c('dplyr', 'bigrquery'), repos='<http://cran.rstudio.com/>')"

COPY r_jobs /r_jobs

CMD ["sh", "-c", "Rscript /r_jobs/$JOB_NAME"]

建立 Docker image 時遇到的瓶頸

雖然這個 image 是可以正常執行，但 docker build 後發現兩個大問題：

  • Docker image 太胖！
    • image 竟然有 2.5 GB 這麼大，這將會造成部署與存放上的問題。
  • R 套件安裝太慢！
    • 光是安裝兩個套件的步驟，就要花 5 分鐘，安裝 12 個套件需要 20 分鐘（如下圖 1,203 秒），時間成本太高。

基於這兩個問題我開始研究 Docker image 的優化方法。

閱讀更多»

Python 與 R 效能大對決！實測比較 Python 和 R 處理數據時的記憶體使用＆執行速度

Jumping發表留言
  1. 前言
  2. 實測環境＆版本
  3. 實測程式碼
    1. Python
    2. R
    3. 檢查 Test Data 是否相同
  4. 實測數據
  5. 實測結論
  6. 總結

前言

近期因為遇到在 GCP Compute Engine 跑 R 程式碼發生 OOM (Out of Memory）的記憶體問題，所以研究了很多關於 Python 和 R 之間的比較，看到不少文章都說 R 在效能、記憶體分配和垃圾處理（Garbage collect）上都是輸給 Python 的，也看到很多人不推薦使用 R 做大型數據處理。

秉持著研究精神，還是自己測一次最有感，所以這篇文章就是我自己實測的 Python VS. R 的記憶體 + 執行時間的大對決！

實測環境＆版本

  • Macbook Pro
    • 晶片: Apple M3
    • 記憶體: 16 GB
    • MacOS: Sonoma 14.2
  • R
    • IDE: 採用最主流的 R Studio 來執行
    • Version:
      • R version: 4.3.3
      • pryr: 0.1.6
  • Python
    • IDE: 採用市占率最高的 VS Code 來執行
    • Version:
      • Python version 3.11.9
      • psutil: 6.0.0
      • numpy: 1.26.4

實測程式碼

這次直接由 ChatGPT-4o 幫我生成兩種不同程式語言的程式碼，我只有附上自己的註解，以及手動更改建立的數據大小而已（下面圖片中的程式碼範例皆為產出一個 70000 x 70000 的表）

閱讀更多»

【資料工程】關於 Airbyte 的介紹、優缺點以及個人使用心得

Jumping發表留言
  1. 什麼是 Airbyte？
  2. 為什麼要選擇 Airbyte？
  3. 關於 Airbyte 的優點
    1. 介面友善
    2. No-Code & 可重複使用的 connectors
    3. 內建 Connector 一鍵更新版本的功能
    4. 不讓 Schema Change 搞壞 Pipeline
  4. Airbyte 目前還是有些小缺點
    1. 無法管理 Secrets 和版本
    2. 開源版的 Airbyte 免費，但需要自架伺服器成本
    3. Metadata 增加儲存成本
    4. Connections 介面資訊不足
    5. 中文欄位名不支援
  5. 總結

什麼是 Airbyte？

在資料工程領域，最常見的工作內容就是處理 ETL/ELT Pipeline（Extract, Load & Transform），現在 ELT 架構比 ETL 更加普及，因為 ETL 會先將資料進行處理後才儲存，就犧牲了資料的彈性（如果後續想要的資料長不一樣會很麻煩），ELT 則是從資料來源先儲存 Raw data，之後有需要做任何處理和變更都會更方便。

Airbyte 是一個開源的資料整合工具，主要是用來建立 ELT Pipeline 中的 EL，也就是把數據從一個來源同步到另一個目的地做儲存，Airbyte 提供很多預先定義好的 Connectors，使用者只要輸入一些資訊就可以建立好一條完整的 EL Pipeline，近期我也花了不少時間研究並嘗試使用 Airbyte，這篇文章就記錄一些心得感想。

為什麼要選擇 Airbyte？

做 EL 的工具很多，就我所知市面上比較熱門的應該是 Fivetran，但 Fivetran 算是需要付費的工具，而且並沒有做開源，因此我覺得 Airbyte 在開源＋免費的這部分很有優勢，截至撰文的此時（2024 年 6 月）GitHub 星數已經穩定上升到快 15K。

閱讀更多»