Data Mesh 和集中式数仓怎么选？
面试怎么回答
Data Mesh 不是一套新数据库，而是领域所有权、数据产品、自助平台和联邦治理的组织技术模式。集中式数仓适合规模较小、统一口径优先、专业能力集中的阶段；当领域众多、中央团队长期成为瓶颈，而且域团队具备产品和工程能力时，才适合逐步下放。实际落地我更倾向混合模式：中央平台提供共性能力，领域对数据产品和 SLA 负责，全局标准通过自动化治理保持一致。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
公司一说“数据团队响应慢”，有人就建议上 Data Mesh，把数据职责全部交回业务域。可如果域团队没有工程能力，去中心化只会把一个烟囱变成十个小烟囱。
Data Mesh 不是换一套存储，而是重新分配数据所有权、平台能力和治理责任。
集中式数仓强调统一建设与专业化效率，Data Mesh 强调领域所有权和数据产品；是否采用取决于组织规模、领域成熟度、平台自助能力与治理机制。
先看问题是不是组织规模问题
集中式团队在业务较少、口径需要快速统一时效率很高。随着领域和需求数量增长，中央团队成为排队入口，业务语义在交接中损失，才出现把所有权下放的现实动力。小团队为了追潮流拆域，通常得不偿失。
Data Mesh 有四个共同原则
领域化的数据所有权、把数据当产品、自助式数据平台、联邦式计算治理缺一不可。只把 ETL 分给业务团队而没有产品 SLA、标准和平台支持，不是 Data Mesh，只是责任转移。
数据产品必须有明确接口
一个领域对外发布的数据要可发现、可理解、可寻址、可信赖，并明确负责人、Schema、质量目标、版本和支持边界。消费者依赖的是稳定契约，不应直接猜测领域内部任意表的含义。
平台负责降低重复建设
存储、调度、权限、血缘、质量、发布和可观测性应由平台封装为自助能力。否则每个领域都建设一套采集、监控和权限系统，组织总成本会迅速上升。
联邦治理不是各自为政
全局命名、隐私、互操作、主数据和跨域指标仍要统一，领域只在边界内自治。治理规则应尽量编码进模板、策略和自动检查，而不是靠会议逐项审批。
更现实的是渐进式混合
多数公司可以保留中央平台与公共数仓，把成熟领域逐步升级为数据产品负责人。先选一个边界清晰、消费方多的领域试点，量化交付周期、质量事件和复用率，再决定是否扩大。
参考资料
- Martin Fowler：Data Mesh Principles and Logical Architecture：https://martinfowler.com/articles/data-mesh-principles.html