“现代数据栈”还是一个有用的概念吗？
厂商和数据从业者越来越怀疑，“现代数据栈”——一个由云端 ETL、数据仓库、像 dbt 这样的转换工具和 BI 平台松散拼接而成的概念——是否真的带来了足以抵消其成本和复杂性的价值。评论者将其描述为一个由炒作驱动的生态系统，把碎片化、SaaS 重度依赖的堆栈强加给那些往往缺乏明确分析目标、扎实工程实践或现实成本核算的公司，导致许多人开始重新考虑由经验丰富的工程师构建的集成平台或定制化方案。逐渐形成的共识是，工具选择应由具体业务需求、规模和可观测性实践驱动，而不是像“现代”这样的营销术语；一些人甚至预测，市场会转向更简单、更加紧密集成的“分析栈”。
“现代数据栈”（MDS）作为一个概念的实用性
- 许多人认为，“MDS”是一个流行词，随着被厂商和 VC 挪用后已经失去了意义。
- 批评点包括：定义不清、“现代”很快就会过时、主要引起投资者和分析师共鸣，而不是实践者。
- 也有人认为，这个标签有助于营销和合作伙伴生态，但几乎没有描述价值。
重型厂商堆栈 vs 集成/定制化方案
- 一种强烈批评是，多厂商的 MDS 造成了不必要的复杂性和高昂支出（例如，仅仅为了运行简单的管道就要用多个工具）。
- 另一种观点认为，企业现在更偏好集成平台或自建，尤其是在意识到雇几名工程师可能比堆叠许多 SaaS 产品更便宜之后。
- 反方观点：模块化的“按需选栈”工具提供灵活性，避免锁定，并让团队定制组件；集成式“全家桶”系统往往笨拙。
- 普遍共识是，正确答案取决于具体情境（公司规模、技能、需求）。
dbt 与分析栈
- 普遍认为，dbt 在组织 SQL 方面是一个重大进步：版本控制、DAG、测试、文档、CI/CD 钩子。
- 但也有人批评它与 dataframe 工具相比更慢、更笨拙，缺少优秀的本地 IDE，而且在规模扩大后（数百个以上模型）会变得难以管理。
- 有些人认为，dbt 最适合“最后一英里”的转换，而不是混乱的原始数据处理。
软件工程实践 vs 数据工程
- 许多人认为，数据领域在 CI/CD、测试、可观测性和部署纪律方面，比标准软件工程落后了十年。
- 也有人说，核心问题其实和通用 SWE 一样：依赖管理、契约变更、监控和错误处理。
- 另一些人强调数据特有的挑战：模式和分布会在代码不变的情况下改变；版本控制并不是系统行为的唯一门槛。
数据采集、成本与过度埋点
- 围绕“测量一切”与基于假设的数据采集展开争论。
- 有些人认为，在存储和内置导出都很便宜、且工作量不大的情况下，广泛采集是合理的。
- 另一些人强调隐藏成本：工程时间、连接器维护、MDS 工具账单，以及机会成本；他们认为许多管道都没有清晰的业务问题或 ROI。
实践中的“现代”栈是什么样
- 建议的栈范围从重量级（Kafka、Flink、Iceberg、Spark/Ray、元数据工具）到非常简单（BigQuery + dbt + 基础 BI；甚至 MySQL + 文件服务器 + 简单报表）不等。
- 常见建议是：尽可能保持简单，让工具匹配具体需求，不要为了简历或炒作去追逐趋势。