DuckDB 也是我用过的一个工具。一开始我并没有在意DuckDB，但后来关于它的讨论越来越多，我无法再忽视。最终，好奇心战胜了我，我决定深入了解一下。
然后我遇到了“SQLite for OLAP”这个短语，这让我更清楚地理解了它，但我对它在自己的数据栈里的位置还是有些疑惑。
直到我在像 Reddit 这样的数据社区里逛了一圈后，我才意识到 DuckDB 和许多开源项目一样，已经超出了创始人的最初设想。那时我决定亲自试试，看看这种说法是否靠谱。结果如何，我们拭目以待。
在我的研究中，我发现DuckDB是一个功能多样的混合引擎。我们来详细看看这些特点。
像 SQLite 一样，它允许你将数据存储在一个单独的 duckdb 数据库文件中，让它在其他项目中更容易携带。
除了可以嵌入之外，DuckDB运作方式类似于传统的DBMS系统，但不需要像MySQL或PostgreSQL那样运行一个长期的服务器。无需启动数据库服务器并通过IP地址和端口建立连接。
你只需要指明存放单个DuckDB数据库文件的位置，或者直接启动内存会话，甚至不需要使用物理数据库。
DuckDB 是一种列存储数据库，非常适合运行分析查询，效率非常高。
它支持两种主要的存储格式，即其本机的 .duckdb 格式或开放标准文件格式，如 Parquet。DuckDB 可以以非常高的效率读写这些格式，其中包括谓词下推功能。
内部来说，DuckDB 使用行柱结构。数据被分割成行组（row group），每个行组包含 120,000 条记录，并且在每个组内，各列分别存储并压缩——类似于流行的二进制格式，如 Parquet 和 ORC。
这种架构设计让你可以高效地存储和查询分析数据，无需额外的功能齐全的OLAP数据库引擎支持。
DuckDB的内部数据组织方式
DuckDB的Python库实际上是一个加强版的数据框。它能够与流行的数据框库如Pandas和Polars无缝对接，支持高效的内存操作。
让DuckDB与众不同的是它可以直接对Python数据框对象运行SQL查询。你可以像操作SQL表一样查询Pandas、Polars和Arrow数据框对象。
DuckDB在不同数据框接口之间的互操作性
你可以将来自不同对象的数据进行合并，例如，Polars DataFrame 和 Pandas DataFrame，在一个 SQL 查询中。结果可以存储到 DuckDB 数据库或导出为 Parquet 等文件格式存储在外部存储中。
你可以直接查询像 MySQL 和 Postgres 这样的数据库管理系统，直接访问存储在云端存储系统如 Amazon S3 中的 JSON、CSV 和 Parquet 格式的文件，以及现代开放表格式如 Apache Iceberg 和 Delta Lake。
尽管DuckDB没有像Hive或Redshift那样的外部表的概念，您仍然可以创建持久的视图来读取外部表或数据文件，就像创建一个只读视图一样。
DuckDB的联机查询能力
无需下载整个文件，我们可以在云存储中查询远程文件。DuckDB 能够高效地抽样检查数据。
DuckDB还可以充当单节点计算引擎（SNE），执行临时批处理任务。SNE首次使用时可以解释一下，之后可以直接用简称。就像拥有一个独立的Spark实例一样，可以高效处理较小规模的工作负载。
这在数据湖架构场景中特别有用，DuckDB能够将原始数据（例如JSON或CSV）高效地转换为优化格式，如Parquet文件，然后转换或聚合数据。
然后我创建了一个每小时处理管道来，以便轻松地将每小时的JSON转储解包、清理并转换为Parquet格式，发布到我的Silver区域。
最后，我再次使用DuckDB运行了一个每日聚合作业，将GitHub事件按“事件类型”、“仓库”和“事件日期”进行分组后，将结果导出至黄金区（分析区）。
以下代码示例演示了聚合逻辑的实现。在我的电脑上，DuckDB读取并处理了从S3上的24个压缩Parquet文件，这些文件总共包含大约500万条记录（约5百万），并在大约5分钟内将结果导回云。
结果是一个简单而高效的数据流，以及Parquet格式的分析所需数据集，可以通过DuckDB的SQL或Python API在我的本地机器上查询。
DuckDB可能无法像分布式引擎那样处理太字节级别的数据，但许多用例并不需要这么大的数据量。此外，现代服务器足够强大，可以轻松处理大量任务，而无需使用分布式处理框架。
根据以上这些能力，你会怎么称呼这样一个系统。
一个可嵌入且便携的DBMS，列式OLAP数据库，基于SQL的互操作数据帧，联邦查询引擎（Federated Query Engine），以及单节点计算引擎。
咱们就叫它DuckDB吧！
了解了DuckDB之后，让我们来看看它在未来数据工程和数据科学生态系统中可能会如何发展。
DuckDB解决了数据科学家工具箱中的一个重要问题：一个功能强大的进程内数据库引擎，它可以无缝地融入数据科学工作流程，无需复杂的设置、安装或在Python与外部数据库之间传输数据。
根据DuckDB的创造者之一马克·拉瑟韦尔的说法，这在设计DuckDB时是一个主要目标。
数据科学家往往觉得配置和利用外部数据库很麻烦，更喜欢处理纯文本或二进制文件（例如CSV或Parquet），因为这些文件便于立即访问和处理。
不过，DuckDB通过允许数据科学家在其Python环境中直接使用关系型SQL数据库进行工作，改变了这种状况，省去了安装外部数据库的麻烦，以及由此产生的数据传输费用。
随着个人电脑和笔记本电脑变得越来越强大，DuckDB 提供了一种“自带计算能力”的模式。它让用户可以利用本地电脑进行数据分析，不论是本地数据还是云端数据。
用户可以轻松地将数据文件或托管在云端的外部数据库系统连接到DuckDB，并利用其强大的本地处理能力进行分析。这在如研究团队这样的合作项目中尤其适合。
DuckDB格式（.duckdb文件）可能成为在网络上共享关系数据的标准格式。
与其导出多个独立的CSV文件，数据集发布者可以将整个数据集导出为一个“duckdb”文件，其中包含所有数据，以优化且易于分析的列式格式存储。
这样一来，这种方法简化了数据的共享，并确保数据是结构化的，可以直接高效地查询和分析。
DuckDB的Python包连接了SQL和Python，允许用户查询Python中的内存对象，例如Pandas 数据框等，就像操作数据库表一样。
这种能力使数据框更容易被更广泛的受众使用，包括那些更习惯使用SQL而不是Python的人。它也使得数据框在使用SQL构建数据处理管道时更加有效。
通过使用DuckDB的SQL接口，用户甚至可以在他们的数据框（DataFrame）上应用如dbt这样的转换模型，进一步增强数据框在数据工程工作流程中的角色。
使用 _pgduckdb Postgres 扩展，你可以在 Postgres 数据库内部直接执行分析查询，而无需再将数据转移至独立的分析系统中。
使用 _pganalytics 扩展可以直接在 S3 等对象存储上的数据集中的数据上运行查询，开发人员可以直接从 Postgres 中访问 Iceberg 或 Delta Lake 等表格式的数据，并利用嵌入的 DuckDB 作为查询引擎。
这还为公开数据集的机构提供了一个成本效益高的解决方案，允许它们自行分析，从而降低服务器负载。
正如我们所发现的，DuckDB不仅仅是一个数据库引擎——它为数据分析、存储和计算开启了新的可能。
如果你发现了 DuckDB 其他功能或独特用法，留言告诉我你的看法吧。