【大厂数仓架构】(七)首汽约车

如题所述


首汽约车:从传统数仓到实时OLAP架构的转型</

首汽约车,这个京城熟知的出行平台,自2015年成立以来,已经拓展了包括即时用车、预约服务等多元化的出行服务。然而,随着业务的迅速发展,其早期基于Hadoop、Spark和Presto构建的大数据平台显得有些力不从心。从2016年至2021年间,首汽约车的架构虽集成了离线实时并行的Lambda技术,但缺乏真正的OLAP数据库,这限制了数据的深度分析和一致性保障。


挑战主要体现在几个方面:首先,MongoDB作为实时数据存储,难以承载大规模明细数据,只能处理汇总后的数据,导致烟囱式开发盛行,效率低下且数据一致性难以保证。其次,业务数据量的快速膨胀(10倍增长)使得Tableau Server的BI层不堪重负,多维报表的刷新时间甚至长达数小时。此外,PrestoDB的并发查询性能不足,用户等待时间过长,严重影响了业务效率。


为了提升数据处理能力,首汽约车开始寻求更高效、灵活的解决方案。经过深入调研,他们最终选择了StarRocks这一实时OLAP数据库,以解决原有架构的痛点。StarRocks以其强大的并发查询性能和灵活的数据模型,成为首汽约车数据架构升级的首选。


在新的架构中,StarRocks取代了MongoDB等数据库,存储大量明细数据,提高了数据处理的时效性和灵活性。实时数仓的构建也焕然一新:通过FlinkCDC从Kafka获取实时数据,写入StarRocks的ODS层,ETL过程由外部调度组件通过SQL自动完成,DWD层进一步处理和聚合,最终写入DWS层。同时,StarRocks的流式系统兼容性使得Flink和Spark Streaming能无缝集成,实现实时场景中的统一OLAP分析。


这次架构升级不仅优化了数据处理流程,减少了复杂开发工作,而且显著提升了数据分析的效率和业务方的执行效率。首汽约车的这一转型,预示着他们在大数据处理领域迈出了坚实的步伐,向着更高效、实时的业务洞察迈进了。


温馨提示:答案为网友推荐,仅供参考
相似回答