2010
Dremel 與 BigQuery 的技術源流
Cloud data systems
論文／雲端分析 Google；Sergey Melnik 與團隊
解決的問題： Hadoop 式批次分析對巨量資料集的互動式即席（ad hoc）查詢來說太慢。
解決方式： Dremel 以欄式配置與多層執行樹，對巢狀資料進行互動式分析。
重要性： 成為 BigQuery 與互動式雲端分析的技術基礎。
DDIA: Ch. 4: Storage & Retrieval Ch. 11: Batch Processing
2010
Apache Spark
Big data processing
軟體／叢集運算 Matei Zaharia，UC Berkeley AMPLab；後由 Databricks 與 Apache 社群發展
解決的問題： MapReduce 對迭代式機器學習、互動式探索與多階段管線的效率不佳。
解決方式： Spark 引入 resilient distributed datasets（RDD）與以記憶體為中心的叢集運算。
重要性： 成為 ETL、ML、串流與 SQL 工作負載的主流通用大數據引擎。
DDIA: Ch. 11: Batch Processing
2010
Elasticsearch
Query processing
軟體／分散式搜尋引擎 Shay Banon；Elastic
解決的問題： 全文搜尋與日誌分析需要可擴展、近即時索引的分散式搜尋引擎。
解決方式： Elasticsearch 提供分散式全文搜尋，具備倒排索引、近即時索引與 REST API。
重要性： 成為主流的搜尋與可觀測性平台，支撐應用程式搜尋、日誌分析與 ELK stack。
DDIA: Ch. 4: Storage & Retrieval Ch. 7: Sharding
2011
Apache Kafka
Streaming
軟體／分散式 log LinkedIn；Jay Kreps、Neha Narkhede、Jun Rao
解決的問題： 企業需要可靠的高流量事件擷取，以及讓 producer 與 consumer 解耦的方式。
解決方式： Kafka 提供耐久的分散式 commit log，支援 topic、partition、重播（replay）與 consumer group。
重要性： 成為串流管線、事件驅動系統與即時資料平台的核心基礎設施。
DDIA: Ch. 12: Stream Processing
2011
Vitess 水平擴展 MySQL 分片
Distributed SQL
軟體／分片中介層 YouTube／Google；Sugu Sougoumarane 與 Mike Solomon；後加入 CNCF
解決的問題： MySQL 本身無法水平擴展；當資料超出單一伺服器，大型部署會碰到連線數、儲存與寫入吞吐量的極限。
解決方式： Vitess 在多個 MySQL 實例之前加入分片與查詢路由層，自動化 resharding、連線池與拓撲管理，同時保留 MySQL 語意。
重要性： 讓 MySQL 得以支撐龐大的工作負載（YouTube、Slack、GitHub、PlanetScale），並成為透明水平分片的參考設計。
DDIA: Ch. 7: Sharding
2012
Spanner
Distributed SQL
論文／全球分散式資料庫 Google；James C. Corbett 與團隊
解決的問題： 全球性服務需要跨區域複寫資料，同時仍支援強一致、外部一致（externally consistent）的交易。
解決方式： Spanner 結合複寫、分散式交易、TrueTime 與類 SQL 語意。
重要性： 重新定義了全球規模與交易一致性之間的關係。
DDIA: Ch. 6: Replication Ch. 8: Transactions Ch. 10: Consistency & Consensus
2012
Calvin 決定性交易
Distributed SQL
論文／交易架構 Alexander Thomson、Daniel Abadi，Yale
解決的問題： 分散式交易的協調成本很高，跨分區發生競爭時尤其嚴重。
解決方式： Calvin 以決定性（deterministic）交易排序來降低執行期協調的複雜度。
重要性： 影響了分散式 SQL 與決定性交易處理架構。
DDIA: Ch. 8: Transactions Ch. 10: Consistency & Consensus
2012
Amazon DynamoDB 託管 NoSQL
Cloud data systems
公司／託管 NoSQL 服務 Amazon Web Services
解決的問題： 2007 年的 Dynamo 設計威力強大但維運複雜；團隊想要它的彈性擴展與可用性，卻不想自己營運和調校叢集。
解決方式： DynamoDB 提供全託管、serverless 的鍵值與文件儲存，具備可預測的個位數毫秒延遲、自動分割與隨需擴展。
重要性： 讓 Dynamo 式的彈性 NoSQL 成為隨開即用的雲端基本元件，以及高規模營運工作負載的預設選項。
DDIA: Ch. 6: Replication Ch. 7: Sharding
2012–2013
Amazon Redshift 與託管雲端資料倉儲
Cloud data systems
公司／雲端資料倉儲 Amazon Web Services
解決的問題： 地端 MPP 資料倉儲昂貴，採購、擴充與維運都很緩慢。
解決方式： Redshift 提供託管的雲端資料倉儲與可擴展的分析容量。
重要性： 推動雲端託管分析成為許多組織的預設選擇。
DDIA: Ch. 4: Storage & Retrieval Ch. 7: Sharding
2012–2013
Presto / Trino 式分散式 SQL
Query processing
軟體／查詢引擎 Facebook／Meta；後由 Presto Foundation 與 Trino 社群發展
解決的問題： 企業資料散落在許多系統中；先把所有資料搬進單一倉儲再查詢，既昂貴又緩慢。
解決方式： Presto 讓互動式 SQL 能直接查詢多種資料來源與儲存系統。
重要性： 讓聯邦式／分散式 SQL 引擎在異質資料平台上普及。
DDIA: Ch. 7: Sharding Ch. 11: Batch Processing
2012–2013
RocksDB
Storage engine
軟體／儲存引擎 Facebook / Meta
解決的問題： 分散式應用需要可嵌入的高效能鍵值引擎，並針對 SSD 與大型寫入密集工作負載最佳化。
解決方式： RocksDB 將 LSM-tree 儲存工業化，提供生產級調校、compaction 控制與面向 SSD 的效能。
重要性： 成為眾多資料庫、串流處理器與分散式系統的儲存引擎基底。
DDIA: Ch. 4: Storage & Retrieval
2012–2017
時序資料庫：Prometheus、InfluxDB、TimescaleDB
Time-series
軟體／專用資料庫 Prometheus：SoundCloud／CNCF；InfluxDB：InfluxData／Paul Dix；TimescaleDB：Timescale Inc.／Ajay Kulkarni、Mike Freedman
解決的問題： 通用資料庫處理高頻率帶時間戳的指標、IoT 遙測與監控資料時效率不佳。
解決方式： 時序資料庫針對 append 密集的寫入、時間範圍查詢、降採樣（downsampling）、保留政策與指標專用壓縮進行最佳化。
重要性： 為可觀測性、IoT 與大規模營運監控創造出專門的資料庫類別。
DDIA: Ch. 4: Storage & Retrieval Ch. 2: Nonfunctional Requirements
2014
Raft 共識演算法
Distributed systems
論文／共識演算法 Diego Ongaro、John Ousterhout，Stanford
解決的問題： Paxos 式共識威力強大，但工程師難以理解並正確實作。
解決方式： Raft 以可理解性優先的設計，將共識拆解為 leader 選舉、log 複寫與安全性三個部分。
重要性： 被實務上的分散式資料庫與協調系統廣泛採用。
DDIA: Ch. 10: Consistency & Consensus
2013
etcd 分散式鍵值儲存
Distributed systems
軟體／協調儲存 CoreOS；後加入 CNCF
解決的問題： 雲端原生系統需要可靠、強一致的儲存來處理組態、服務發現與 leader 選舉，並能承受節點故障。
解決方式： etcd 實作 Raft 共識演算法，提供具複本、可線性化（linearizable）的鍵值儲存，支援 watch 與 lease。
重要性： 成為 Kubernetes 的骨幹（儲存所有叢集狀態），以及雲端原生基礎設施的預設協調元件。
DDIA: Ch. 9: Distributed Systems Ch. 10: Consistency & Consensus
2014–2015
Airflow 與資料編排即程式碼
Data engineering
軟體／工作流程編排 Airbnb；Maxime Beauchemin；Apache 社群
解決的問題： 資料團隊需要撰寫、排程、監控、重試並修復橫跨多個系統的複雜管線。
解決方式： Airflow 以 Python 定義的 DAG 表示工作流程，並提供排程與維運可視性。
重要性： 讓「編排即程式碼」在現代資料工程中普及。
DDIA: Ch. 11: Batch Processing
2014–2015
CockroachDB
Distributed SQL
軟體／分散式 SQL 資料庫 Spencer Kimball、Peter Mattis、Ben Darnell；Cockroach Labs
解決的問題： 想要全球分散、可序列化 SQL 卻不依賴專有基礎設施的組織，需要 Google Spanner 的開源替代方案。
解決方式： CockroachDB 實作受 Spanner 啟發的分散式 SQL，在商用硬體上提供可序列化交易、自動分片與跨地域複寫。
重要性： 讓 Google 以外的世界也能使用全球分散、強一致的 SQL 資料庫。
DDIA: Ch. 6: Replication Ch. 8: Transactions Ch. 10: Consistency & Consensus
2014–2015
Amazon Aurora
Cloud data systems
公司／雲端原生關聯式資料庫 Amazon Web Services
解決的問題： 傳統關聯式資料庫將運算與儲存耦合，使雲端上的複寫、故障轉移與擴展緩慢、昂貴且寫入放大嚴重。
解決方式： Aurora 將 redo log 處理下推到分散式、跨多可用區的儲存層——「log 即資料庫」——網路上只傳輸 log 記錄，儲存層可自我修復。
重要性： 以儲存與運算分離重新定義了雲端原生 OLTP，啟發了 Neon、AlloyDB 與一整個世代的分離式儲存資料庫。
DDIA: Ch. 1: Data Systems Trade-offs Ch. 6: Replication
2016–2019
TiDB 與 YugabyteDB
Distributed SQL
軟體／分散式 HTAP SQL PingCAP（TiDB）；Yugabyte（YugabyteDB）
解決的問題： 團隊想要水平擴展與高可用，又不想放棄 MySQL/PostgreSQL 相容性，並且越來越希望在同一份資料上同時執行交易與分析。
解決方式： TiDB 與 YugabyteDB 打造受 Spanner 啟發、以 Raft 複寫的分散式 SQL 引擎並保持協定相容；TiDB 另增欄式引擎（TiFlash）以支援 HTAP。
重要性： 讓開源、可直接替換的分散式 SQL——以及實用的 HTAP——進入主流。
DDIA: Ch. 7: Sharding Ch. 8: Transactions
2014–2016
Flink、Druid、Pinot 與 ClickHouse
Streaming
軟體／串流與即時 OLAP Apache Flink 社群；Metamarkets／Druid；LinkedIn／Pinot；Yandex／ClickHouse
解決的問題： 隔夜批次系統無法支援即時儀表板、事件時間（event-time）串流運算，或面向使用者的分析延遲要求。
解決方式： Flink 解決了有狀態串流處理；Druid、Pinot 與 ClickHouse 則主攻對新鮮事件資料的低延遲分析查詢。
重要性： 讓即時分析與串流資料平台成為主流。
DDIA: Ch. 4: Storage & Retrieval Ch. 12: Stream Processing
2014–2016
Snowflake 雲端資料倉儲
Cloud data systems
公司／雲端資料倉儲 Snowflake；Benoit Dageville、Thierry Cruanes、Marcin Żukowski 與團隊
解決的問題： 傳統資料倉儲把儲存、運算、擴展與工作負載管理綁得太緊。
解決方式： Snowflake 分離儲存與運算，提供彈性擴展與多叢集的工作負載隔離。
重要性： 定義了雲端原生資料倉儲架構，重塑企業分析的採購與設計。
DDIA: Ch. 1: Data Systems Trade-offs Ch. 4: Storage & Retrieval
2013–2016
Parquet 與 Arrow
Data formats
檔案格式／記憶體格式 Apache 社群；橫跨 Hadoop、Spark、Pandas 與 R 生態系的貢獻者
解決的問題： 分析系統需要高效率的欄式檔案，以及快速的跨語言記憶體內資料交換。
解決方式： Parquet 提供欄式磁碟儲存；Arrow 定義與語言無關的欄式記憶體格式。
重要性： 成為現代分析資料湖、引擎與 dataframe 互通性的基礎建設。
DDIA: Ch. 4: Storage & Retrieval Ch. 5: Encoding & Evolution
2016
Apache Beam
Big data processing
軟體／統一處理模型 Google（源自 Dataflow 模型）；Tyler Akidau、Robert Bradshaw、Craig Chambers；Apache 社群
解決的問題： 開發者必須在批次與串流處理框架之間二選一，為兩者撰寫不同的程式碼。
解決方式： Beam 提供批次與串流統一的程式設計模型，並支援可插拔的 runner（Flink、Spark、Dataflow）。
重要性： 確立了可攜、與 runner 無關的資料處理管線 API。
DDIA: Ch. 11: Batch Processing Ch. 12: Stream Processing
2016–2018
Apache Pulsar
Streaming
軟體／訊息與串流 Yahoo；後捐給 Apache Software Foundation
解決的問題： 大規模訊息與串流讓單層式設計吃緊：運算與儲存耦合使彈性擴展、多租戶與跨地域複寫都變得困難。
解決方式： Pulsar 將服務層（broker）與儲存層（Apache BookKeeper）分離，加上原生多租戶、分層儲存至物件儲存與內建跨地域複寫。
重要性： 提供了一個具備儲存／運算彈性分離與強多租戶隔離的 Kafka 替代方案，服務大型訊息平台。
DDIA: Ch. 12: Stream Processing
2016
dbt (data build tool)
Data engineering
軟體／分析工程 Tristan Handy；dbt Labs（前身 Fishtown Analytics）
解決的問題： 撰寫 SQL 轉換的分析師缺乏版本控制、測試、文件與模組化等軟體工程實務。
解決方式： dbt 將軟體工程工作流程（版本控制、測試、文件、DAG 相依關係）帶入以 SQL 為基礎的資料轉換。
重要性： 催生了「analytics engineering」這個角色，成為 modern data stack 的核心工具。
DDIA: Ch. 11: Batch Processing
2015–2020 年代
Debezium 與 Change Data Capture (CDC)
Change data capture
軟體／CDC 平台 Red Hat；Randall Hauch 與社群貢獻者
解決的問題： 要把資料庫變更複寫到下游系統，過去得仰賴脆弱的輪詢、雙寫（dual write）或廠商專屬的 log 解析。
解決方式： Debezium 從資料庫交易 log 進行 log-based change data capture，將變更送入 Kafka topic 並提供 exactly-once 傳遞語意。
重要性： 讓 OLTP 資料庫與 data lake、搜尋索引、快取之間的即時資料整合變得可靠且主流。
DDIA: Ch. 6: Replication Ch. 12: Stream Processing
2016–2018
Kubernetes StatefulSets 與 Operators
Cloud data systems
平台／維運模式 Kubernetes 社群、CoreOS／Red Hat、CNCF 生態系
解決的問題： 容器平台起初更適合無狀態應用，而非需要穩定身分與持久儲存的資料庫。
解決方式： StatefulSets 與 Operators 為有狀態服務加入了基本元件與自動化模式。
重要性： 讓資料庫的雲端原生維運變得更可行，儘管維運上仍然複雜。
DDIA: Ch. 9: Distributed Systems
2016；2018 年生效
GDPR 與資料隱私法規
Data governance
法規／法律 歐盟；歐洲議會與歐盟理事會
解決的問題： 資料系統蒐集並保存個人資料，對儲存、處理、刪除與跨境傳輸幾乎沒有限制。
解決方式： GDPR 強制要求被遺忘權（right to erasure）、資料可攜性、同意管理、資料外洩通知與目的限制，並附帶高額罰則。
重要性： 迫使資料系統加入刪除能力、稽核日誌、資料血緣（lineage）與 privacy-by-design——重塑了資料庫架構與資料管線設計。
DDIA: Ch. 14: Doing the Right Thing
2017
FAISS
AI / Vector retrieval
軟體／向量搜尋 Facebook AI Research / Meta AI
解決的問題： 機器學習應用需要在數十億個高維 embedding 上進行快速相似度搜尋。
解決方式： FAISS 提供高效率的近似最近鄰（approximate nearest-neighbor）向量索引與搜尋。
重要性： 在 LLM/RAG 熱潮之前，就讓 embedding 檢索變得實用。
DDIA: Ch. 4: Storage & Retrieval