系列文章
Day 11 - OpenTelemetry Signal: Traces 重建分散式系統的因果關係
對於微服務架構來說，一個看似簡單的用戶請求，實際上可能要橫跨十幾個不同的服務才能完成。當系統出現問題時，我們很難就著單一個服務的錯誤來排查問題。這正是 Open...
Day 12 - OpenTelemetry Signal: Baggage 跨服務的上下文傳遞機制
在昨天的 Traces 介紹中，我們了解到 SpanContext 提供了追蹤關聯性，讓分散式系統中的操作能夠正確地關聯到同一個 trace。然而，在實際的業務...
Day 13 - 資料要存在哪裡？Data Lake到Data Lakehouse的技術演進
很快地第二週的學習即將告一段落！到今天為止，我們學習到 OpenTelemetry 解決了哪些可觀測性的痛點，了解了它的元件是如何各司其職，專門來生成、收集、匯...
Day 14 - Apache Iceberg：核心架構與效能優化設計
目前已經有許多發展成熟的 Data Lakehouse 解決方案，例如 Apache Hudi、Apache Iceberg、Delta Lake 等。它們都是...
Day 15 - 解構 Parquet：從檔案結構看欄式儲存設計原理（上）
在前兩篇文章中，我們探討了 Data Lakehouse 的概念演進，以及 Apache Iceberg 如何透過三層架構實現高效的 metadata 管理。但...
Day 16 - 解構 Parquet：從檔案結構看欄式儲存設計原理（下）
昨天，我們成功將 OTLP 資料轉換成 Parquet 格式。今天，讓我們接續昨天的實驗，來拆解 Parquet 內部的結構吧。 實驗工具 由於 Parquet...
Day 17 - OLAP 查詢引擎的核心技術
目前為止，我們已經深入了解 Parquet 的欄式儲存設計，看到它如何透過分層架構和壓縮技術來高效儲存資料。但是，資料儲存只是第一步，真正的價值在於如何快速查詢...
Day 18 - AWS Kinesis Data Firehose：架構選擇與設計考量（上）
前言 前面幾天，我們深入探討了 Data Lakehouse 的核心技術：從 Apache Iceberg 的 table format、Parquet 的欄式...
Day 19 - AWS Kinesis Data Firehose：架構選擇與設計考量（下）
昨天我們探討了在建立可觀測性資料管道時的考量，以及為什麼最後選擇 AWS Kinesis Data Firehose + Lambda 作為我們的即時轉換方案。...
Day 20 - S3 Table 的介紹與設計
上一篇文章中，提到 Firehose 的 recordID 會和目標寫入的資料是一比一的關係，所以必須在 Firehose 前面架設一個 Lambda 來去分割...