① 数据仓库是什么意思啊通俗的讲
数据仓库：数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，从字面意义上看数据仓库就是数据的仓库，它的实质就是一个可以容纳更多数据的数据集。其目的是通过将操作型数据集成带统一的环境中，为企业所有级别的决策制定过程，提供所有类型数据支撑的战略集合，主要是用于数据挖掘和数据分析，以建立数据沙盘为基础，为消灭消息孤岛和支持决策。数据仓库关注的是解决数据一致性，可信性，集合性……通过统一数据口径，整理清洗数据将杂乱无序的业务数据转化为对于业务运营、业务分析来说简单易用的数据形式。
就零售行业来讲，其每天进行的交易行为是以万或者千万来讲的，每一次数据录入必须要在极短的时间内完成。所以数据库只能储存短时间的一段数据，数据仓库则是根据这些时效数据，对数据进行清洗处理，然后进行分析，挖掘利用数据仓库中的数据价值，为企业进行决策提供数据支撑。
② 浅谈数据仓库体系（3）-历史层
如上文所说，一个基本的数据仓库分为贴源层，历史层，数据模型层
本文主要来讲一下历史层(his），重点是如下三个方面
1.历史层的数据清洗
2.历史层的数据存储
3.历史层的数据校验
历史层，顾名思义，就是保存所有的历史数据，我们知道数据仓库的一个原则就是数据是不变的，就是说进来了的数据就不做更改，不做删除，那这个不做更改，不做删除，主要体现在的就是历史层。
数据仓库体系是一个OLAP体系，主要用来分析历史数据的，那么历史层数据的保存就显得异常的重要。
一.历史层的数据清洗
到了历史层，其实对清洗的要求也不会很高，如果在ODS层做了基本的清洗，那么在历史层要做的清洗就更少了。历史层因为是保存历史的数据，简单的理解就是把ODS的数据全部都存一遍，历史层的粒度最好还是保持最细的粒度，在历史层来说，相对更为重要的应该是存储了。本文也主要讲述历史层的存储
二.历史层的数据存储
历史层的数据存储主要有4种，1.全量，2.增量切片，3.全量切片，4.拉链
1.全量
如前面ODS讲到的，如果我们是全量把数据导入到ODS的，我们会根据业务需要，如果是缓慢变化的，或者确认这种变化后对我们的业务作用基本可以忽略不计的，我们通常就采取全量的方式存储，这样的存储方式其实是和ODS里面一样的。
2.全量切片
如前面ODS讲到的，如果我们是全量把数据导入到ODS的，如果数据量不是很大的话，我们通常考虑全量切片的方式。就是把每一次全量抽取过来的数据都保存下来，然后在后面加一个操作时间字段
这里要讲一下选择全量存储，还是全量切片存储的问题
对于数据仓库来说，因为要保存历史的数据，历史的变化，那么在这种原则下，我们肯定优先选择全量切片存储了。但是，我们还需要考虑其他的存储和实际的业务情况。
(1)个就是存储空间的问题，假设一张很大的表从源体系全量抽取的，每天1个T，一年下来就365T，hive中再乘以3，那对存储空间的要求实在太多了。可能这张表变化的字段就是一个一年就用一次的字段。从存储和使用比来说，划不来。
(2)个就是使用问题，在hive这种有分区的数仓体系中还好，如果是oracle，TD等数据仓库，如果这张表存储了1年的数据，我要查一个某一天的数据的某一部分，可能怎么样都没法查出来了
所以通常的原则，1.是小表，变化比较频繁的表，变化的字段比较重要，并且经常要进行历史对比的表，考虑全量切片
如果是变化比较慢，并且变化的字段基本不用的，就全量存储就好，比如，一张地区维度表，把北京市统一改为北京存储了，其实就没有必要每天都存一遍了。
(3).就是数据量大，变化的字段比较缓慢的，这样也考虑用全量表
那么这里问题就来了，如果数据量大，又变化的字段比较重要呢？
也许这真的就是数据存储中的一个难题了，现在大数据量，又变化快的情况，可能主要使用的还是增量切片的方式，
3.增量切片，就是把新增的数据存储下来，或者说变化的数据存储下来，一般来说，这是当前一种主要的存储形态
主要优点有2个：
1> 增量数据相对全量数据来说，量级会少好多，会节省很多存储空间
2>每天存储变化的值，在我们做相关使用时，效率会更高，总体的数据量级会少
4.拉链表
拉链表对于很多人来说可能比较陌生，一般做数据仓库没做个一年，可能都不会接触到这种类型的表，并且目前考虑用这种表存储的情况，实际来说比较少，这里就说两点：1.拉链表本质上适合与缓慢变化的大量数据集，2.拉链表的使用不方便。
三.历史层的数据校验
历史数据的准确性，是数据仓库分析的基础，对于历史数据的校验，其他也遵循通用的校验方法，因为多了历史数据缘故，还可以加一些趋势性的校验方法，比如同比，环比的数据总量，某一类指标的变化阈值，都可以根据历史数据做一定的预警
③ 数仓建模分层理论
这篇文章较为完整、清晰的讲述了数仓建模分层理论，要点如下：
1、分层的意义：清晰结构体系、数据血缘跟踪、减少重复开发、复杂问题简单化及统一数据口径
2、ODS：用作缓冲，可以存一周左右，跟DWD大多重复，留存的目的还在于保持跟源端一致，方便追溯
3、DWD：针对ODS做数据的清洗和整合，在DWD层会根据维度模型，设计事实表和维度表，DWD层是一个非常规范的、高质量的、可信的数据明细层
4、DWS：基于DWD层形成某一主题的轻度汇总表或分析宽表，DWS形成大量维度退化的事实表以提高易用性，DWS层应覆盖80%的应用场景
5、TDM：标签层，通过统一的ID-Mapping 把各个业务板块，各个业务过程中同一对象的数据打通，形成对象的全域数据标签体系，方便深度分析、挖掘、应用，大家注意，这个ID不仅仅指客户或用户ID，也包括其它的主数据ID，其是全流程分析的基础
6、ADS：数据应用层ApplicationDataService面向业务定制的应用数据，主要提供给数据产品和数据分析使用的数据，一般会放在ES，MYSQL，Redis等前端系统供线上系统使用，也可以放在Hive中供数据分析和数据挖掘使用
7、DM：主要是提供数据产品和数据分析的数据，主要解决部门用户报表和分析需求而建立数据库，数据集市就代表数据仓库的主题域。DM 是面向单个主题的，所以它不会从全局考虑进行建设。
强烈推荐阅读！
正文开始
简单点儿，直接ODS+DM就可以了，将所有数据同步过来，然后直接开发些应用层的报表，这是最简单的了；当DM层的内容多了以后，想要重用，就会再拆分一个公共层出来，变成3层架构,这个过程有点类似代码重构，就是在实践中不断的进行抽象、总结。
数仓的建模或者分层，其实都是为了更好的去组织、管理、维护数据,所以当你站在更高的维度去看的话，所有的划分都是为了更好的管理。小到JVM 内存区域的划分，JVM 中堆空间的划分(年轻代、老年代、方法区等)，大到国家的省市区的划分，无一例外的都是为了更好的组织管理 。
所以数仓分层是数据仓库设计中十分重要的一个环节， 优秀的分层设计能够让整个数据体系更容易理解和使用 。
这一节，我们主要是从整体上出发进行分析和介绍，就和上一节数仓建模方法论一样，进度对比分析，更多细节的东西我们后面会单独拆分出来，用案例进行演示，例如维度建模，维度表的设计，事实表的设计、以及如何设计标签、如何管理标签等等。
每一个数据分层都有它的作用域，这样在使用表的时候能更方便的定位和理解。
由于最终给业务呈现的是一个能直接使用的业务表，但是表的数据来源有很多，如果有一张来源表出问题了，我们希望能够 快速准确的定位到问题，并清楚它的影响范围，从而及时给到业务方反馈，从而将损失降到最低 。
将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
过数据分层提供统一的数据出口，统一对外输出的数据口径，这往往就是我们说的数据应用层。
前面我们说到分层其实是为了更好更快更准的组织管理，但是这个是从宏观上来说的，接下来我们从微观上也来看一下分层。
越靠上的层次，对应用越友好,比如ADS层，基本是完全为应用设计,从数据聚合程度来讲，越上层的聚合程度越高，当然聚合程度越高可理解程度就越低。
数仓层内部的划分不是为了分层而分层， 分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题 ，当然我们常说的分层也是面向行业而言的，也是我们常用分层方法，但是你需要注意的是分层仅仅是手段而已。
ODS 全称是 OperationalDataStore， 操作数据层存储的是面向业务系统的数据 ，也是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。
本层的数据，总体上大多是 按照源头业务系统的分类方式而分类的 ，前面我们说到为什么在数仓主要用维度建模的情况下，我们依然要学习范式建模呢，因为我们的数据源是范式建模的，所以学习范式建模可以帮助我们更好的理解业务系统，理解业务数据，所以你可以认为我们的ODS 层其实就是用的实范式建模。
这里的数据处理，并不涉及业务逻辑，仅仅是针对数据完整性以及重复值和空值的处理，其实就是做的是数据规约，数据清洗，但是为了考虑后续可能追溯数据源问题，因此 对这一层不建议做过多的数据清洗工作 ，原封不动接入源数据即可，至于数据的去噪，去重，异常值处理等过程可以放在后面的DW层
表名的设计 ODS_业务系统_表名_标记 ，这样的设计可以保持与业务表名一致，又可以有清晰的层次，还可以区分来源。标记一般指的是其他数仓特有的属性，例如表是天级的还是小时的，是全量的还是增量的。
ods 的设计可以保证所有的数据按照统一的规范进行存储。
DW是数据仓库的核心，从ODS层中获得的数据按照主题建立各种数据模型。DW又细分数据明细层DWD 和轻度汇总层DWS
这一层和维度建模会有比较深的联系，业务数据是按照 业务流程方便操作的角度 来组织数据的，而统一数仓层是 按照业务易理解的角度或者是业务分析的角度 进行数据组织的，定义了一致的指标、维度，各业务板块、数据域都是按照统一的规范来建设，从而形成统一规范的 标准业务数据体系 ，它们通常都是基于Kimball的维度建模理论来构建的， 并通过一致性维度和数据总线来保证各个子主题的维度一致性 。
公共层的维度表中相同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致，因为这样可以降低我们在使用过程中犯错误的概率，例如使用了不正确的字段，或者因为数据类型的原因导致了一些奇怪的错误
将维度所描述业务相关性强的字段在一个物理维表实现。相关性强是指经常需要一起查询或进行报表展现、两个维度属性间是否存在天然的关系等。例如，商品基本属性和所属品牌。
公告明细数据层，可以说是我们数仓建设的核心了。
DWD层要做的就是将 数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理 。然后加工成面向数仓的基础明细表，这个时候可以加工一些面向分析的大宽表。
DWD层应该是覆盖所有系统的、完整的、干净的、具有一致性的数据层。在DWD层会根据维度模型，设计事实表和维度表，也就是说DWD层是一个非常规范的、高质量的、可信的数据明细层。
DWS层为 公共汇总层 ，这一层会进行轻度汇总，粒度比明细数据稍粗， 基于DWD层上的基础数据，整合汇总成分析某一个主题域的服务数据 ，一般是也是面向分析宽表或者是面向某个注意的汇总表。DWS层应覆盖80%的应用场景，这样我们才能快速响应数据需求，否则的话，如果很多需求都要从ods开始做的话，那说明我们的数仓建设是不完善的。
例如按照业务划分，例如流量，订单，用户等，生成字段比较多的宽表，用于后续的业务查询，OLAP分析，数据分析等。
一般采用维度模型方法作为理论基础，更多的采用一些维度退化手法，将维度退化至事实表中，减少维度表与事实表的关联，提高明细数据表的易用性；同时在汇总数据层要加强指标的维度退化，采用更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工 。
维表层，所以其实维度层就是大量维表构成的，为了统一管理这些维度表，所以我们就建设维度层，维度表本身也有很多类型，例如稳定维度维表，渐变维度维表。
维度指的是观察事物的角度，提供某一业务过程事件涉及用什么过滤和分类的描述属性 ，"谁、什么时候、什么地点、为什么、如何"干了什么，维度表示维度建模的基础和灵魂。
所以可以看出，维度表包含了业务过程记录的业务过程度量的上下文和环境。维度表都包含单一的主键列， 维度表设计的核心是确定维度字段，维度字段是查询约束条件(where)、分组条件(group)、排序(order)，与报表标签的基本来源 。
维度表一般为 单一主键 ，在ER模型中，实体为客观存在的事务，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。维度建模的核心是 数据可以抽象为事实和维度 ，维度即观察事物的角度，事实某一粒度下的度量词， 维度一定是针对实体而言的 。
每个维度表都 包含单一的主键列 。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。例如customer（客户表）、goods(商品表)、d_time(时间表)这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。
维度表通常比较宽 ，包含多个属性、是扁平的规范表 ，实际应用中包含几十个或者上百个属性的维度并不少见，所以 维度表应该包括一些有意义的描述，方便下游使用 。
维度表的维度属性，应该尽可能的丰富，所以维度表中，经常出现一些反范式的设计，把其他维度属性并到主维度属性中， 达到易用少关联的效果。
维度表的设计包括维度选择，主维表的确定，梳理关联维度，定义维度属性的过程。
维度的选择一般从报表需求和从业务人员的交谈中发现，主要用于过滤、分组、排序，主维度表一般从业务库直接同步，比如用户表，但是数仓的本身也会有自己的维度，这是因为数仓是面向分析的，所以会有很多从分析的角度出发的维度。
关联维度主要是不同业务系统或者同一业务系统的表之间存在关联性(范式建模)，根据对业务表的梳理，确定哪些表和主维度表之间存在关联关系，并选择其中的某些表用于生成维度属性。
随着互联网的普及，获客成本越来越高，这也使得公司对用户运营提出了更高的要求，不仅需要精细化更需要个性化。解决这一问题的办法之一就是建立相对完备的标签系统，而数仓的标签层对于标签系统而言就像数据仓库对于数据系统一样，有着举足轻重的地位，这样的标签系统需要与业务进行紧密结合， 从业务中获取养分—用户标签，同时也要服务于业务—给用户提供更加精准和个性的服务 。
底层的标签系统就像一个索引，层层展示大千世界，而用户就从这大千世界中不断选择一些东西表明自己的身份和喜好，也不断反哺，使得这个大千世界更加丰富多彩。 其实到最后用户就是一些标签的集合。
对跨业务板块、跨数据域的特定对象进行数据整合，通过统一的ID-Mapping 把各个业务板块，各个业务过程中 同一对象的数据打通 ，形成对象的全域数据标签体系，方便深度分析、挖掘、应用。ID-Mapping 可以认为是通过对象的标识对不同数据体系下相同对象进行关联和识别。对象的标识可以标识一个对象，一般是对象的ID,比如手机号，身份证，登录账号
完成对象的ID 打通需要给对象设置一个超级ID,需要根据对象当前业务体系的ID和获取得到或者计算得到超级ID,进而完成所有业务标识的ID打通一般来说ID打通是建设标签体系的前提，如果没有ID打通就无法收集到一个对象的全面信息，也就无法对这个对象进行全面的标签刻画。
传统的计算方法要有 ID-ID之间的两两关系，例如邮箱和手机号可以打通，手机号和身份证号可以打通，那么邮箱就和身份证号可以打通，但是当数据量非常大，且业务板块非常多的时候，例如有上一个对象，每个对象有数十种ID,这个时候打通就需要非常漫长的计算
那么什么是标签呢，利用原始数据，通过一定的逻辑加工产出直接能被业务所直接使用的、可阅读的，有价值的数据。标签类目，是标签的分类组织方式，是标签信息的一种结构化描述，目的是管理、查找，一般采用多级类目，一般当一个对象的标签个数超过50个的时候，业务人员查找标签就会变得非常麻烦，这个时候我们往往会通过标签类目进行组织管理
标签按照产生和计算方式的不同可分为属性标签，统计标签，算法标签，关联标签。
对象本身的性质就是属性标签，例如用户画像的时候打到用户身上的标签。
对象在业务过程中产生的原子指标，通过不同的计算方法可以生成统计标签。
对象在多个业务过程中的特征规律通过一定的算法产出的标签。
对象在特定的业务过程会和其他对象关联，关联对象的标签也可以打在主对象上。
我们的标签一定是针对用户的，而不是一些虚假、高大上、无用的标签，一定要真实反映用户行为喜好的，所以我们不能只依赖人工智能算法的分析，来完成对一个用户标签的建立与定期维护，我们需要走出去和用户交互，引导用户使用，要抓住用户痛点，及时获取用户反馈，形成闭环。
如何引导使用呢？这个方式有很多我们就不再这里介绍了，后面我们会专门介绍这一层的建设细节。
数据应用层ApplicationDataService面向业务定制的应用数据，主要提供给数据产品和数据分析使用的数据，一般会放在ES，MYSQL，Redis等系统供线上系统使用，也可以放在Hive中供数据分析和数据挖掘使用，或者使用一下其他的大数据工具进行存储和使用。
数仓层，DIM 层，TDM 层是相对稳定的，所以无法满足灵活多变业务需求 ，所以这和数仓层的规范和划分相矛盾，所以我们在此基础上建立了另外一个层，这就是ADS 层，解决了规划稳定和灵活多变之间的矛盾。其实到这里你也就慢慢的看明白了，分层和分类其实没多大差别，其实就是相似的放在一起，有点代码重构的意味啊。
数据应用层，按照业务的需要，然后从统一数仓层和DIM进行取数，并面向业务的特殊需求对数据进行加工,以满足业务和性能的需求。ADS 层因为面向的实众多的需求，所以这一层没有太多的规范，只需要按照命名规范来进行就可以了。
前面也说了，ADS 层因为面向的实众多的需求，所以这一层没有太多的规范，但是ADS 层的建设是强业务推动的，业务部门需要参与到ADS 的建设中来，至少我们得了解用户的痛点才能对症施药啊。
理清需求，了解业务方对数据内容、使用方式(怎么交互的，报表、接口、即席查询、在线查询、指标查询、搜索)、性能的要求。
盘点现有的数仓表是否可以支持，看以前有没有类似的需求，有没有可以复用的接口、报表什么的。
代码实现，选择合适的存储引擎和查询引擎，配置线上监控然后交付。
主要是提供数据产品和数据分析的数据，一般会存放在ES、Mysql、也可能直接存储在hive中或者druid供数据分析和数据挖掘使用。主要 解决部门用户报表和分析需求 而建立数据库，数据集市就代表数据仓库的主题域。
DM 是面向单个主题的，所以它不会从全局考虑进行建设，只专注于自己的数据、往往是某个业务线，例如流量主题、社交主题、电商主题等等。
④ 数据仓库的数据清理与数据挖掘的数据清理有什么不同
数据仓库主要是对不完整的、错误的、重复的数据进行清洗，经过清洗的数据就可以在数据仓库的存储层进行存储。对于数据挖掘来讲，数据清洗是数据预处理的一部分，数据挖掘的数据预处理包括数据清理、数据集成、数据变换、数据归约、数据离散化。其中，数据清理的内容要大于等于数据仓库的数据清洗，如果数据挖掘的数据源是从数据仓库， 则在数据清理阶段可以省去对不完整数据、错误数据和重复数据的清理，但像平滑噪声数据，识别并删除孤立点，解决不一致性等还是要在数据清理阶段执行。
也就是说，数据仓库是为所有的分析应用提供数据源支撑，而数据挖掘是分析应用的一种，数据质量高的数据仓库可以让数据挖掘过程省去一部分预处理过程，但是不可能代替。
⑤ 大数据数仓建设性能优化方案
大数据数仓的性能优化主要围绕以下四个方面：
在数据仓库建设的过程中，我们不可避免的要执行数据任务，那么这些任务如何进行配置才会是最优的？如果任务调度配置存在问题，将会导致出现瓶颈任务，或者无法及时提供业务所需的数据，这时我们就需要首先从调度方面来考虑，是不是有些任务的调度时间设置不合理？或者是不是有的任务的优先级设置不合理？
对于数仓的建模而言，其实可以分为3NF建模和维度建模，推荐使用维度建模方式，可以按照星型模型或者雪花模型架构的方式去建模。3NF建模方式或者实体建模方式的应用性会差一点，在很多时候其性能也会差一点，但3NF会避免数据的冗余，其扩展性会好一些。而维度建模会有一定的数据冗余，并且冗余程度会很高，但是对于上层使用者而言，其易用性要好很多，并且其查询的性能也会好很多，虽然牺牲了一定的可扩展性，但是仍然在可接受的范围之内。之所以在大数据的框架下推荐使用维度建模，是因为建模产生的数据冗余对于大数据离线数仓来说，存储的成本并不高，因为其都属于SATA盘的存储，这样的存储成本是很低的。
总之，在大数据框架下推荐大家使用维度建模，使用星型模型或者雪花模型建模的方式，这样无论对于后续的运维还是后续的数据使用而言，都是比较便利的，并且性能会好一些。星型模型其实就是中间一个事实表，周边围绕着一堆维度表，其结构会简单一些，使用比较方便，性能也比较好；对于雪花模型而言，维度表可能还会继续关联其他的维度表，这种方式就是雪花模型，它会略微比星型模型复杂一些。其实星型模型也可以理解为较为简单的雪花模型。这里推荐大家使用星型模型，当然如果业务非常复杂，必须要使用雪花型也可以使用。这是因为星型模型虽然有数据冗余，但是其结构比较简单，容易理解，而且使用起来只需要A传给B就可以了，不需要再关联一个C。
除了上述两个较大的关键点之外，还有一些需要注意的小点，比如中间表的使用。我们一般将数仓分为三层，第一层做缓冲，第二层做整合，第三层做应用。但是并不是严格的只能分为三层，中间可能会有一些中间表，用于存储中间计算的结果，如果能够利用好中间表则会增强数仓的易用性和整体的性能。中间表的使用主要在数仓的第二层里面，因为需要整合数据，但整合后的数据仍是明细数据，对于这些表而言，数据量往往会比较大，而且会有见多的下游任务依赖这个表，因此可以做一些轻度的汇总，也就是做一些公共的汇总的中间表，这样应用层可以节省很多的计算量和成本。此外，虽然建议使用中间表，但也要注意中间表的数量，因为中间表数量过多，就会有太多的依赖层级。
在某些业务场景下，我们还需要对宽表进行拆表，拆表的情况一般发生在该表的字段较多，而其中几个字段的产出时间较晚，导致整个表的交付时间也会延迟，在这种情况下我们可以将这几个字段单独拆出来处理，这样就不会因为几个字段影响其余业务的使用。
与拆表相对的情况是合表，随着业务的增多，可能会有多个表中存放类似的数据指标，此时，我们可以将多个表整合到一个表中，减少数据任务的冗余。
表分区的功能一定要合理利用，这对于性能会产生很大的影响，一级分区一般都是按照天划分的，建议大家一天一个增量或者一天一个全量来做。二级分区的选择反而会多一些，首先大家要烤炉是否建立二级分区，其次大家再选择二级分区的建立方式。二级分区比较适合于在where语句中经常使用到的字段，而且这个字段应该是可枚举的，比如部门名称这样的。这里还有一个前提，就是如果这个字段的值的分布是非常不均匀的，那么就不太建议做二级分区。
离线数仓的计算任务基本都是通过SQL实现，这里也只讲在SQL部分如何进行优化。我们平时在进行数据处理，数据清洗，数据转换，数据加工的过程中都会使用到SQL。对于大数据体系下的SQL的优化而言，主要集中在两个大的方面进行：减少数据输入和避免数据倾斜。减少数据输入是最核心的一点，如果数据输入量太大，就会占用很多的计算资源。而数据倾斜是在离线数仓中经常会遇到的，数据倾斜分为几种，需要针对性的进行优化。
对有分区的表，合理使用分区可以过滤数据，避免全表扫描，有效的降低计算的数据输入。
SQL支持只读取一次源数据，然后将其写入到多个目标表，这样就保证了只做一次查询。语法如下
当我们在使用join，Rece或者UDF时，先对数据进行过滤也能有效的提高任务的效率
当发生数据再Map阶段倾斜的情况，第一种处理方式反馈至业务层面，看能否通过业务层面的修改让kv值均衡分布，如果业务层面无法处理，那么可以调整Map的个数，也就是加大Map的计算节点，默认情况是每256M的数据为一个计算节点，我们可以将其调小，也就是加大Map处理的节点的个数，使得数据分割的更加均匀一些。
Join阶段的倾斜也是比较常见的，其解决方案需要分钟如下几种情况处理：
Rece倾斜可能的情况有以下几种：
总结一下，性能调优归根结底还是资源不够了或者资源使用的不合理，或者是因为任务分配的不好，使得某些资源分配和利用不合理。
⑥ ETL过程的数据清洗和整合
主要目的是记录ETL流水线过程中所有质量单元出现的错误时间。也可用于其他应用之间传输数据的集成应用中。
如图：
错误事件事实表：
主表。包含错误日历日期，错误产生的批处理作业以及产生错误的单元模块。
每个错误在表中用一行表示。
包含一个单列的主键，作为错误时间的键。
批处理维度:
可以泛华为针对数据流的处理步骤，而不仅仅是针对批处理。
错误事件细节事实表：
每行确定与错误有关的某个特定记录的个体字段。因此某个高级别的错误事件事实表中的一行激活的复杂结构或业务规则对应错误细节事实表中的多行。
审计维度用于后端装配ETL系统的每个事实表。
在货运事实表将按照批处理文件每天更新一次，假设一天的工作顺利进行没有产生错误标记，此时将建立唯一的一行审计维度，将被附加到今天所加载的所有事实行。所有的分类，分数，版本号都将相同
假设出现异常情况，则需要不止一个审计维度行用于标记这一情况。
重复数据删除：需要考虑保留那些数据
匹配和数据保留：按照来自所有可能源系统的列值并且清楚的定义了优先顺序的业务规则，用于确保每个存在的行具有最佳的保留属性。
一致性处理包含所有需要调整维度中的一些或者所有列的内容以与数据仓库中其他相同或者类似的维度保持一致的步骤。
建立一致性维度的过程需要采用敏捷方法，对两个需要一致性处理的维度，他们必须至少有一个具有相同名称和内容的公共属性。
数据仓库-概述-读书笔记一
数据仓库-DW/BI架构对比-读书笔记二
数据仓库-事实表/维度表技术-读书笔记三
维度处理-数据仓库-读书笔记(四)
数据仓库-高级事实表技术-读书笔记五
数据仓库-高级维度表技术-读书笔记六
数据仓库，零售业务举例，维度模型设计4步骤，读书笔记（七）
数据仓库-零售业务举例维度表设计细节-读书笔记（八）
数据仓库-零售业务举例如何提高仓库扩展能力-读书笔记（九）
数据仓库-零售业务中库存如何设计-读书笔记(十)
如何使用缓慢变化维技术
数据仓库-订单管理应该注意那些
ETL中前期数据分析、变化数据探测，数据获取 注意事项
数据仓库基础概念分享
数据仓库工具箱
如果您觉得我用心了，觉得您有所收获，麻烦关注下我吧，您的关注就是我的动力，因为有你，我就不是一个人在前行。
⑦ 什么是数据预处理（在数据仓库中的概念）
数据预处理：就是指在数据进入数据仓库之前，对数据进行清洗转换装载。
⑧ 什么是数据仓库，数据仓库在哪里保存数据。BI项目需要用到哪些技术
数据仓库还是数据库,数据还是在数据库里放着呢,不过是按照数据仓库的理念去设计架构和开发数据库.BI项目主要运用数据仓库,OLAP,和数据挖掘的技术,细分下来又有主流数据库的开发,如oracle,db2,sqlserver, java,cognos,bo,biee,sas,spss,clementine,weka等等
⑨ 数据挖掘的数据处理
数据挖掘的数据处理
从数据本身来考虑，数据挖掘通常需要有信息收集、数据集成、数据规约、数据清理、数据变换、数据挖掘实施过程、模式评估和知识表示8个步骤。
步骤（1）信息收集：根据确定的数据分析对象，抽象出在数据分析中所需要的特征信息，然后选择合适的信息收集方法，将收集到的信息存入数据库。对于海量数据，选择一个合适的数据存储和管理的数据仓库是至关重要的。
步骤（2）数据集成：把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中，从而为企业提供全面的数据共享。
步骤（3）数据规约：如果执行多数的数据挖掘算法，即使是在少量数据上也需要很长的时间，而做商业运营数据挖掘时数据量往往非常大。数据规约技术可以用来得到数据集的规约表示，它小得多，但仍然接近于保持原数据的完整性，并且规约后执行数据挖掘结果与规约前执行结果相同或几乎相同。
步骤（4）数据清理：在数据库中的数据有一些是不完整的（有些感兴趣的属性缺少属性值）、含噪声的（包含错误的属性值），并且是不一致的（同样的信息不同的表示方式），因此需要进行数据清理，将完整、正确、一致的数据信息存入数据仓库中。不然，挖掘的结果会差强人意。
步骤（5）数据变换：通过平滑聚集、数据概化、规范化等方式将数据转换成适用于数据挖掘的形式。对于有些实数型数据，通过概念分层和数据的离散化来转换数据也是重要的一步。
步骤（6）数据挖掘过程：根据数据仓库中的数据信息，选择合适的分析工具，应用统计方法、事例推理、决策树、规则推理、模糊集，甚至神经网络、遗传算法的方法处理信息，得出有用的分析信息。
步骤（7）模式评估：从商业角度，由行业专家来验证数据挖掘结果的正确性。
步骤（8）知识表示：将数据挖掘所得到的分析信息以可视化的方式呈现给用户，或作为新的知识存放在知识库中，供其他应用程序使用。
数据挖掘过程是一个反复循环的过程，每一个步骤如果没有达到预期目标，都需要回到前面的步骤，重新调整并执行。不是每件数据挖掘的工作都需要这里列出的每一步，例如在某个工作中不存在多个数据源的时候，步骤（2）便可以省略。
步骤（3）数据规约、步骤（4）数据清理、步骤（5）数据变换又合称数据预处理。在数据挖掘中，至少60%的费用可能要花在步骤（1）信息收集阶段，而其中至少60%以上的精力和时间花在了数据预处理过程中。
⑩ 数据旅程之数据仓库（一）
二十一世纪是生物的世纪，这句话只要上过高中的小伙伴应该都知道，当初选择大学专业也是受其影响。大一、大二兴致勃勃，乖乖学习，成绩将就，到了大三逐渐发现这并非自己所喜欢的专业（生物医疗专业，但当时想研究基因，脑科学）。并且学校主要专业是通信、计算机等，教学重心根本不在生物医疗上，自己对着冷冰冰的医疗仪器没有什么兴趣，对此非常失望。
大三到来，面临着就业的压力，到底另谋出路还是坚持现在？结合自身特点，加之参加过几次数学建模比赛，发现数据是非常有意思的事物。网上各种调查，发现倒是有数据分析师的职位与数据挂钩，但是有技能要求，经验要求。无意之中，了解到一个在线教育平台（mooc，当时并不是非常流行）。这犹如给我带来了希望，无论逃课还是下课，都泡在图书馆，上Coursera，学习数据课程，才踏上数据道路。 数据因业务而产生，不了解业务也就不了解数据，也就无法利用数据推动业务 ，因此自己也放弃考研，走上数据岗位获取业务经验，更好的学习数据。
前言：数据数据，存储过去，预测未来
实习之初，由于部门人少，虽说岗位是数据开发但做的事情常常鱼龙混杂，了解运营需求、调取业务数据、开发日常报表、处理第三方产品数据，大大小小的事情都干过，也因此对业务有了不少了解。后来因公司业务快速发展，原有的数据仓库架构已不能正常支持日常需求，自己便转向数据仓库开发工作，提升公司数据质量。
数据仓库 ，顾名思义就是存放数据的仓库，英文名称Data Warehouse。
首先了解一下常用的 数据架构 ，如下所示
可以看出数据仓库处于核心位置， 多源数据集成、多维数据建模、数据清洗 都在数据仓库内部完成，为后面报表展示、数据分析、数据挖掘打下坚实的基础，因此数据仓库至关重要。
数据仓库的起源可以追溯到计算机与信息系统初期，它是伴随着支持决策系统出现而出现。
这里的数据模型设计并不是数据挖掘中的数据建模，它是一种数据组织方式，将数据加以整理，便于管理使用。 构建数据模型是为了抽象实体与实体之间联系关系，从而表示事务关系的一种映射 。
当我们在完善数据仓库时，需要根据业务选择合适的模型进行设计，以满足数据上的性能。当公司业务非常复杂时，需要联合使用多种模型方式处理数据 。
有了数据模型之后，需要将数据进行分层，如下图所示
数据仓库的数据质量既是数据使用的基础也是数据平台发展的前提，因而不能掉以轻心。数据质量的保障既需要保障数据准确，同时也要保障数据时效 。那么集群资源充足、网络带宽高就是数据质量保障的基础条件之一。
从数据仓库架构来看，数据质量产生主要有三个方面：
那么对应解决方案也主要在这三个方向：
数据仓库之旅，未完待续。。。。