近期看到好多企业在设计本身的数据..，以及选型一些数据剖析对象，正好拜读了数据仓库之父的《数据架构：大数据、数据仓库以及Data Vault》一书，有些许感想，就来聊一下小我思虑吧。
首先从企业信息化成长阶段时，数据..构造的水平来看。小我遵照企业信息化，将数据..阶段划分为：只有买卖数据库——>中央库——>完美数据仓库（DW）——>数据集市（Data Mart），顺序与阶段并不停对准确，或者有组合，或者地点阶段不完全一致。以下先看各个数据..阶段特点，再看对应阶段数据剖析对象选型的考虑吧。
1.买卖数据库
一个企业IT信息化扶植最初的阶段，买卖库中数据量不大，要剖析展示下数据情形啦，不慌，问题不大，这时候OLTP构造下也能够写写SQL快速显现，随便玩玩office对象也没问题。
然则跟着时间的推移，各类问题起头显现：
（1）查询和写入频率越来越高，高频write和和长时间read辩说越来越严重。而数据剖析要花消大量较量资源，不克动不动挂买卖系统吧。
（2）数据量越来越大，汗青买卖数据啦，新买卖数据激增啦，第一要务就是要解决买卖应用效率问题了，谁管数据剖析里的问题呢。
（3）买卖越来越多，表构造越来越复杂。买卖系统数量的越来越多，导致数据孤岛起头形成。
这种情形下，企业面临数据展示与数据..扶植的阶段了要怎么处理。这种情形下要做数据剖析就麻烦了，要工资去各个系统取数，人力是一个方面。各个系统口径定名啥都有差别，工资的处理失足率高就是另一方面。
2.中央库
因为上述问题，就要引入中央库来处理。左图构造解决了高频write和read辩说问题，以及单数据库办事器机能问题，顺手也搞定了数据备份。这种情形下呢简洁查询照样能够的，然则在转换聚合等需要多表关系、以及大数据量等买卖复杂度高的情形下，其处理机能就不容乐观了。
此时就起头考虑能够行使余暇时间的办事器机能来做预先处理呢。右图这种T+n的预处理离线较量的架构就显现了，引入自力的义务调剂和较量引擎：较量压力能够交给数据库处理，也可交给ETL处理，显现机能初步解决。
然则这种情形下，数据库表构造实在太甚复杂，每做一个剖析，就要理一次买卖逻辑、写一段sql，还没法进行汗青追溯，以及数据整顿功效的复用，so sad。
那有没有理一次之后，后续可以省点事的体式呢？这时候数仓的概念就能够使用上了。
3.完美数据仓库（DW）
把买卖库数据整顿成星型构造，包管了事实的储蓄和维度的追溯。自由选择需要的维度和相关事实进行筛选较量，麻麻再也不消担心每次写sql都要去看“蜘蛛网”了。还有索引、究竟表、分区分表等等黑科技来包管每次查旬需扫描的数据量最小，解决数据库机能问题。
当然这种架构体式的瑕玷也很显着，不是企业内一致的数据（多系统，多主题数据纷歧致），就会发生信息孤岛。当然，若是客户企业就是很小，就一个系统，不消整合，一个数据集市足以的情形下采用这种体式也能够。常见情形是会在各个自力的DW间竖立一些对照表，可实现数据交流。若是多个DW间没有物理阻隔，也能够形成EDW。
4.完美数仓+数据集市（Data Mart）
为了实现各个买卖系统取数剖析，或许做更多把持，就实现中心数据仓库EDW从各个源系统收集数据，再将数据供应给各个数据集市和挖掘仓库使用。这也被称为企业信息工场架构（CIF），一样情形下，大型企业会破费很多精神实现这类架构。
买卖复杂度的提高与数据量级的增大以及对这些数据的应用，促成了各个大数据..的繁荣，这个放到另一篇文章陈述。
无论是以什么架构存在，数据展示的需求都必弗成少。剖析对象选择必弗成少，要在以上阶段以一款对象涵盖，那必然需要一款既能够做迅速数据集市建模，又能够做数据展示剖析的对象来处理。这种对象可对买卖数据进行简洁、快速整合，实现迅速建模节约时间，而且能够大幅度提拔数据的展示速度，可对接前端的数据剖析展示层，实现自由数据展示与OLAP剖析，典型如各类BI剖析对象。
数据剖析也很考验剖析对象数据读取、运算的机能，但拥有大数据量较量引擎的BI剖析对象并不多。像FineBI（www.finebi.com）与其高机能数据引擎在以上几个阶段均可在分歧水平解决好多场景。
（1）买卖数据库阶段，此阶段已经陈述过，重点问题就是较量机能影响大，以及数据孤岛问题。竖立数仓的过程相对迅速数据集市而言，时间照样久的。这个时候就看看竖立个常规意义的数仓和数据展示需求谁更紧要啦，或许或者有的也没建数据..的意识也说禁绝。此时快速的数据展示需求，就能够经由将数据放到FineBI的数据引擎中撑持实现。
（2）中央库与完美数仓阶段，此阶段其实首要就是较量机能问题了，用户的数据量级也必然挺大了。正好借助于FineBI的分布式引擎，完成数据加快较量工作。此引擎属hadoop生态，焦点较量引擎行使的spark，借助了alluxio作为内存加快较量，处理了大数据较量问题，也很好阐释了“大数据”。这个在接下来的文章中也会说到，这里先埋个伏笔，暂不赘述。
此阶段呢，一定有一些响应时间要求较高的展示需求，多次功课同步或者带来延迟影响。而FineBI的引擎扩展了kettle的插件，实现数据能够直接load到引擎中，却是将麻烦的功课处理工作解决了。
（3）完美数仓+数据集市阶段，这种阶段数据..扶植已经很完美了，各买卖部门数据量级，买卖复杂度都很高。
底层手艺上固然数据集市是竖立在集成的中心数据仓库EDW上，然则这些数据集市之间照样不克进行数据交流的，人人竖立的方式和ETL法式都邑分歧，各个数据集市之间的数据不见得的是一致，且..架构超等复杂，扩展以及再为各买卖部门设计较量层究竟表之类都相对麻烦。此时可考虑部门需整合数据放到迅速数据集市处理，可直接对接的再直接对接处理。FineBI的引擎正好都知足如许的场景需求，前端OLAP剖析正好也有，简洁处理整合展示一站式解决。
