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

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

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

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

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

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

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

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

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

  就是公司所有的数据相关都归到一个部门中。业务方有任何的需要都会向数据部门提出，数据部门会在内部对这些需求和报表做沟通，避免重复开发，也便于对需求来做总结。

  这种架构的好处是，所有的数据都是一个部门出，相对来说数据的口径会比较统一;

  这个架构的坏处，如果部门组织的不好。会造成数据部门离业务比较远 ;有时候对于数据的思考不够深入，造成与业务部门的沟通成本上升。同时会存在技术部的对于数据***层平台建设的分工,造成与技术部存在一定沟通成本。

  有一个比较大的数据部门，负责数据分析，挖掘，数据统一工作。一般来说这个部门会直接像管理层汇报，主要服务企业管理层;同时也会和业务方的数据分析师合作一起解决某个具体问题。

  在业务方也会有自己的小数据分析团队。这个数据团队主要服务由自己这个业务团队，同时也会和公司的数据部门有沟通和合作。【有的公司会向业务团队开放数据访问权限，有的可能还要他们通过前端的报表获取数据】

  每个方式都有各自的优点与缺点，没有对与错之分;还是要结合公司具体的业务情况，公司规模等来决定，如果一个公司的数据部门从小公司发展到大公司过程中组织架构都没什么变化，可能这不是一个适合有想法的数据人去的公司。哈哈

  我个人观点是：小公司适合分散式;公司发展中间阶段：合适集权式;公司大的时候合适：混合式;

  使用AWS管理控制台或者亚马逊RedshiftAPI，公司能够配置一个2TB数据库;作为选择，公司能够选择由16个2TB超大容量存储(XL)节点组成的一个集群。除了2TB或者16TB存储容量之外，这些节点还有15GB内存或者120GB内存。价格是XL节点每小时85美分，8XL节点每小时6.80美元。

  实习中的一个主要工作就是分析HTTP中的协议，自己也用Python写过正则表达式对HTTP请求和响应的内容做匹配，然后把关键字段抽离出来放到一个字典中以备使用(可以稍微改造一下就是一个爬虫工具)。HTTP协议中的很多坑，自己都遇到过，我就针对自己遇到的几种HTTP常见的数据格式，来做一个总结。