標籤: Database

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

閱讀更多»

【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」。

閱讀更多»

【資料工程】關於 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。

閱讀更多»

資料傳輸效能提升 70%！實測 GCP 的 gcloud storage 與 gsutil 指令的差異

Jumping發表留言
  1. 前言
  2. 什麼是 gsutil 指令？
  3. 什麼是 gcloud 指令？
  4. 官方建議使用 gcloud storage 取代 gsutil
  5. 自行實測結果
    1. 實測環境
    2. 實測結果表
    3. 實測 1：複製一個 249.1 MiB 小型檔案
      1. gsutil cp: 5.4 sec
      2. gcloud storage cp: 3.2 sec ( Speed Up 40% )
    4. 實測 2：複製一個 1.0 GiB 大型檔案
      1. gsutil cp: 24 sec
      2. gcloud storage cp: 6.3 sec ( Speed Up 74% )
  6. 總結
  7. 補充資料

前言

在資料工程師的工作中，常會使用雲端 Google Cloud Platform (GCP) 的 Google Cloud Storage (GCS) 作為 Data Lake 儲存一些非結構化資料，而操作 GCS 的指令我都是用 gsutil 來進行，但近期發現有另一個指令是 gcloud storage ，所以這篇文章記錄我針對這兩種指令實測後發現的差異，以及官方文件的建議。

什麼是 gsutil 指令？

  • gsutil 是一個 Python application，主要用來讓使用者可以透過 Command Line 操作 Cloud Storage，操作包含：
    • Creating and deleting buckets.
    • Uploading, downloading, and deleting objects.
    • Listing buckets and objects.
    • Moving, copying, and renaming objects.
    • Editing object and bucket ACLs.

什麼是 gcloud 指令？

  • gcloud 是 GCP 主要的 CLI 工具，用途更廣不限於 GCS，操作包含：
    • Manages authentication, local configuration and developer workflow.
    • Interactions with the Google Cloud APIs.
閱讀更多»

[Streamlit] 解決部署錯誤：Failed to create the application reverse proxy

Jumping發表留言

最近在使用 Streamlit 並且使用 Streamlit cloud 進行部署的時候，在 App 跑完部署的背景流程之後，遇到一個黑畫面顯示：

{"Code":2,"RawMessage":"Failed to create the application reverse proxy"}

上網查也找不到解法，後來發現是因為我裡面有用到 Database 的 credentials（我是用 MongoDB），但忘記把他新增到 Settings 裡面的 Secrets 裡面，如下圖的地方

新增上去之後重新整理頁面，App 就可以正常執行了。