一般企业的数字化发展到一定阶段的时候就会有数据分析、数据挖掘等高层次的数据需求，这时候会开始考虑建设数据仓库，一般数据仓库分离线数据仓库和实时数据仓库，这两种类型怎么选？各有什么特点？
来跟大家聊一聊。
一、数仓要不要做？
在数字化转型过程中、建数仓并不是优先项，对于中小企业，数据量不大的企业完全没有必要做。
数仓的成本比较高，一是大数据技术人员薪资高，二是服务器集群成本高。
中小企业虽然不做数仓，但是我们数据治理还是要做的。主要围绕业务数据来做就行，其它的数据先别管，以贵司目前的实力还没能力分析业务数据之外的数据。
建议直接使用mysql从生产库的只读库用数据同步工具(Kettle、Canal、Datax)同步到报表项目的数据库即可。
报表系统的数据也要对数据按照数据治理的规范来进行简单的治理，ODS层+DWD层，报表工具直接从DWD层取数报表。ODS层是同步过来的源数据，DWD层是简单治理后的明细宽表。
例如：在业务系统中，我们的订单表只保存了一个客户的账号ID，我们在DWD时把对应的客户基础信息都拉过来。 做过报表开发的同学应该是理解的，实现报表时我们避免不了要做中间宽表。
中小企业先不要上数仓，先实现报表；不要好高骛远，在企业不具备深度应用数据的能力时建数仓只是用大炮打蚊子。
也可以使用第三方的数据中台产品，这些中心产品一般的简化了开发部署难度，只要会sql就可以用低代码的方式实现数据仓库。
对于大企业来说，数仓是必须要建的；因为数据量和数据的范围已经不是用简单的办法能处理得了的，需要专业的人，专业的技术来治理。
大企业也有使用数据的条件，深度的数据分析、挖掘只有在企业上了规模后带来的收益才会明显。
二、做离线数仓还是实时数仓？
致于是离线还是实时，这个要根据当前数据的主要用途而定。
如果主要是为了报表分析，数据挖掘，首推方案是离线T+1，Hadoop+Hive。
对于报表分析来说其实并没有这么多的实时需求，一般只有对外的大屏，供人参观的地方需要用到。这些数据纯缀是为了好看(显示实力)，对于决策管理并没有任何帮助。
少部分特殊地方需要实时数据的，实时数一般日、周数据，最多不会超过一个月，超过一个月那一定是产品经理的问题。
这时业务系统数据库能满足的情况下直接使用api从业务系统聚合输出即可。
如果场景多，直接从生产库拿数据满足不了话；可以用Kafka+Flink+Hbase来处理增量部分的数据，然后和离线Hive数据的历史数据合并后交给前端应用使用。
不管是离线还是实时，最终ADS层的数据都要落到如mysql这种结构化数据库里；API接口将ADS层的离线数据和实时数据查询出来后合并起来交给前端大屏即可。
这样的好处是实时数仓的数据量会很小，离线是T+1的情况下，实时数仓只要处理当天的数据即可。昨天实时处理的数据合并进离线数仓后，就不用保存了。
如果数仓是为了支持风险监听、拦截那么就必须要实时数仓；首推方案是Kafka+Flink+Hbase。
数据仓库具体怎么做，大家可以一起来探讨；
总结：对于大企业来说，基本是离线+实时双数仓；离线用于数据分析/挖掘，实时用来风险监控，实时的信息推荐。 中小企业暂时没必要做数据仓库，先把报表做好即可。
三、数据部门人才梯队怎么搭？
中小企业：
中小企业的数据需求基本是数据报表这一块，看板展示可使用成熟的BI工具，对人才的要求没要太严格。
一般招一个专业一点的数据产品经理+2-3个数据分析工程师+1个ETL工程师即可。
产品经理负责指标体系的搭建，数据宽表的设计，数据看板设计。
数据分析工程师负责数据看板的实现。
ETL工程师负责数据的抽取工作。
大企业：
数据治理专家+数据产品经理+大数据架构师+ETL工程师；人数根据项目的情况来定。
数据挖掘的算法工程师根据项目需要来吧，这一块其实大多企业前期是用不上的；只有在做数分析这一块应用得比较好了才会往深度上钻研。
总结：人才这块，企业一定要先找到一个专业的首席数字官（CDO），可能价钱会贵一点，但是可以让企业少走很多弯路，避免很多损失。正所谓方向不对，努力白费。