作者回复: 你好，非常认可你的想法。你们团队的这段经历也非常有代表性，相信很多团队都经历过类似的过程。 你提到的从多引擎到统一的演进路径，恰恰体现了技术选型中一个重要的原则，就是在解决当下问题和保持长期可维护性之间找到平衡。 我想说的是，你们经历的“为了解决各式各样场景，加入了非常多的 OLAP 引擎”这个阶段，其实并不是走了弯路。在技术选型的早期，特别是团队对不同场景的需求还不够清晰的时候，尝试多种技术方案是很自然的，这个过程本身就是学习和积累经验的过程。没有这个过程，也很难真正理解不同引擎的优劣，更不会有底气做出“统一到 Doris”这个决策。 但是，你说得对，这种“杂而不精”的状态不能持续太久。是团队学习成本高，新人进来要学习多套系统，老人也容易因为精力分散而无法深入掌握任何一个系统。技术债务累积，每个引擎都有自己的特定用法和配置，时间长了，这些历史包袱会成技术债务为改进的阻碍。所以，我觉得你们后来统一到 Doris 的决策是明智的。 关于你提到的“不能只以解决一个个业务场景为导向，同时也要兼顾未来拓展性”，这个认识非常深刻。我想补充几点思考。 第一，技术选型要有长期视角。在做选型的时候，不能只看当下的问题，要考虑未来一到两年的业务发展方向。第二，要克制引入新技术的冲动。当遇到一个现有系统解决不好的问题时，首要反应不应该是引入新系统，而应该先思考，能不能通过优化现有系统来解决？能不能通过调整架构来解决？能不能通过改变业务需求来解决？只有在确实无法用现有技术栈解决，而且这个问题足够重要和普遍时，才考虑引入新技术。第三，建立技术选型的决策机制。对于引入新技术，应该有一个团队共同参与的评估流程，而不是某个人拍脑袋决定。评估的内容应该包括：这个问题有多重要？影响多少业务？现有方案为什么解决不了？新方案的学习成本和运维成本是多少？团队是否有能力掌握？引入后的维护计划是什么？有了这样的机制，就能够避免技术选型的随意性。第四，允许少量的技术异构，但要有明确的边界。完全的技术统一不一定是最优解，在某些特定场景下，使用专用的技术可能会带来显著的收益。比如，对于需要毫秒级点查的场景，HBase 或 Redis 可能比 Doris 更合适。但是，这种异构应该是有意识的决策，而且要明确使用边界，不能无限制扩散。第五，持续优化和演进。技术选型不是一劳永逸的，随着业务发展和技术演进，可能需要调整。所以，要定期回顾技术栈，评估是否还能满足需求，是否有更好的替代方案。但这种调整应该是谨慎的、渐进的，而不是频繁的推倒重来。 关于你提到的在“刚起步的业务线且数据量有限时，尝试一些高难度处理方式积累经验”，我觉得这个想法有一定道理，但要注意度的把握。新业务确实是试验新技术的好机会，因为影响面小，即使失败了成本也可控。但是，试验的目的应该是验证技术的可行性，而不是为了技术而技术。如果一项技术在试验中被证明是可行的，下一步应该考虑如何推广；如果被证明不可行，也要及时止损，不要让试验变成长期维护的负担。 最后，关于你提到的“离线处理内容挑战性不太足”，我想说的是，技术的价值不在于是否有挑战性，而在于是否能够解决业务问题、创造业务价值。如果离线处理能够满足业务需求，那就是最合适的方案。当然，如果有机会在成本可控的情况下提升时效性，为业务创造更大的价值，那当然值得去做。但这个出发点应该是业务价值，而不是技术挑战。作为技术人员，我们要有技术追求，但更要有业务意识，技术最终是为业务服务的。 你们团队的这段经历，从多引擎探索到统一收敛，体现了技术选型从混乱到成熟的过程。这个过程中积累的经验和教训，是非常宝贵的财富。也欢迎你继续分享在使用这个过程中的经验和遇到的问题，这对我和其他同学都很有帮助。