网站数据信息剖析的1些难题3:数据信息库房有关


网站数据信息剖析的1些难题3:数据信息库房有关的难题


短视頻,自新闻媒体,达人种草1站服务

 

以前的文章内容 网站数据信息剖析的1些难题2中关键梳理了BI有关的难题,这篇文章内容关键想梳理1些数据信息库房有关的难题。由于近期再次在看1些数据信息库房的材料和书本,想把以前和当今遇到的关键难题提出来(blog中相关数据信息库房的有关內容请参考网站数据信息库房这个文件目录),另外自身也对数据信息库房层面的专业知识开展下再次的梳理和了解,并且很久沒有在blog发新的文章内容了,不可以让自身过度散漫了。

以前看过Inmon的《搭建数据信息库房》和《DW 2.0》,而此外1位数据信息库房高手Kimball的《数据信息库房性命周期专用工具箱》1直沒有時间阅读文章,近期才有時间看完了绝大多数,就急不可耐想写点物品了。实际上数据信息库房行业广泛觉得Inmon和Kimball的基础理论是对立面的,二者在搭建数据信息库房上方位性的差别1直争执难休,谁也没法说动谁究竟哪样方式更好。我的Evernote的笔记里边不知道何时从哪里摘录过来了对二者见解的归纳性叙述,十分简约明了而1针见血:

Inmon vs Kimball

Kimball Let everybody build what they want when they want it, we ll integrate it all when and if we need to. (BOTTOM-UP APPROACH)

Pros: fast to build, quick ROI, nimble

Cons: harder to maintain as an enterprise resource, often redundant, often difficult to integrate data marts

Inmon Don t do anything until you ve designed everything. (TOP-DOWN APPROACH)

Pros: easy to maitain, tightly integrated

Cons: takes way too long to deliver first projects, rigid

实际上看了《数据信息库房性命周期专用工具箱》以后,发现二者的见解沒有那末大的实质性差别,将会伴随着数据信息库房的持续发展趋势,二者在总体的构架上渐渐地趋同。基础上,搭建统1的公司级数据信息库房的方位是1致的,而Inmon偏重于从最底层的数据信息集成化考虑,而Kimball则趋于于从顶层的要求角度考虑,这将会跟二者从业的新项目和所处的部位相关。

有了上面这段高品质的归纳,第1个难题 你更偏重于以何种方法构建数据信息库房(BOTTOM-UP or TOP-DOWN),各自有甚么好坏势? 实际上就无需问了,因此下面关键提几个在具体中将会常常遇到或必须想清晰的难题:

Q1、数据信息库房的技术性处理计划方案有哪些,这些处理计划方案的优点在哪儿,短板在哪儿?

伴随着数据信息库房的持续发展趋势和完善, 绝大多数据 定义的盛行,有愈来愈多的有关商品出来,最多见的技术性处理计划方案包含hadoop和hive,oracle,mysql的infobright,greenplum及nosql,或好几个融合应用。

实际上梳理起来就两类:1是用传统式RDBMS为主导的数据信息库管理方法数据信息,oracle、mysql等全是根据传统式的关联型数据信息库,优点便是有更认真细致的数据信息构造,关联型数据信息库对数据信息的管理方法更为标准,数据信息解决全过程中将会出現的不是人为偏差极小,并且规范的SQL插口使数据信息获得的成本费较低,数据信息的查寻和获得更为灵便和高效率;但缺点也很显著,对大量数据信息的解决和储存的工作能力不够,当数据信息量做到1定水平的情况下就会出現显著的短板。而是根据文字的遍布式解决模块,hadoop、greenplum和nosql全是根据文字数据信息的解决和储存,优点是强劲的数据信息解决工作能力,遍布式的构架适用并行处理测算,而且具有超强的拓展拓宽工作能力;缺点便是顶层插口不便捷,因而Hadoop顶层的hive和greenplum顶层的postgreSQL全是以便处理数据信息插口的难题,而且数据信息的查寻和获得很难保证即时回应,灵便性不够。

Q2、数据信息库房是不是就应当储存汇聚数据信息,细节数据信息不可该放入数据信息库房?

实际上这个难题基础早已达到共鸣,假如是搭建公司级的数据信息库房,那末对细节数据信息的集成化和储存是必不能少的,但实际中還是存在许多立即由外部数据信息源测算汇聚以后导入数据信息库房的案例。假如对数据信息库房只是轻量级的运用,仅储放汇聚数据信息也没法厚非,终究没人要求数据信息库房1定如果如何的,最后的目地不过便是考虑对数据信息的适用和要求。

但针对公司的长期性发展趋势看来,数据信息库房中储放细节数据信息有两层面的益处:1层面从技术性层面,数据信息库房储存细节数据信息能够释放出来前台接待数据信息库的查寻工作压力,另外针对文字类数据信息和外界文本文档类数据信息进库以后管理方法更为标准,数据信息库房保存历史时间和不能变动的特点可让信息内容不被遗失;另外一层面便是从数据信息的应用上,数据信息库房让数据信息的获得和应用更为简单,集成化细节数据信息让很多的文字型数据信息可查寻,可关系,而朝向主题的设计方案让数据信息的呈现和剖析更有方位性和目地性,并且细节数据信息是适用数据信息剖析和数据信息发掘运用所必不能少的。因此,假如数据信息库房要持续地催生出更大的使用价值,细节数据信息的储存是必不能少的。

Q3、你会把数据信息库房分成几层,每层的数据信息功效是甚么?

沒有规范回答,依据数据信息库房中数据信息的繁杂性和对数据信息应用的要求水平,数据信息库房能够有无需的等级区划。

我1般会把数据信息库房划成3层:底层的细节数据信息,管理方法对策是提升储存,1般储存导入的初始数据信息,便于开展向上的统计分析汇总,由于数据信息量较大因此必须提升储存;正中间层是多维度实体模型,管理方法对策是提升构造和查寻,朝向主题的多维度实体模型的设计方案,必须考虑OLAP和数据信息查寻的多样要求,另外确保查寻的方便快捷性,重要在与维表的设计方案和维度的挑选及组成,客观事实表必须关心储存和数据库索引的提升;最顶层是呈现数据信息,管理方法对策是提升高效率,1般会储放每日必须呈现的汇总表格,或依据多维度实体模型组装的主视图,呈现层的数据信息必须以最快的速率呈现出来,1般用于BI服务平台的Dashboard和表格。

Q4、数据信息库房构建中最复杂的事儿是甚么,最非常容易缺少的是哪1块?

1判断力得数据信息库房的关键不在于数据信息集成化,自然数据信息集成化是数据信息库房完成使用价值的前提条件,数据信息库房真实的使用价值反映在数据信息的合理运用,数据信息源于业务流程反作用力于业务流程。而构建数据信息库房的关键在于数据信息库房的构架和数据信息实体模型的设计方案,如何衡量数据信息的储存和数据信息获得高效率之间的分歧是数据信息库房管理方法上的难点,这个难点任何数据信息库房都会存在,而绝大多数据增大了这类衡量中的难度。而数据信息的集成化和数据信息品质操纵是数据信息库房构建中最复杂的事儿,特别是数据信息清理的全过程,我以前也写过几篇数据信息品质操纵的文章内容,但实际中这个全过程还要繁杂很多,并且以便顶层数据信息产出的精确性和合理性,这项工作中又迫不得已做,并且要做得尽可能细腻。

构建数据信息库房中最非常容易缺少的便是对元数据信息的管理方法,非常少了解据库房精英团队具有详细的元数据信息,自然构建数据信息库房的工程项目师自身便是活的元数据信息,但不管是以便用数据信息的人還是数据信息库房本身的精英团队着想,元数据信息都不能或缺。1层面元数据信息为数据信息要求方出示了详细的数据信息库房应用文本文档,协助她们能独立地迅速获得数据信息,另外一层面数据信息库房精英团队组员能够从平常的数据信息解释中摆脱出来,不管是对后期的持续迭代更新升级和维护保养還是学习培训新的职工,都十分有益处,元数据信息可让数据信息库房的运用和维护保养更为高效率。

写在最终:以上仅意味着本人见解,欢迎大伙儿积极拍砖,更为期待大神们能在评价中得出珍贵的回答,任何角度的见解和探讨都可以以,众长。

网站数据信息剖析的1些难题1

网站数据信息剖析的1些难题2