企业常见的三种数据部门架构优与劣
问题：为什么传统BI没有达到今天互联网数据应用的高度呢?
在之前的传统BI可能因为这些因素，所以没有达到今天的数据在高度，可能是互联网本身发展的因素，数据对于互联网企业价值。但其中有一个很大的因素，可能是传统的BI，更多是偏重数据仓库的架构，根据需求来帮报表。在数据部门没有一批主动去思考业务，思考业务与数据关系的人。这种人很可能都是在业务方，他们更多把业务问题转为要看的报表，然后与数据部门沟通报表开发，数据部门收集需求沟通后，进行排期，进入比较慢长的等待期。
在一个企业中，可能数据部门在一个公司中组织架构中的位置，决定了部门的定位和一些做的事情，所以个人认为数据部门所处的组织架构对数据价值实现是一个很重要因素。这也是今天我也来谈一谈的主题。
我先把数据部门分成二个部门：一个我们就叫前端，例如：数据分析，数据挖掘，数据产品等;一个我们叫后端：数据仓库，大数据平台等;
第一种形式，分散式
数据平台由技术部建设，技术没有数据分析/业务分析人员;这部分人员都分到各个业务块中。
技术部负责搭建大数据平台(在传统主要叫数据仓库)
目前大数据平台，如果比较大型的公司基本上会包括几块内容：
- 分布式：hadoop 平台;
- 实时计算: storm平台
- 内存计算：spark 平台
- 传统关系数据库
业务分析人员怎么得到数据：
方式一：向数据平台接口人提需求，在传统的BI部门中一定会有一种叫：需求分析/数据PD这种角度;这种角度就是把业务方的进行转化，转为PRD文档，让ETL开发工程师，报表开发工程师实现 。【业务人员是没有访问数据仓库的权限的】
方式二：当一些业务方比较强势，或者对响应速度比较有意见的时候，可能会开放所有或者部分给业务人员进行去访问，业务可以自己去写SQL去取数据。
这种在一些业务变化不快，或者业务相对不那么复杂的公司可能比较好。但是如果是一些业务复杂，业务变化非常快的可能就不适合。为什么?
- 数据平台/仓库建议跟不上业务变化。造成数据仓库效率低，数据口径混乱。因为数据仓库架构离业务比较远，对业务理解不深。
- 业务数据分析师很多人的知识不能很有效沉淀下来。
这会导致业务要求为各个业务建议自己 “数据集市”，当这种数据集市我的时候，又会造成数据仓库负担中，各个业务方的数据“各大自为政”。
最终公司数据混乱，后面大家对数据都摇头。
第二种形式，集权式
就是公司所有的数据相关都归到一个部门中。业务方有任何需要都会向数据部门提出，数据部门会在内部对这些需求和报表进行沟通，避免重复开发，也便于对需求进行总结。
这种架构的好处是，所有的数据都是一个部门出，相对来说数据的口径会比较统一;
这个架构的坏处，如果部门组织的不好。会造成数据部门离业务比较远 ;有时候对于数据的思考不够深入，造成与业务部门的沟通成本上升。同时会存在技术部的对于数据最底层平台建设的分工,造成与技术部存在一定沟通成本。
第三种：混合式
大数据平台建设由技术负责，他们核心是把数据平台建设的足够强大。
有一个比较大的数据部门，负责数据分析，挖掘，数据统一工作。一般来说这个部门会直接像管理层汇报，主要服务公司管理层;同时也会和业务方的数据分析师合作一起解决某个具体问题。
在业务方也会有自己的小数据分析团队。这个数据团队主要服务由自己这个业务团队，同时也会和公司的数据部门有沟通和合作。【有的公司会向业务团队开放数据访问权限，有的可能还是需要他们通过前端的报表获取数据】
在这种情况下，可能存在主要问题是会"抢"活干。
每个方式都有各自的优点与缺点，没有对与错之分;还是要结合公司具体的业务情况，公司规模等来决定，如果一个公司的数据部门从小公司发展到大公司过程中组织架构都没有什么变化，可能这不是一个适合有想法的数据人去的公司。哈哈
我个人观点是：小公司适合分散式;公司发展中间阶段：合适集权式;公司大的时候合适：混合式;
本文作者：佚名
来源：51CTO
