搜狐智能媒体数据仓库体系建设实践

搜狐智能媒体数据仓库体系建设实践,会对数据仓库中的基本概念进行简单梳理,明确数据仓库体系建设涵盖的相关流程,主要划分为批量 ( 非实时 ) 数据处理和实时数据处理。

一、数据仓库体系建设主要工作

1. 数据仓库定义

数据仓库是1991年Bill Inmon在《Building the Data Warehouse》中最开始提出的概念。数据仓库的定义是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理决策。从定义中,可以看出数据仓库不仅仅是一个数据存储计算软件或产品,而是包含整个数据分析处理过程体系。

2. 数据分析

数据仓库主要是供给数据数据分析使用的,其分类主要参考商业智能分为三大部分:

  • Data Reporting:分析维度较少,延迟较低,并发度较高
  • OLAP:分析维度、延迟和并发度都比较适中
  • Data Mining:分析维度可能几百上千,维度较多,对于延迟的容忍度较高,一般用户较少,并发度较低

3. OLAP

OLAP是数据仓库中最经常使用数据处理和分析技术,是Edgar F.Codd在1993年发表于《Providing OLAP(On-line Analytical Processing) to User-Analysts:An IT Mandate 》论文中。OLAP主要是针对OLTP对比来说的:

  • OLTP:支持业务处理,操作数据或者业务数据,不适合支持决策分析
  • OLAP:支持决策分析、多维分析/多维数据库

上方图中可以看出,OLTP产生的业务数据汇总到OLAP的数据仓库中,然后数据仓库中产生的分析结果会促进业务系统的改进。

4. 多维模型 ( Multidimensional Model)

前面提到的多维分析是建立在多维模型之上的:

  • 多维模型就是OLAP中的数据组织范型
  • 主要概念:多维数据集 ( Cube );维度 ( Dimension );维度层次 ( Hierarchy );维度级别 ( Level );维度成员 ( Member );度量/指标 ( Measure )
  • 多维分析操作:上卷 ( Roll-up );下钻 ( Drill-down );切片 ( Silce );切块 ( Dice );旋转 ( Pivot )

5. 多维分析操作

① 上卷

虽然多维分析都是对立方体的操作,但是可以映射到关系模型的sql语句上来;上卷就是通过group by把一些多的维度去掉。

② 下钻

下钻操作,对应到关系模型的sql语句就是对一些低层次维度进行group by。

③ 切片

切片操作,对应到关系模型的sql语句就是增加一个where条件。

④ 切块

切块操作,对应到关系模型的sql语句就是增加两个where条件。

⑤ 旋转

旋转操作,对应到关系模型的sql语句就是select时,把列的顺序重新编排一下。

6. OLAP Cube构建

Cube构建主要包含两类:

维度构建:扩展 ( 例如:a. 通过时间戳字段扩展天、小时和分钟维度;b. 利用Id关联将维度表的属性放到Cube里面来 );剪裁 ( 类似于上卷操作,缩减维度 )

指标构建:联合 ( 指标在两个Cube里面,通过union all方式放到一个Cube里面 )

7. OLAP多维数据库

OLAP多维数据库按照存储格式划分:

  • ROLAP:基于关系型模型的数据库
  • MOLAP:基于多维模型的数据库,如上图所示,将不同的维度组成一个CuboId,然后将结果存储到KV数据库中,MOLAP大概就是这样
  • HOLAP:就是讲ROLAP和MOLAP的一些特点综合起来

ROLAP和MOLAP对比来看:

  • 查询速度:严格按照多维分析方式查询,MOLAP查询速度会更快一些,但是目前随着ROLAP的几十年发展,包含分布式和索引的一些优化,查询速度已经开始接近于MOLAP
  • 装载速度:因为MOLAP需要做一些组合,所以装载速度慢于ROLAP
  • 存储空间:MOLAP存储空间膨胀还是比较厉害的,所以要大于ROLAP
  • 分析灵活性:MOLAP基本上只能基于KV查询,ROLAP是基于关系型的,灵活性上MOLAP要比ROLAP差的较多

8. 维度建模

提到ROLAP就要提到维度建模,维度建模是数据仓库另一位大师Ralph Kimall倡导的,关系建模方法,就是将维度模型映射到关系模型:

  • 维度表
  • 事实表
  • 星型模型/雪花模型/星座模型

9. 表分层

另一个比较重要的就是数据仓库都是面向主题的,一般创建Cube都会对表进行分层,主要分为下面几个层次:STG原始数据层、ODS操作数据层、DWD明细数据层、DWS汇总数据层、ADS应用数据层、DIM维度层。

这样分层的优势是:

  • 防止烟囱模式,减少重复开发
  • 将复杂问题简单化
  • 层次清晰,便于使用和理解

10. 数据仓库体系架构

此处数据仓库体系架构主要参考了Lambda架构,按照数据时效性,分为实时层和批量层,只做新增和读取,一般不做删除和修改:

  • 批量数据一般是小时级滞后,是最终标准
  • 实时数据一般是秒、分钟级滞后,只作参考

批量数据层从原始的业务数据系统或者行为日志系统抽取数据到STG层,然后经由ODS、DWD、DWS层最终到ADS层供给应用方使用;实时数据层一般没有那么多层次,经过Spark Streaming等处理后直接放到Kafka里面,最后存储到ADS层供给业务系统使用

二、整体方案

上面主要讲了数据仓库体系建设主要工作,也就是需求;接下来讲一下搜狐智能媒体的相关技术实践。

1. 搜狐智能媒体数据仓库技术架构

首先简单分析一下计算泛型,主要是根据Michael Stonebraker的论文《One Size Fits All》,不同场景选用不同的数据库:

批量数据计算:交互式分析 ( 场景:报表、OLAP、Ad HOC;技术:Impala、Apache Doris );批量处理 ( 场景:ETL、数据挖掘;技术:Hive、Spark )

实时数据计算:流处理 ( 场景:ETL、复杂事件处理;技术:Spark Streaming、Flink );统计分析 ( 场景:报表、Ad HOC;技术:Apache Doris )

2. Apache Doris

Apache Doris是百度开发的MPP架构的分析性数据库,看一下和其他技术选型的对比:

  • Kylin:MOLAP型数据库,因为目前主流应该是ROLAP数据库,所以没有考虑
  • ClickHouse/Druid/Elaticsearch:早期的典型的两阶段计算,没法做复杂的SQL处理,从分析复杂性角度上没有考虑
  • Impala/Presto:目前比较主流是MPP架构的数据库,Presto和Hawq可以认为是查询引擎,依赖HDFS作为存储引擎,HDFS适合批量数据导入,对实时数据导入支持不好;Impala也是查询引擎,但Impala既可以使用HDFS作为批量数据存储引擎,也可以使用KuDu作为实时数据存储引擎,但Impala的缺点是部署依赖太多,另外kudu只支持Unique Key模式,数据导入性能较Doris差,且对聚合查询不友好

三、批量数据管理

1. 批量数据管理

批量数据管理和业界的方案基本相似,分为数据任务管理、数据元信息管理、数据质量管理和数据安全管理。

批量数据处理都是对全域数据在Hadoop上进行一些分析计算,最后供给业务层使用;在Hadoop上分析计算时候我们会进行上述的管理,首先对执行的数据任务进行管理,然后对产生的数据质量进行校验,校验通过后才能给业务方使用,基于这之上做了元信息和安全的管理。

2. 数据任务管理

① Workflow管理系统

数据任务管理实际上就是Workflow的管理,Workflow是指一类能够完全自动执行的经营过程,根据一系列过程规则,将文档、信息或任务在不同的执行者之间进行传递与执行;Workflow管理系统通过计算机软件对工作流的经营过程进行定义、执行并监控。

数据处理任务Workflow就是将节点通过数据流向依赖在一起,形成DAG有向无环图;可以根据任务依赖,自动执行任务,在任务之间传递数据。

开源的数据仓库Workflow管理系统:

目前用的比较多的框架有国外的Azkaban、Oozie和Airflow,但是他们都存在一些问题:

  • 以Flow为单位进行编辑、管理和发布部署,对多人协同开发不友好
  • 复杂的任务依赖不友好,如天依赖小时任务,需要写代码调度的辅助代码
  • 新建任务或修复任务,需要有补数据功能,以Flow为单位进行调度,不适合补数据处理

② DAG节点=>任务&实例
 

在数据任务管理中,将DAG节点抽象为两个概念:任务和实例。

任务:用户以任务为单位进行编辑,使用SQL、Shell等进行数据处理代码,支持最细小时粒度的周期属性,可配置依赖父节点、就近依赖和自依赖以及一些其他属性、告警等

实例:按天或小时为单位,根据任务周期属性,生成一个或多个实例,并制定每个实例运行时间;继承对应任务中的数据处理代码;根据任务依赖属性和运行时间动态生成;依赖的父节点运行成功或者自身运行时间已到则会生成一个实例

③ 实例依赖生成规则

上图展示了实例依赖生成的具体规则。

④ 实例依赖示例

根据上面举的例子来看上图实例依赖的示例,通过小时级表数据汇总成天级表数据,父任务会在每小时调度一次,子任务在每天的0点9分执行一次,然后根据父任务的结果产生一个天级别的数据;父任务要设置自依赖,子任务要设置就近依赖,这样就可以通过这样的语义设置很方便地达到业务要求。

⑤ 补历史数据

介绍一下补历史数据的问题,一个大的DAG任务中需要新增数据处理任务,或者是某个任务运行或逻辑有问题,就把这块的根节点拿出来从对应的时间段开始向下游修复数据,这样的模型实现起来就比较方便了。

3. 数据质量管理

  • 表为校验单位:一个任务实例可以产生多张表数据
  • 校验规则:以表为单位进行配置;一张表可以对应多个规则;数据行数、关键指标等校验
  • 触发:任务实力执行完后触发;严重的质量问题可以阻塞下游实例调度

4. 数据元信息管理

元信息管理主要功能包含:表的创建、修改、查询;表的生命周期管理;表的大小、分区等信息统计;表的名称、字段等搜索;表及字段的血缘关系。

主要说一下血缘解析的做法,这块是设计时候的难点:目前业内的大部分做法是通过hive的hook将字段信息释放出来,然后直接导入到mysql表里面;但目前没有采用这种方案原因是集群不是自主维护,另外就是它是在任务执行完之后才执行,我们需要在任务保存时候就要进行数据血缘关系的解析。

在这块有调研一些方案:阿里的Druid提供一些解析功能,但是对Hive支持不是很好;利用Anltr结合网上开源的一些代码进行解析,但是对Hive的集成也是有一定问题的;后来调研了Hive的代码,发现可以重写SematicAnalyzer函数,放到自己代码里面,像是hook那样在保存或者执行代码时候解析血缘关系。

接下来看一下上图的Hive的整个生命操作流程:

HQL->Parser->Semantic Analyzer->Logic Plan Generator->Logical Optimizer->Physical Plan Generator->Physical Optimizer->Execution

血缘解析:

血缘解析这块主要分为两部分:

表血缘解析:解析SQL语句获得抽象语法树;对抽象语法树进行验证和裁剪;遍历抽象语法树获取上游表名 ( TOK_TAB ) 和下游表名 ( TOK_TABREF )

字段血缘解析:注册UDF;重构SemanticAnalyzer;逻辑计划生成和逻辑计划优化;添加postExecHook,执行LineageLogger获得Lineage Context;从LineageContext中组装血缘信息

5. 数据安全管理

有了数据血缘关系之后做数据安全管理就很简单了,目前只做了表级别的安全管理,字段级别太复杂,可能会对用户使用产生一定的影响。

数据安全管理流程是:用户针对要使用的表进行权限申请,然后管理者就会对表权限进行审批或者回收;在数据任务执行前,会进行表权限的校验,如果没有权限则会暂停任务执行,并通过使用方。

四、实时数据管理

实时数据管理比较简单一点,表没有很分散,不需要Workflow方式执行;只需要把Kafka的Topic抽象成一张表,然后在Apache Doris里面再建一张表,将两边字段映射起来,然后下发一个任务,任务方式有两种:一种是写个Sql下发到Spark Streaming导入到Apache Doris里面;另一种是创建一个Doris的Routine Load任务,这里面主要是看Doris的使用,提供代码支持解析这种Json格式数据,只需要先在Doris里面先创建一张表,然后创建一个Routine Load任务从Kafka中消费Json格式数据直接处理映射到表中。

五、总结

简单总结下:我们在做整个项目时的思想是产品化、服务化,可以方便业务对接。在做技术实践时,选择可靠的开源产品和开源代码,并借鉴可靠的业务解决方案,可以帮助我们快速实践应用。

今天的分享就到这里,谢谢大家。

 

立即体验DorisDB,开启前所未有的极速体验!

申请试用