数据产品经理讲述:如何建立一套数据储备分析仓库

数据仓库的目的是构建面向分析的集成化数据环境,为企业提供决策支持(Decision-Support)。其实数据仓库本身并不“生产”任何数据,同时自身也不需要“消费”任何的数据,数据来源于外部,并且开放给外部应用,这也是为什么叫“仓库”,而不叫“工厂”的原因。因此数据仓库的基本架构主要包含的是数据流入流出的过程,可以分为三层——源数据数据仓库数据应用

从图中可以看出数据仓库的数据来源于不同的源数据,并提供多样的数据应用,数据自上而下流入数据仓库后向上层开放应用,而数据仓库只是中间集成化数据管理的一个平台。

数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL(抽取Extra, 转化Transfer, 装载Load)的过程,ETL是数据仓库的流水线,也可以认为是数据仓库的血液,它维系着数据仓库中数据的新陈代谢,而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。

下面主要简单介绍下数据仓库架构中的各个模块,当然这里所介绍的数据仓库主要是指网站数据仓库。

数据仓库的数据来源

其实之前的一篇文章已经介绍过数据仓库各种源数据的类型——数据仓库的源数据类型,所以这里不再详细介绍。

对于网站数据仓库而言,点击流日志是一块主要的数据来源,它是网站分析的基础数据;当然网站的数据库数据也并不可少,其记录这网站运营的数据及各种用户操作的结果,对于分析网站Outcome这类数据更加精准;其他是网站内外部可能产生的文档及其它各类对于公司决策有用的数据。

数据仓库的数据存储

源数据通过ETL的日常任务调度导出,并经过转换后以特性的形式存入数据仓库。其实这个过程一直有很大的争议,就是到底数据仓库需不需要储存细节数据,一方的观点是数据仓库面向分析,所以只要存储特定需求的多维分析模型;另一方的观点是数据仓库先要建立和维护细节数据,再根据需求聚合和处理细节数据生成特定的分析模型。我比较偏向后面一个观点:数据仓库并不需要储存所有的原始数据,但数据仓库需要储存细节数据,并且导入的数据必须经过整理和转换使其面向主题。简单地解释下:

(1).为什么不需要所有原始数据?数据仓库面向分析处理,但是某些源数据对于分析而言没有价值或者其可能产生的价值远低于储存这些数据所需要的数据仓库的实现和性能上的成本。比如我们知道用户的省份、城市足够,至于用户究竟住哪里可能只是物流商关心的事,或者用户在博客的评论内容可能只是文本挖掘会有需要,但将这些冗长的评论文本存在数据仓库就得不偿失;

(2).为什么要存细节数据?细节数据是必需的,数据仓库的分析需求会时刻变化,而有了细节数据就可以做到以不变应万变,但如果我们只存储根据某些需求搭建起来的数据模型,那么显然对于频繁变动的需求会手足无措;

(3).为什么要面向主题?面向主题是数据仓库的第一特性,主要是指合理地组织数据以方面实现分析。对于源数据而言,其数据组织形式是多样的,像点击流的数据格式是未经优化的,前台数据库的数据是基于OLTP操作组织优化的,这些可能都不适合分析,而整理成面向主题的组织形式才是真正地利于分析的,比如将点击流日志整理成页面(Page)、访问(Visit或Session)、用户(Visitor)三个主题,这样可以明显提升分析的效率。

数据仓库基于维护细节数据的基础上在对数据进行处理,使其真正地能够应用于分析。主要包括三个方面:

数据的聚合

这里的聚合数据指的是基于特定需求的简单聚合(基于多维数据的聚合体现在多维数据模型中),简单聚合可以是网站的总Pageviews、Visits、Unique Visitors等汇总数据,也可以是Avg. time on page、Avg. time on site等平均数据,这些数据可以直接地展示于报表上。

多维数据模型

多维数据模型提供了多角度多层次的分析应用,比如基于时间维、地域维等构建的销售星形模型、雪花模型,可以实现在各时间维度和地域维度的交叉查询,以及基于时间维和地域维的细分。所以多维数据模型的应用一般都是基于联机分析处理(Online Analytical Process, OLAP)的,而面向特定需求群体的数据集市也会基于多维数据模型进行构建。

业务模型

这里的业务模型指的是基于某些数据分析和决策支持而建立起来的数据模型,比如我之前介绍过的用户评价模型、关联推荐模型、RFM分析模型等,或者是决策支持的线性规划模型、库存模型等;同时,数据挖掘中前期数据的处理也可以在这里完成。

数据仓库的数据应用

之前的一篇文章——数据仓库的价值中介绍过数据仓库的四大特性上的价值体现,但数据仓库的价值远不止这样,而且其价值真正的体现是在数据仓库的数据应用上。图中罗列的几种应用并未包含所有,其实一切基于数据相关的扩展性应用都可以基于数据仓库来实现。

报表展示

报表几乎是每个数据仓库的必不可少的一类数据应用,将聚合数据和多维分析数据展示到报表,提供了最为简单和直观的数据。

即席查询

理论上数据仓库的所有数据(包括细节数据、聚合数据、多维数据和分析数据)都应该开放即席查询,即席查询提供了足够灵活的数据获取方式,用户可以根据自己的需要查询获取数据,并提供导出到Excel等外部文件的功能。

数据分析

数据分析大部分可以基于构建的业务模型展开,当然也可以使用聚合的数据进行趋势分析、比较分析、相关分析等,而多维数据模型提供了多维分析的数据基础;同时从细节数据中获取一些样本数据进行特定的分析也是较为常见的一种途径。

数据挖掘

数据挖掘用一些高级的算法可以让数据展现出各种令人惊讶的结果。数据挖掘可以基于数据仓库中已经构建起来的业务模型展开,但大多数时候数据挖掘会直接从细节数据上入手,而数据仓库为挖掘工具诸如SAS、SPSS等提供数据接口。

元数据管理

元数据(Meta Date),其实应该叫做解释性数据,即数据的数据。主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。一般会通过元数据资料库(Metadata Repository)来统一地存储和管理元数据,其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。

最后做个Ending,数据仓库本身既不生产数据也不消费数据,只是作为一个中间平台集成化地存储数据;数据仓库实现的难度在于整体架构的构建及ETL的设计,这也是日常管理维护中的重头;而数据仓库的真正价值体现在于基于其的数据应用上,如果没有有效的数据应用也就失去了构建数据仓库的意义。
VIA:网络

01 数据仓库的发展趋势

1.1 数据仓库的趋势

关于数据仓库的概念就不多介绍了。

数据仓库是伴随着企业信息化发展起来的,在企业信息化的过程中,随着信息化工具的升级和新工具的应用,数据量变得越来越大,数据格式越来越多,决策要求越来越苛刻,数据仓库技术也在不停的发展。

数据仓库的趋势:

  • 实时数据仓库以满足实时化&自动化决策需求
  • 大数据&数据可以支持大量&复杂数据类型

1.2 数据仓库的发展

数据仓库有两个环节:数据仓库的构建与数据仓库的应用。

早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中,其应用以报表为主,目的是支持管理层和业务人员决策(中长期策略性决策)。

随着业务和环境的发展,这两方面都在发生着剧烈变化。

随着IT技术走向互联网、移动化,数据源变得越来越丰富,在原来业务数据库的基础上出现了非结构化数据,比如网站 log,IoT 设备数据,APP 埋点数据等,这些数据量比以往结构化的数据大了几个量级,对 ETL 过程、存储都提出了更高的要求。

互联网的在线特性也将业务需求推向了实时化,随时根据当前客户行为而调整策略变得越来越常见,比如大促过程中库存管理,运营管理等(即既有中远期策略型,也有短期操作型);同时公司业务互联网化之后导致同时服务的客户剧增,有些情况人工难以完全处理,这就需要机器自动决策,比如欺诈检测和用户审核。

总结来看,对数据仓库的需求可以抽象成两方面:实时产生结果、处理和保存大量异构数据。

02 数据仓库架构的演变

从1990年 Inmon 提出数据仓库概念到今天,数据架构经历了最初的传统数仓架构——离线数仓库——离线大数据架构、Lambda 架构、Kappa 架构以及 Flink 的火热带出的流批一体架构,数据架构技术不断演进,本质是在往流批一体的方向发展,让用户能以最自然、最小的成本完成实时计算。

2.1 传统数仓架构

这是比较传统的一种方式,结构或半结构化数据通过离线ETL定期加载到离线数据,之后通过计算引擎取得结果,供前端使用。这里的离线数仓+计算引擎,通常是使用大型商业数据库来承担,例如Oracle、DB2、Teradata等。

2.2 离线大数据架构

随着数据规模的不断增大,传统数仓方式难以承载海量数据。随着大数据技术的普及,采用大数据技术来承载存储与计算任务。当然,也可以使用传传统数据库集群或MPP架构数据库来完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。

2.3 Lambda架构

随着业务的发展,随着业务的发展,人们对数据实时性提出了更高的要求。此时,出现了Lambda架构,其将对实时性要求高的部分拆分出来,增加条实时计算链路。从源头开始做流式改造,将数据发送到消息队列中,实时计算引擎消费队列数据,完成实时数据的增量计算。

与此同时,批量处理部分依然存在,实时与批量并行运行。最终由统一的数据服务层合并结果给予前端。一般是以批量处理结果为准,实时结果主要为快速响应。

2.4 Kappa架构

Lambda架构,一个比较严重的问题就是需要维护两套逻辑。一部分在批量引擎实现,一部分在流式引擎实现,维护成本很高。此外,对资源消耗也较大。而后面诞生的Kappa架构,正是为了解决上述问题。其在数据需要重新处理或数据变更时,可通过历史数据重新处理来完成。

方式是通过上游重放完成(从数据源拉取数据重新计算)。Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,但这个可以通过增加计算资源来弥补。

2.5混合架构

上述架构各有其适应场景,有时需要综合使用上述架构组合满足实际需求。当然这也必将带来架构的复杂度。用户应根据自身需求,有所取舍。在一般大多数场景下,是可以使用单一架构解决问题。现在很多产品在流批一体、海量、实时性方面也有非常好的表现,可以考虑这种“全能手”解决问题。

03 三种大数据数据仓库架构

3.1 离线大数据架构

数据源通过离线的方式导入到离线数据中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务,比如 MySQL 或 Redis。数据仓库从模型层面分为三层:

  • ODS,操作数据层,保存原始数据;
  • DWD,数据仓库明细层,根据主题定义好事实与维度表,保存最细粒度的事实数据;
  • DM,数据集市/轻度汇总层,在 DWD 层的基础之上根据不同的业务需求做轻度汇总;

典型的数仓存储是 HDFS/Hive,ETL 可以是 MapReduce 脚本或 HiveSQL。

3.2 Lambda 架构

Lambda 架构问题:

同样的需求需要开发两套一样的代码:这是 Lambda 架构最大的问题,两套代码不仅仅意味着开发困难(同样的需求,一个在批处理引擎上实现,一个在流处理引擎上实现,还要分别构造数据测试保证两者结果一致),后期维护更加困难,比如需求变更后需要分别更改两套代码,独立测试结果,且两个作业需要同步上线。

资源占用增多:同样的逻辑计算两次,整体资源占用会增多,多出实时计算这部分。

3.3 Kappa 架构

Lambda 架构虽然满足了实时的需求,但带来了更多的开发与运维工作,其架构背景是流处理引擎还不完善,流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现,流处理技术很成熟了,这是为了解决两套代码的问题,LickedIn 的 Jay Kreps 提出了 Kappa 架构。

Kappa 架构可以认为是 Lambda 架构的简化版(只要移除 lambda 架构中的批处理部分即可)。
在 Kappa 架构中,需求修改或历史数据重新处理都通过上游重放完成。
Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,但这个可以通过增加计算资源来弥补。

Kappa 架构的重新处理过程:

3.4 Lambda 架构与 Kappa 架构的对比


在真实的场景中,很多时候并不是完全规范的 Lambda 架构或 Kappa 架构,可以是两者的混合,比如大部分实时指标使用 Kappa 架构完成计算,少量关键指标(比如金额相关)使用 Lambda 架构用批处理重新计算,增加一次校对过程。

Kappa 架构并不是中间结果完全不落地,现在很多大数据系统都需要支持机器学习(离线训练),所以实时中间结果需要落地对应的存储引擎供机器学习使用,另外有时候还需要对明细数据查询,这种场景也需要把实时明细层写出到对应的引擎中。后面案例会涉及到。

04 实时数仓建设思路

  • 计算框架选型:storm/flink等实时计算框架,强烈推荐flink,其『批量合一』的特性及活跃的开源社区,有逐渐替代spark的趋势。
  • 数据存储选型:首要考虑查询效率,其次是插入、更新等问题,可选择apache druid,不过在数据更新上存在缺陷,选型时注意该问题频繁更新的数据建议不要采用该方案。当然存储这块需要具体问题具体分析,不同场景下hbase、redis等都是可选项。
  • 实时数仓分层:为更好的统一管理数据,实时数仓可采用离线数仓的数据模型进行分层处理,可以分为实时明细层写入druid等查询效率高的存储方便下游使用;轻度汇总层对数据进行汇总分析后供下游使用。
  • 数据流转方案:实时数仓的数据来源可以为kafka消息队列,这样可以做到队列中的数据即可以写入数据湖用于批量分析,也可以实时处理,下游可以写入数据集市供业务使。

05 菜鸟实时数仓案例

最后分享菜鸟仓配实时数据仓库的案例本,涉及全局设计、数据模型、数据保障等几个方面。

5.1 整体设计

整体设计如下图,基于业务系统的数据,数据模型采用中间层的设计理念,建设仓配实时数仓;计算引擎,选择更易用、性能表现更佳的实时计算作为主要的计算引擎;数据服务,选择天工数据服务中间件,避免直连数据库,且基于天工可以做到主备链路灵活配置秒级切换;数据应用,围绕大促全链路,从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度,建设仓配大促数据体系。

5.2 数据模型

不管是从计算成本,还是从易用性,还是从复用性,还是从一致性等等,都必须避免烟囱式的开发模式,而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致,将实时中间层分为两层。

  • 第一层 DWD 公共实时明细层。实时计算订阅业务数据消息队列,然后通过数据清洗、多数据源 join、流式数据与离线维度信息等的组合,将一些相同粒度的业务系统、维表中的维度属性全部关联到一起,增加数据易用性和复用性,得到最终的实时明细数据。这部分数据有两个分支,一部分直接落地到 ADS,供实时明细查询使用,一部分再发送到消息队列中,供下层计算使用。
  • 第二层 DWS 公共实时汇总层。以数据域+业务域的理念建设公共汇总层,与离线数仓不同的是,这里汇总层分为轻度汇总层和高度汇总层,并同时产出,轻度汇总层写入 ADS,用于前端产品复杂的 olap 查询场景,满足自助分析和产出报表的需求;高度汇总层写入 Hbase,用于前端比较简单的 kv 查询场景,提升查询性能,比如实时大屏等。

06 美团点评基于Flink的实时数仓平台实践

最底层是收集层,这一层负责收集用户的实时数据,包括 Binlog、后端服务日志以及 IoT 数据,经过日志收集团队和 DB 收集团队的处理,数据将会被收集到 Kafka 中。这些数据不只是参与实时计算,也会参与离线计算。

收集层之上是存储层,这一层除了使用 Kafka 做消息通道之外,还会基于 HDFS 做状态数据存储以及基于 HBase 做维度数据的存储。

存储层之上是引擎层,包括 Storm 和 Flink。实时计算平台会在引擎层为用户提供一些框架的封装以及公共包和组件的支持。

在引擎层之上就是平台层了,平台层从数据、任务和资源三个视角去管理。

架构的最上层是应用层,包括了实时数仓、机器学习、数据同步以及事件驱动应用等。

从功能角度来看,美团点评的实时计算平台主要包括作业和资源管理两个方面的功能。其中,作业部分包括作业配置、作业发布以及作业状态三个方面的功能。

  • 在作业配置方面,则包括作业设置、运行时设置以及拓扑结构设置;
  • 在作业发布方面,则包括版本管理、编译/发布/回滚等;
  • 作业状态则包括运行时状态、自定义指标和报警以及命令/运行时日志等。

在资源管理方面,则为用户提供了多租户资源隔离以及资源交付和部署的能力。

07 实时数仓与离线数仓的对比

在看过前面的案例之后,我们看一下实时数仓与离线数仓在几方面的对比:

  • 首先,从架构上,实时数仓与离线数仓有比较明显的区别,实时数仓以 Kappa 架构为主,而离线数仓以传统大数据架构为主。Lambda 架构可以认为是两者的中间态。
  • 其次,从建设方法上,实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论,产出事实宽表。另外实时数仓中实时流数据的 join 有隐藏时间语义,在建设中需注意。
  • 最后,从数据保障看,实时数仓因为要保证实时性,所以对数据量的变化较为敏感。在大促等场景下需要提前做好压测和主备保障工作,这是与离线数据的一个较为明显的区别。

综上,实时数仓主要解决数据时效性问题,结合机器学习框架可以处理实时推荐、实时获取广告投放效果等智能化业务场景。实时数仓的建设应早日提上日程,未来企业对数据时效性的要求会越来越高,实时数仓会很好的解决该问题。

 

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/4019.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息