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

  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 實際上會造成什麼問題?

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

BigQuery 新功能 – UNION ALL BY NAME

閱讀更多»

解決 R 程式碼在 VS Code 中格式 Style Lint 的問題

  1. Step 1: 安裝 R extension
  2. Step 2: 新增 .lintr 檔案
    1. .lintr 檔案會出現在你的專案根目錄中
  3. Step 3: 修改 .lintr 檔案
  4. Step 4: 重新開啟 R code
    1. 最終完整 .lintr 檔範例
    2. 所有設定都可以參考官網
  5. 常見問題
    1. 顯示 Malformed config file, ensure it ends in a newline 的錯誤

此篇文章記錄如何解決 R 程式碼在 VS Code 上會顯示一大堆波浪底線的問題(如下圖)


Step 1: 安裝 R extension

第一步一定要先安裝 VS Code 的 R 擴充套件,才會有排版建議和自動 Format 的功能

預設的 R Linter 是一行只能 80 字,很多程式碼底下會出現警告的波浪線條

Step 2: 新增 .lintr 檔案

  1. cmd + p (或 ctrl + p for Windows) 叫出 VS Code 的指令列
  2. 輸入 > R 之後點擊「Create .lintr to the workspace」

(當然你也可選擇直接手動在根目錄新增檔案)

.lintr 檔案會出現在你的專案根目錄中

透過 R extension 預設內容如下,可以把全部先刪掉

Step 3: 修改 .lintr 檔案

閱讀更多»

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

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

閱讀更多»

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

  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 的優化方法。

閱讀更多»

【資料工程】關於 Data Lakehouse 的崛起與目前主流框架

  1. 前言
  2. Data Lakehouse 的崛起
  3. 目前 Data Lakehouse 主流框架
  4. 個人感想
  5. 2024.10.13 補充
  6. 參考資料

前言

這幾年數據量增加速度越來越快,過去很多工具都標榜 Petabyte 等級,但今年開始有些公司的數據量已經達到 Exabyte (EB) 等級,例如 Uber 在近期的技術文章中就有提到他們 Hadoop 數據量已經超過 1 EB。

按照過去已經成熟普及的 Data Lake + Data Warehouse 體系,這麼大量的數據進到 Data Lake 後,再做處理儲存到 Data Warehouse 的流程,除了會造成非常大量的資料移動、資料處理、重複的數據產生之外,還需要維護複雜的大型 ETL Pipeline(Data Engineer 的惡夢…)

Data Lakehouse 的崛起

而這一兩年崛起的 Data Lakehouse 就是在解決這樣的問題,Data Lakehouse 通常會採用 Zero-copy + Open Table Format 的方式,讓 Data Lake 數據也兼具 Warehouse 的功能。

例如 Dashborad 使用的資料其實是直接取用自 Data Lake 的 Raw Data,等於直接省去了 Data Warehouse 這一層,這樣節省下來的成本會非常驚人!

目前 Data Lakehouse 主流框架

閱讀更多»