随着互联网的发展从红海时代进入蓝海时代，数据的时效性对企业的精细化运营越来越重要，在每天产生的海量数据中，如何挖掘出实时有效的信息，对于公司的快速决策、产品的快速迭代都非常重要。在本地生活服务领域的两大巨头，滴滴在自己的业务如顺风车、美团在自己的业务如团购外卖中进行实时数仓的建设，为消费者提供更好的服务，如我们在滴滴上可以更快的打到更便宜的车、在美团上可以更快的取到最想要吃的餐，这其中的功劳也要算实时数仓一份。那么实时数仓到底是什么呢？与传统数仓有什么区别？如何建设实时数仓呢？

数仓，即存放数据的仓库，包括全量数据、历史数据。类型上又分为实时数仓、离线数仓，所谓实时数仓是指数据的实时性更高、延迟性低，一般是统计一天以内的数据，支持毫秒级的统计，在建设工具上一般采用Flink，而离线数仓则统计历史数据，在建设工具上一般采用Hive。对于实时性要求比较高的场景，如实时的交易分析、实时数据看板（比如双十一的成交额看板）、实时业务监控、实时数据接口服务等，我们就需要实时数仓了。

在数仓的开发实现中包含四个模块，即物理存储、数据抽象、runtime作业执行、编程接口。那么离线数仓和实时数仓有什么区别呢？在物理存储模块，离线数仓一般使用HDFS存储，实时数仓使用Kafka消息队列进行存储，在数据抽象模块，离线数仓使用HIve表，实时数仓使用streamtable。在作业执行模块，离线数仓使用mapreudce，而实时数仓使用FlinkStreaming。在编程模块，离线数仓使用HiveSQL进行开发，实时数仓使用FlinkSQL 进行开发。这就是实时数仓和离线数仓在开发实现上的区别了。

介绍完了数仓概念、实时数仓和传统数仓的区别之后，我们再来看看技术选型。

在实时数仓的建设中对于大规模数据的处理架构有Lambda架构、Kappa架构，从业界使用情况、灵活性、容错性、成熟度、迁移成本、批/流处理代码来看，Lambda都是最佳的方案。在实时计算引擎上，Flink是最佳的选择方案，因为比较准确、延时低、业界内使用多、易用性高。在实时存储引擎上，综合业务维度索引、高并发情况、高性能查询特征，一般推荐ClickHouse。

介绍完技术选型之后，我们来看看实时数仓和实时存储两块如何实现？

在实时数仓中包含四层，即数据接入层ODS、数据明细层DWM、数据汇总层DWS、数据应用层APP。如下图所示，ODS层是数据的源头，包含系统的消息队列数据、系统日志、流量埋点数据、系统消息，不同业务线可能采用的方式存储数据，但是在接入数仓时需要统一来源接入，这样可以方便数据的处理以及数据一致性。在数据明细层，一般分两类进行数据建设，一类是业务数据明细、一类是按维度进行数据拆分，比如在美团中，商家的地理位置、评分、菜品、价格就是明细数据，也可以按地域维度、商家维度、菜品维度、价格维度进行建设。在汇总层主要基于共性维度进行建模分析，比如系统的日活、月活等数据，在汇总层就可以统一的运算。在APP层主要就是把实时数据写入应用系统的数据库，用于建设实时看板、实时特征应用、实时分析。

在整个业务系统的架构设计中分为两部分，即实时数仓和实时存储。对于实时数仓我们已经介绍了，而对于实时存储，一般满足三个需求，即支持海量数据存储、支持分布式高可用、支持高性能查询。对于海量数据的写入，业界内一般采用clickhouse大数据库存储。为了保障系统的高可用，互联网通用的模式是分布式部署，一般借助分布式协调框架Zookeeper来进行实现，数据写入某一个分片时，zookeeper告诉同一个分片的其它副本，副本来拉取数据，保障同一分片内的数据是一致的。在数据查询中，借助于存储数据库clickhouse的稀疏索引优势，将时间维度和内容进行稀疏索引建立，之后就可以基于内容进行查询了。

在互联网流量为王的时代，通过数据精准的了解用户情况，进行准确的营销和运营才能把用户长久的留在自己平台，从而保障业务的长久发展，在滴滴的打车业务中采用实时数仓，可以知道某个时间点某个区域的乘客发单情况、司机应答情况，从而采取对应的优惠券触发或加派司机进行调度支持等策略，现在滴滴推出的特惠快车背后也有实时数仓的功劳呢，系统通过实时数仓发现该时间点乘客较少、司机比较空闲，于是通过比较优惠价格，提高乘客打车欲望、增加司机收入。

通过本文的介绍，相信你已经了解了BAT、TMD等互联网巨头都在建设的实时数仓到底是什么样了吧？如果是准备从事数据分析行业的朋友，实时数仓是一个不错的方向噢；而对于待在互联网圈、使用互联网服务的朋友，在享受服务的同时了解一些背后的逻辑也是不错噢！