数据仓库与ODS的区别,数据仓库和ODS并存方案

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据仓库与ODS的区别,数据仓库和ODS并存方案相关的知识,希望对你有一定的参考价值。

一直想整理一下这块内容,既然是漫谈,就想起什么说什么吧。我一直是在互联网行业,就以互联网行业来说。先大概列一下互联网行业数据仓库、数据平台的用途:

    整合公司所有业务数据,建立统一的数据中心;

    提供各种报表,有给高层的,有给各个业务的;

    为网站运营提供运营上的数据支持,就是通过数据,让运营及时了解网站和产品的运营效果;

    为各个业务提供线上或线下的数据支持,成为公司统一的数据交换与提供平台;

    分析用户行为数据,通过数据挖掘来降低投入成本,提高投入效果;比如广告定向精准投放、用户个性化推荐等;

    开发数据产品,直接或间接为公司盈利;

    建设开放数据平台,开放公司数据;

    。。。。。。


    上面列出的内容看上去和传统行业数据仓库用途差不多,并且都要求数据仓库/数据平台有很好的稳定性、可靠性;但在互联网行业,除了数据量大之外,越来越多的业务要求时效性,甚至很多是要求实时的 ,另外,互联网行业的业务变化非常快,不可能像传统行业一样,可以使用自顶向下的方法建立数据仓库,一劳永逸,它要求新的业务很快能融入数据仓库中来,老的下线的业务,能很方便的从现有的数据仓库中下线;


    其实,互联网行业的数据仓库就是所谓的敏捷数据仓库,不但要求能快速的响应数据,也要求能快速的响应业务;


    建设敏捷数据仓库,除了对架构技术上的要求之外,还有一个很重要的方面,就是数据建模,如果一上来就想着建立一套能兼容所有数据和业务的数据模型,那就又回到传统数据仓库的建设上了,很难满足对业务变化的快速响应。应对这种情况,一般是先将核心的持久化的业务进行深度建模(比如:基于网站日志建立的网站统计分析模型和用户浏览轨迹模型;基于公司核心用户数据建立的用户模型),其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。


    整体架构下面的图是我们目前使用的数据平台架构图,其实大多公司应该都差不多:


    请点击输入图片描述

    逻辑上,一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同,本质上的角色都大同小异。


    我们从下往上看:


    数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上,期间有可能会做一些简单的清洗。



    数据源的种类比较多:


    网站日志:


    作为互联网行业,网站日志占的份额最大,网站日志存储在多台网站日志服务器上,


    一般是在每台网站日志服务器上部署flume agent,实时的收集网站日志并存储到HDFS上;


    业务数据库:


    业务数据库的种类也是多种多样,有mysql、Oracle、SqlServer等,这时候,我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具,Sqoop是一种,但是Sqoop太过繁重,而且不管数据量大小,都需要启动MapReduce来执行,而且需要Hadoop集群的每台机器都能访问业务数据库;应对此场景,淘宝开源的DataX,是一个很好的解决方案(可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》),有资源的话,可以基于DataX之上做二次开发,就能非常好的解决,我们目前使用的DataHub也是。


    当然,Flume通过配置与开发,也可以实时的从数据库中同步数据到HDFS。


    来自于Ftp/Http的数据源:


    有可能一些合作伙伴提供的数据,需要通过Ftp/Http等定时获取,DataX也可以满足该需求;


    其他数据源:


    比如一些手工录入的数据,只需要提供一个接口或小程序,即可完成;



    数据存储与分析毋庸置疑,HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。



    离线数据分析与计算,也就是对实时性要求不高的部分,在我看来,Hive还是首当其冲的选择,丰富的数据类型、内置函数;压缩比非常高的ORC文件存储格式;非常方便的SQL支持,使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多,一句SQL可以完成的需求,开发MR可能需要上百行代码;


    当然,使用Hadoop框架自然而然也提供了MapReduce接口,如果真的很乐意开发Java,或者对SQL不熟,那么也可以使用MapReduce来做分析与计算;Spark是这两年非常火的,经过实践,它的性能的确比MapReduce要好很多,而且和Hive、Yarn结合的越来越好,因此,必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn,使用Spark其实是非常容易的,不用单独部署Spark集群,关于Spark On Yarn的相关文章,可参考:《Spark On Yarn系列文章》


    实时计算部分,后面单独说。


    数据共享这里的数据共享,其实指的是前面数据分析与计算后的结果存放的地方,其实就是关系型数据库和NOSQL数据库;



    前面使用Hive、MR、Spark、SparkSQL分析和计算的结果,还是在HDFS上,但大多业务和应用不可能直接从HDFS上获取数据,那么就需要一个数据共享的地方,使得各业务和产品能方便的获取数据; 和数据采集层到HDFS刚好相反,这里需要一个从HDFS将数据同步至其他目标数据源的工具,同样,DataX也可以满足。


    另外,一些实时计算的结果数据可能由实时计算模块直接写入数据共享。



    数据应用

    业务产品


    业务产品所使用的数据,已经存在于数据共享层,他们直接从数据共享层访问即可;


    报表


    同业务产品,报表所使用的数据,一般也是已经统计汇总好的,存放于数据共享层;


    即席查询


    即席查询的用户有很多,有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大,他们都有即席查询数据的需求;


    这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求,需要从数据存储层直接查询。


    即席查询一般是通过SQL完成,最大的难度在于响应速度上,使用Hive有点慢,目前我的解决方案是SparkSQL,它的响应速度较Hive快很多,而且能很好的与Hive兼容。


    当然,你也可以使用Impala,如果不在乎平台中再多一个框架的话。


    OLAP


    目前,很多的OLAP工具不能很好的支持从HDFS上直接获取数据,都是通过将需要的数据同步到关系型数据库中做OLAP,但如果数据量巨大的话,关系型数据库显然不行;


    这时候,需要做相应的开发,从HDFS或者HBase中获取数据,完成OLAP的功能;


    比如:根据用户在界面上选择的不定的维度和指标,通过开发接口,从HBase中获取数据来展示。


    其它数据接口


    这种接口有通用的,有定制的。比如:一个从Redis中获取用户属性的接口是通用的,所有的业务都可以调用这个接口来获取用户属性。



    实时计算现在业务对数据仓库实时性的需求越来越多,比如:实时的了解网站的整体流量;实时的获取一个广告的曝光和点击;在海量数据下,依靠传统数据库和传统实现方法基本完成不了,需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架;Storm在这块是比较成熟了,但我选择Spark Streaming,原因很简单,不想多引入一个框架到平台中,另外,Spark Streaming比Storm延时性高那么一点点,那对于我们的需要可以忽略。


    我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。


    做法也很简单,由Flume在前端日志服务器上收集网站日志和广告日志,实时的发送给Spark Streaming,由Spark Streaming完成统计,将数据存储至Redis,业务通过访问Redis实时获取。


    任务调度与监控在数据仓库/数据平台中,有各种各样非常多的程序和任务,比如:数据采集任务、数据同步任务、数据分析任务等;



    这些任务除了定时调度,还存在非常复杂的任务依赖关系,比如:数据分析任务必须等相应的数据采集任务完成后才能开始;数据同步任务需要等数据分析任务完成后才能开始; 这就需要一个非常完善的任务调度与监控系统,它作为数据仓库/数据平台的中枢,负责调度和监控所有任务的分配与运行。


    前面有写过文章,《大数据平台中的任务调度与监控》,这里不再累赘。


    总结在我看来架构并不是技术越多越新越好,而是在可以满足需求的情况下,越简单越稳定越好。目前在我们的数据平台中,开发更多的是关注业务,而不是技术,他们把业务和需求搞清楚了,基本上只需要做简单的SQL开发,然后配置到调度系统就可以了,如果任务异常,会收到告警。这样,可以使更多的资源专注于业务之上。

    请点击输入图片描述

    请点击输入图片描述

参考技术A

DW

数据仓库存储是一个面向主题的,反映历史变化数据,用于支撑管理决策。

ODS

操作型数据存储,存储的是当前的数据情况,给使用者提供当前的状态,提供即时性的、操作性的、集成的全体信息的需求。

ODS作为数据库到数据仓库的一种过渡形式,与数据仓库在物理结构上不同,能提供高性能的响应时间,ODS设计采用混合设计方式。

ODS中的数据是"实时值",而数据仓库的数据却是"历史值",一般ODS中储存的数据不超过一个月,而数据仓库为10年或更多.

数据仓库和ODS并存方案

经过调研,发现大体上有三种解法:

1、业务数据 - ODS - 数据仓库

优点:这样做的好处是ODS的数据与数据仓库的数据高度统一;开发成本低,至少开发一次并应用到ODS即可;可见ODS是发挥承上启下的作用,调研阿里巴巴的数据部门也是这么实现的。

缺点:数据仓库需要的所有数据都需要走ODS,那么ODS的灵活性必然受到影响,甚至不利于扩展、系统的灵活性差

2、OB - ODS

优点:结构简单。一般的初创数据分析团队都是类似的结构,比如我们部门就应该归结到这一范畴

缺点:这样所有数据都归结到ODS,长期数据决策分析能力差,软硬件成本高,模块划分不清晰,通用性差

3、数据仓库和ODS并行

可见这个模型兼顾了上面提高的各自优点,且便于扩展,ODS和数据仓库各做各的,形成优势互补!可以解决现在互联网公司遇到的快速变化、快速开发等特点!特别是对于那些刚刚创建数据团队,数据开发人员紧缺的公司,可以尝试使用这个数据架构解决问题!

什么是ODS?还有什么是事实表和维度表啊?希望高手指教~

最近在实习,经常听老员工在说什么ODS,还有事实表和维度表,希望哪个高手可以给我解释下?

ODS全称为Operational Data Store,即操作型数据存储,是“面向主题的、集成的、可变的、反映当前数据值的和详细的数据的集合,用来满足企业综合的、集成的以及操作型的处理需求”(Bill.Inmon)。ODS是数据仓库体系结构中的一个可选部分,ODS具备数据仓库的部分特征和OLTP系统的部分特征。
事实表就是按某个分析领域组合的数据表
纬度表则是这个领域上的分析指标的组合表

解释2:

简单点说;
事实表就是交易表。
维度表就是基础表。
用来解释事实表中关键字纬度的具体内容。

解释3:

事实数据表
数据仓库架构中的中央表,它包含联系事实与维度表的数字度量值和键。事实数据表包含描述业务(如银行事务或产品销售)内特定事件的数据。

维度表
数据仓库中的表,其条目描述事实数据表中的数据。维度表包含创建维度所基于的数据。

再举个实际的例子。银行对存款记账,A表中存放实际数据,包括账号、所属机构号、存款金额等,B表存放机构号和机构名称的对应关系。则A是事实表,B是维表。

事实表
每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据,如现金登记事务
所产生的数据,事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据(事实),并且这些数字信息可以汇总,以提供有关单位作为历史的数据,每个事实数据表包含一个由多个部分组成的索引,该索引包含作为外键的相关性纬度表的主键,而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息,也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。
包含在事实数据表中的“度量值”有两中:一种是可以累计的度量值,另一种是非累计的度量值。最有用的度量值是可累计的度量值,其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息,例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表,单汇总结果一般是没有意义的,例如,在一座大厦的不同位置测量温度时,如果将大厦中所有不同位置的温度累加是没有意义的,但是求平均值是有意义的。
一般来说,一个事实数据表都要和一个或多个纬度表相关联,用户在利用事实数据表创建多维数据集时,可以使用一个或多个维度表。
维度表
维度表可以看作是用户来分析数据的窗口,纬度表中包含事实数据表中事实记录的特性,有些特性提供描述性信息,有些特性指定如何汇总事实数据表数据,以便为分析者提供有用的信息,维度表包含帮助汇总数据的特性的层次结构。例如,包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构,这些产品中的每一类进一步多次细分,直到各产品达到最低级别。
在维度表中,每个表都包含独立于其他维度表的事实特性,例如,客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。
参考技术A ODS全称为Operational Data Store,即操作型数据存储,是“面向主题的、集成的、可变的、反映当前数据值的和详细的数据的集合,用来满足企业综合的、集成的以及操作型的处理需求”(Bill.Inmon)。ODS是数据仓库体系结构中的一个可选部分,ODS具备数据仓库的部分特征和OLTP系统的部分特征。

事实数据表
数据仓库架构中的中央表,它包含联系事实与维度表的数字度量值和键。事实数据表包含描述业务(如银行事务或产品销售)内特定事件的数据。

维度表
数据仓库中的表,其条目描述事实数据表中的数据。维度表包含创建维度所基于的数据。

举个实际的例子:银行对存款记账,A表中存放实际数据,包括账号、所属机构号、存款金额等,B表存放机构号和机构名称的对应关系。则A是事实表,B是维表。
参考技术B CFCs,化学名称氯氟烃,商业名称氟利昂,以前大量用于冰箱空调制冷剂、有机溶剂、气雾剂等。化学性质很稳定,进入空气后会累积,消耗大气层中的臭氧,形成臭氧层空洞,加速温室效应。进入21世纪,全球的冰箱空调生产商禁用氟利昂。
ODS是消耗臭氧层物质。《关于消耗臭氧层物质的蒙特利尔议定书》规定要淘汰的ODS物质中,在我国生产和消费的ODS包括六类94种,这六类物质是:CFCs、哈龙、四氯化碳、1,1,1-三氯乙烷、HCFC和甲基溴。 在94种ODS中,我国目前主要生产和使用的有10种,它们是:CFC-11、CFC-12、CFC-113、哈龙-1211、哈龙-1301、四氯化碳、1,1,1-三氯乙烷、HCFC-22、HCFC-141b和甲基溴。其余的ODS在我国的生产量和消费量很小。
这里有详细的解答

以上是关于数据仓库与ODS的区别,数据仓库和ODS并存方案的主要内容,如果未能解决你的问题,请参考以下文章

ODS与数据仓库的区别

数据仓库与ODS

DW数据仓库与ODS的区别

ODS与数据仓库的区别

ODS与数据仓库的区别

数据仓库 业务数仓 ODS层