数据分层_数据仓库分层 - CSDN
精华内容
参与话题
  • 什么是数据分层,数据分层的作用!

    千次阅读 2020-05-15 15:31:46
    大数据环境下该如何优雅地设计数据分层 0x00 前言 最近出现了好几次同样的对话场景: 问:你是做什么的? 答:最近在搞数据仓库。 问:哦,你是传统行业的吧,我是搞大数据的。 答:...... 发个牢骚,搞大数据的也...

    大数据环境下该如何优雅地设计数据分层

    0x00 前言

    最近出现了好几次同样的对话场景:
    问:你是做什么的?
    答:最近在搞数据仓库。
    问:哦,你是传统行业的吧,我是搞大数据的。
    答:......

    发个牢骚,搞大数据的也得建设数据仓库吧。而且不管是传统行业还是现在的互联网公司,都需要对数据仓库有一定的重视,而不是谈一句自己是搞大数据的就很厉害了。数据仓库更多代表的是一种对数据的管理和使用的方式,它是一整套包括了etl、调度、建模在内的完整的理论体系。现在所谓的大数据更多的是一种数据量级的增大和工具的上的更新。 两者并无冲突,相反,而是一种更好的结合。

    话说,单纯用用Hadoop、Spark、Flume处理处理数据,其实只是学会几种新的工具,这是搞工具的,只是在数据仓库中etl中的一部分。

    当然,技术的更新往往能领到一个时代的变革,比如Hadoop的诞生,光是深入研究一个大数据组件就要花很大的时间和精力。但是在热潮冷却之后,我们更应该考虑地是如何更好地管理和使用自己的数据。

    对于数据的从业者来讲,要始终重视紧跟技术的变革,但是切记数据为王,在追求技术的极致的时候,不要忘了我们是搞数据的。

    文章主题

    吐槽完毕,本文主要讲解数据仓库的一个重要环节:如何设计数据分层!,其它关于数据仓库的内容可参考其它的文章数据仓库

    本文对数据分层的讨论适合下面一些场景,超过该范围场景 or 数据仓库经验丰富的大神就不必浪费时间看了。

    • 数据建设刚起步,大部分的数据经过粗暴的数据接入后就直接对接业务。
    • 数据建设发展到一定阶段,发现数据的使用杂乱无章,各种业务都是从原始数据直接计算而得。
    • 各种重复计算,严重浪费了计算资源,需要优化性能。

    文章结构

    最初在做数据仓库的时候遇到了很多坑,由于自身资源有限,接触数据仓库的时候,感觉在互联网行业里面的数据仓库成功经验很少,网上很难找到比较实践性强的资料。而那几本经典书籍里面又过于理论,折腾起来真是生不如死。还好现在过去了那个坎,因此多花一些时间整理自己的思路,帮助其他的小伙伴少踩一些坑。

    1. 为什么要分层?这个问题被好几个同学质疑过。因此分层的价值还是要说清楚的。
    2. 分享一下经典的数据分层模型,以及每一层的数据的作用和如何加工得来。
    3. 分享两个数据分层的设计,通过这两个实际的例子来说明每一层该怎么存数据。
    4. 给出一些建议,不是最好的,但是可以做参考。

    0x01 为什么要分层

    我们对数据进行分层的一个主要原因就是希望在管理数据的时候,能对数据有一个更加清晰的掌控,详细来讲,主要有下面几个原因:

    1. 清晰数据结构:每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。
    2. 数据血缘追踪:简单来讲可以这样理解,我们最终给业务诚信的是一能直接使用的张业务表,但是它的来源有很多,如果有一张来源表出问题了,我们希望能够快速准确地定位到问题,并清楚它的危害范围。
    3. 减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。
    4. 把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。而且便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复。
    5. 屏蔽原始数据的异常。
    6. 屏蔽业务的影响,不必改一次业务就需要重新接入数据。

    数据体系中的各个表的依赖就像是电线的流向一样,我们都希望它是很规整,便于管理的。但是,最终的结果大多是第一幅图,而非第二幅图。

    0x02 怎样分层

    理论

    我们从理论上来做一个抽象,可以把数据仓库分为下面三个层,即:数据运营层、数据仓库层和数据产品层。

    1. ODS全称是Operational Data Store,操作数据存储

    “面向主题的”,数据运营层,也叫ODS层,是最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说传说中的ETL之后,装入本层。本层的数据,总体上大多是按照源头业务系统的分类方式而分类的。

    例如这一层可能包含的数据表为:人口表(包含每个人的身份证号、姓名、住址等)、机场登机记录(包含乘机人身份证号、航班号、乘机日期、起飞城市等)、银联的刷卡信息表(包含银行卡号、刷卡地点、刷卡时间、刷卡金额等)、银行账户表(包含银行卡号、持卡人身份证号等)等等一系列原始的业务数据。这里我们可以看到,这一层面的数据还具有鲜明的业务数据库的特征,甚至还具有一定的关系数据库中的数据范式的组织形式。

    但是,这一层面的数据却不等同于原始数据。在源数据装入这一层时,要进行诸如去噪(例如去掉明显偏离正常水平的银行刷卡信息)、去重(例如银行账户信息、公安局人口信息中均含有人的姓名,但是只保留一份即可)、提脏(例如有的人的银行卡被盗刷,在十分钟内同时有两笔分别在中国和日本的刷卡信息,这便是脏数据)、业务提取、单位统一、砍字段(例如用于支撑前端系统工作,但是在数据挖掘中不需要的字段)、业务判别等多项工作。

    2. 数据仓库层(DW),是数据仓库的主体

    在这里,从ODS层中获得的数据按照主题建立各种数据模型。例如以研究人的旅游消费为主题的数据集中,便可以结合航空公司的登机出行信息,以及银联系统的刷卡记录,进行结合分析,产生数据集。在这里,我们需要了解四个概念:维(dimension)、事实(Fact)、指标(Index)和粒度( Granularity)。

    3. 数据产品层(APP),这一层是提供为数据产品使用的结果数据

    在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在es、mysql等系统中供线上系统使用,也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。
    比如我们经常说的报表数据,或者说那种大宽表,一般就放在这里。

    技术实践

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

    1. 数据来源层--> ODS层

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

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

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

    2. ODS、DW --> App层

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

    1. 每日定时任务型:比如我们典型的日计算任务,每天凌晨算前一天的数据,早上起来看报表。 这种任务经常使用Hive、Spark或者生撸MR程序来计算,最终结果写入Hive、Hbase、Mysql、Es或者Redis中。
    2. 实时数据:这部分主要是各种实时的系统使用,比如我们的实时推荐、实时用户画像,一般我们会用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表了。

    问:嗯,最后一个疑问,在现实生产中,可不可能存在计算dws时,会用到dwd表的情况?

    答:不 这样依赖就混了,dws不会依赖dwd,dws直接轻度汇总,业务用的话都说app。

    问:就是说,dwd针对的是对象,它的数据质量处理有点像对用户等等的实体信息的纠错和汇总;dws针对的是行为,可以在某些维度上上卷的行为~

    答:你这样理解吧 dws存事实表,dwd 维度表。

    0xFF 总结

    数据分层是数据仓库非常重要的一个环节,它决定的不仅仅是一个层次的问题,还直接影响到后续的血缘分析、特征自动生成、元数据管理等一系列的建设。因此适于尽早考虑。

    另外,每一层的名字不必太过在意,自己按照喜好就好。

    本文分享了笔者自己对数据仓库的一些理解和想法,不一定十分准确,有什么问题可以多交流。

    初步估计在数据仓库方面,应该还会有三个主题分享:血缘分析、特征自动生成、元数据管理。分享完成之后,数据仓库相关的就告一段落了。

    参考

     

    展开全文
  • 数据仓库各层说明: 一、数据加载层:ETL(Extract-Transform-Load) 二、数据运营层:ODS(Operational Data Store) 三、数据仓库层:DW(Data Warehouse) 1. 数据明细层:DWD(Data Warehouse ...

    参考:

    https://www.cnblogs.com/itboys/p/10592871.html 数据仓库--通用的数据仓库分层方法

     

    数据仓库各层说明:

    一、数据加载层:ETL(Extract-Transform-Load)

    二、数据运营层:ODS(Operational Data Store)

    三、数据仓库层:DW(Data Warehouse)

    1. 数据明细层:DWD(Data Warehouse Detail)

    2. 数据中间层:DWM(Data WareHouse Middle)

    3. 数据服务层:DWS(Data WareHouse Service)

    四、数据应用层:APP(Application)

    五、维表层:DIM(Dimension)

    分层好处

    清晰数据结构:每一个数据分层都有它的作用域和职责,在使用表的时候能更方便地定位和理解

    减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算

    统一数据口径:通过数据分层,提供统一的数据出口,统一对外输出的数据口径

    复杂问题简单化:将复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。当数据出现问题之后,不用修复所有的数据,只需要从有问题的步骤开始修复。

    屏蔽原始数据的异常:不必改一次业务就需要重新接入数据。

     

    我们将数据模型分为三层:数据运营层( ODS )、数据仓库层(DW)和数据应用层(APP):

    ODS层存放的是接入的原始数据,DW层是存放我们要重点设计的数据仓库中间层数据,APP是面向业务定制的应用数据。

    一、数据运营层:ODS(Operational Data Store)
    “面向主题的”数据运营层,也叫ODS层,是最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说传说中的 ETL 之后,装入本层。本层的数据,总体上大多是按照源头业务系统的分类方式而分类的。

    一般来讲,为了考虑后续可能需要追溯数据问题,因此对于这一层就不建议做过多的数据清洗工作,原封不动地接入原始数据即可,至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。

    二、数据仓库层:DW(Data Warehouse)
    数据仓库层是我们在做数据仓库时要核心设计的一层,在这里,从 ODS 层中获得的数据按照主题建立各种数据模型。DW层又细分为 DWD(Data Warehouse Detail)层、DWM(Data WareHouse Middle)层和DWS(Data WareHouse Servce)层。

    1. 数据明细层:DWD(Data Warehouse Detail)

    该层一般保持和ODS层一样的数据粒度,并且提供一定的数据质量保证。同时,为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联。

    另外,在该层也会做一部分的数据聚合,将相同主题的数据汇集到一张表中,提高数据的可用性,后文会举例说明。

    2. 数据中间层:DWM(Data WareHouse Middle)

    该层会在DWD层的数据基础上,对数据做轻度的聚合操作生成一系列的中间表,提升公共指标的复用性,减少重复加工。

    直观来讲,就是对通用的核心维度进行聚合操作,算出相应的统计指标。

    3. 数据服务层:DWS(Data WareHouse Servce)

    又称数据集市或宽表。按照业务划分,如流量、订单、用户等,生成字段比较多的宽表用于提供后续的业务查询,OLAP分析,数据分发等。

    一般来讲,该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表。

    在实际计算中,如果直接从DWD或者ODS计算出宽表的统计指标,会存在计算量太大并且维度太少的问题,因此一般的做法是,在DWM层先计算出多个小的中间表,然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定,也可以去掉DWM这一层,只留DWS层,将所有的数据在放在DWS亦可。

    三、数据应用层:APP(Application)
    在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据,一般就放在这里。

    四、维表层(Dimension)
    最后补充一个维表层,维表层主要包含两部分数据:

    高基数维度数据:一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

    低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表。数据量可能是个位数或者几千几万。

    至此,我们讲完了数据分层设计中每一层的含义,这里做一个总结便于理解,如下图。

    主题(Subject)是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念,每一个主题基本对应一个宏观的分析领域。在逻辑意义上,它是对应企业中某一宏观分析领域所涉及的分析对象。例如“销售分析”就是一个分析领域,因此这个数据仓库应用的主题就是“销售分析”。

     

    各层示例应用说明:

    如下图,可以认为是一个电商网站的数据体系设计。我们暂且只关注用户访问日志这一部分数据。

    按业务分类汇总数据源,ODS层不同来源的日志文件汇总成一张表,保存到DWD层

    DWD层中选取业务关注的核心维度来做聚合操作,比如只保留人、商品、设备和页面区域维度,以此类推生成很多个DWM的中间表;

    DWM层抽取数据,将一个人在整个网站中的行为数据放到一张表中,到DWS层,这就是我们的宽表了,可以快速满足大部分的通用型业务需求;

    最后,在APP应用层,根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可

     

    不同的层次中会用到什么计算引擎和存储系统:

    数据层的存储一般如下:

    Data Source:数据源一般是业务库和埋点,当然也会有第三方购买数据等多种数据来源方式。业务库的存储一般是Mysql 和 PostgreSql。

    ODS 层:ODS 的数据量一般非常大,所以大多数公司会选择存在HDFS上,即Hive或者Hbase,Hive居多。

    DW 层:一般和 ODS 的存储一致,但是为了满足更多的需求,也会有存放在 PG 和 ES 中的情况。

    APP 层:应用层的数据,一般都要求比较快的响应速度,因此一般是放在 Mysql、PG、Redis中。

    计算引擎的话,可以简单参考图中所列就行。目前大数据相关的技术更新迭代比较快,本节所列仅为简单参考。

    从能力范围来讲,我们希望80%需求由20%的表来支持。直接点讲,就是大部分(80%以上)的需求,都用DWS的表来支持就行,DWS支持不了的,就用DWM和DWD的表来支持,这些都支持不了的极少一部分数据需要从原始日志中捞取。结合第一点来讲的话就是:80%的需求,我们都希望以对应用很友好的方式来支持,而不是直接暴露给应用方原始日志

     

     

     

    展开全文
  • 数据仓库的基础知识(分层结构)

    万次阅读 多人点赞 2018-08-02 16:19:43
    数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策。   数据...

    该文章转载自http://blog.sina.com.cn/s/blog_5e98ca2b0101b1qt.html,仅作学习使用。

     

    数据仓库

    数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策。

     

    数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。——数据仓库之父--Bill Inmon

     

    数据仓库基本特性

    面向主题性

    面向主题性表示了数据仓库中数据组织的基本原则,数据仓库中的所有数据都是围绕着某一主题组织的。 

    确定主题以后,需要确定主题应该包含的数据。 

    不同的主题之间可能会出现相互重叠的信息。 

    主题在数据仓库中可以用多维数据库方式进行存储。

    主题的划分中,必须保证每一个主题的独立性。 

     

    一个主题领域的表来源于多个操作型应用(如:客户主题,来源于:定单处理;应收帐目;应付帐目;…);

    典型的主题领域:客户;产品;交易;帐目;

    主题领域以一组相关的表来具体实现;

    相关的表通过公共的键码联系起来(如:顾客标识号Customer ID);

    每个键码都有时间元素(从日期到日期;每月累积;单独日期…);

    主题内数据可以存储在不同介质上(综合级,细节级,多粒度);

     

    数据集成性

    根据决策分析的要求,将分散于各处的源数据进行抽取、筛选、清理、综合等工作,最终集成到数据仓库中。

    数据的时变性

    数据应该随着时间的推移而发生变化,不断地生成主题的新快照。

    数据的非易失性

    数据的相对稳定性。

    数据仓库中的数据只进行刷新,从不进行更新处理。

    反映历史变化。

    数据库与数据仓库的对比

     

    商务智能

    简单定义:综合企业所有沉淀下来的信息,用科学的分析方法,为企业领导提供科学决策信息的过程。 

    完整定义:基于数据仓库技术的决策支持系统(DSS)。它 以数据仓库(DW)技术为基础,通过抽取、转换和清洗将分散在企业各处的数据整合在一起,转化为信息;进而以联机分析处理(OLAP)工具、数据挖掘(DM)工具、报表工具为手段将信息提升为知识;最后运用可视化技术以快捷直观的方式将探察分析结果呈现给最终用户,为管理决策层提供量化依据的过程。

     

    数据挖掘

    数据挖掘使您得以定义包含分组和预测规则的模型,以便应用于关系数据库或多维 OLAP 数据集中的数据。之后,这些预测模型便可用于自动执行复杂的数据分析,以找出帮助识别新机会并选择有获胜把握的机会的趋势。

     

    联机事务处理(OLTP)

    OLTP系统是设计用来允许高并发性的,这样很多用户就能够访问同一个数据源并进行所需的处理。

    OLTP系统是面向在数据库上进行事务处理的理念的。而事务则进一步蕴含着发生在表中数据上的受控的变更,这些变更包括在商务运作过程中发生的插入、更新和删除操作。通常,一个OLTP系统将会有大量的客户端应用程序通过各种各样的方式(插入、更新、删除--实际上可以是任何操作)访问数据库以查询一小块信息。

    OLTP系统的实例包括数据输入程序,如银行处理、订票、联机销售和库存管理系统。

     

    联机分析处理(OLAP)

    联机分析处理(或OLAP)是一种广义上的决策支持系统(DSS),或者最近越来越流行的商业智能(BI)。BI系统的目标是分析海量数据,然后以很多不同的方式(包括每天、每周、每季和年度报告)生成小结和总结以把精力高度集中在记分卡和仪表盘上,它们通常用于帮助那些准备好根据这些数据采取一定的措施的特定用户来获取竞争优势。

    一旦数据进入数据仓库之后就很少会发生变化。数据被保存在那里用于查询和生成报表,以便帮助决策者规划企业的未来。它不需要关心插入、更新和删除操作。因此与高度规范的事务数据库不同,在这种情况下通常会使用所谓的维度数据库 (dimensional database),它将遵循特定的结构或模式。

    维度数据库可以用来构建数据立方体,数据立方体是数据的多维表示,用来方便联机业务分析和提高查询性能。立方体中的每一维都表示业务数据中的一个不同的分析类别。

     

    维度数据库

    在OLTP系统中进行复杂查询存在一些固有的问题,对这些问题的解决方案是构建一个单独的数据库来更简洁地表示业务事实(fact)。这个数据库的结构不是关系型的,相反,它是维度化的。

     

    ETL

       数据抽取(Extract)、转换(Transform)、清洗(Cleansing)、装载(Load)的过程。是构建数据仓库的重要一环,用户从数据源抽取出所需的数据,经过数据清洗,最终按照预先定义好的数据仓库模型,将数据加载到数据仓库中去。

     

    元数据(Meta Data)

       关于数据仓库的数据,指在数据仓库建设过程中所产生的有关数据源定义,目标定义,转换规则等相关的关键数据。同时元数据还包含关于数据含义的商业信息,所有这些信息都应当妥善保存,并很好地管理。为数据仓库的发展和使用提供方便。

       关于数据的数据,用于构造、维持、管理、和使用数据仓库,在数据仓库中尤为重要。

       不同 OLAP 组件中的数据和应用程序的结构模型。元数据描述 OLTP 数据库中的表、数据仓库和数据集市中的多维数据集这类对象,还记录哪些应用程序引用不同的记录块。

     

    数据集市(Data mart)

       数据集市 -- 小型的,面向部门或工作组级数据仓库。

       即”小数据仓库”。如果说数据仓库是建立在企业级的数据模型之上的话。那么数据集市就是企业级数据仓库的一个子集,他主要面向部门级业务,并且只是面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。

     

    ODS

    Operation Data Store,操作数据存储 — ODS是能支持企业日常的全局应用的数据集合,是不同于DB的一种新的数据环境, 是DW 扩展后得到的一个混合形式。四个基本特点:面向主题的(Subject -Oriented)、集成的、可变的、 当前或接近当前的。

       

    主题(SUBJECT)

       是一个在较高层次将数据归类的标准,每一个主题对应一个宏观的分析领域,针对具体决策需求可细化为多个主题表,具体来说就是确定决策涉及的范围和所要解决的问题。 

     

    多维数据集

    多维数据集是联机分析处理 (OLAP) 中的主要对象,是一项可对数据仓库中的数据进行快速访问的技术。多维数据集是一个数据集合,通常从数据仓库的子集构造,并组织和汇总成一个由一组维度和度量值定义的多维结构。

     

    维度(DIMENSION)

        是人们观察数据的特定角度,是考虑问题时的一类属性,属性集合构成一个维(时间维、地理维等)。

        是多维数据集的结构性特性。它们是事实数据表中用来描述数据的分类的有组织层次结构(级别)。这些分类和级别描述了一些相似的成员集合,用户将基于这些成员集合进行分析。

        这词,英国著名物理学家史蒂芬·霍金教授有这样的解释:这就像一根头发,远看是一维的线,在放大镜下,它确实是三维的;如果面对时空,如果有足够高倍的放大镜的话,也应该能揭示出其它可能存在的4维、5维空间,直至11维空间。因此,维度是指一种视角,而不是一个固定的数字;是一个判断、说明、评价和确定一个事物的多方位、多角度、多层次的条件和概念

     

    事实表

    每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据,如现金登记事务

    所产生的数据,事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据(事实),并且这些数字信息可以汇总,以提供有关单位作为历史的数据,每个事实数据表包含一个由多个部分组成的索引,该索引包含作为外键的相关性纬度表的主键,而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息,也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。

    包含在事实数据表中的“度量值”有两中:一种是可以累计的度量值,另一种是非累计的度量值。最有用的度量值是可累计的度量值,其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息,例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表,单汇总结果一般是没有意义的,例如,在一座大厦的不同位置测量温度时,如果将大厦中所有不同位置的温度累加是没有意义的,但是求平均值是有意义的。

    一般来说,一个事实数据表都要和一个或多个纬度表相关联,用户在利用事实数据表创建多维数据集时,可以使用一个或多个维度表。

    从用途的不同来说,事实表可以分为三类,分别是原子事实表,聚集事实表和合并事实表。

    原子事实表(Atom Fact Table)是保存最细粒度数据的事实表,也是数据仓库中保存原子信息的场所。

    聚集事实表(Aggregated Fact Table)是原子事实表上的汇总数据,也称为汇总事实表。即新建立一个事实表,它的维度表是比原维度表要少,或者某些维度表是原维度表的子集,如用月份维度表代替日期维度表;事实数据是相应事实的汇总,即求和或求平均值等。在做数据迁移时,当相关的维度数据和事实数据发生变化时,聚集事实表需要做相应的刷新。物化视图是实现聚集事实表的一种有效方式,可以设定刷新方式,具体功能由DBMS来实现。

    合并事实表(Consolidated Fact Table)是指将位于不同事实表中处于相同粒度的事实进行组合建模而成的一种事实表。即新建立一个事实表,它的维度是两个或多个事实表的相同维度的集合;事实是几个事实表中感兴趣的事实。在Kimball的总线架构中,由合并事实表为主组成的合并数据集市称为二级数据集市。合并事实表的粒度可以是原子粒度也可以是聚集粒度。在做数据迁移时,当相关的原子事实表的数据有改变时,合并事实表的数据需要重新刷新。合并事实表和交叉探察是两个互补的操作。

    聚集事实表和合并事实表的主要差别是合并事实表一般是从多个事实表合并而来。但是它们的差别不是绝对的,一个事实表既是聚集事实表又是合并事实表是很有可能的。因为一般合并事实表需要按相同的维度合并,所以很可能在做合并的同时需要进行聚集,即粒度变粗。

     

    维度表

    维度表可以看作是用户来分析数据的窗口,纬度表中包含事实数据表中事实记录的特性,有些特性提供描述性信息,有些特性指定如何汇总事实数据表数据,以便为分析者提供有用的信息,维度表包含帮助汇总数据的特性的层次结构。例如,包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构,这些产品中的每一类进一步多次细分,直到各产品达到最低级别。

    在维度表中,每个表都包含独立于其他维度表的事实 特性,例如,客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。

    结论:

    1、事实表就是你要关注的内容;

    2、维度表就是你观察该事务的角度,是从哪个角度去观察这个内容的。

    例如,某地区商品的销量,是从地区这个角度观察商品销量的。事实表就是销量表,维度表就是地区表。

     

    度量值

    在多维数据集中,度量值是一组值,这些值基于多维数据集的事实数据表中的一列,而且通常为数字。此外,度量值是所分析的多维数据集的中心值。即,度量值是最终用户浏览多维数据集时重点查看的数字数据。您所选择的度量值取决于最终用户所请求的信息类型。一些常见的度量值有 sales、cost、expenditures 和 production count 等。

    “度量值”是来自事实数据表的值,也称为“事实数据”。度量值维度的值有时也通称为“成员”。度量值通常是数值,但也可以是字符串值。

     

    Measures 维度 (Measures dimension)

    “度量值维度”是包含多维数据集中所有度量值的维度。度量值维度是一种特殊的维度,其中的成员通常是根据各个维度属性(存在指定的度量值)的当前成员(通常采用求和或计数方式)进行聚合。

     

    度量值组 (Measure Group)

    “度量值组”是 SQL Server 2005 Analysis Services 多维数据集中的相关度量值集合(通常是来自同一事实数据表的度量值)。在 SQL Server 2005 Analysis Services 中,一个多维数据集可包含多个度量值组。

     

    级别

    级别是维度层次结构的一个元素。级别描述了数据的层次结构,从数据的最高(汇总程度最大)级别直到最低(最详细)级别。

     

    多维 OLAP (MOLAP):MOLAP 存储模式使得分区的聚合和其源数据的复本以多维结构存储在分析服务器计算机上。根据分区聚合的百分比和设计,MOLAP 存储模式为达到最快查询响应时间提供了潜在可能性。总而言之,MOLAP 更加适合于频繁使用的多维数据集中的分区和对快速查询响应的需要。

     

    关系 OLAP (ROLAP):ROLAP 存储模式使得分区的聚合存储在关系数据库的表(在分区数据源中指定)中。但是,可为分区数据使用 ROLAP 存储模式,而不在关系数据库中创建聚合。

     

    混合 OLAP (HOLAP):HOLAP 存储模式结合了 MOLAP 和 ROLAP 二者的特性。

     

    粒度

    数据汇总的层次或深度。数据仓库的数据单位中保存数据的细化或综合程度的级别。细化程度越高,粒度越小。

     

    聚合|聚集:聚合是预先计算好的数据汇总,由于在问题提出之前已经准备了答案,聚合可以改进查询响应时间。

     

    分割

    数据分散到各自的物理单元中去,它们能独立地处理。

     

    切块:由多个维的多个成员限定的分区数据,称为一个切块。

     

    切片:由一个维的一个成员限定的分区数据,称为一个切片。

     

    数据钻取:最终用户从常规多维数据集、虚拟多维数据集或链接多维数据集中选择单个单元,并从该单元的源数据中检索结果集以获得更详细的信息,这个操作过程就是数据钻取。

     

    数据挖掘模型:数据挖掘使您得以定义包含分组和预测规则的模型,以便应用于关系数据库或多维 OLAP 数据集中的数据。之后,这些预测模型便可用于自动执行复杂的数据分析,以找出帮助识别新机会并选择有获胜把握的机会的趋势。

     

    数据库维度 (Database dimension)

    “数据库维度”是与某个键属性相关的维度属性的集合,而该键属性又与度量值维度中的事实数据相关。

     

    维度属性 (Dimension attribute)

    “维度属性”被绑定到维度表中的一个或多个列并包含成员。维度属性可以包含客户名称、月份名称和产品名称。

     

    成员 (Member)

    “成员”是维度属性(包括度量值维度)的值。层次结构中的成员可以是叶成员、父成员、数据成员或“(全部)”成员。

     

    “(全部)”成员 ((All) member)

    “(全部)”成员是属性层次结构或用户定义的层次结构中的所有成员的计算值。

     

    计算成员 (Calculated member)

    “计算成员”是在查询时定义和计算的维度成员。可以在用户查询或 MDX 计算脚本中定义计算成员,并将其存储在服务器上。 一个计算成员对应于定义它们的维度中的多个维度表行。

     

    数据成员 (Data member)

    “数据成员”是在父子层次结构中与父成员相关联的子成员。数据成员包含其父成员的数据值,而不是该父成员的子级的聚合值。

     

    父成员 (Parent member)

    “父成员”是父子层次结构中的成员,包含其子级的聚合值。

     

    叶成员 (leaf member)

    “叶成员”是层次结构中不包含子级的成员。

     

    子成员 (Child member)

    “子成员”是层次结构中位于顶层下面的成员。

     

    键属性 (Key attribute)

    数据库维度的“键属性”是维度中的所有非键属性(以直接或间接方式)所链接到的属性。键属性通常也是粒度属性。

     

    粒度属性 (Granularity attribute)

    多维数据集维度的属性,它将维度链接到度量值维度内度量值组中的事实数据。如果粒度属性和键属性为不同的属性,则非键属性必须直接或间接地链接到粒度属性。在多维数据集中,粒度属性定义维度的粒度。

     

    多维数据集维度 (Cube dimension)

    “多维数据集维度”是多维数据集中的数据库维度实例。

     

    属性层次结构 (Attribute hierarchy)

    “属性层次结构”是包含以下级别的属性成员层次结构:

     

    数据仓库建模 — 星型模式

    Example of Star Schema

    在多维分析的商业智能解决方案中,根据事实表和维度表的关系,又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候,就应考虑数据是按照星型模型还是雪花型模型进行组织。

    当所有维表都直接连接到“ 事实表”上时,整个图解就像星星一样,故将该模型称为星型模型,星型架构是一种非正规化的结构,多维数据集的每一个维度都直接与事实表相连接,不存在渐变维度,所以数据有一定的冗余,如在地域维度表中,存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录,那么国家 A 和省 B 的信息分别存储了两次,即存在冗余。

    数据仓库建模 — 雪片模式

    Example of Snowflake Schema

    当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化,原有的各维表可能被扩展为小的事实表,形成一些局部的 " 层次 " 区域,这些被分解的表都连接到主维度表而不是事实表。将地域维表又分解为国家,省份,城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

    星型模型因为数据的冗余所以很多统计查询不需要做外部的连接,因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素,设计与实现 都比较简单。 雪花型模型由于去除了冗余,有些统计就需要通过表的联接才能产生,所以效率不一定有星型模型高。正规化也是一种比较复杂的过程,相应的数据库结构设计、数 据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下,实际运用中星型模型使用更多,也更有效率

     

    参考文献:

    Inmon,W.H.,” Building the Data Warehouse” ,Johm Wiley and Sons,1996.

    Ladley,John,”Operational Data Stores:Building an Effective Strategy”,Data warehouse:Pratical Advice form the Experts,Prentice Hall,Englewood Cliffs,NJ,1997.

    Gardmer,Stephen R., “Building the Data warehouse”,Communication of ACM, September 1998, Volume 41, Numver 9, 52-60.

    Douglas Hackney , Http:// www.egltd.com, DW101: A Practical Overview, 2001

     Pieter R. Mimno, “The Big Picture - How Brio Competes in the Data Warehousing Market”, Presentation to Brio Technology - August 4, 1998.

    Alex Berson, Stephen Smith, Kurt Therling, “Building Data Mining Application for CRM”, McGraw-Hill, 1999

    Martin Stardt, Anca Vaduva, Thomas Vetterli, “The Role of Meta for Data Warehouse”, 2000

    W.H.Inmon, Ken Rudin, Christopher K. Buss, Ryan Sousa, “Data Warehouse Performance”, John Wiley & Sons , 1999

    Bill Inmon比尔·恩门

    http://baike.baidu.com/view/1332560.htm?subLemmaId=1332560&fromenter=Bill+Inmon

    Ralph Kimball

    http://baike.baidu.com/view/3952196.htm

    展开全文
  • 详解大数据数据仓库分层架构

    万次阅读 2019-01-08 20:24:14
    大数据数据仓库是基于HIVE构建的数据仓库,分布文件系统为HDFS,资源管理为Yarn,计算引擎主要包括MapReduce/Tez/Spark等,分层架构如下: 1、数据来源层:日志或者关系型数据库,并通过Flume、Sqoop、Kettle等...

    大数据数据仓库是基于HIVE构建的数据仓库,分布文件系统为HDFS,资源管理为Yarn,计算引擎主要包括MapReduce/Tez/Spark等,分层架构如下:

    1、数据来源层:日志或者关系型数据库,并通过Flume、Sqoop、Kettle等etl工具导入到HDFS,并映射到HIVE的数据仓库表中。

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

    3、维度表是维度属性的集合。是分析问题的一个窗口。是人们观察数据的特定角度,是考虑问题时的一类属性,属性的集合构成一个维。数据库结构中的星型结构,该结构在位于结构中心的单个事实数据表中维护数据,其它维度数据存储在维度表中。每个维度表与事实数据表直接相关,且通常通过一个键联接到事实数据表中。星型架构是数据仓库比较流向的一种架构。

    星型模式的基本思想就是保持立方体的多维功能,同时也增加了小规模数据存储的灵活性。

    说明:

    1)、事实表就是你要关注的内容;

    2)、维度表就是你观察该事务的角度,是从哪个角度去观察这个内容的。

    例如,某地区商品的销量,是从地区这个角度观察商品销量的。事实表就是销量表,维度表就是地区表

    4、主题表:主题(Subject)是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念,每一个主题基本对应一个宏观的分析领域。在逻辑意义上,它是对应企业中某一宏观分析领域所涉及的分析对象。例如“销售分析”就是一个分析领域,因此这个数据仓库应用的主题就是“销售分析”。

    面向主题的数据组织方式,就是在较高层次上对分析对象数据的一个完整并且一致的描述,能刻画各个分析对象所涉及的企业各项数据,以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的,是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应,数据仓库中的数据是面向主题进行组织的。例如,一个生产企业的数据仓库所组织的主题可能有产品订货分析和货物发运分析等。而按应用来组织则可能为财务子系统、销售子系统、供应子系统、人力资源子系统和生产调度子系统。

    5、汇总数据层:聚合原子粒度事实表及维度表,为满足固定分析需求,以提高查询性能为目的,形成的高粒度表,如周报、月报、季报、年报等。

    6、应用层:

    为应用层,这层数据是完全为了满足具体的分析需求而构建的数据,也是星形结构的数据。应用层为前端应用的展现提现数据,可以为关系型数据库组成。

    7、【补充】

    数据缓存层:

    用于存放接口方提供的原始数据的数据库层,此层的表结构与源数据保持基本一致,数据存放时间根据数据量大小和项目情况而定,如果数据量较大,可以只存近期数据,将历史数据进行备份。此层的目的在于数据的中转和备份。

    临时数据表层:

    存放临时测试数据表(Temp表),或者中间结果集的表。

    如何学习大数据?学习没有资料?

    想学习大数据开发技术,Hadoop,spark,云计算,数据分析等技术,在这里向大家推荐一个学习资料分享群:894951460,里面有大牛已经整理好的相关学习资料,希望对你们有所帮助。

    展开全文
  • 数据仓库分层设计

    千次阅读 2019-05-21 17:05:28
    文章参考...为什么要对数据仓库分层: a)用空间换时间,通过大量的预处理来提升应用系统的用户体验(效率),因此数据仓库会存在大量冗余的数据; b)如果不...
  • 大数据之数据仓库分层

    千次阅读 2019-06-03 10:32:18
    2. 数据分层的好处一种通用的数据分层设计3. 举例4. 各层会用到的计算引擎和存储系统5. 大数据相关基础概念 1. 什么是数据分层数据分层是一套行之有效的数据组织和管理方法,使得数据体系更有序。 2. 数据分层的...
  • 释放价值,分享知识和经验,解读IT前沿和技术。帮助他人,提升自己。更多交流请关注微信公众号itboxes(IT智囊)。
  • 数据仓库的架构以及数据分层

    万次阅读 2016-09-26 14:37:18
    数据仓库分层的原因 1通过数据预处理提高效率,因为预处理,所以会存在冗余数据 2如果不分层而业务系统的业务规则发生变化,就会影响整个数据清洗过程,工作量巨大 3通过分层管理来实现分步完成工作,这样每一层的...
  • Python中如何实现分层抽样

    万次阅读 2017-08-06 14:57:09
    如果我们想在一个大的数据总体中,按照数据的不同分类进行分层抽样,在Python中如何用代码来实现这一操作呢。 下面我们要实现分层抽样操作的应用背景: 随机抽取2017年重庆市不同区域高中学生的高考成绩。 这里数据...
  • 1.观察数据集head(iris) 选取数据集中前6个数据,我们可以看出iris数据集一共有5个字段。dim(iris) iris数据集一共有150条数据,5个字段summary(iris) 观察各个变量的内容,可以看出前四个变量(Sepal.Length ...
  • TCP/IP分层模型

    万次阅读 多人点赞 2016-08-18 17:21:32
    推荐书籍:图解TCP/IP 人民邮电出版社 竹下隆史等【日】一、TCP/IP分层模型TCP/IP模型分为5层:应用层、传输层、网络层、数据链路层以及 物理层。分层就类似接口的定义,定义了每个层的行为职责。这样的分层抽象提供...
  • DW数据仓库分层模型设计

    千次阅读 2018-08-10 08:27:24
    DW分层模型设计
  • 目录powerDesigner画分层数据流图的方法step 1step 2step 3step 4step 5图文讲解到此结束 powerDesigner画分层数据流图的方法 step 1 step 2 画好顶层的数据流图 step 3 右击,点击Descompose Process(分解操作) ...
  • 数仓分层

    万次阅读 2019-02-28 14:48:31
    数据仓库和数据仓库分层 1 数据仓库的概念 数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它是单个数据存储,出于分析性...
  • (这不合理,太复杂的分层会导致混乱,《阿里巴巴手册》还是很有问题的。) 分层领域模型规约: DO( Data Object):与数据库表结构一一对应,通过DAO层向上传输数据源对象。 DTO( Data Transfer Object):...
  • 各层的作用1:数据访问层:主要是对非原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据库的操作,而不是数据,具体为业务逻辑层或表示层提供数据服务.2:业务逻辑层...
  • 数据仓库分层与架构

    万次阅读 多人点赞 2018-12-19 22:27:16
    目录 数据仓库的定义 数据仓库的特点 数据仓库的作用 数据仓库的架构 数据仓库的要求 ...数据仓库本身并不“生产”任何数据,同时自身也不需要“消费”任何的数据数据来源于外部,并且开放给外部...
  • python实现的分层随机抽样

    万次阅读 2017-05-13 12:15:22
    昨天写了一段用来做分层随机抽样的代码,很粗糙,不过用公司的2万名导购名单试了一下,结果感人,我觉得此刻的我已经要上天了,哈哈哈哈哈哈 代码如下: #分层随机抽样 stratified sampling import xlrd,...
  • 互联网分层架构的本质

    千次阅读 2017-11-02 13:13:48
    上图是一个典型的互联网分层架构: 客户端层:典型调用方是browser或者APP 站点应用层:实现核心业务逻辑,从下游获取数据,对上游返回html或者json 数据-缓存层:加速访问存储 数据-数据库层:...
  • MVC分层架构

    千次阅读 2017-09-19 22:57:00
    MVC即模型-视图-控制器,将应用程序的...三层架构三层架构重点内容分层架构一般为三层:表示层、业务逻辑层(或领域层)、数据访问层。 表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他
1 2 3 4 5 ... 20
收藏数 202,804
精华内容 81,121
关键字:

数据分层