Go最新什么是数据分层,数据分层的作用!(2)，2024年最新2024最新Golang高频精选面试题分享

2401_84926028

于 2024-05-17 04:29:56 发布

阅读量801

点赞数 21

分类专栏：面试学习路线阿里巴巴文章标签： go 学习面试

本文链接：https://blog.csdn.net/2401_84926028/article/details/138986075

版权

面试同时被 3 个专栏收录

9 篇文章 0 订阅

订阅专栏

学习路线

9 篇文章 0 订阅

订阅专栏

阿里巴巴

9 篇文章 0 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

这三层技术划分，相对来说比较粗粒度，后面我们会专门细分一下。在此之前，先聊一下每一层的数据一般都是怎么流向的。这里仅仅简单介绍几个常用的工具，侧重中开源界主流。

1. 数据来源层–> ODS层

这里其实就是我们现在大数据技术发挥作用的一个主要战场。我们的数据主要会有两个大的来源：

业务库，这里经常会使用sqoop来抽取，比如我们每天定时抽取一次。在实时方面，可以考虑用canal监听mysql的binlog，实时接入即可。
埋点日志，线上系统会打入各种日志，这些日志一般以文件的形式保存，我们可以选择用flume定时抽取，也可以用用spark streaming或者storm来实时接入，当然，kafka也会是一个关键的角色。
其它数据源会比较多样性，这和具体的业务相关，不再赘述。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

注意： 在这层，理应不是简单的数据接入，而是要考虑一定的数据清洗，比如异常字段的处理、字段命名规范化、时间字段的统一等，一般这些很容易会被忽略，但是却至关重要。特别是后期我们做各种特征自动生成的时候，会十分有用。后续会有文章来分享。

2. ODS、DW --> App层

这里面也主要分两种类型：

每日定时任务型：比如我们典型的日计算任务，每天凌晨算前一天的数据，早上起来看报表。这种任务经常使用Hive、Spark或者生撸MR程序来计算，最终结果写入Hive、Hbase、Mysql、Es或者Redis中。
实时数据：这部分主要是各种实时的系统使用，比如我们的实时推荐、实时用户画像，一般我们会用Spark Streaming、Storm或者Flink来计算，最后会落入Es、Hbase或者Redis中。

0x03 举个例子

网上的例子很多，就不列了，只举个笔者早期参与设计的数据分层例子。分析一下当初的想法，以及这种设计的缺陷。上原图。

此处@Ruby大神。现实是我只是个打酱油的。盗图、盗思想。

当初的设计总共分了6层，其中去掉元数据后，还有5层。下面分析一下当初的一个设计思路。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

** 缓冲层(buffer) **

概念：又称为接口层（stage），用于存储每天的增量数据和变更数据，如Canal接收的业务变更日志。
数据生成方式：直接从kafka接收源数据，需要业务表每天生成update,delete,inseret数据，只生成insert数据的业务表，数据直接入明细层
讨论方案：只把canal日志直接入缓冲层，如果其它有拉链数据的业务，也入缓冲层。
日志存储方式：使用impala外表，parquet文件格式，方便需要MR处理的数据读取。
日志删除方式：长久存储，可只存储最近几天的数据。讨论方案：直接长久存储
表schema：一般按天创建分区
库与表命名。库名：buffer,表名：初步考虑格式为：buffer_日期_业务表名,待定。

明细层（ODS, Operational Data Store,DWD: data warehouse detail）

概念：是数据仓库的细节数据层，是对STAGE层数据进行沉淀，减少了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中，明细层跟stage层的粒度一致，属于分析的公共资源
数据生成方式：部分数据直接来自kafka，部分数据为接口层数据与历史数据合成。
canal日志合成数据的方式待研究。
讨论方案：canal数据的合成方式为：每天把明细层的前天全量数据和昨天新数据合成一个新的数据表，覆盖旧表。同时使用历史镜像，按周/按月/按年存储一个历史镜像到新表。
日志存储方式：直接数据使用impala外表，parquet文件格式，canal合成数据为二次生成数据，建议使用内表，下面几层都是从impala生成的数据，建议都用内表+静态/动态分区。
日志删除方式：长久存储。
表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名。库名：ods,表名：初步考虑格式为ods_日期_业务表名,待定。
旧数据更新方式：直接覆盖

轻度汇总层(MID或DWB, data warehouse basis)

概念：轻度汇总层数据仓库中DWD层和DM层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计（可以把复杂的清洗，处理包含，如根据PV日志生成的会话数据）。轻度综合层与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并未满意一些不可预见的需求而进行沉淀；轻度综合层则面向分析型应用进行细粒度的统计和沉淀
数据生成方式：由明细层按照一定的业务需求生成轻度汇总表。明细层需要复杂清洗的数据和需要MR处理的数据也经过处理后接入到轻度汇总层。
日志存储方式：内表，parquet文件格式。
日志删除方式：长久存储。
表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名。库名：dwb,表名：初步考虑格式为：dwb_日期_业务表名,待定。
旧数据更新方式：直接覆盖

主题层（DM，date market或DWS, data warehouse service）

概念：又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
数据生成方式：由轻度汇总层和明细层数据计算生成。
日志存储方式：使用impala内表，parquet文件格式。
日志删除方式：长久存储。
表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名。库名：dm,表名：初步考虑格式为：dm_日期_业务表名,待定。
旧数据更新方式：直接覆盖

应用层(App)

概念：应用层是根据业务需要，由前面三层数据统计而出的结果，可以直接提供查询展现，或导入至Mysql中使用。
数据生成方式：由明细层、轻度汇总层，数据集市层生成，一般要求数据主要来源于集市层。
日志存储方式：使用impala内表，parquet文件格式。
日志删除方式：长久存储。
表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名。库名：暂定apl，另外根据业务不同，不限定一定要一个库。
旧数据更新方式：直接覆盖

0x04 如何更优雅一些

前面提到的一种设计其实相对来讲已经很详细了，但是可能层次会有一点点多，而且在区分一张表到底该存放在什么位置的时候可能还有一点点疑惑。我们在这一章里再设计一套数据仓库的分层，同时在前面的基础上加上维表和一些临时表的考虑，来让我们的方案更优雅一些。

下图，做了一些小的改动，我们去掉了上一节的Buffer层，把数据集市层和轻度汇总层放在同一个层级上，同时独立出来了维表和临时表。

这里解释一下DWS、DWD、DIM和TMP的作用。

DWS：轻度汇总层，从ODS层中对用户的行为做一个初步的汇总，抽象出来一些通用的维度：时间、ip、id，并根据这些维度做一些统计值，比如用户每个时间段在不同登录ip购买的商品数等。这里做一层轻度的汇总会让计算更加的高效，在此基础上如果计算仅7天、30天、90天的行为的话会快很多。我们希望80%的业务都能通过我们的DWS层计算，而不是ODS。
DWD：这一层主要解决一些数据质量问题和数据的完整度问题。比如用户的资料信息来自于很多不同表，而且经常出现延迟丢数据等问题，为了方便各个使用方更好的使用数据，我们可以在这一层做一个屏蔽。
DIM：这一层比较单纯，举个例子就明白，比如国家代码和国家名、地理位置、中文名、国旗图片等信息就存在DIM层中。
TMP：每一层的计算都会有很多临时表，专设一个DWTMP层来存储我们数据仓库的临时表。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

0x05 问答

有读者问了一些问题，是我之前有一些没讲清楚，补到这里。

问：dws和dwd是并行而不是先后顺序？
答：并行的，dw层
问：那其实对于同一个数据，这两个过程是串行的？
答：dws 会做汇总，dwd和ods的粒度相同，这两层之间也没有依赖的关系
问：对呀，那这样dws里面的汇总没有经过数据质量和完整度的处理，或者单独做了这种质量相关的处理，为什么不在dwd之上再做汇总呢？我的疑问其实就是，dws的轻度汇总数据结果，有没有做数据质量的处理？

答：ods 之间到dws就好没必要过dwd，我举个例子，你的浏览商品行为，我做一层轻度汇总，就直接放在dws了。但是你的资料表，要从好多表凑成一份，我们从四五分个人资料表中凑出来了一份完整的资料表放在了dwd中。然后在app层，我们要出一张画像表，包含用户资料和用户近一年的行为，我们就直接从dwd中拿资料，然后再在dws的基础上做一层统计，就成一个app表了。