从0开始研究数据仓库的一些想法

2020-10-12  本文已影响0人  lodestar

研究方向

数仓理论:分层设计理论、维度建模理论
基于OLAP数仓:adb/clickhouse/greenplum/presto/kylin等
基于阿里云EMR的hadoop平台:hdfs/hbase/hive等
基于阿里云MaxCompute/DataWorks平台
基于阿里云DLA平台
基于阿里云DMS数仓开发平台
实时计算引擎:Flink
存储:kafka/redis/hbase/es/rds等

数仓建设如果从头开始,那么需要调研的技术非常多,需要花费很多的时间来学习相关的技术,然后从中选择使用哪些技术,更多的是满足自身的需求。

阿里将数仓分为如下几层:
操作数据层ODS,存储在kafka/hive/hbase
明细数据层DWD,存储在kafka/hive/hbase
汇总数据层DWS,存储在kafka/hive/hbase,impala/presto/kylin等OLAP
应用数据层ADS ,存储在rds或KV系统

目前比较通用的方案是通过维度建模来实现数仓建设,维度表始终贯穿于整个数仓全局,参考下有赞技术关于数仓建设实践 https://tech.youzan.com/dw-in-youzan/

目前有2种可以实施的方案:

方案一、DTS+Datahub+Kafka+Hbase+Flink
流程:通过DTS同步工具,将Polardb数据库中的表同步到Datahub,然后通过Flink关联Datahub和kafka,然后再通过Flink写入到Hbase中,具体使用方法可以参考前一篇文章。
方案二、DLA+DMS+ADB
流程:在数据湖分析DLA中将Polardb关联存储到OSS中,然后再DMS管理工具中通过查询的方式将OSS中数据写入到ADB中。

方案一 方案二
流批一体计算 批量计算
灵活性高、可以分层设计 设计受限于DMS
延时低,准实时(秒级) 延时高,定时任务
ETL繁琐 ETL简单
宽表实现复杂 宽表通过物化视图(最低2分钟延时)
前期费用高,费用平稳 前期费用低,随着请求量级增加、费用增加巨大
使用难度高、维护成本高 使用难度低、维护成本低
可以满足高QPS QPS低
海量存储 湖量存储

总结起来就是,方案一功能强大,复杂度高;方案二功能简单,复杂度低

核心观点:

1、不管是用OLAP还是Hadoop平台做数仓,有个核心环节是明细层(大宽表)是如何实现的。如果OLAP支持物化视图,那就会省去很多工作量。

2、对于OLAP的数仓,QPS都不算高,如果QPS比较高,需要提供给业务,那么无论如何需要将数据统计结果转化到RDS或者KV存储系统中。

上一篇 下一篇

猜你喜欢

热点阅读