GizmoEdge分布式SQL引擎成功完成1万亿行数据处理挑战，在Azure上部署1000个节点的集群，仅用5秒就完成了对1万亿条数据的聚合查询，平均每节点处理24亿行数据，展现了强大的分布式计算能力。

标题：GizmoEdge成功挑战万亿行数据处理

内容概述：

分布式SQL引擎GizmoEdge近期在Azure平台上完成了Coiled万亿行数据处理挑战，展示了其卓越的大规模数据处理能力。测试中，GizmoEdge成功处理了来自测量数据集的1万亿条记录，并快速完成了数据汇总。

基础设施配置： - 部署了1000个工作节点的GizmoEdge集群 - 每个节点运行DuckDB引擎，通过Kubernetes编排 - 使用Azure Standard E64pds v6节点（64个vCPU和504GiB内存） - 每个工作节点配置3.8个vCPU和30GiB内存 - 共使用约63个物理节点

性能表现： 1. 基础查询（计数）： - 执行时间：<0.5秒 - 处理行数：1万亿行

2. 聚合查询：
   • 执行时间：<5秒
   • 生成412行结果集
   • 每组平均处理约24亿行数据

核心技术特点： 1. 分布式处理架构： - 服务器端生成分布式执行计划 - 将查询分解为工作节点SQL和服务器端聚合SQL

2. 安全数据分片：

   • 采用TLS加密的WebSocket通信
   • 通过SHA-256哈希验证数据完整性
   • 基于令牌的身份验证机制

3. 并行执行：

   • 工作节点使用DuckDB处理本地数据
   • 通过Arrow IPC格式传输中间结果
   • 服务器端并行聚合最终结果

跨平台能力： GizmoEdge支持异构计算环境，可在云端（AWS/Azure/GCP）、边缘设备（iPhone等）和Kubernetes集群上同时运行工作节点。

相关产品表现： GizmoSQL（单节点版本）在AWS Graviton 4实例上用时约2分钟完成相同挑战。

未来发展： GizmoEdge目前处于预发布阶段，正在招募设计合作伙伴，特别适合需要处理TB/PB级数据的组织。

[注：原文中的视频链接和部分技术细节链接已省略，保留了核心的技术参数和性能数据]

以下是评论内容的总结：

1. 对开源分片查询规划器的需求

   • 询问是否有类似的开源工具可以跨多个DuckDB/SQLite数据库聚合查询。
   • 引用："Are there any open sourced sharded query planners like this?" (maxmcd)

2. 对硬件资源的关注

   • 指出测试使用了高性能硬件（63个节点，共4000个CPU和30TB内存），认为这可能是速度快的原因。
   • 引用："That's 4000 CPUs and 30TB memory." (tgv)
   • 引用："Yes, I would expect when each node has that kind of power..." (1a527dd5)

3. 对数据集和测试细节的疑问

   • 询问数据集是否公开，以及“1T挑战”的具体含义。
   • 引用："Is the dataset somewhere accessible?" (shinypenguin)
   • 质疑测试是否包括数据分发和导入的时间。
   • 引用："How long did it take to distribute and import the data to all workers?" (NorwegianDude)

4. 技术实现细节的讨论

   • 对使用WebSocket而非普通Socket提出疑问，认为HTTP层可能增加开销。
   • 引用："Why not just use regular sockets and cut the overhead of the http layer?" (MobiusHorizons)
   • 对节点配置的选择（3.8 vCPU和30 GiB RAM）表示不解。
   • 引用："Why not just run 16 workers total using the entire 64 vCPU and 504 GiB of memory each?" (nodesocket)

5. 对测试结果的质疑

   • 认为测试忽略了数据预处理的耗时，实际性能可能被高估。
   • 引用："You're not doing the challenge if you do the work up front." (NorwegianDude)
   • 询问查询时间是否包括数据加载和物化步骤。
   • 引用："I'm interested to know whether the 5s query time includes this materialization step..." (djhworld)

6. 与其他技术的比较

   • 提出与Clickhouse集群的性能对比问题。
   • 引用："How would a 63 node Clickhouse cluster compare?" (sammy2255)
   • 认为测试未涵盖大规模内连接（inner join）的实际需求。
   • 引用："Why doesn't such large-scale test the big feature everyone needs, which is inner join at scale?" (lolive)

7. 对自身应用的反思

   • 对比自己的应用性能，质疑是否遗漏了某些优化点。
   • 引用："Maybe I'm missing something fundamental here." (ta12653421)

8. 对分布式DuckDB设置的兴趣

   • 询问如何设置分布式DuckDB实例（非63节点）。
   • 引用："Are there any good instructions somewhere on how to set this up?" (mosselman)

9. 对DuckLake格式的关注

   • 引用相关演讲视频，讨论DuckLake的设计理念。
   • 引用："DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us..." (boshomi)

10. 幽默与调侃

    • 以幽默方式调侃大规模数据处理的复杂性。
    • 引用："Wait until you see a 800-line Tableau query that joins TB data with TB data /s" (ferguess_k)