数据仓库

1. 引言 本篇主要讲述数据仓库系统的体系结构与组成要素、数据集市与数据仓库之间的关系、元数据的定义与作用。 在 上一篇 ，笔者介绍了数据仓库的定义： “数据仓库是一个面向主题的、集成的、不可更新的、随时间不断变化的用来更好地支持企业或组织决策分析的数据集合。” 数据仓库是区别于传统操作型数据库的数据集合，主要应用于分析型数据操作，支持企业全局的决策分析。但是要实现这一应用目的，单一的数据仓库是无法完成的，需要建立一个数据仓库系统。 基于数据仓库系统，完成数据从操作型数据库等数据源到数据仓库或者数据集市的流动、传输，以支持前台的决策分析处理工作。 2. 数据仓库系统的体系结构 一个典型的数据仓库系统的体系结构图，如下所示。 简单地说，数据从操作型数据库、文件、网络等数据源，通过ETL集成工具进行数据抽取、清洗、转换、加载等工作，进入到数据仓库和数据集市中，进而通过OLAP服务器支持前台的多维分析、查询报表、数据挖掘等操作。 3. 组成要素 数据仓库系统是由数据源、集成工具、数据仓库与数据仓库服务器、OLAP服务器、元数据与元数据管理工具、数据集市和前台分析工具等组成。 （1）数据源： 数据源就是提供初始数据的地方，是数据仓库系统的基础。通常包括企业内部数据和外部数据。内部数据包括各种操作型数据库中的数据以及文档数据，外部数据包括各类法律法规、市场信息

前言 数据仓库建模包含了几种数据建模技术，除了之前在数据库系列中介绍过的 ER建模 和 关系建模 ，还包括专门针对数据仓库的维度建模技术。 本文将详细介绍数据仓库维度建模技术，并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系：规范化数据仓库，维度建模数据仓库，以及独立数据集市。 回到顶部 维度建模的基本概念 维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。 它本身属于一种关系建模方法，但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念： 1. 维度表(dimension) 表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。 2. 事实表(fact table) 表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。 注：在数据仓库中不需要严格遵守规范化设计原则(具体原因请看 上篇 )。本文示例中的主码，外码均只表示一种对应关系，此处特别说明 。 回到顶部

以主题域规划 DW 主题域包含了某方面决策者关注的事物。一个主题域通常会覆盖多个业务部门，例如产品主题域涉及到销售、财务、物流、采购等部门。 主题域下包括了主题，例如产品主题 域中包括成本、发运、库存等主题。 主题域模型是对业务模型的抽象，需要从决策者和管理者的角度反映企业业务模型。决策者不需要了解每个部门详细的业务细节；销售部门的管理者需要知道产品的库存和采购计划以安排销售，但是他不知道物流部和采购部的业务流程。因此在整合多业务部门数据同时，尽量减少 OLTP 数据库中的具体业务逻辑，以实现数据交付时更易于理解、更具效率。 EDW 开发 在开发模式上，一种是逐个开发多个数据集市，然后将这些数据集市合并成数据仓库。这种方法的优点是在初期效率高、见效快，但由于这些数据集市独立运作，后期的管理、整合就会碰到问题，最后往往成为一种 Hub 的形式，多个数据集市支撑着一个中心数据集市。 另一种开发模式是，先开发统一的数据仓库，然后由数据仓库支撑多个数据集市。但这种方式在大型企业实施困难，甚至是难以实现的。 实际上比较可行的是平行开发，每开始着手新的数据集市同时，调整数据仓库，将新的内容加入到数据仓库中。这种模式需要一定经验和对企业整体的了解，以便为数据仓库的下一次调整和扩充留下空间和弹性。 熟悉 Business Applications 企业中通常会有多种商业应用程序，比如 ERP 、

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> BI/数据仓库/数据分析 基础入门：一些常见概念解释 什么是数据仓库？ 数据仓库的架构 数据仓库多维数据模型的设计 数据仓库的架构以及数据分层 数仓的基本操作 数据仓库模型 数据建模相关 数仓进化史 举例：网站ctr流量数据分析 数据产品及开发流程参考 PowerBI可视工具参考 数据仓库的基础架构和处理流程参考： 来源： oschina 链接： https://my.oschina.net/u/1998220/blog/1841668

[目录] 第一章：概述 第二章：整体数据分层 第三章：整体实现框架 第四章：元数据 第五章：ETL 第六章：数据校验 第七章：数据标准化 第八章：去重 第九章：增量/全量 第十章：拉链处理 第十一章：分布式处理增量 第十二章：列式存储 第十三章：逻辑数据模型（数仓模型） 第十四章：数据模型参考 第十五章：维模型 第十六章：渐变维 第十七章：数据回滚 第十八章：关于报表 第十九章：数据挖掘 数据仓库实践杂谈（八）——去重 数据重复是一个比较麻烦的事情。从正常逻辑上来看，如果应用系统和数据卸出的程序没问题，不应该存在这个问题。但实际情况来看，确又时有发生。一旦确定数据源的数据会有重复的可能，就需要专门进行去重处理。 在数据量很大的情况下，去重很耗时。所以如果可以，尽量先行优化数据源系统。 最直观的去重可能就是先把数据加载到数据库中，然后通过select distinct *，直接把重复的数据去掉。但一般来说这是个悲剧。这种操作如果无法在分布式体系下执行，将会非常慢。 从算法角度，去重的处理流程包括如下两个步骤： 先排序，需要对所有数据进行整体排序；一般整行数据会比较大，可以先计算没一行数据的MD5（此MD5值可以保留，以后也有用的），然后针对MD5值进行排序； 然后逐行检查是否跟下一行相同，如果不同，下移一行；如果相同，标记出来，再看下一行是否相同，直到不同为止。 先说排序

第三篇：数据仓库系统的实现与使用(含OLAP重点讲解) 转载自：https://www.cnblogs.com/muchen/p/5318808.html 前言 上一篇 重点讲解了数据仓库建模，它是数据仓库开发中最核心的部分。然而完整的数据仓库系统还会涉及其他一些组件的开发，其中最主要的是ETL工程，在线分析处理工具(OLAP)和商务智能(BI)应用等。 本文将对这些方面做一个总体性的介绍(尤其是OLAP)，旨在让读者对数据仓库的认识提升到一个全局性的高度。 回到顶部 创建数据仓库 数据仓库的创建方法和数据库类似，也是通过编写DDL语句来实现。在 过去，数据仓库系统大都建立在RDBMS上，因为维度建模其实也可以看做是关系建模的一种。但如今随着开源分布式数据仓库工具如Hadoop Hive，Spark SQL的兴起，开发人员往往将建模和实现分离。使用专门的建模软件进行ER建模、关系建模、维度建模，而具体实现则在Hive/Spark SQL下进行。没办法，谁让这些开源工具没有提供自带的可视化建模插件呢:-(。 话说现在的开源分布式工具都是"散兵作战"，完成一个大的项目要组合N个工具，没有一个统一的开发平台。还有就是可视化效果比较差，界面很难看或者没有界面。个人建议在资金足够的情况下尽量使用商用大数据平台来开发，虽然这些商用产品广告打得多少有点夸张，但是它们的易用性做的是真好

先抛出几个问题 1. 存储是不是基石？ 2. 假如存储不挂，数据真的准确吗？ 3. 存储挂了，数据还准确吗？ 4. 如何校验是否正确？如何让其正确？机制是不是必须有？ 注： sqoop 抽数据，无 error 丢数据的概率很小 数据质量校验：数据量校验 count 相同吗？ count 相同内容相同吗？ 数据量相同-->数据量不同 重刷机制 补 or 删 spark 95%-->数据内容不同？ 抽样 5% 现在重点理解一下重刷机制 背景：用 count 校验上下游的数据不准确 引入重刷机制：通过对上下游的两个表求 full outer join 来对比字段的 null 值 上游表a 1 data1 18 2 data2 19 3 data3 20 7 data7 22 下游表b 1 data1 18 3 data3 19 5 data5 20 6 data6 21 我们发现表 a 和表 b 对比 表 a 少了 5 和 6 多了 7 ，表 b 少了 2 和 7 多了 6，我们现在对两个表做 full outer join aid bid 1 ruoze1 18 1 2 ruoze2 19 null 3 ruoze3 20 3 7 ruoze7 22 null null null null 5 null null null 6 以表 a 为标准，对生成后的大表做筛选，分别查找 aid

1、数据仓库建设 一般在OLAP中使用维度建模，在OLTP中使用3NF建模 数据仓库的建设主要分为以下四个步骤 ：业务建模 -> 领域建模 -> 逻辑建模 -> 物理建模 （要理解其大概步骤） 互联网数仓与传统数仓还是有所区别的，主要在操作的是人员、数据的加工ETL、以及对业务的支持模式(数据立方体或数据中台) 维度建模 缺点：一般在ODS层不用维度建模，因为无法百分百保证一致性，并且假如在ODS层时出错了，恢复数据的成本很大， 维度建模需要对数据较多的预处理，投入的存储空间和人力资源较大 优点：比较适合做分析 范式建模 缺点：范式建模不太适合做复杂的分析 优点：处理起来简单 要知道数据中台与数据库的区别 2、Sql应用题 （1）统计连续登录超过三天的用户 Mysql （2）row_number实现 （3）limit 分页时跨度过大如何解决（子查询） Hive （4）row_number （5）开窗函数 （6）行转列、列转行的方法 （7）缓慢变化维 3、优化方面 一、数仓整体优化可以从以下4个方面优化 （1）模型优化 选定合适的建模方法 适当拆表、合表、创建中间表 合理对待缓慢变化维 合理使用分区表、二级分区表等 （2）调度优化 尽量少依赖、减少长依赖 关键任务定时时间提前 生产任务与测试任务尽量库与库之间隔离 （3）同步优化 注意数据同步任务的资源性能 计算资源优化、减少数据倾斜

随着大数据的到来，经常听到相关的词汇，维度、指标、BI、PV、UV等等，今天整理了这些词汇。 1. DW DW是Data Warehouse的缩写，即数据仓库。 DW要区别于普通数据库，数据仓库用于支持决策，面向分析型数据处理；而普通数据库主要服务于软件/网站，对于一致性/事物要求较高。 数据仓库是一个支持管理决策的数据集合。数据是面向主题的、集成的、不易丢失的并且是时间变量。数据仓库是所有操作环境和外部数据源的快照集合。 数据粒度 数据粒度，是指数据仓库中数据的细化和综合程度。根据数据粒度细化标准：细化程度越高，粒度越小；细化程度越低，粒度越大。 2. 数据集市（DM） 数据仓库是一个支持管理决策的数据集合。数据是面向主题的、集成的、不易丢失的并且是时间变量。数据仓库是所有操作环境和外部数据源的快照集合。 CRM 客户关系管理（Customer Relationship Management），数据仓库是以数据库技术为基础但又与传统的数据库应用有着本质区别的新技术，CRM就是基于数据仓库技术的一种新应用。但是，从商业运作的角度来讲，CRM其实应该算是一个古老的"应用"了。比如，酒店对客人信息的管理，如果某个客人是某酒店的老主顾，那么该酒店很自然地会知道这位客人的某些习惯和喜好，如是否喜欢靠路边，是否吸烟，是否喜欢大床，喜欢什么样的早餐，等等。当客人再次光临时，不用客人自己提出来

看了这么多数仓模型的对比文章，我想把我总结的一些东西记录下来。 说到数仓建模，那么肯定离不开两种方式：范式建模（Inmon）和维度建模（kim ball）。这两种方式各有适用的地方，需要根据具体应用场景进行选择。当然还有一种独立数据集市的方法，不过这种方法容易造成很多数据烟囱以及数据孤岛（没有一致性维度和一致性事实的支持，是无法支持支持多主题区域，并且使得各个数据集市成为信息孤岛，缺乏兼容性。），无法广泛性的运用，这里就不讨论了。 Inmon Inmon建模的方式是自下而上的，那么什么是自下而上呢？我的理解是先打好广而全的数据基础，考虑当下业务场景中的所有可能，基于范式建模的理念去设计数据仓库，然后基于各种业务场景去开发数据集市以及BI应用。 Kimball 而kimball的方式是自上而下的，这种方式就不用考虑很大的框架，针对某一个数据域或者业务进行维度建模，得到最细粒度的事实表和维度表，形成适用于某一个数据域、业务的数据集市之后，再集成各个数据集市为数据仓库。这其中的要点就是保持各集市之间的一致性维度和一致性事实，不然在集成为数据仓库的时候很麻烦，会无法确认各个集市之间的数据具有关联性、通用性。kimball的这种范式就是开发速度比较快，相对比较省事，但是后续维护会比较麻烦。 在这里引用一张图，相信大家就能比较清楚的了解kimball和Inmon的区别了。 图片来自 来源网址