HackerNews中文版

我在进行机器学习特征工程和多组学数据处理时遇到了一个实际的限制。在某些时候，问题不再是“有多少行”，而是变成了“有多少列”。几千列，然后是几万列，有时甚至更多。我实际观察到的情况是：- 标准 SQL 数据库通常在 ~1,000–1,600 列左右达到上限。 - 像 Parquet 这样的列式存储格式可以处理宽度，但通常需要 Spark 或 Python 管道。 - OLAP 引擎速度很快，但往往假定相对较窄的模式。 - 特征存储通常通过将数据分解成连接或多个表来解决这个问题。在极宽的情况下，元数据处理、查询规划，甚至 SQL 解析都会成为瓶颈。我尝试了一种不同的方法： - 没有连接 - 没有事务 - 列分布而不是行分布 - SELECT 作为主要操作通过这种设计，可以在具有数十万到数百万列的表上运行原生 SQL 选择，并且在访问列的子集时具有可预测的（亚秒级）延迟。在一个小型集群（2 台服务器，AMD EPYC，每台 128 GB 内存）上，粗略的数字如下： - 创建一个 100 万列的表：~6 分钟 - 插入一个包含 100 万个值的单列：~2 秒 - 选择 ~5,000 行中的 ~60 列：~1 秒我很好奇这里其他人是如何处理超宽数据集的。您是否见过在不依赖繁重的 ETL 或复杂连接的情况下，在这种宽度下也能干净运行的架构？

查看原文

I ran into a practical limitation while working on ML feature engineering and multi-omics data.At some point, the problem stops being “how many rows” and becomes “how many columns”. Thousands, then tens of thousands, sometimes more.What I observed in practice:- Standard SQL databases usually cap out around ~1,000–1,600 columns. - Columnar formats like Parquet can handle width, but typically require Spark or Python pipelines. - OLAP engines are fast, but tend to assume relatively narrow schemas. - Feature stores often work around this by exploding data into joins or multiple tables.At extreme width, metadata handling, query planning, and even SQL parsing become bottlenecks.I experimented with a different approach: - no joins - no transactions - columns distributed instead of rows - SELECT as the primary operationWith this design, it’s possible to run native SQL selects on tables with hundreds of thousands to millions of columns, with predictable (sub-second) latency when accessing a subset of columns.On a small cluster (2 servers, AMD EPYC, 128 GB RAM each), rough numbers look like: - creating a 1M-column table: ~6 minutes - inserting a single column with 1M values: ~2 seconds - selecting ~60 columns over ~5,000 rows: ~1 secondI’m curious how others here approach ultra-wide datasets. Have you seen architectures that work cleanly at this width without resorting to heavy ETL or complex joins?

超宽表分布式 SQL 引擎