企业常见的三种数据部门架构优与

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

在之前的传统BI可能因为这些因素，所以没有达到今天的数据在高度，可能是互联网本身发展的因素，数据对于互联网企业价值。但其中有一个很大的因素，可能是传统的BI，更多是偏重数据仓库的架构，根据需求来帮报表。在数据部门没有一批主动去思考业务，思考业务与数据关系的人。这种人很可能都是在业务方，他们更多把业务问题转为要看的报表，然后与数据部门沟通报表开发，数据部门收集需求沟通后，进行排期，进入比较慢长的等待期。

在一个企业中，可能数据部门在一个公司中组织架构中的位置，决定了部门的定位和一些做的事情，所以个人认为数据部门所处的组织架构对数据价值实现是一个很重要因素。这也是今天我也来谈一谈的主题。

我先把数据部门分成二个部门：一个我们就叫前端，例如：数据分析，数据挖掘，数据产品等;一个我们叫后端：数据仓库，大数据平台等;

第一种形式，分散式

数据平台由技术部建设，技术没有数据分析/业务分析人员;这部分人员都分到各个业务块中。

技术部负责搭建大数据平台(在传统主要叫数据仓库)

目前大数据平台，如果比较大型的公司基本上会包括几块内容：

分布式：hadoop 平台;

实时计算: storm平台

内存计算：spark 平台

传统关系数据库

业务分析人员怎么得到数据：

方式一：向数据平台接口人提需求，在传统的BI部门中一定会有一种叫：需求分析/数据PD这种角度;这种角度就是把业务方的进行转化，转为PRD文档，让ETL开发工程师，报表开发工程师实现 。【业务人员是没有访问数据仓库的权限的】

方式二：当一些业务方比较强势，或者对响应速度比较有意见的时候，可能会开放所有或者部分给业务人员进行去访问，业务可以自己去写SQL去取数据。

这种在一些业务变化不快，或者业务相对不那么复杂的公司可能比较好。但是如果是一些业务复杂，业务变化非常快的可能就不适合。为什么?

数据平台/仓库建议跟不上业务变化。造成数据仓库效率低，数据口径混乱。因为数据仓库架构离业务比较远，对业务理解不深。

业务数据分析师很多人的知识不能很有效沉淀下来。

这会导致业务要求为各个业务建议自己 “数据集市”，当这种数据集市我的时候，又会造成数据仓库负担中，各个业务方的数据“各大自为政”。

最终公司数据混乱，后面大家对数据都摇头。