随着滴滴业务的高速发展，业务对于数据时效性的需求越来越高，而伴随着实时技术的不断发展和成熟，滴滴也对实时建设做了大量的尝试和实践。本文主要以顺风车这个业务为引子，从引擎侧、平台侧和业务侧各个不同方面，来阐述滴滴所做的工作，分享在建设过程中的经验。
随着互联网的发展进入下半场，数据的时效性对企业的精细化运营越来越重要，商场如战场，在每天产生的海量数据中，如何能实时有效的挖掘出有价值的信息， 对企业的决策运营策略调整有很大帮助。
其次从智能商业的角度来讲，数据的结果代表了用户的反馈，获取结果的及时性就显得尤为重要，快速的获取数据反馈能够帮助公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不可替代的作用。
从目前数仓建设的现状来看，实时数仓是一个容易让人产生混淆的概念，根据传统经验分析，数仓有一个重要的功能，即能够记录历史。通常，数仓都是希望从业务上线的第一天开始有数据，然后一直记录到现在。但实时流处理技术，又是强调当前处理状态的一个技术，结合当前一线大厂的建设经验和滴滴在该领域的建设现状，我们尝试把公司内实时数仓建设的目的定位为，以数仓建设理论和实时技术，解决由于当前离线数仓数据时效性低解决不了的问题。
现阶段我们要建设实时数仓的主要原因是：
公司业务对于数据的实时性越来越迫切，需要有实时数据来辅助完成决策；
实时数据建设没有规范，数据可用性较差，无法形成数仓体系，资源大量浪费；
数据平台工具对整体实时开发的支持也日渐趋于成熟，开发成本降低。
在公司内部，我们数据团队有幸与顺风车业务线深入合作，在满足业务方实时数据需求的同时，不断完善实时数仓内容，通过多次迭代，基本满足了顺风车业务方在实时侧的各类业务需求，初步建立起顺风车实时数仓，完成了整体数据分层，包含明细数据和汇总数据，统一了DWD层，降低了大数据资源消耗，提高了数据复用性，可对外输出丰富的数据服务。
数仓具体架构如下图所示：
从数据架构图来看，顺风车实时数仓和对应的离线数仓有很多类似的地方。例如分层结构；比如ODS层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。但仔细比较不难发现，两者有很多区别：
1）与离线数仓相比，实时数仓的层次更少一些：
从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部，但实时数仓中，app应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离；
应用层少建设的好处：实时处理数据的时候，每建一个层次，数据必然会产生一定的延迟；
汇总层少建的好处：在汇总统计的时候，往往为了容忍一部分数据的延迟，可能会人为的制造一些延迟来保证数据的准确。举例，在统计跨天相关的订单事件中的数据时，可能会等到 00:00:05 或者 00:00:10再统计，确保 00:00 前的数据已经全部接受到位了，再进行统计。所以，汇总层的层次太多的话，就会更大的加重人为造成的数据延迟。
接下来，根据顺风车实时数仓架构图，对每一层建设做具体展开：
根据顺风车具体场景，目前顺风车数据源主要包括订单相关的binlog日志，冒泡和安全相关的public日志，流量相关的埋点日志等。这些数据部分已采集写入kafka或ddmq等数据通道中，部分数据需要借助内部自研同步工具完成采集，最终基于顺风车数仓ods层建设规范分主题统一写入kafka存储介质中。
命名规范：ODS层实时数据源主要包括两种。
根据顺风车业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表；结合顺风车分析师在离线侧的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，完成宽表化处理，之后基于当前顺风车业务方对实时数据的需求重点，重点建设交易、财务、体验、安全、流量等几大模块；该层的数据来源于ODS层，通过大数据架构提供的Stream SQL完成ETL工作，对于binlog日志的处理主要进行简单的数据清洗、处理数据漂移和数据乱序，以及可能对多个ODS表进行Stream Join，对于流量日志主要是做通用的ETL处理和针对顺风车场景的数据过滤，完成非结构化数据的结构化处理和数据的分流；该层的数据除了存储在消息队列Kafka中，通常也会把数据实时写入Druid数据库中，供查询明细数据和作为简单汇总数据的加工数据源。
命名规范：DWD层的表命名使用英文小写字母，单词之间用下划线分开，总长度不能超过40个字符，并且应遵循下述规则：realtime_dwd_{业务/pub}_{数据域缩写}_[{业务过程缩写}]_[{自定义表命名标签缩写}]
命名规范：DIM层的表命名使用英文小写字母，单词之间用下划线分开，总长度不能超过30个字符，并且应遵循下述规则：dim_{业务/pub}_{维度定义}[_{自定义命名标签}]：
在建设顺风车实时数仓的汇总层的时候，跟顺风车离线数仓有很多一样的地方，但其具体技术实现会存在很大不同。
第一：对于一些共性指标的加工，比如pv，uv，订单业务过程指标等，我们会在汇总层进行统一的运算，确保关于指标的口径是统一在一个固定的模型中完成。对于一些个性指标，从指标复用性的角度出发，确定唯一的时间字段，同时该字段尽可能与其他指标在时间维度上完成拉齐，例如行中异常订单数需要与交易域指标在事件时间上做到拉齐。
第二：在顺风车汇总层建设中，需要进行多维的主题汇总，因为实时数仓本身是面向主题的，可能每个主题会关心的维度都不一样，所以需要在不同的主题下，按照这个主题关心的维度对数据进行汇总，最后来算业务方需要的汇总指标。在具体操作中，对于pv类指标使用Stream SQL实现1分钟汇总指标作为最小汇总单位指标，在此基础上进行时间维度上的指标累加；对于uv类指标直接使用druid数据库作为指标汇总容器，根据业务方对汇总指标的及时性和准确性的要求，实现相应的精确去重和非精确去重。
第三：汇总层建设过程中，还会涉及到衍生维度的加工。在顺风车券相关的汇总指标加工中我们使用Hbase的版本机制来构建一个衍生维度的拉链表，通过事件流和Hbase维表关联的方式得到实时数据当时的准确维度
命名规范：DWM层的表命名使用英文小写字母，单词之间用下划线分开，总长度不能超过40个字符，并且应遵循下述规则：realtime_dwm_{业务/pub}_{数据域缩写}_{数据主粒度缩写}_[{自定义表命名标签缩写}]_{统计时间周期范围缩写}：
{业务/pub}：参考业务命名
{数据域缩写}：参考数据域划分部分
{数据主粒度缩写}：指数据主要粒度或数据域的缩写，也是联合主键中的主要维度
{自定义表命名标签缩写}：实体名称可以根据数据仓库转换整合后做一定的业务抽象的名称，该名称应该准确表述实体所代表的业务含义
{统计时间周期范围缩写}：1d:天增量；td:天累计(全量)；1h:小时增量；th:小时累计(全量)；1min:分钟增量；tmin:分钟累计(全量)
样例：realtime_dwm_trip_trd_pas_bus_accum_1min
该层主要的工作是把实时汇总数据写入应用系统的数据库中，包括用于大屏显示和实时OLAP的Druid数据库(该数据库除了写入应用数据，也可以写入明细数据完成汇总指标的计算)中，用于实时数据接口服务的Hbase数据库，用于实时数据产品的mysql或者redis数据库中。
命名规范：基于实时数仓的特殊性不做硬性要求。
截止目前，一共为顺风车业务线建立了增长、交易、体验、安全、财务五大模块，涉及40+的实时看板，涵盖顺风车全部核心业务过程，实时和离线数据误差<0.5%，是顺风车业务线数据分析方面的有利补充，为顺风车当天发券动态策略调整，司乘安全相关监控，实时订单趋势分析等提供了实时数据支持，提高了决策的时效性。同时建立在数仓模型之上的实时指标能根据用户需求及时完成口径变更和实时离线数据一致性校验，大大提高了实时指标的开发效率和实时数据的准确性，也为公司内部大范围建设实时数仓提供了有力的理论和实践支持。
目前公司内部的实时数仓建设，需要依托数据平台的能力才能真正完成落地，包括StreamSQL能力，数据梦工程StreamSQL IDE环境和任务运维组件，实时数据源元数据化功能等。
StreamSQL是滴滴大数据引擎部在Flink SQL 基础上完善后形成的一个产品。
使用 StreamSQL 具有多个优势：
描述性语言：业务方不需要关心底层实现，只需要将业务逻辑描述出来即可；
接口稳定：Flink 版本迭代过程中只要 SQL 语法不发生变化就非常稳定；
问题易排查：逻辑性较强，用户能看懂语法即可调查出错位置；
批流一体化：批处理主要是 HiveSQL 和 Spark SQL，如果 Flink 任务也使用 SQL 的话，批处理任务和流处理任务在语法等方面可以进行共享，最终实现一体化的效果。
StreamSQL 相对于 Flink SQL （1.9之前版本）的完善：
Join 能力扩展：
基于 TTL 的双流 join：在滴滴的流计算业务中有的 join 操作数据对应的跨度比较长，例如顺风车业务发单到接单的时间跨度可能达到一个星期左右，如果这些数据的 join 基于内存操作并不可行，通常将 join 数据放在状态中，窗口通过 TTL 实现，过期自动清理；
维表 join 能力：维表支持 HBase、KVStore、Mysql 等，同时支持 inner、left、right、full join 等多种方式。
2、基于数据梦工厂的StreamSQL IDE和任务运维
StreamSQL IDE：
任务运维：任务运维主要分为四个方面。
3、基于数据梦工厂的实时数据源元数据化（meta化表）
将topic引入成实时表，metastore统一管理元数据，实时开发中统一管理DDL过程。对实时数仓来说，通过元数据化，可以沉淀实时数仓的建设成果，使数仓建模能更好的落地。
