命令行工具可能比你的 Hadoop 集群快 235 倍（2014）
在一台现代单机上，命令行工具往往能比 Hadoop 或 Spark 集群更快、更便宜地处理 GB 级甚至 TB 级数据，但许多组织仍然默认采用“大数据”技术栈来处理那些轻松装进 RAM 或本地 SSD 的工作负载。评论者讲述了为了几十 GB 数据而耗资巨大、受政治驱动的 Hadoop 部署案例，并将其与简单的 awk/grep 风格流水线或 DuckDB/Polars 等工具进行对比；他们认为，横向扩展和复杂基础设施常常是出于炒作、简历或对未来需求的预期，而不是实际规模。同时，也有人指出，当数据量或业务约束确实需要时，标准化流水线、高可用性和长期可维护性可以为更重的平台提供正当性。
当“Big Data”并不大时
- 许多评论者认为，大多数 Hadoop/Spark 部署处理的数据量，用一台现代单机就足以轻松应对。
- 多个轶事提到：为几十 GB 或低数百 GB 的数据、或小型“数据湖”工作负载而配置的集群，往往是出于政治、顾问建议或战略幻灯片，而非真正需要。
- 也有人指出，某些组织确实在多 PB 规模上运行，此时 Hadoop/Spark 是合理的。
- 核心结论：人们系统性地高估了自己的数据有多“大”；“你的数据放得进 RAM”是反复出现的梗。
纵向扩展 vs 横向扩展
- 强烈的主题是：先扩容单机（更多 RAM/CPU），只有在这确实不行时才横向扩展。
- 现代硬件（多 TB RAM、NVMe）极大地改变了单节点可容纳的数据规模，相比 MapReduce 设计出来的年代尤其如此。
- 还有人强调流式方法（例如 awk 风格的管道），它们根本不需要数据集完全装入内存。
可维护性 vs 简洁性
- 一方认为：企业级流水线（Spark/Hadoop 等）提供了稳健性、可复现性，以及超越“让 Jeff 去跑一下他的脚本”的连续性。
- 反方则认为：一个设计良好、纳入源代码管理并通过 cron 在服务器上运行的脚本，往往以远低得多的复杂度和成本，提供同样的特性。
成本、可靠性与单点故障
- 争论焦点在于单台大机器是否作为单点故障过于危险。
- 有人认为，RAID 和合理设计使单节点处理对于非任务关键的批处理作业是可接受的。
- 也有人指出，在真实公司里，“分析”集群最终会承担近实时、影响生产的工作负载，这时多节点冗余就很重要。
工具与替代方案
- 许多例子表明，对于中等规模任务，grep/awk/Perl/Go/Rust+Polars/DuckDB 远远快于集群工具。
- 对于低于 TB 级的工作负载，Spark 和 Hadoop 因缓慢而笨重受到批评；当数据能放在一台机器上时，更受欢迎的是列式和进程内工具（DuckDB、ClickHouse、SQLite+FAISS、numpy.dot）。
炒作周期与激励
- Big Data 被描述为过去的一波炒作浪潮，类似 XML；AI 则被视为当前的、往往更糟的流行词。
- 以简历驱动、时髦驱动的开发、管理层跟风，以及供应商销售，是集群被不必要地搭建出来的反复原因。
- 有人感叹缺乏严谨且广泛应用的性能“工程”，但也有人说，认真的从业者确实会仔细建模吞吐量和容量。