从入门到进阶实时架构,数据仓库的那些事,不知道的快来看看

每个人对于数仓的理解,都源自于大数据,而大数据又源自于那个神奇的故事:从前有一家超市,它有一个怪现象,尿布和啤酒赫然摆在一起出售。外行人不明所以,但内行人却看到了尿布和啤酒的销量双双增加。

为什么呢?正是因为大数据发挥了它最原始的作用:组合分析。

妇女们经常会嘱咐她们的丈夫下班以后要为孩子买尿布,而丈夫在买完尿布之后又要顺手买回自己爱喝的啤酒,因此啤酒和尿布在一起购买的机会还是很多的。这就是大数据最初的魔力。

数据仓库已经是一个非常成熟稳定的模型了:

业务数据仓库,数据仓库分层,数据仓库技术架构

这个模型有六个阶段:孕育期、婴儿期、儿童期、少年期、成人期、长者期。

孕育期:打印基本的报表,交给各个部门的员工来手工填写;

婴儿期:用Excel完成基本的数据组织与统计

儿童期:能够部署独立的应用程序,来满足单个部门的需求;

少年期:形成了基本的数仓概念,并引入了数据的定义、规则、维度标准化等概念;

成人期:搭建企业级数据仓库,并通过整合的数据来支持一些关键业务的驱动;

长者期:BI的概念形成,数仓建设非常规范。

(此处已添加小程序,请到今日头条客户端查看)

当然,由于中国过早的进入了互联网和移动互联网时代,并没有经历过软件时代的相关历程,因此数仓的概念从一开始就与大数据紧紧的绑定在了一起,成为了每个互联网公司的标配部门。

如果你是一名数据开发的同学,出去面试,基本都会被问到一个问题:“如果是你来负责数据仓库建设,你会考虑如何来建设好数据仓库?”这个问题通常是考察候选人的架构设计水平的,看你对于业务有多深入的了解。

大部分人的回答都是偏技术层面的,通常会说出一个比较完整的数据分层模型,但仅仅分层清晰就足够了吗?不一定。

我们先看一下通常的数据仓库分层模型:

业务数据仓库,数据仓库分层,数据仓库技术架构

数据逻辑通常按照下图进行分层:

业务数据仓库,数据仓库分层,数据仓库技术架构

到这里为止,如何建设好一个数据仓库的概念,就基本解释清楚了,这也是一名从业3年的数据人应该有的基本能力。但是,这也仅仅是技术层面的总结,解决了工程上的“能不能实现”,但“能不能有用”,就是另外一个话题了。

数据仓库是不是有用,要看它能做什么。通常而言,数据仓库要解决业务的问题,为业务的发展提供决策依据和运营参考,换句话说,数据仓库要与业务有强绑定的关系

如果一个数据仓库只能把数据接入进来,做好分层,但不知道给谁用,那么这个数据仓库通常就是没有价值的,在你做部门汇报的时候,会被大佬疯狂diss。那么业务会怎么用数据?通常而言,还是从数仓的概念出发,我们给出三个很具体的用途:

第一个用途是集成:对于互联网公司来说,数据通常十分的零散,例如数据库日志在运维手里、广告数据在广告团队那里、业务数据在后端那里,产品同学在全局角度上设计了一些好的产品或者功能,需要综合各方面的情况,来看这个产品或者功能是否有用,那么数据仓库就是他们唯一的选择

从技术层面说,决策支持需求通常是全局的、关联的,必须将数据整合到一个地方才能方便统计分析和挖掘。从数据处理层面说,不同的数据格式不一样,有的是关系型的数据表,有的是本结构化的日志,有的数据还以多媒体的形式存在,也需要将数据转化成相对统一的格式。

在集成的层面上,我们就需要强调不同开源框架的作用与相互配合了。自底向上,与OSI类似,通用框架下的大数据体系有七层:数据源、数据收集层、数据存储层、资源管理与服务协调层、计算引擎层、数据分析层及数据可视化层

第二个用途是面向主题:我们把四面八方的数据都拿到了,那怎样组织这些数据呢?换句话说,产品丢了一个又一个的需求过来,我们通过怎样的方式,能够尽快消灭掉这些需求嗯?通常而言,这里就要引入两个很重要的概念:建模、域。

在数据仓库领域,经常会听到两个名字,Bill Inmon与Ralph Kimball。Inmon最早提出数据仓库的概念,在构建数据仓库过程中,主张自顶向下的设计,先设计好数仓的整体架构,然后进行局部设计,而Kimball正好相反,主张自底向上设计,先根据各个业务主题进行设计,然后通过维度模型将数据仓库整合起来。

下图为Inmon构建过程示例:

业务数据仓库,数据仓库分层,数据仓库技术架构

下图为Kimball维度建模示例:

业务数据仓库,数据仓库分层,数据仓库技术架构

域的概念,简单来说就是主题,是业务方向的统称。为什么要按主题来组织?因为数据仓库是分析型的数据集合,我们分析的出发点通常是业务实体,分析的目的就是要了解业务实体的各种行为状态、了解每个业务的效果

通过将相对固定的业务领域,按照一定的抽象规则进行归纳,便可以形成相对独立的信息模型

通常而言,我们会在公共层,也就是DWS层进行数据域的划分,在某些已成熟单一主体业务按照这样来做比较好,比如像金融,安全等领域,通过对主体业务内的数据进行抽象分类,进行精细化的管理。

但是,当业务领域过多时,会将数据管理复杂化,在当前业务快速响应的时代,基于业务+数据域的划分或许是更好的一种管理方式,它没有对原有的业务重新归纳,基于非直接业务数据也从横向整体通盘进行考虑。如下图所说:

业务数据仓库,数据仓库分层,数据仓库技术架构

第三个用途是反应历史变化:可能很多业务场景并不涉及到历史变化,但一旦涉及到了,就绝不是一件简单的事情,尤其是在电商领域。可以说,历史变化是一个将纵向比对横向的过程,只有对比历史才能发掘目前数据的价值

所以,数据仓库有一个很重要的使命,就是保存历史数据的状态,免得产品同学挖出了一个坑后,你无从下手排查……

但是,历史数据的保存是有成本的,如果不加区分全量保存,会对存储系统产生非常大的压力,很快Hadoop集群就是各种90%、各种疯狂报警了。那么我们如何组织和整理历史变化数据呢?通常而言,这里就是拉链表、快照事实表等概念了。

下图是快照事实表的说明:

业务数据仓库,数据仓库分层,数据仓库技术架构

业务数据仓库,数据仓库分层,数据仓库技术架构

下图是拉链表的说明:

业务数据仓库,数据仓库分层,数据仓库技术架构

即便我们进阶了很多,既有技术支撑,也有方法论铺垫之后,还是会面对一个现实的问题:工作内容没有价值。大家其实能说出很多很多的原因,比如下面这些:

1.工作职责划分不明确,把数据分析当作报表开发,怎么体现价值?

2.需求一个接一个做不完,产品不把分析当合作伙伴,就是工具!

3.分析师没有主动权,只能被动接需求,需求是谁提的,谁的成果和价值才高!

对于不同的角色,能做的事情是很不同的:

1.对于一名执行者,小兵,没什么可说的,老老实实把自己的专业度提升到自己的巅峰,你的专业度才是你的立身之本,这都没有,那你有什么用?老大争取来了项目,你能完成吗?

2.对于一名团队的骨干,要学会去帮助老大发掘有价值的项目和好的切入点,去推动,去协调。你具备的不只是专业技能,更多的是一名职业人的职业性。

3.对于团队的老大,要学会共赢,一定要能够把大老板的路子打通,有一个至多个业务方的盟友。互联网很多Leader都是从技术转过来的,这时候要学会转变思维,不要总感觉自己是一名顶尖的工程师。

在整个实时数仓的建设中,业界已经有了常用的方案选型。整体架构设计通过分层设计为OLAP查询分担压力,让出计算空间,复杂的计算统一在实时计算层处理掉,避免给OLAP查询带来过大的压力

汇总计算交给OLAP数据库进行。因此,在整个架构中实时计算一般是Spark+Flink配合,消息队列Kafka一家独大,在整个大数据领域消息队列的应用中仍然处于垄断地位,Hbase、Redis和MySQL都在特定场景下有一席之地。

目前还没有一个OLAP系统能够满足各种场景的查询需求。其本质原因是,没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美,每个系统在设计时都需要在这三者间做出取舍。

从长远看,Spark和Flink更有可能成为下一代的Hadoop,值得投入大量时间学习

但这一切都要基于一个好用的数据可视化平台。现在市面上流行的有FineBI、Power BI、DataV、鼎数,但权威机构IDC指出市场占有率第1的还是FineBI,这些都可以做数据分析

原创文章,作者:Maggie-Hunter,如若转载,请注明出处:https://blog.ytso.com/173376.html

(0)
上一篇 2021年9月28日
下一篇 2021年9月28日

相关推荐

发表回复

登录后才能评论