数据仓库

1.github创建上游仓库 2.执行git fetch 而后git pull <origin> <branchname>拉取远程仓库分支 主要是为了下面push时无冲突 3.git remote add master <origin> 设置远程提交分支 4.执行正常git add git commit 5.首次push时需指定刚才设置的远程master分支 git push --set-upstream master master 来源： https://www.cnblogs.com/pp2018/p/11361852.html

核心思想：预计算。 　　对多维分析可能用到的度量进行预计算，将计算好的结果保存成Cube，并存在HBase中，供查询时直接访问 　　将高复杂度的聚合运算、多表连接……操作转换成对预计算结果的查询。决定了Kylin拥有很好的快速查询、高并发能力 　　理论基础：空间换时间 Cuboid：Kylin中将维度任意组合成为一个Cuboid Cube：Kylin中将所有维度组合成为一个Cube，即包含所有的Cubeid 　　为了更好地使用Hadoop大数据环境，Kylin从通常用来做数据仓库的HIve中读取源数据，使用Mapreduce作为Cube构建的引擎，并将于计算结果保存在HBase中，对外暴露Restful API/JEBC/ODBC的查询接口。 　　Kylin支持标准的ANSI SQL,所以可以和常用分析工具（Tableau、Excel）进行无缝对接 restful api： 　　符合REST架构设计的API。 　　RESTful架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用 　　REST，即Representational State Transfer的缩写 　　如果一个架构符合REST原则，就称它为RESTful架构 　　什么是RESTful架构： 　　（1）每一个URI代表一种资源； 　　（2）客户端和服务器之间

&Hive产生背景 1.MapReduce编程的不方便性 2.传统RDBMS人员的需要 HDFS上的文件没有schema概念 &HIve概述 1.由Facebook开源，用于解决海量结构化日志的数据统计问题 2.构建在Hadoop之上的数据仓库 3.Hive提供的SQL查询语言：HQL 4.底层支持多种不同的执行引擎 MR/Tez/Spark 5.提供统一元数据管理，Hive数据是存放在HDFS，元数据信息（记录数据的数据）是存放在MySQL中 7.简单统一上手，为超大数据集设计的计算/扩展能力 8.HIve在Hadoop生态系统中的位置 Hive官网概述： The Apache Hive ™ data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage using SQL. Structure can be projected onto data already in storage. A command line tool and JDBC driver are provided to connect users to Hive. Apache Hive™数据仓库软件支持使用SQL读取

标题为“数据分析师如何进行数据仓库建设？”，那么就先对数据分析师、数据仓库工程师这两种角色进行简单的描述。 数据分析师：根据主题分析需求，抽取对应的数据进行分析的人员。分析需求来源以及分析结果应用在此就不详述了； 数据仓库工程师：顾名思义，就是对数据仓库进行设计和实现的人员。设计模型及实现手段在此就不详述了。 那一名数据分析师在数据仓库建设中有什么优势呢？ 1、直接接触业务，对业务的理解更深； 2、对建设何种数据主题更有助于业务分析更有经验； 3、对数据更敏感，也更能快速确认数据异常的情况； 来源： https://www.cnblogs.com/sherial/p/11341706.html

来源： https://www.cnblogs.com/akic/p/11340914.html

1、为什么要建设数据仓库？ 为了更快更好的响应业务上的分析需求。 1.1、数据仓库建设方法？ 建设流程：梳理业务主题--》ER图(ER模型)--》逻辑建模(关系模型)。其中，数据仓库建设过程即ER图到关系模型的实现过程，数仓模型也属于关系模型中的一种，只是在此基础上需要考虑几个问题： 1）哪些维度对分析主题有用？ 2）如何使用当前数据建设维表？ 3）用什么指标度量主题？ 4）如何使用当前数据建设事实表？ 2、为什么要做元数据管理？ 为了更好的管理不同层级数据表的属性，以及其间的关联关系、父子关系，以实现快速追溯、核查。 3、为什么要做数据质量管理？ 为了保证数据的完整性、准确性、一致性、及时性。一旦数据质量出现问题，任何用数据作支撑的业务分析都是无效的。 3.1、数据质量管理办法？ 1）完整性 2）准确性 3）一致性 4）及时性 来源： https://www.cnblogs.com/sherial/p/11340159.html

7.1 数据仓库准备工作 为什么要对数据仓库分层？ l 用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据； l 如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大 l 通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。 数据仓库标准上可以分为四层：ODS（临时存储层）、PDW（数据仓库层）、MID（数据集市层）、APP（应用层） ODS层： 为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。一般来说ODS层的数据和源系统的数据是同构的，主要目的是简化后续数据加工处理的工作。从数据粒度上来说ODS层的数据粒度是最细的。ODS层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存； PDW层： 为数据仓库层，PDW层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质

01 Hive的基本介绍 1、hive产生的原因 · a) 方便对文件及数据的元数据进行管理，提供统一的元数据管理方式 ​ b) 提供更加简单的方式来访问大规模的数据集，使用SQL语言进行数据分析 2、hive是什么？ The Apache Hive ™ data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage using SQL. Structure can be projected onto data already in storage. A command line tool and JDBC driver are provided to connect users to Hive. ​ Hive经常被大数据企业用作企业级数据仓库。 ​ Hive在使用过程中是使用SQL语句来进行数据分析，由SQL语句到具体的任务执行还需要经过解释器，编译器，优化器，执行器四部分才能完成。 ​ （1）解释器：调用语法解释器和语义分析器将SQL语句转换成对应的可执行的java代码或者业务代码 ​ （2）编译器：将对应的java代码转换成字节码文件或者jar包 ​ （3）优化器

文章转自： http://chinabi.net/blog/user1/105/390.html 这是IT pub上一篇帖子引发出的问题，以前还真没去仔细思考这个问题：为什么要建立数据仓库，数据仓库和数据库的区别？因为理论上的优点说法都很多，但要真正很好地理解，能简洁地向客户阐述明白，让客户觉得建立数据仓库是一件值得做的事情，还是值得讨论一下这个问题。有如下一些朋友们说法（自己在批注处谈点个人的意见）： A 数据库是一个装数据（信息的原材料）的地方。 数据仓库是一种系统，这种系统也是用数据库装东西。（这有点没说清楚：个人理解数据库和数据仓库当然都是装数据的地方，关键的区别是装的什么样的数据，数据库装的原始数据，没经过任何加工；而数据仓库是为了满足分析需要，对源数据进行了Transform过程，具体是怎样一个处理过程，可以从Bill Inmon的仓库定义四个特性进行理解。） 数据仓库系统（用数据库装东西）与其他基础业务系统（例如财务系统、销售系统、人力资源系统等，也是用数据库装东西）的区别是： 基础业务系统的特点是各管各的，例如财务系统生产了白菜，那么用一个数据库来装，人力资源系统生产了猪肉，再用一个数据库来装。我要做一道菜，需要分别到各个数据库去取，比较麻烦（现实的情况是大部分时候让种菜的农民伯伯送过来，但送过来的东西不一定是我想要的，而且不同的时候我想要不同的东西

在做项目时是不是时常让客户有这样的困扰： 1、开发时间太长 2、花费太多 3、需要太多资源 4、集成多个事务系统数据总是需要大量人力成本 5、找不到合适的技能和经验的人 6、一旦建立,数据仓库无法足够迅速地应对变化 7、一直达不到客户的期望 8、业务人员很难获得数据仓库的数据 9、传统构建数据仓库费用极其可怕地保持运行后建立架构和设计不足,缺乏项目文档和团队支持 10、数据仓库有太多太复杂的工具和技术，不好分辨那个工具是实用的 11、构建数据仓库一直以来是一个高风险的任务 选择ETL工具的维度有很多都可以影响你的决策，如时间、成本、易用性、云能力、未来需求变化的应对能力等等。当有一个工具能够在同一时间解决这些困扰你的因素你会选择么？在寻找ETL工具之前其实更好的方式是总结数据仓库构建过程中真正导致失败的原因： 缺乏强有力的执行团队 不完整的企业级数据仓库体系结构和文档 缺乏数据仓库设计思维 执行团队未获知完整的需求 分析过程没有及时验证原型 企业级数据仓库数据库设计没有可扩展性和适应性 执行团队从来没有构建数据仓库 需求采集不懂业务 没有专业技术团队协同开发的工具 数据集成证明比预期的更困难 一个好的数据仓库解决方案可以给你节省大量时间和成本，易用性的工具可以让企业不在困扰没有足够强大的技术团队项目后期。你可能觉得在寻找一个能够轻松应对客户需求变化的ETL工具很困难