大厂实时数仓建设项目实例.docx

《大厂实时数仓建设项目实例.docx》由会员分享，可在线阅读，更多相关《大厂实时数仓建设项目实例.docx（56页珍藏版）》请在第一文库网上搜索。

1、大厂实时数仓建设项目实例01实时数仓建设背景1 .实时需求日趋迫切目前各大公司的产品需求和内部决策对于数据实时性的要求越来越迫切，需要实时数仓的能力来赋能。传统离线数仓的数据时效性是T+1,调度频率以天为单位，无法支撑实时场景的数据需求。即使能将调度频率设置成小时，也只能解决部分时效性要求不高的场景，对于实效性要求很高的场景还是无法优雅的支撑。因此实时使用数据的问题必须得到有效解决。2 .实时技术日趋成熟实时计算框架已经经历了三代发展，分别是：Storm、SparkStreaming Flink,计算框架越来越成熟。一方面，实时任务的开发已经能通过编写SQL的方式来完成，在技术层面能很好地继承

2、离线数仓的架构设计思想；另一方面，在线数据开发平台所提供的功能对实时任务开发、调试、运维的支持也口渐趋于成熟，开发成本逐步降低，有助于去做这件事。02实时数仓建设目的1 .解决传统数仓的问题从目前数仓建设的现状来看，实时数仓是一个容易让人产生混淆的概念,根据传统经验分析,数仓有一个重要的功能，即能够记录历史。通常，数仓都是希望从业务上线的第一天开始有数据，然后一直记录到现在。但实时流处理技术，乂是强调当前处理状态的一个技术，结合当前一线大厂的建设经验和滴滴在该领域的建设现状，我们尝试把公司内实时数仓建设的FI的定位为，以数仓建设理论和实时技术，解决由于当前离线数仓数据时效性低解决不了的问题。现

3、阶段我们要建设实时数仓的主要原因是：公司业务对于数据的实时性越来越迫切，需要有实时数据来辅助完成决策；实时数据建设没有规范，数据可用性较差，无法形成数仓体系，资源大量浪费；数据平台工具对整体实时开发的支持也日渐趋于成熟，开发成本降低。2 .实时数仓的应用场景实时OLAP分析；实时数据看板；实时业务监控;实时数据接口服务。03实时数仓建设方案接下来我们分析下目前实时数仓建设比较好的几个案例，希望这些案例能够给大家带来一些启发。1.滴滴顺风车实时数仓案例滴滴数据团队建设的实时数仓，基本满足了顺风车业务方在实时侧的各类业务需求，初步建立起顺风车实时数仓，完成了整体数据分层，包含明细数据和汇总数据，统

4、一了 DWD层，降低了大数据资源消耗，提高了数据复用性，可对外输出丰富的数据服务。数仓具体架构如下图所示:顺风车实时数仓架构APP应用层实时数据看板实时数据产品实时数据接口服务实时OLAPODS贴源层、数据库binlogPublic日志埋点日志消息队列从数据架构图来看，顺风车实时数仓和对应的离线数仓有很多类似的地方。例如分层结构;比如0DS层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。但仔细比较不难发现，两者有很多区别：与离线数仓相比，实时数仓的层次更少一些:从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中

5、应用层数据在数仓内部，但实时数仓中，app应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离；应用层少建设的好处：实时处理数据的时候，每建一个层次，数据必然会产生一定的延迟;汇总层少建的好处：在汇总统计的时候，往往为了容忍一部分数据的延迟，可能会人为的制造一些延迟来保证数据的准确。举例，在统计跨天相关的订单事件中的数据时; 可能会等到00:00:05或者00:00:10再统计，确保00:00前的数据已经全部接受到位了，再进行统计。所以，汇总层的层次太多的话，就会更大的加重人为造成的数据延迟。O与离线数仓相比，实时数仓的数据源存储不同：O在建设离线数仓的时候，目前滴滴内部整个离线数

6、仓都是建立在Hive表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。比如常见的情况卜，明细数据或者汇总数据都会存在Kafka里面，但是像城市、渠道等维度信息需要借助Hbase, mysql或者其他KV存储等数据库来进行存储。接下来，根据顺风车实时数仓架构图，对每一层建设做具体展开：1) ODS贴源层建设根据顺风车具体场景，目前顺风车数据源主要包括订单相关的binlog日志，冒泡和安全相关的public 口志，流量相关的埋点口志等。这些数据部分已采集写入kafka或ddmq等数据通道中，部分数据需要借助内部自研同步工具完成采集，最终基于顺风车数仓ods层建设规范分主题统一

7、写入kafka存储介质中。命名规范：ODS层实时数据源主要包括两种。一种是在离线采集时已经自动生产的DDMQ或者是Kafka topic,这类型的数据命名方式为采集系统自动生成规范为：cn-binlog-数据库名-数据库名eg：cn-binlog-ihap_fangyuan-ihap_fangyuan一种是需要自己进行采集同步到kafka topic中，生产的topic命名规范同离线类似：ODS层采用：realtime_ods_binlog_源系统库/表名/ods_log_日志名 eg:realtime_ods_binlog_ihap_fangyuan2) DWD明细层建设根据顺风车业务过程作

8、为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表；结合顺风车分析师在离线侧的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，完成宽表化处理，之后基于当前顺风车业务方对实时数据的需求重点，重点建设交易、财务、体验、安全、流量等几大模块；该层的数据来源于ODS层，通过大数据架构提供的Stream SQL完成ETL工作，对于binlog 口志的处理主要进行简单的数据清洗、处理数据漂移和数据乱序，以及可能对多个ODS表进行Stream Join,对于流量日志主要是做通用的ETL处理和针对顺风车场景的数据过滤，完成非结构化数据的结构化处理和数据的分流;该层的数据除了存储在消

9、息队列Kafka中，通常也会把数据实时写入Druid数据库中，供查询明细数据和作为简单汇总数据的加工数据源。命名规范：DWD层的表命名使用英文小写字母，单词之间用下划线分开，总长度不能超过40个字符，并且应遵循下述规则：realtime_dwd_业务/pub_数据域缩写业务过程缩写_自定义表命名标签缩写业务/pub：参考业务命名数据域缩写:参考数据域划分部分自定义表命名标签缩写:实体名称可以根据数据仓库转换整合后做一定的业务抽象的名称，该名称应该准确表述实体所代表的业务含义样例：realtime dwd trip trd order base3) DIM 层公共维度层，基于维度建模理念思想，建

10、立整个业务过程的一致性维度，降低数据计算口径和算法不统一风险；DIM层数据来源于两部分：一部分是Flink程序实时处理ODS层数据得到，另外一部分是通过离线任务出仓得到；DIM层维度数据主要使用MySQL、Hbase. fusion（滴滴自研KV存储）三种存储引擎，对于维表数据比较少的情况可以使用MySQL,对于单条数据大小比较小，查询QPS比较高的情况，可以使用fusion存储，降低机器内存资源占用，对于数据量比较大，对维表数据变化不是特别敏感的场景，可以使用HBase存储。命名规范：DIM层的表命名使用英文小写字母，单词之间用下划线分开，总长度不能超过30个字符，并且应遵循下述规则：dim

11、业务/pub_维度定义 _自定义命名标签:业务/pub：参考业务命名维度定义:参考维度命名自定义表命名标签缩写:实体名称可以根据数据仓库转换整合后做一定的业务抽象的名称，该名称应该准确表述实体所代表的业务含义样例：dim_trip_dri_base4) DWM汇总层建设在建设顺风车实时数仓的汇总层的时候，跟顺风车离线数仓有很多一样的地方，但其具体技术实现会存在很大不同。第一：对于一些共性指标的加工，比如pv, UV,订单业务过程指标等，我们会在汇总层进行统一的运算，确保关于指标的口径是统一在一个固定的模型中完成。对于一些个性指标,从指标复用性的角度出发，确定唯一的时间字段，同时该字段尽可能与其

12、他指标在时间维度上完成拉齐，例如行中异常订单数需要与交易域指标在事件时间上做到拉齐。第二：在顺风车汇总层建设中，需要进行多维的主题汇总，因为实时数仓本身是面向主题的,可能每个主题会关心的维度都不一样，所以需耍在不同的主题下，按照这个主题关心的维度对数据进行汇总，最后来算业务方需要的汇总指标。在具体操作中，对于PV类指标使用Stream SQL实现1分钟汇总指标作为最小汇总单位指标，在此基础上进行时间维度上的指标累加；对于uv类指标直接使用druid数据库作为指标汇总容器，根据业务方对汇总指标的及时性和准确性的要求，实现相应的精确去重和非精确去重。第三：汇总层建设过程中，还会涉及到衍生维度的加工

13、。在顺风车券相关的汇总指标加工中我们使用Hbase的版本机制来构建一个衍生维度的拉链表，通过事件流和Hbase维表关联的方式得到实时数据当时的准确维度命名规范：DWM层的表命名使用英文小写字母，单词之间用下划线分开，总长度不能超过40个字符，并且应遵循下述规则：realtime_dwm_业务/pub_数据域缩写“数据主粒度缩写_自定义表命名标签缩写_统计时间周期范围缩写:业务/pub：参考业务命名数据域缩写:参考数据域划分部分数据主粒度缩写:指数据主要粒度或数据域的缩写，也是联合主键中的主要维度自定义表命名标签缩写:实体名称可以根据数据仓库转换整合后做一定的业务抽象的名称，该名称应该准确表述实

14、体所代表的业务含义统计时间周期范围缩写： Id:天增量；td:天累计（全量）；lh:小时增量；th:小时累计（全量）;lmin:分钟增量;tmin:分钟累计（全量）样例：rea 11 ime_dwm_trip_trd_pas_bus_accum_ 1 min5) ） APP应用层该层主要的工作是把实时汇总数据写入应用系统的数据库中，包括用于大屏显示和实时OLAP的Druid数据库（该数据库除了写入应用数据，也可以写入明细数据完成汇总指标的计算）中，用于实时数据接口服务的Hbase数据库，用于实时数据产品的mysql或者redis数据库中。命名规范：基于实时数仓的特殊性不做硬性要求。2.快手实时

15、数仓场景化案例Apache Flink1）目标及难点目标及难点数据准确性离线差异1%以内数据延迟活动核心报表5minO数据稳定性数据不出现尖刺掉坑数据量大数据量万亿级别QPS幢值亿/秒组件依赖复杂链路涉及56个组件O链路复杂200实时作业50核心数据源目标首先由于是做数仓，因此希望所有的实时指标都有离线指标去对应，要求实时指标和离线指标整体的数据差异在1%以内，这是最低标准。其次是数据延迟，其SLA标准是活动期间所有核心报表场景的数据延迟不能超过5分钟,这5分钟包括作业挂掉之后和恢复时间，如果超过则意味着SLA不达标。最后是稳定性，针对一些场景，比如作业重启后，我们的曲线是正常的，不会因为作业重启导致指标产出一些明显的异常难点第一个难点是数据量大。每天整体的入口流量数据量级大概在万亿级。