关于大规模实时数仓搭建，我有几条心得...

现状

闲鱼作为一款闲置交易APP，在二手交易市场中是当之无愧的佼佼者。闲鱼从2014年诞生到现在七整年间持续增长，在这高速增长的背后带来的是每天近百亿的曝光点击浏览等数据，在这些数据规模如此庞大的背后也会带来诸多关于实时性的问题：

•用户反馈商品曝光异常，如何快速定位？

•产品同学圈了一批商品，如何查看该样本的实时报表？

•发现问题总是晚一步，如何在第一时间获取自定义的预警信息？   

 •......

为了解决上述的这些问题，我们开始了打造闲鱼实时数仓的探索之路。

预研

数仓调研

在开始设计闲鱼的实时数据仓库之前，我们也调研了集团内外的各种数据仓库的设计与架构，一些是比较老的架构设计，另外一些是由于技术突破后进而带来的创新性的解决方案。本文不妨将这些实时数据仓库的新老设计做一下分类：

• 第一类：从无到有

当Apache Storm(开源的分布式实时计算系统)问世后，大数据不在依靠MapReduce这种单一的计算方式，拥有了当日数据当日处理的能力。

• 第二类：从有到全

以Lambda和Kappa为代表的架构，能够将实时与离线架构结合在一起，一套产品可以实现多种数据更新策略。

• 第三类：从全到简

以Flink为代表的支持窗口计算的流式框架出现，使离线和实时的逻辑能够统一起来，一套代码实现两种更新策略，避免了因为开发方式不统一导致的数据不一致问题。

• 第四类：架构走向工具

以Hologres为代表的HSAP(Hybrid Serving/Analytical Processing)引擎，用服务分析一体化的设计理念，统一分析型数据库和业务数据库，再配合Flink，真正实现数仓的彻底实时化。

首先我们摒弃了比较古老的方案，由于现在的技术创新非常快，涌现出很多优秀的产品可供我们去使用，另外基于闲鱼自身的业务需求，最终选择了Hologres[1]+Blink[2]来构建实时数据仓库。

数据模型