小米技术团队最近公开了一个重磅改造项目:把原本乱七八糟的数据平台架构彻底重构了。
效果有多夸张?查询性能直接提升 6 倍,高并发场景下延迟最高降低 300%。按小米的数据规模,光服务器成本一年就能省下千万级别。
更关键的是,技术栈从原来的七八套系统简化到现在的两三套,运维同学终于不用半夜起来救火了。
想象一下小米每天产生多少数据:几亿台手机在线上报,IoT 设备传感器数据不停涌入,米家商城的交易数据,还有汽车业务的车联网数据。这些数据加起来,每天都是 PB 级别的增长。
为了满足不同业务需求,小米不得不把同一份数据存储在多个系统里:
结果就是数据到处都是,一致性没法保证,存储成本飞涨。
计算引擎更是一大堆:Presto 负责离线查询,Druid 做实时 OLAP,Doris 搞交互分析,Spark 跑批处理。
每个引擎都有自己的监控体系、权限管理、数据建模逻辑。新人入职光是搞清楚什么场景用什么工具就要好几个月。
运维同学更惨,半夜经常被不同系统的告警吵醒。修好了 Presto,Druid 又出问题;搞定了 Druid,Doris 又开始报警。
数据分析师想做个简单的用户行为分析,得先搞清楚:
学会这套组合拳,起码要半年时间。很多业务需求因为工具复杂度高,最后都不了了之。
小米团队经过深度调研,发现了一个关键洞察:数据湖和数据库其实不冲突,完全可以优势互补。
Apache Paimon 这个数据湖的优势很明显:存储便宜、格式开放、流批一体、事务支持。但查询性能确实不如专门的分析数据库。
Apache Doris 查询性能强悍,毫秒级响应,高并发支持好,但存储成本高,扩展性有限。
小米的想法很简单:让 Paimon 负责存储,Doris 负责计算,两者深度融合。
存储层统一: 所有数据都存在 Paimon 里,流批数据统一管理,开放格式保证兼容性。
计算层分工:
加速机制: 热点数据通过 Doris 物化视图缓存,用户查询自动路由到最快的数据源。
原来 Doris 读取 Paimon 数据要通过 Java SDK,这个 SDK 是单线程处理文件合并,性能瓶颈很明显。
小米团队直接绕过了 SDK,用 Doris 自己的 C++ Parquet Reader 读取数据文件,然后用分布式并行引擎做合并计算。
这个改动让聚合查询从 40 秒缩短到 8 秒,性能提升了 5 倍。
传统物化视图更新是按分区来的,对大分区或非分区表效率很低。小米开发了基于快照的增量读取:
SELECT * FROM paimon_table@incr('startSnapshotId'='0', 'endSnapshotId'='5')
这样就能精确读取两个快照之间的增量数据,然后增量更新物化视图。数据时效性大幅提升,更新成本显著降低。
HDFS 默认 60 秒超时在网络不稳定时会让查询延迟暴增。小米把超时时间调到 100 毫秒,启用快速重试,再加上本地缓存机制。
结果是 P99 延迟提升 1 倍,高并发场景延迟降低最高 300%。
查询平均延迟从 60 秒降到 10 秒,整体并发能力达到 Presto 的 5 倍。这个提升幅度在业界都算很少见的。
技术栈简化后,服务器资源需求明显减少。数据去重存储,空间利用率提升。运维人力成本大幅下降。
按小米的体量估算,这套新架构一年能节省数千万成本。
业务同学反馈最多的是:终于不用学那么多工具了,一个 SQL 接口就能搞定大部分需求。
开发效率也明显提升,新功能上线速度更快,数据建模更统一。
小米把所有技术成果都贡献给了 Apache Doris 社区:
快照级增量读取:现在所有用户都能用这个功能物化视图增强:支持更细粒度的增量更新HDFS 优化:读取性能优化策略Paimon 深度集成:各种读取和缓存优化
这就是开源的魅力,一家公司的创新能让整个生态受益。
小米的经验告诉我们,技术选型不能只看单点能力,要看整体架构的协调性。
数据湖和数据库不是非此即彼的关系,完全可以优势互补。关键是要找到合适的融合点。
Apache Doris 和 Apache Paimon 的组合在小米这样的大规模场景下表现优异,说明开源技术已经具备了替代商业产品的能力。
对很多公司来说,这是降本增效的好机会。
小米没有一次性推倒重建,而是逐步优化改造。这种方式风险可控,业务影响最小。
从小米的实践看,湖仓一体已经不是概念,而是实实在在能落地的技术方案。
未来的数据架构会更加专业化:存储、计算、缓存、调度等组件都会更专注于自己的领域,但通过标准化接口实现深度协作。
对技术团队来说,系统性的架构设计能力比单点技术更重要。小米的成功不只是选对了技术,更重要的是找到了最佳的组合方式。
数据时代的竞争,拼的不是单项技术,而是整体架构的协调性和演进能力。