在进行机器学习特征工程和多组学数据处理时，我遇到了一个实际限制。
在某个时刻，问题不再是“有多少行”，而是“有多少列”。列数从几千到几万，有时甚至更多。
我在实践中观察到：
- 标准SQL数据库通常限制在大约1000到1600列。
- 像Parquet这样的列式格式可以处理宽度，但通常需要Spark或Python管道。
- OLAP引擎速度很快，但通常假设相对较窄的模式。
- 特征存储通常通过将数据拆分为连接或多个表来解决这个问题。
在极宽的情况下，元数据处理、查询规划甚至SQL解析都会成为瓶颈。
我尝试了一种不同的方法：
- 不使用连接
- 不使用事务
- 列分布而不是行
- 将SELECT作为主要操作
通过这种设计，可以在具有数十万到数百万列的表上运行原生SQL选择，并且在访问部分列时具有可预测的（亚秒级）延迟。
在一个小集群（2台服务器，AMD EPYC，每台128 GB内存）上，粗略的数据如下：
- 创建一个100万列的表：约6分钟
- 插入一个包含100万值的单列：约2秒
- 在约5000行中选择约60列：约1秒
我很好奇这里的其他人是如何处理超宽数据集的。你们是否见过在这种宽度下能够顺利工作的架构，而不需要依赖繁重的ETL或复杂的连接？
返回首页
最新
我发现自己经常想在Claude Code中安排任务（包括一次性和定期任务），所以我开发了一个CC插件来帮助实现这一点。
安装方法：
/plugin marketplace add jshchnz/claude-code-scheduler
/plugin install scheduler@claude-code-scheduler
然后只需告诉Claude你想要做什么（以下是一些示例）：
每周三凌晨3点查找死代码：未使用的函数、不可达的分支、注释掉的代码和未使用的导入。按文件列出并附上行号。
在每个工作日的上午9点安排代码审查。审查过去24小时内的提交，检查漏洞、安全问题、错误处理缺口以及需要注释的代码。总结时附上文件:行号的引用。
我写下这些内容是为了描述一种执行模型，其中恢复是在本地强制执行，而不是从历史中推断出来的。与重试重放或协调不同，每个单元都接受或拒绝状态和输入对，并在约束被违反时立即重置。恢复成本是恒定的，故障之间没有相关性，尾延迟不会形成，因为没有恢复协商。这并不是关于可用性表演或更智能的重试，而是关于拒绝继续处于故障状态。
我与越来越多的团队进行了交流，这些团队正在训练和服务大型模型，他们不再仅仅依赖按需的超大规模云服务提供商的GPU。<p>相反，他们正在锁定不同供应商和地区的预留容量（通常为6到36个月），以获得可预测的定价和保证的可用性。实际上，这引发了一系列问题：
• 如何评估不同供应商的数据中心质量和网络拓扑？
• 在价格、地理位置和互联互通之间，你观察到了哪些权衡？
• “相同的GPU，不同的系统”在实际工作负载中到底有多重要？
• 在合同、交付风险或随着时间推移扩展集群方面，有哪些经验教训？<p>背景：我在一个市场平台上工作，帮助团队在不同供应商之间获取长期的GPU容量，因此我经常看到这种模式，并希望与社区进行核实。
我们开始在一天中直接将餐具放入洗碗机。从早到晚。没有水槽里的堆积。<p>晚上，我们会运行洗碗机。早上，我们会将洗碗机完全卸空。<p>空的洗碗机 = 随时可以再次使用。<p>就这样。<p>没有堆积。没有猜测轮到谁了。没有把洗碗机当作储物柜。令人惊讶的是……争吵少了很多。<p>在采用这个系统之前，我们都是手洗或大批量装卸洗碗机。
嗨，我叫肖恩·多杰（yc x25）。<p>我创建了Harmony，因为我们的团队在Discord上已经运行了多年，我们一直渴望有这样一个工具，以便能够最终跟踪我们的会议记录和行动事项。<p>如果你的团队也在使用Discord，请随时试用一下！<p>它永久免费使用 :)