最新

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

我发现自己经常需要在 Claude Code 中安排任务（一次性和重复性任务），所以我构建了一个 CC 插件来帮助实现这个功能。<p>安装方法： /plugin marketplace add jshchnz/claude-code-scheduler /plugin install scheduler@claude-code-scheduler<p>然后，只需告诉 Claude 你想做什么（一些示例）：<p>每周三凌晨 3 点查找无效代码：未使用的函数、无法访问的分支、注释掉的代码和未使用的导入。按文件和行号列出。<p>安排每周工作日早上 9 点进行代码审查。审查过去 24 小时的提交，检查错误、安全问题、错误处理漏洞以及需要注释的代码。总结时附带文件：行号的引用。

我写这段话是为了描述一种执行模型，在这种模型中，恢复是在本地强制执行的，而不是从历史记录中推断出来的。与其重试、重放或协调，不如让每个单元接受或拒绝状态和输入对，并在违反约束时立即重置。恢复成本是恒定的，故障之间没有关联，并且尾部延迟永远不会形成，因为不存在恢复协商。这与“可用性剧场”或更智能的重试无关，而是关于拒绝保持损坏状态。

我最近和越来越多的团队交流，他们正在训练和部署大型模型，并且不再仅仅依赖于按需付费的超大规模云服务商GPU。 相反，他们正在锁定跨多个服务商和地区的预留算力（通常为6-36个月），以获得可预测的价格和有保障的可用性。实际上，这引发了一系列问题： • 如何评估不同服务商的数据中心质量和网络拓扑？ • 你在价格、地理位置和互连方面看到了哪些权衡？ • 在实际工作负载中，“相同的GPU，不同的系统”到底有多大影响？ • 在合同、交付风险或随着时间推移扩展集群方面，有哪些经验教训？ 背景：我所在的公司运营一个市场，帮助团队跨服务商采购长期GPU算力，因此我经常看到这种趋势，并希望与社区进行核实。

我们开始一整天都直接把碗碟放入洗碗机。从早到晚，没有水槽堆积的碗碟。<p>晚上，我们运行洗碗机。 早上，我们彻底清空它。 空洗碗机 = 随时可以使用。<p>就是这样。<p>没有堆积。不用猜轮到谁洗碗。洗碗机也不再被用作储物空间。而且，令人惊讶的是……争吵也少了很多。<p>请注意，在使用这套系统之前，我们是手洗或集中装载和卸载洗碗机的。