hive olap 数据仓库_我在hive上搭建数据仓库

一般将hive作为大数据中离线数据的存储，并把hive作为构建数据仓库的环境。可我们也要了解一个事实，hive不支持行级操作，无法像RMDB那样进行updata、delete，add操作。当你将hive作为数据库来使用时，这种设定可能不是你喜欢的。此外，hive的高延迟也会让你头疼，所以都会配备一些即时查询的工具，如presto。

在hive上，如何实现我们的调度和etl，则是另一块工作了。这个等到以后我们再说吧

数据仓库模型介绍

数据开发的工作中，最为核心的则是如何抽象我们的业务过程，通过数据模型来覆盖当前的需求，并考虑它的扩展性、维护性和易用性。关于模型的设计也是众说纷纭，主流的就是Inmon-范式和kimball-维度了，其他数据仓库建设方法论，都被化作细枝末流了。不过对于大数据中数据仓库建设来说，这两位的思想却是成型于RMDB时代，而如何在大数据中应用怎么每个人自己的想法了。

在Inmon和Kimball中，维度建模的方法成为当前互联网的主流选择。伴随互联网业务的快速迭代、更新，响应的敏捷性成为重要的考量指标。而维度建模的方法与之高度契合，它低成本、可集成的方式为企业提供了一个不错的解决方案。

我们经常讨论的维度建模，是以星型模型为主。对它的理解也十分的简单，它的形状像个星星，拥有一个核心源和多个延伸的“手臂”，其中核心源对应的是事实表，“手臂”则为维度表。在整个仓库构建过程中，将我们面向操作的数据，转变为面向主题(域)。将企业中不同的业务过程，建立一个可共享的多维度表和不同业务过程的数据集成。

Inmon在他的代表作《建立数据仓库》中说到，数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。这也成为了公认的数据仓库的定义。

工作几年来，先后经历了一些互联网公司，如果从整体数据建设角度来说，都很扑街。遇到的问题也主要是专业：缺乏数仓理论基础和实践经验

认知：没有从数据管理上思考投入产出，盲目的铺人满足需求

战略：心血来潮，后期便放弃了对数仓的持久性建设

数据分层

分层就像是在盖房子一样，几层，几个门，几个摄像头等。而不同的家庭，对房子的需求不同，设计也不同。从数据仓库角度来说，一个合适的分层结构，能为我们建设数仓带来数据管理、安全、问题定位、血缘关系等助益。通常意义下，一般有有三个层级结构：ODS层(存源数据)、DW层(存宽表)，DA层(存报表)。结合个人的经验，给出一种数据分层的设计。希望有所启发，有不当之处欢迎指出。同步层(Synchronize data level)：以增量的方式存储源系统的数据，并实现历史数据的存档。是整个结构的底层，与源系统的数据应尽量保持一致性。

明细层(Detail data level)：对源系统的数据进行清洗、整理。该层要保留历史数据的衍变情况，考虑缓慢变化维的实现。

模型层(Model data level)：结合业务和当前的数据情况，设计可扩展、易维护的星型模型。该部分是整个数据仓库的核心，结合业务和当下场景，如何布局你的数据仓库。在事实表和维度表中，怎么设计才能够给业务提供有力支撑，以避免走入烟囱式开发的漩涡和数据孤岛等困境，这是个考验。

轻度汇总层(LittleAggregation data level)：这层的输出是业务过程的各种宽表。基于更好的数据支持，我们将维度和事实合并成冗余的宽表，以减少业务分析涉及的数据复杂度和探索成本，解决灵活性和敏捷性的数据需求。

应用层(Application data levl)：该层已涉及到对具体业务场景的满足，是一种高度聚合的数据。它可能是每日销售情况、每月用户变化等

我的建模案例

我曾在一家公司负责搭建一套数据仓库体系，以帮助分析师，将他们从复杂业务逻辑的泥潭中拖出来。经过几个月的奋斗，成果谈不上硕果累累，也略有成就。在这0->1的建设中有了不少的体会和思考，我时不时的在想，如果我能再来一次，会不会变得更好。

业务选择

模型建设之前，选择好你要干的事情。从业务最关心、最重要、最清晰的业务过程去考虑，比如这是一家卖产品的。那么，先去解决大家关心的有关钱的问题吧。这里以我曾经的交易模型来探讨，在面向交易这个过程，应该从哪里着手展开。

在建设模型的时候，一般都会有几个设计阶段。业务模型、逻辑模型、物理模型。业务模型：在交易这个过程中，业务流程有哪些，是否是有关联。可以和业务专家沟通，梳理好整个交易中的流程以及业务关心点。结合调研工作，能够抽象整个业务过程，并将抽象的东西落地形成一个清晰的结构矩阵。

逻辑模型：结合业务模型，探讨具体的实现。将抽象的东西给落地到数据库中，比如事实表中应该有哪些，维度表中应该有哪些，这些落地的东西如何从明细层中转化过来。

物理模型：结合当前的数据库，将逻辑层实现并落地，产出具体的表和数据。

数据探索

有时候很痛苦，不同的开发同事对于相同的业务字段命名不同，有的名称可读性还差。就比如创建时间的命名，多种多样，五花八门也不为过。create_time,created_time,createAt,rec_createtime等等。当然这样的抱怨，并不能改变现状，应该每个人的代码风格不同，在缺少统一审查和规则下，必然存在。

不规范性和低可读性往往也会影响探索的效率，你去找开发也要基于一定的业务知识储备，否则也难免多耗些时间的。所以，在任何数据建设过程中，都应该有相应的规范和知识沉淀。

探索的过程，其实就是一个业务模型建设的过程。你会很自然地想到潜在分析场景有哪些，业务关心点可能出现的地方。如果你了解这个行业，你也一定知道他们要做什么样的分析。再结合业务与自己的摸索，将业务模型整理出来。

模型建设

在交易模型中，事实表的度量被简单的描述为：“花了多少钱，用了多少券，参与了哪些活动”。从星型模型的角度考虑，我们以这个事实为核心，发散其他维度作为"手臂"。这里要考虑到最细粒度是什么：十分重要，拆到不能拆的地步，这样的模型才是最基础的。

性能如何保证：对于海量的数据，怎么样才能够既正确又快速

历史追溯：对缓慢变化维的考虑

交易模型中，我们的产品是多种多样的，有着不同的属性。那么该如何统一为单一的产品维度呢？我的做法是将所有能合并的合并，放大冗余(空值处理为NotApplication,度量值置为0)。我们不能保证所有的产品属性能合并到一个维度表中，但是我们尽可能的将重要的属性放在一起。毕竟数据仓库不能解决所有的问题。除此之外，对于产品维度来说，往往也不止一个，细分的产品维度表也都会有，以此来覆盖尽可能多的业务场景需求。【如果合并导致数据爆炸，这对于性能而言可能是致命的，这时建议换条路来走】

模型交付

模型完成后，模型首先应通过数据质量校验(空值异常、重复异常、度量异常等)，能够覆盖当前的业务流程和数据需求。交付，则是让这个模型开始发挥它最初的目的了。你可能需要介绍、宣传、收集用户反馈(为迭代进行考虑)等。

没有谈到的东西元数据管理

数据质量管理

数据安全策略

面试的一些反馈实时数仓

OLAP与OLTP对比

大数据组件原理与数据存储

窗口函数、行列转换、间断与孤岛

未来可能会变成什么样

对于信息的解析势必会越来越广，将不再局限于当前的文本化数据。对于音频、视频的解析，也许会以其他的模式来展开(本质上都是二进制字符串)。对于当前的边缘计算、深度学习，还处在辨别事物的阶段，是在模拟人的眼睛。以后将会以什么样的方式来模拟人的大脑，对抽象的美丽、丑陋、公平、正义进行辨别呢？

信息承载经历了刻字、印刷、计算机，下一代会是什么呢？