前几天在数据产品经理的群里，有朋友提问“没有数仓，没有数据建模可以做好BI吗”，今天把问题打开一下，不建设数仓，企业能做好数字化转型吗？
首先是能不能做的问题
答案是可以，但不是长久之计，或者说，长远来看做不好。企业不建设数仓，也可以使用数据。就像在大数据火爆之前，很多ERP系统也会提供基础的数据统计分析报表。主要的做法业务系统的研发基于一些关系型的数据库，通常为备份从库。按照业务的指标统计逻辑进行数据加工和处理。曾经和我们公司财务部门沟通BI分析需求时，了解到他们就是这么干的。财务系统的操作数据库是GP库。（OLTP联机数据处理，一般为了快速响应用户的前端操作）为了满足财务部门日常的数据报表需求，财务系统研发人员基于GP写了很多的数据清洗任务，做了一堆的财务报表。
后来，财务研发找到大数据团队，想学习大数据的处理流程和方法，因为他们过去直接基于OLTP的做法遇到了很多痛点问题。
1.定制化开发数据没法复用，需求做不完了
因为每一个报表的逻辑是直接在关系型数据库的基础上，写GP SQL的查询逻辑，前端查询时，直接输出结果。有新的报表需求了，就要再写一遍逻辑，或者copy一遍逻辑。
2.查询性能差，业务和老板天天吐槽技术不行
最开始的时候，数据量比较小，都是内部人员使用的系统。但后来用户量和分析的精细化，直接基于SQL逻辑进行大量的数据查询，每次请求都要重新计算，性能非常差，可能一个报表要加载个5分钟10分钟。所以，在处理的数据量方面有着非常明显的瓶颈。
3.学习成本高，开发离职了没人能接手工作
直接基于OLTP的数据处理不仅在SQL逻辑上冗长复杂，而且有的是基于Java或者其他语言的代码脚本，只有具备相关技术背景的人才能够进行开发和维护。
4.缺少数据资产沉淀，做完的需求就“不见了”
因为加工逻辑是写在接口当中，所以用户端只能拿着输出的报表结果进行后期分析和处理，想去更灵活的数据探查分析，几乎是实现不了的。因为没有结果数据沉淀下来。没有资产沉淀，后期的智能化分析，AI应用就只能另起炉灶了，效率就非常低。
5.运维成本高，业务系统迭代最痛苦
比如，业务系统更新，需要调整指标统计逻辑。前端新增了一个页面。这个时候，就要把所有涉及这个指标的报表逻辑全部去更新一遍。
其次是数据仓库能起到什么作用
数据仓库是一项基础工程，需要花很长的时间以及人力成本进行资产的建设。有些公司的CTO或者业务团队的管理者为了能够快速的给老板汇报“大数据“效果，容易忽略数据基础的建设。而只想要上层的应用。但是，经济基础决定上层建筑，欠的债迟早是要还的。曾经面试过一家公司，早些年的时候，为了追求业务的快速应用，忽略了数据仓库的建设，现在还得回过头来还技术债。因为在这个阶段，数据的复用性以及数据输出的效率已经成为数据团队的最大痛点。’
数据仓库的主要思想是，首先需要把数据统一地从异构数据源（GP、Tidb、MySQL）等统一的汇聚，例如离线数仓一般是基于Hadoop架构的HDFS存储。一是在数据量上，可以支持海量数据的查询和分析，其次，数据逻辑ETL处理时，只需要学习简单的Hive SQL即可。学习成本大大降低。甚至有的数据开发可能会觉得自己就是个写SQL的没啥技术含量。其次，数据按照业务的指标维度的需求加工处理后，常用的数据可以形成物理表，沉淀成数据资产，这样不仅开发自身的可以复用，业务人员可以简单的SQL查询或拖拽式的分析。此外，数据仓库的分层建设，也可以让运维更加高效。比如，业务端新增页面后，只需要修改最底层的ODS层的处理逻辑即可，下游的应用重跑或者第二天周期执行即可实现逻辑的自动更新。
所以，数据仓库对数字化转型的主要价值体现在降本和增效上。可以把散落在企业各个系统各个部门的数据汇聚，打破数据孤岛。此外，随着数据模型的完善，新增业务需求时，直接基于不同的模型进行关联查询，或者简单的select from即可，可以大大的节省定制化开的时间。
数据应用和数据仓库都不是新的名词。不建数据仓库也可以使用数据。但更多的是短期的应急方案。长远来看，企业的数字化转型响应获得长久的成功，就必须重视数据资产的建设、数据资产管理、数据治理工作。
