数据仓库技术选型，离线数仓和实时数仓如何选择？

编辑搜图

请点击输入图片描述（最多18字）

企业数字化转型过程中，面对海量数据的分析需求，建数据仓库是必选项。那么建数据仓库时是选择离线数仓还是实时数仓，下面老高分享一下自己的踩坑经验；让企业少花冤枉钱。

先得简单介绍一下老高的踩坑历程，血的教训，以警后人。

最开始我们做数字化转型时包括我自己在内的高管都没有数字化、信息化的意识；我们之所以做是看到大家都在做，同行的效率比我们高，所以也做了。整个过程完全没有理论体系化的指导，盲人摸象，边踩坑边学习。

数字化的概念也是后面踩坑失败了，浪费了不少钱才去外面咨询，参加学习，自学后才有的。

我们意识到数据的价值从业务系统开发时就有了，所以在系统上线后就立即着手做数据报表；但是当时我本人并没有大数据相关的知识积累，也没有意识到大数据，数据治理都没听说过。

所以我们第一版的数据报表中心是简单粗暴的自研了一套系统，把业务系统的数据拉过去，然后用脚本跑计划任务。其中没有使用任何大数据技术，报表后面的数据库也是没有数据仓库的分层分类的概念。当时计算一个用户留存的梯形报表，计划任务脚本跑一次数据要两天。 每次大批量同步数据时，还会把生产库耗死。

不用说这项目失败了，浪费了半年的研发时间。

第二次是我招了一个技术总监过来，他给我和老板灌输的数据仓库，数据治理概念；公司高度认可了他的方案，然后招人起项目。因为我们刚好也要做系统的java技术重构，所以就招的是java团队，然后让他们临时学习大数据相关的技术。

因为我当时对大数据相关的技术一窍不通，所以技术选型完全由技术总监做主，采用的是flink+doris的实时数仓方案，之所以要实时因为我当时觉得有些报表是要实时滚动展示的。很遗憾，这次又失败，浪费了半年，技术总监+研发团队被我全砍掉了。失败的原因是技术总监自己也只简单的了解过，我们还是用sql脚本拉报表的模式来做数据仓库，根本没有数据治理的意识。结果就是原来sql脚本两三天做好的看板，到了数仓一个月做出来，结果数据还不准确。用了实时的技术，最终做了离线的事。

这次失败浪费了10个月左右，连续的两次失败可谓是教训惨痛，也让老高从小白成长变成大白。

那么正确的数据仓库建设办法是什么？且听老高胡扯一番。

一、数仓要不要做？

在数字化转型过程中、建数仓并不是优先项，对于中小企业，数据量不大的企业完全没有必要做。

数仓的成本比较高，一是大数据技术人员薪资高，二是服务器集群成本高。

中小企业虽然不做数仓，但是我们数据治理还是要做的。主要围绕业务数据来做就行，其它的数据先别管，以贵司目前的实力还没能力分析业务数据之外的数据。

建议直接使用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），可能价钱会贵一点，但是可以让企业少走很多弯路，避免很多损失。正所谓方向不对，努力白费。