分類: Data Engineering

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

Jumping1 則迴響

前言

最近對於 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 則迴響

前言

在 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發表留言

前言

近期遇到有部分 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發表留言

前言

近期因為遇到在 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發表留言

什麼是 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。

閱讀更多»