前 言 写在前面 笔者先后在外企,互联网,金融行业工作,从最初的ODS,DM架构到后面ODS,DWD,DWS,ADS架构都有较深的理解和应用,甚至在相当长的时间内,数仓设计一直作为一个常规的面试题目,来考核各层级的数仓开发和架构师。然而在实际的沟通的交流中,发现很多同学虽然对同样的架构分层设计多多少少都能说出来一些,但是反过来再问为什么这样分层,答案就五花八门了。 这篇文章主要针对数仓设计来谈谈我的看法,因为不同的规模的公司对数仓建设的目的有差异,这里从架构师角度仅讨论中大型企业的数仓架构建设。本文主要以一问一答式来展开讨论。 1.为什么要建数仓? 这就要从数仓能解决的问题或者痛点来说,大型公司的业务相对复杂,随着公司业务的扩大,跨BU,跨BG的业务往来越来越多,而数据一般分散在各个部门,这样需要统一的平台来存储这样的跨系统的数据。此外,近年来分库分表等应用越来越多,仅通过传统关系型数据库做数据分析和挖掘已经不能满足要求。当然随着手机APP的大量使用,埋点等数据一般都以log日志方式存在,需要一个新的介质后者方案来解析这些数据,为了解决这个问题,数仓技术应运而生。 2.一般用数仓来做什么? 数仓一般分为实时和离线数仓,现在绝大多数公司采用的是lambda架构来统筹管理实时和离线数据,那么就有这样一个问题,数仓能干啥? 3.数仓分多少层比较合适 如果我给你一个具体的答案肯定会有各种不一致的意见,那么我换种方法来回答,也就是,根据你的需要来(不要打我)。 A.统一ODS层,这一层有一个关键字,是统一,也就是用通用的,全自动或者半自动化的技术来做,在oracle时代,构建ods层的目的除了把多个数据源做统一外,还有一个用途,就是把不同的codepage通过这一层来解析成统一的codepage,避免乱码。现在可选择的大数据同步技术也比较多,如datax,canal,kafka等。因为这一层的目的主要是把源系统的数据基本原样(有些数据敏感等级高不同步)的同步到大数据平台,因此比较容易进行方案的统一。因为是统一的工具来同步,所以清洗的功能较为有限,基于此,该层数据不建议直接对外暴露给到应用层。 B.dw层,这一层建设很有讲究,一般大的公司有公共IT部门,该部门会构建统一数仓,如主数据,如统一交易表,统一埋点 或者 标准维度表等。当然大一点的事业群或者事业部会构建自己的数仓层,有一些部门特有的业务数据。 C.集市层,这一层一个更直观的叫法是宽表层,为什么是宽表,主要是这一层存在的意义来决定的,前面提到这一层主要是为了解决某一类的分析问题,也就是面向分析,既然是面向分析,那么一般来讲是多个业务过程,而将多个业务过程融合成一个分析主题,势必会关联很多数据。宽表就是这样来的。在olap分析工具还不是很成熟的时候,仍然建议构建多维宽表,这样可以避免过多的模型间的关联操作。一般用于机器学习的特征宽表存在于这一层。集市层构建的好坏有一个比较好的衡量标准就是是否可以满足超过80%的应用层数据需要,剩下的20%来源于数仓层。 D.应用层,从名字来看,很显然这一层主要是面向应用的,面向应用的特点一般有以下几个特征,灵活多变,简单。灵活多变,也就是说业务需要各种形式或者各种自定义口径的数据,如KV结构的,各种条件来计算的。因此复用性较差,需要根据业务来调整和变更;简单,指的是数据一般是高度汇总的,如报表或者核心KPI指标,应用层的数据一般不建议大范围开放,不然其他用户搜索一个指标的时候,会有很多不同的口径,反而不利于数据使用。 4.有哪些让你眼前一亮的数仓设计方法? 数仓设计是有别于传统的业务系统的三范式设计方法的。这里暂时不讨论Inmon和Kimball两位大神设计理念的异同,只从实际工作中来讲。 a. 针对主数据,核心维度,是用缓慢变化维中的哪种设计方法。 b. 如何规避上游模型完成过晚问题? c. 维度过多,算不出来 d.数据变化过快 5.数仓设计的关键点有哪些? a.熟练掌握列转行和行转列,不展开 b.不是宽表越宽越好,仍然是看你所分析的领域用到的高度相关的数据是否放在一张表里了。大数据时代性能优化的终极方案就是把数据变小 c.开发脚本过程中,千万不要用select * ,除了开发者或许只有上帝知道*都代表了什么。 d.使用其他人数据前记得看别人的模型主键是什么,是否有重复记录,记住了这一条,可以避免绝大多数的数据倾斜 6. 实时数仓的方向? 实时数仓的应用领域越来越广,但并不是说上了实时数仓就能解决所有问题,很多时候离线数据也很好用,那么是否应该上实时数仓呢? 赠书环节
《数据仓库(原书第4版)》适合开发人员、管理人员、设计人员、数据管理员、数据库管理员,以及其他在现代数据处理环境中进行系统建造的人员阅读。另外,本书也很适用于学习信息处理技术的学生。 |
|
来自: 新用户16606013 > 《数据仓库建设》