标签: #duckdb

한국어English日本語中文

← 全部文章

• 如何解读 2026 年的数据工具地形图 —— 不是工具清单，而是分层决策

  2026 年 7 月 28 日，一篇《面向开发者的数据工具地形指南》登上 GeekNews，获得 51 点赞。这是一份不错的地图，但地图不会替你选目的地。本文把同一片地形拆成五个层次，梳理每一层实际要做的决策是什么：表格式之争如何在 Iceberg v3 上事实终结、战场如何转移到目录(catalog)层，DuckDB 级别的单节点引擎如何把原本属于集群的工作拉回本地，Fivetran 与 dbt Labs 的合并对层与层之间的边界意味

  2026-07-31 · 24 分钟阅读 #data-engineering#lakehouse#iceberg#duckdb#data-platform

• DuckDB 有了客户端-服务器协议 — Quack 改变了什么，又没有改变什么

  2026 年 5 月 12 日，DuckDB 团队发布了 Quack。这是一套架在 HTTP 之上的客户端-服务器协议，让两个 DuckDB 实例互为客户端和服务器，使同一个数据库可以被多个进程同时读写。一个把「进程内」当作身份标签坚持了 7 年的项目，如今自己给自己装上了服务器 — 相比「改变了什么」，「没有改变什么」反而更重要。本文梳理了 Quack 的设计取舍(为什么是 HTTP、为什么不是 Arrow Flight SQL)、D

  2026-07-16 · 26 分钟阅读 #database#duckdb#olap#analytics#data-engineering

• OLAP 引擎 2025 对比指南：DuckDB、ClickHouse、Snowflake、StarRocks、Pinot、Druid、Trino，基准测试的陷阱，引擎布局（2025）

  Season 5 Ep 3。没有哪一个引擎能覆盖全部 OLAP。DuckDB 带来单节点的革命，ClickHouse 负责实时 OLAP，Snowflake 与 BigQuery 提供托管式的便利，StarRocks、Doris、Pinot、Druid 承担实时 MPP，Trino 负责联邦查询。涵盖各引擎的强项与弱项、基准测试的陷阱、因地制宜的布局模式，以及面向韩国企业的选型指南。

  2026-04-15 · 16 分钟阅读 #olap#duckdb#clickhouse#snowflake#bigquery