云计算·大数据 频道

如何构建准实时数仓?

  当前,数据仓库被分为离线数仓和实时数仓,离线数仓一般是传统的T+1型数据ETL方案,而实时数仓一般是分钟级甚至是秒级ETL方案。并且,离线数仓和实时数仓的底层架构也不一样,离线数仓一般采用传统大数据架构模式搭建,而实时数仓则采用Lambda、Kappa等架构搭建。

  其中,实时数仓又被细分为两类:一类是标准的实时数仓,所有ETL过程都通过Spark或Flink等实时计算、落地;另一类是简化的实时数仓,甚至是离线数仓的简单升级,这类数仓叫做准实时数仓。

  接下来,本文重点梳理准实时数仓应用场景!

  简单理解,准实时数仓一定会有延迟,相比一天只统计一次的离线数据仓库,准实时仓库要根据业务需求,按照小时、分钟或者秒来计算。这里,以5分钟为界限,5分钟出一次结果,可以基于Structured Streaming实现准实时数据仓库构建,这是一个基于流式数据基础之上的离线操作,即按照时间切分批次,整体的数据在流式计算引擎上面,也就是在Structured Streaming上面。

  实时数仓项目分行业、分领域,以新闻资讯类为例,比如今日头条、一点资讯、腾讯新闻、网易新闻、百度浏览器、360浏览器、新浪、搜狐等。这类应用有哪些数据源?一般包括用户信息、隐私以及和用户收益相关的业务数据;还有用户浏览文章留下的行为日志;用户发布作品产生的内容日志,这些信息首先会收集到Kafka上。

  之后的过程是,通过Spark Structured Streaming消费Kafka的原始数据。这里需要强调一点,采用Spark Structured Streaming有三个原因。第一,实现流批统一,可以处理批计算;第二支持file sink,实现端到端的一致性语义;第三,可以控制sink到HDFS的时间,比如:对批次数据设置5分钟节点,延时低,处理速度快。

  从sink到HDFS时,可以选择使用Hudi,也可以选择不使用Hudi,如果通过Spark Streaming直接写数据到HDFS时,不可避免地要处理小文件问题,一般有四种处理方式。第一,增大批处理能力,但也会增加延迟;第二分区合并;第三外部程序融入;第四,如果文件没有达到指定大小,下一个批次写数据的时候不创建文件,而是和已存在的小文件合并。这四种方式各有其使用场景,无论采用哪种方式,都会增加工作量。但是,如果通过Hudi写入数据,小文件的问题,Hudi会帮忙解决。

  还有一个问题,除了用户行为事件日志不会更新,很多业务数据需要实时更新,比如:用户信息的修改。但是,HDFS本身不支持更新,导致需要修改的数据要经过一个复杂的处理流程,并且在整个过程中,数据的实时性也无法保证,如果使用Hudi,可以在相对较短的延迟下,比如分钟级别,提供数据更新的支持,同时Hudi也支持ACID。

  当原始数据落地到HDFS上,可以在落地过程中做一些数据预处理的工作,比如之前在Flume Interceptor中的数据处理工作,之后我们可以通过Hive建立对应的外部表,可以对这些表划分一个层次,叫做ODS层的表,这些表都是最原始数据,也是数仓的第一层。

  建立完ODS层的Hive表,就可以根据业务需求查询数据了。至于,我们是不是要构建更上层的数仓层次,要根据业务需求来确定。映射Hive的原始数据层ODS后,就有数据可以分析处理,分析使用的是Presto分析引擎,基于内存的计算框架,计算速度要比Hive和Spark快很多。

  使用Presto查询操作完成OLAP分析处理,还会整合Spring Boot框架,使用JDBC连接Presto,提供对外查询接口,供分析人员使用。

0
相关文章