三种数据部门架构优与劣

上海天元项目数据分析师事务所有限公司
问题：为什么传统的没有达到今天互联网数据应用的高度呢?

在一个企业中，可能数据部门在一个公司中组织架构中的位置，决定了部门的定 位和一些做的事情，所以个人认为数据部门所处的组织架构对数据价值实现是一个很重要因素。
我先把数据部门分成二个部门：一个我们就叫前端，例如：数据分析，数据挖掘，数据产品等；一个我们叫后端：数据仓库，大数据平台等；

种，分散式
数据平台由技术部建设，技术没有数据分析/业务分析人员；这部分人员都分到各个业务块中。
技术部负责搭建大数据平台
目前大数据平台，如果比较大型的公司基本上会包括几块内容：
1、分布式：hadoop 平台；
2、实时计算: storm平台
3、内存计算：spark 平台
4、传统关系数据库
业务分析人员怎么得到数据：
方式一：向数据平台接口人提需求，在传统的BI部门中一定会有一种叫：需求分析/数据PD这种角度；这种角度就是把业务方的进行转化，转为PRD文档，让ETL开发工程师，报表开发工程师实现 。
方式二：当一些业务方比较强势，或者对响应速度比较有意见的时候，可能会开放所有或者部分给业务人员进行去访问，业务可以自己去写SQL去取数据。
这种在一些业务变化不快，或者业务相对不那么复杂的公司可能比较好。但是如果是一些业务复杂，业务变化非常快的可能就不适合。为什么？
1、数据平台/仓库建议跟不上业务变化。造成数据仓库效率低，数据口径混乱。因为数据仓库架构离业务比较远，对业务理解不深。
2、业务数据分析师很多人的知识不能很有效沉淀下来。
这会导致业务要求为各个业务建议自己 “数据集市”，当这种数据集市我的时候，又会造成数据仓库负担中，各个业务方的数据“各大自为政”。
终公司数据混乱，大家对数据都摇头。

第二种，集权式
就是公司所有的数据相关都归到一个部门中。业务方任何有需要都会向数据部门提出，数据部门会在内部对这些需求和报表进行沟通，避免重复开发，也便于对需求进行总结。
这种架构的好处是，所有的数据都是一个部门出，相对来说数据的口径会比较统一；
这个架构的坏处，如果部门组织的不好。会造成数据部门离业务比较远 ；有时候对于数据的思考不够深入，造成与业务部门的沟通成本上升。
同时会存在技术部的对于数据底层平台建设的分工,造成与技术部存在一定沟通成本。
第三种：混合式
大数据平台建设由技术负责，他们核心是把数据平台建设的足够强大。
有一个比较大的数据部门，负责数据分析，挖掘，数据统一工作。一般来说这个部门会直接像管理层汇报，主要服务公司管理层；同时也会和业务方的数据分析师合作一起解决某个具体问题。
在业务方也会有自己的小数据分析团队。这个数据团队主要服务由自己这个业务团队，同时也会和公司的数据部门有沟通和合作。
在这种情况下，可能存在主要问题是会"抢"活干。

总结（个人观点）：小公司适合分散式；公司发展中间阶段：合适集权式；公司大的时候合适：混合式。