数据仓库

小尝试：基于指标体系的数据仓库搭建和数据可视化 关于作者：小姬，某知名互联网公司产品专家，对数据采集、生产、加工有所了解，期望多和大家交流数据知识，以数据作为提出好问题的基础，发觉商业价值。 0x00 前言 我将整理文章分享数据工作中的经验，因为业务内容上的差异，可能导致大家的理解不一致，无法体会到场景中的诸多特殊性，不过相信不断的沟通和交流，可以解决很多问题。前面我们分析了职场基本功、数据指标体系，今天我们来就前面文章中的指标体系，聊一下 数据仓库的搭建和数据可视化 。 历史导读： 小进阶：数据指标体系和数据治理的管理 小诀窍：不妨尝试从交付质量上打败对手 以下，Enjoy： 0x01 为什么基于指标体系搭建数据仓库 前面文章中我们提到过为什么要搭建指标体系，如果还无法体会指标体系的作用和意义，可以通过历史导读重温前面的2篇文章，或者加入我们的微信群，同大家一起交流。这里简单的在换2句话描述一下做指标体系的重要性。 搭建指标体系实际上是同需求方达成一种协议，可以有效地遏止不靠谱的需求，让需求变得体系且有条理； 数据指标体系是指导数据仓库搭建的基石，稳定且体系的数据需求，有利于数据仓库方案优化，效率提升。 没有数据指标体系的团队内数据需求经常表现为“膨胀”现象。每个人都有看数据的视角和诉求，然后以非专业的方式创造维度/指标的数据口径。数据从业人员被海量的数据需求缠住

基本概念: DW (Data Warehouse) 是一个面向主题的(Subject Oriented), 集成的(Integrated), 相对稳定的(Non-Volatile), 反映历史变化(Time Variant)的数据集合，用于支持管理决策(Decision Making Support)。 ODS (Operational Data Store) 是一个面向主题的, 集成的, 可变的, 当前细节数据集合。 用于支持企业对于即时性的, 操作性的, 集成的全体信息的需求。 与数据仓库(DW)的区别: ODS 是短期的实时的数据, 供产品或者运营人员日常使用, 而数据仓库是供战略决策使用的数据 ODS是可以更新的数据, 数据仓库是基本不更新的反应历史变化的数据 ODS 作为数据库到数据仓库的一种过渡形式, 与数据仓库在物理结构上不同, 能提供高性能的响应是见, ODS设计采用混合设计方式。 ODS中的数据是"实时值", 而数据仓库的数据却是"历史值", 一般ODS中储存的数据不超过一个月, 而数据仓库为10年或更多。 DM (Data Mart) 为了特定的应用目的或应用范围, 而从数据仓库中独立出来的一部分数据, 也可称为部门数据或主题数据(subjectarea)。 在数据仓库的实时过程中往往可以从一个部门的数据集着手, 以后再用几个数据集市组成一个完整的数据仓库。

Hive数据仓库位置配置 1）Default数据仓库的最原始位置是在hdfs上的：/user/hive/warehouse路径下。 2）在仓库目录下，没有对默认的数据库default创建文件夹。如果某张表属于default数据库，直接在数据仓库目录下创建一个文件夹。 3） 修改default数据仓库原始位置（将hive-default.xml.template如下配置信息拷贝到hive-site.xml文件中）。 <property> <name>hive.metastore.warehouse.dir</name> <value>/user/hive/warehouse</value> <description>location of default database for the warehouse</description> </property> 配置同组用户有执行权限 bin/hdfs dfs -chmod g+w /user/hive/warehouse Hive运行日志信息配置 1．Hive的log默认存放在/tmp/atguigu/hive.log目录下（当前用户名下） 2．修改hive的log存放日志到/opt/module/hive/logs （1） 修改/opt/module/hive/conf/hive-log4j.properties

一、数据仓库的特征 　　数据仓库就是一个面向主题的、集成的、稳定的、随时间变化二变化的数据集合。 　　1、面向主题 　　主题是指用户使用数据仓库进行决策时所关心的重点领域，也就是在一个较高的管理层次上对信息系统的数据按照某一具体的管理对象进行综合、归纳所形成的分析对象。 　　2、继承性 　　数据仓库中存储的数据一般从企业原来已经建立的数据库系统中提取出来，但并不是原有数据的简单拷贝，而是经过了抽取、筛选、清洗、转换、综合等工作得到的数据。 　　3、稳定性 　　数据仓库在某个时间段内来看是保持不变的。 　　4、随时间变化性 　　数据仓库大多关注的是历史数据，其中的数据是批量载入的 ，即定期从操作型应用系统中接收到新的数据内，这使得数据仓库中的数据总是拥有时间维度。 二、数据仓库的应用 　　1、决策支持 　　数据仓库系统提供各种业务数据，用户利用各种访问工具从数据仓库获取决策信息，了解业务的运营情况。 　　2、客户分类评价 　　以客户为中心的业务策略，最重要的特征是细分市场，即把客户或潜在客户分为不同的类别，针对不同种类的客户提供不同的产品和服务，采用不同的市场和销售策略。 　　3、市场自动化 　　决策支持帮助企业指定产品和市场策略，客户分类和评价为企业指出了目标客户的范围，下一步是对这些客户展开市场攻势。 三、数据仓库系统的组成 　　 　　1、抽取工具 　

1.背景 最近终于将这个项目测试结束了，之前写过一篇文章，写的是测试过程中遇到的问题，感兴趣的同学可有先去看看上一篇文章。 2.目的 项目结束后问题也没有得到根本解决。宝路由此引发了一些列的思考，今天想跟大家聊聊。 3.引发的思考 前一篇文章写了压测报表系统时的问题，问题抛给某厂商后，厂商人员来了两次做现场支持，然而效果并不理想。深问其产品底层原理，为什么内存回收后会导致，报表系统的“不可用现象”，然而。。。。。。 在这里吐槽下，派来支持的人，远程桌面怎么最小化都TM的不清楚，我也是醉了。 思考1：脚本采用匿名登录的方式来查询报表。 先解释下这里所说的匿名登录，其实就是个白名单，将执行脚本的机器的ip增加值白名单，然后可以通过指定的url来获取token，再拿这个token来访问指定报表。这样就避免了登录系统的步骤。（因为他们自己都没解决登录系统的密码加解密问题，当时也跟他们聊了为不能提供登录密码的加密方式，然而回复却是，目前他们自己测试也是采用匿名登陆方式）。 这样的脚本就极其简单，发送请求获取token，再发一个请求（带token)来查看报表，这种方式是否合理？试想真实环境中用户是这种场景么？显然不是。。。。。试想下这样的方式与真正用LR录制出的脚本相比是不是会少了好些页面请求？ 思考2：忽略思考时间这种压测方式到底有没有问题 这又要说到，前篇文章测试中提到的压测问题

有两个层面/角度来回答这个有趣的问题： 1，逻辑层面/概念层面：数据库和数据仓库其实是一样的或者及其相似的，都是 通过某个数据库软件 ，基于某种数据模型来组织、管理数据。但是， 数据库通常更关注业务交易处理（OLTP），而数据仓库更关注数据分析层面（OLAP） ，由此产生的数据库模型上也会有很大的差异。 数据库通常追求交易的速度，交易完整性，数据的一致性，等等，在数据库模型上主要遵从范式模型（1NF，2NF，3NF，等等），从而尽可能减少数据冗余，保证引用完整性 ；而数据仓库强调数据分析的效率，复杂查询的速度，数据之间的相关性分析，所以在数据库模型上，数据仓库喜欢使用多维模型，从而提高数据分析的效率。 2，产品实现层面：数据库和数据仓库软件是有些不同的，数据库通常使用行式存储，如SAP ASE，Oracle, Microsoft SQL Server，而数据仓库倾向使用列式存储，如SAP IQ，SAP HANA 数据仓库是一个面向主题的(Subject Oriented)，集成的(Integrate)，相对稳定的(Non-volatile)，反映历史变化(Time Variant)的数据集合，用于支持管理决策。 所谓的： 面向主题：指数据仓库中的数据是按照一定的主题域进行组织 集成：指对原有的分散的数据库经过系统加工，整理得到的消除源数据中的不一致性 相对稳定

ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。 　　ETL的实现有多种方法，常用的有三种。一种是借助ETL工具(如Oracle的OWB、SQL Server 2000的DTS、SQL Server2005的SSIS服务、Informatic等)实现，一种是SQL方式实现，另外一种是ETL工具和SQL相结合。前两种方法各有各的优 缺点，借助工具可以快速的建立起ETL工程，屏蔽了复杂的编码任务，提高了速度，降低了难度，但是缺少灵活性。SQL的方法优点是灵活，提高ETL运行效 率，但是编码复杂，对技术要求比较高。第三种是综合了前面二种的优点，会极大地提高ETL的开发速度和效率。 　　 一、 数据的抽取（Extract） 　　这一部分需要在调研阶段做大量的工作，首先要搞清楚数据是从几个业务系统中来,各个业务系统的数据库服务器运行什么DBMS,是否存在手工数据，手工数据量有多大，是否存在非结构化的数据等等，当收集完这些信息之后才可以进行数据抽取的设计。 　 　1、对于与存放DW的数据库系统相同的数据源处理方法 　　这一类数据源在设计上比较容易。一般情况下，DBMS(SQLServer、Oracle)都会提供数据库链接功能

原作者介绍 晓军 1992年加入Sybase中国，之后曾在Informix、 IBM任职， 现在就职于Oracle。专注于数据库和数据仓库十余年。 导语 从上世纪90年代开始，国产数据库的开发就不断被人提起，国内已有不少企业、团体在这个方面做了不少的投入。在此，我们与大家分享一下对几个数据库国产化途径的看法。我们主要讨论自主研发、引进代码和互联网厂商提供的云上数据库。 自主研发 国内自主研发关系型数据库的企业、单位基本上都是发源于上世纪90年代的，而且都是以大学、科研机构为主。到今天，有代表性的厂商有： 南大通用（Gbase 8a）- 南开大学的背景，2010年左右自主研发的，基于列式存储的，面向数据分析、数据仓库的数据库系统。 其他没有列出的，属于在下孤陋寡闻，绝无贬低的意思。 这些公司的发展分为两个阶段，以2007年作为分界线。前一个阶段集中在20世纪90年代，公司的出发点就是开发一款通用的，主要面向OLTP的关系型数据库。在那个年代，中国的人工成本还是比较低的，国外厂商的数据库，如：Oracle，Sybase，Informix，DB2都算是成本较高的产品。很多人认为，只要做出功能、性能、稳定性合适的国产数据库，就能有一定的市场，至少价格能够有优势；即便市场不成功，作为科研教学也有一定价值，至少申请科研经费和政府补贴是个好题材。 但是，这么些年下来

数据仓库概念 数据仓库是一个面向主题的、集成的、非易失的、随时间变化的用来支持管理人员决策的数据集合 面向主题:操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。 集成:数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出数据仓库的核心工具来，进行加工与集成，统一与综合之后才能进入数据仓库； 非易失的:数据仓库中的数据通常以批量方式载入和访问，在数据仓库环境中一般不进行更新 随时间而变化:数据仓库中的每个数据单元只是在某一时间是准确的。在一些情况下，数据中加有时戳，而在另一些情况下记录则包含一个事务的时间。总之，在任何情况下，记录都包含某种形式的时间标志用以说明数据在那一时间是准确的。 数据仓库发展 数据仓库和决策支持系统的起源可以追溯到计算机与信息系统发展的初期。 1. 20世纪60年代：穿孔卡和纸带作为最常用的存储介质，应用以报表处理为特征。 主文件和磁带的使用量的迅速增长，出现了大量冗余数据，导致： 1）更新数据时需要保持数据一致性 2）程序维护的复杂性 3）开发新程序的复杂性 4）支持所有主文件需要大量硬件 2. 20世纪70年代：出现磁盘存储器，数据库管理系统以及在线事务处理（OLTP） 3. 20世纪80年代

总线架构是数据仓库建设的总体规划，从整体视角描述了解决方案的维度模型，描述了各个子系统的功能以及关系，描述数据从源系统到决策系统的数据流程，提供建立企业数据仓库系统的增量式方法。业务需求回答了要做什么，总线架构就是回答怎么做的问题。 一、数据仓库整体解决方案架构 数据仓库的核心功能从源系统抽取数据，通过清洗、转换、标准化，将数据加载到BI平台，进而满足业务用户的数据分析和决策支持。数据仓库整体解决方案架构包含三个部分：源数据、 数据仓库、数据应用。 二、数据仓库分层架构： 数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自下而上流入数据仓库后向上层开放应用，而数据仓库可以是数据中心管控平台。 源数据层（ODS）：此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备，一般只会进行数据筛选和异常处理。 数据转换层（DSA）：数据加工区域，主要涉及数据的转换数据，清洗数据，过滤数据等操作。 数据仓库层（EDW）：DW 层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。 数据应用层（DA 或 APP）：前端应用直接读取的数据仓库；根据报表、专题分析需求而计算生成的数据，数据仓库是数据处理的后台，业务用户并不关心后台怎么处理。数据应用是数据呈现的前台