问题：为什么传统的没有到达今日互联网数据使用的高度呢?

在之前的传统BI或许由于这些要素，所以没有到达今日的数据在高度，或许是互联网自身开展的要素，数据关于互联网企业价值。但其中有一个很大的要素，或许是传统的BI，更多是侧重数据库房的架构，依据需求来帮报表。在数据部分没有一批自动去考虑事务，考虑事务与数据联系的人。这种人很或许都是在事务方，他们更多把事务问题转为要看的报表，然后与数据部分交流报表开发，数据部分搜集需求交流后，进行排期，进入比较慢长的等候期。

在一个企业中，或许数据部分在一个公司中安排架构中的方位，决议了部分的定位和一些做的作业，所以个人认为数据部分所在的安排架构对数据价值完成是一个很重要要素。这也是今日我也来谈一谈的主题。

我先把数据部分分红二个部分：一个咱们就叫前端，例如：数据剖析，数据发掘，数据产品等；一个咱们叫后端：数据库房，大数据渠道等；

***种方法，涣散式

数据渠道由技能部建造，技能没有数据剖析/事务剖析人员；这部分人员都分到各个事务块中。

技能部担任建立大数据渠道(在传统首要叫数据库房）

现在大数据渠道，假如比较大型的公司根本上会包含几块内容：

1、分布式：hadoop 渠道；

2、实时核算: storm渠道

3、内存核算：spark 渠道

4、传统联系数据库

事务剖析人员怎样得到数据：

方法一：向数据渠道接口人提需求，在传统的BI部分中必定会有一种叫：需求剖析/数据PD这种视点；这种视点便是把事务方的进行转化，转为PRD文档，让ETL开发工程师，报表开发工程师完成 。【事务人员是没有拜访数据库房的权限的】

方法二：当一些事务方比较强势，或许对响应速度比较有定见的时分，或许会敞开一切或许部分给事务人员进行去拜访，事务能够自己去写SQL去取数据。

这种在一些事务改变不快，或许事务相对不那么杂乱的公司或许比较好。可是假如是一些事务杂乱，事务改变非常快的或许就不适宜。为什么？

1、数据渠道/库房主张跟不上事务改变。形成数据库房功率低，数据口径紊乱。由于数据库房架构离事务比较远，对事务了解不深。

2、事务数据剖析师很多人的常识不能很有用沉积下来。

这会导致事务要求为各个事务主张自己 “数据集市”，当这种数据集市我的时分，又会形成数据库房担负中，各个事务方的数据“各大自为政”。

终究公司数据紊乱，后边我们对数据都摇头。

第二种方法，集权式

便是公司一切的数据相关都归到一个部分中。事务方任何有需求都会向数据部分提出，数据部分会在内部对这些需求和报表进行交流，防止重复开发，也便于对需求进行总结。

这种架构的长处是，一切的数据都是一个部分出，相对来说数据的口径会比较一致；

这个架构的害处，假如部分安排的欠好。会形成数据部分离事务比较远 ；有时分关于数据的考虑不行深化，形成与事务部分的交流本钱上升。

一同会存在技能部的关于数据***层渠道建造的分工,形成与技能部存在必定交流本钱。

第三种：混合式

大数据渠道建造由技能担任，他们中心是把数据渠道建造的满足强壮。

有一个比较大的数据部分，担任数据剖析，发掘，数据一致作业。一般来说这个部分会直接像管理层报告，首要服务公司管理层；一同也会和事务方的数据剖析师协作一同处理某个详细问题。

在事务方也会有自己的小数据剖析团队。这个数据团队首要服务由自己这个事务团队，一同也会和公司的数据部分有交流和协作。【有的公司会向事务团队敞开数据拜访权限，有的或许仍是需求他们经过前端的报表获取数据】

在这种状况下，或许存在首要问题是会”抢”活干。

每个方法都有各自的长处与缺陷，没有对与错之分；仍是要结合公司详细的事务状况，公司规划等来决议，假如一个公司的数据部分从小公司开展到大公司过程中安排架构都没有什么改变，或许这不是一个适宜有主意的数据人去的公司。哈哈

我个人观点是：小公司适宜涣散式；公司开展中心阶段：适宜集权式；公司大的时分适宜：混合式；