一般将hive作为大数据中离线数据的存储，并把hive作为构建数据仓库的环境。可我们也要了解一个事实，hive不支持行级操作，无法像RMDB那样进行updata、delete，add操作。当你将hive作为数据库来使用时，这种设定可能不是你喜欢的。此外，hive的高延迟也会让你头疼，所以都会配备一些即时查询的工具，如presto。
在hive上，如何实现我们的调度和etl，则是另一块工作了。以后有机会再谈谈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)：该层已涉及到对具体业务场景的满足，是一种高度聚合的数据。它可能是每日销售情况、每月用户变化等
这些层级都有固定的处理方式，在跨层级处理中，会增加一个temp层，用于中间处理过程中的临时数据。临时层数据的丢失不会影响整个业务过程。
我的建模案例
我曾在一家公司负责搭建一套数据仓库体系，以帮助分析师，将他们从复杂业务逻辑的泥潭中拖出来。经过几个月的奋斗，成果谈不上硕果累累，也略有成就。在这0->1的建设中有了不少的体会和思考，我时不时的在想，如果我能再来一次，会不会变得更好。
业务选择
模型建设之前，首先做的事情便是了解面对的是什么，解决什么难题，达成什么成果。一般会从业务过程去考虑，比如这是一家卖凉鞋的。那么，首当其冲要解决的问题便是钱的问题。这里以我曾经的交易模型来探讨，面向交易过程中，会怎么考虑
在建设模型的时候，一般都会有几个设计阶段。业务模型、逻辑模型、物理模型。
业务模型：在交易这个过程中，业务流程有哪些，是否是有关联。可以和业务专家沟通，梳理好整个交易中的流程以及业务关心点。结合调研工作，能够抽象整个业务过程，并将抽象的东西落地形成一个清晰的结构矩阵。
逻辑模型：结合业务模型，探讨具体的实现。将抽象的东西给落地到数据库中，比如事实表中应该有哪些，维度表中应该有哪些，这些落地的东西如何从明细层中转化过来。
物理模型：结合当前的数据库，将逻辑层实现并落地，产出具体的表和数据。
数据探索
有时候很痛苦，不同的开发同事对于相同的业务字段命名不同，有的名称可读性还差。就比如创建时间的命名，多种多样，五花八门也不为过。create_time,created_time,createAt,rec_createtime等等。当然这样的抱怨，并不能改变现状，应该每个人的代码风格不同，在缺少统一审查和规则下，必然存在。
不规范性和低可读性往往也会影响探索的效率，你去找开发也要基于一定的业务知识储备，否则也难免多耗些时间的。所以，在任何数据建设过程中，都应该有相应的规范和知识沉淀。
探索的过程，其实就是一个业务模型建设的过程。你会很自然地想到潜在分析场景有哪些，业务关心点可能出现的地方。如果你了解这个行业，你也一定知道他们要做什么样的分析。再结合业务与自己的摸索，将业务模型整理出来。
模型建设
在交易模型中，事实表的度量被简单的描述为：“花了多少钱，用了多少券，参与了哪些活动”。从星型模型的角度考虑，我们以这个事实为核心，发散其他维度作为"手臂"。这里要考虑到：
1. 最细粒度是什么：十分重要，拆到不能拆的地步，这样的模型才是最基础的。
2. 性能如何保证：对于海量的数据，怎么样才能够既正确又快速
3. 历史追溯：对缓慢变化维的考虑
交易模型中，我们的产品是多种多样的，有着不同的属性。那么该如何统一为单一的产品维度呢？我的做法是将所有能合并的合并，放大冗余（空值处理为NotApplication,度量值置为0）。我们不能保证所有的产品属性能合并到一个维度表中，但是我们尽可能的将重要的属性放在一起。毕竟数据仓库不能解决所有的问题。除此之外，对于产品维度来说，往往也不止一个，细分的产品维度表也都会有，以此来覆盖尽可能多的业务场景需求。【如果合并导致数据爆炸，这对于性能而言可能是致命的，这时建议换条路来走】
模型交付
模型完成后，模型首先应通过数据质量校验（空值异常、重复异常、度量异常等），能够覆盖当前的业务流程和数据需求。交付，则是让这个模型开始发挥它最初的目的了。你可能需要介绍、宣传、收集用户反馈（为迭代进行考虑）等。
没有谈到的东西
1. 元数据管理
2. 数据质量管理
3. 数据安全策略
面试的一些反馈
1. 实时数仓
2. OLAP与OLTP对比
3. 大数据组件原理与数据存储
4. 窗口函数、行列转换、间断与孤岛
未来可能会变成什么样
 对于信息的解析势必会越来越广，将不再局限于当前的文本化数据。对于音频、视频的解析，也许会以其他的模式来展开。对于当前的边缘计算、深度学习，还处在辨别事物的阶段，是在模拟人的眼睛。以后将会以什么样的方式来模拟人的大脑，对抽象的美丽、丑陋、公平、正义进行辨别呢？
网友评论