標籤: data

如何評估開源專案的價值與健康度，以及判斷是否適合導入與採用？

Jumping發表留言
  1. 最優先要考慮的是需求
  2. 開源專案的參考指標
    1. 1. 功能性
    2. 2. 文件完整性
    3. 3. 維護活躍度
    4. 4. 社群支持度
    5. 5. 程式碼品質與穩定性
    6. 6. 安全性
    7. 7. 相依相容性
  3. 總結
  4. 參考資料

在資料工程師的工作中，很常需要使用到開源工具來解決問題，像是 Apache Airflow 或 FastAPI 都是可商用且已經被泛用的開源工具，但我們該如何評估一個新的開源專案值不值得使用或研究呢？ 這篇文章我整理了網友和我自己的經驗，以 GitHub 為例，分享有哪些重點是我們在選擇 Open Source 時可以納入考慮的。

最優先要考慮的是需求

我認為所有的考量都要以需求出發，思考這個開源工具是否真的能解決目前遇到的問題，或是達成使用者提出的需求，並且這個工具的規範在公司內是合法合規的，都確認後才能繼續往下探討其他指標。

其他指標我目前把他們分成幾大類：

  1. 功能性
  2. 文件完整性
  3. 維護活躍度
  4. 社群支持度
  5. 程式碼品質與穩定性
  6. 安全性
  7. 相依相容性

開源專案的參考指標

1. 功能性

  • 功能完整性： 工具的功能是否完整且穩定？是否缺少關鍵功能？
  • 易用性：
    • 這個工具是否容易安裝、設定和使用？是否有清晰的 API 或介面？
    • 是否可用 pip install 安裝？
    • 是否提供 Dockerfile / Docker Compose 的方式來部署？
  • 效能：
    • 工具的效能是否能處理你的資料量和運算量？是否有相關的效能測試報告？
    • 這個工具在 ELT、分析、視覺化或建模方面的能力如何？
以 Apache Airflow 為例，GitHub 文件上清楚寫了可以使用 pip 或是 Docker Compose 的方式來安裝
閱讀更多»

UNION ALL 語法其實有陷阱？介紹 BigQuery 最新的 UNION ALL BY NAME

Jumping發表留言
  1. SQL 中的 UNION ALL 其實有陷阱？
  2. UNION ALL 實際上會造成什麼問題？
  3. BigQuery 新功能 – UNION ALL BY NAME
  4. 總結
  5. 補充資料 – CORRESPONDING 語法
  6. 參考資料

SQL 中的 UNION ALL 其實有陷阱？

在查詢結構化資料庫時，常會使用到一個 SQL 語法：UNION ALL，但其實這個語法背後有一個很大的坑，就是在合併資料時，UNION ALL 其實會按照 SELECT 的順序來合併 (Positional 特性) ，所以當欄位資料型態一樣時，資料就會無視欄位名稱被按照順序合併起來。

按照順序來合併資料是什麼意思呢？
讓我們看一下範例

UNION ALL 實際上會造成什麼問題？

在這個範例中，我們想要讓名稱為 Number 和 Emoji 分別 UNION 在各自的欄位，由於這些值都是字串型態，所以 UNION ALL 是會成功執行的，但我們會發現結果並不是我們想要的那樣，因為我們的 SQL 中 SELECT 欄位的順序是錯的，UNION ALL 並不會自動幫我們依據欄位名稱去合併，這個問題除了 BigQuery 之外，其他資料庫像是 MySQL 或 PostgreSQL 也會有一樣的情況。

BigQuery 新功能 – UNION ALL BY NAME

閱讀更多»

【GCP】如何建立與使用一個具有 IAM 權限控管的 Cloud Run Service

Jumping發表留言
  1. Step 1: 建立 Docker image 並上傳到 GCP Artifact Registry
  2. Step 2: 部署 Cloud Run 並設定 Security
  3. Step 3: 確認 IAM permission
  4. Step 4: 取得 ID Token
  5. Step 5: 將 token 帶入 Request Headers

本文說明如何建立一個有鎖 IAM 權限的 GCP Cloud Run Service/Job 並使用 Python 送 Request

Step 1: 建立 Docker image 並上傳到 GCP Artifact Registry

1. 先使用 gcloud 指令進行身份驗證

    登入並授權 gcr.io，才能順利將 image 下載到本機（如果是直接使用 GCP Cloud Shell 就可以不用這一步）

      gcloud auth configure-docker gcr.io

      2. 建立 Docker Image 並推送到 GCP Artifact Registry

      docker build --platform linux/amd64 -t gcr.io/my-gcp-project/service-name .

      docker push gcr.io/my-gcp-project/service-name
        • --platform linux/amd64: 如果是在非 linux 的作業系統（如：MacOS, Windows）中進行 image build 就需要另外指定 image 系統，不然會無法在 Cloud Run 上順利運行

        Step 2: 部署 Cloud Run 並設定 Security

        前往 GCP Artifact Registry 找到剛剛推上去的 Image，並將 image 部署到 Cloud Run（點擊如下圖的 Deploy to Cloud Run）

        部署後可以在該 Cloud Run Service 的 Security 頁面看到預設是 Require authentication (Manage authorized users with Cloud IAM)，代表只有 IAM 許可的人可以呼叫這個 Service

        Step 3: 確認 IAM permission

        閱讀更多»

        【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 的使用方法

        閱讀更多»