搞数据仓库，你是不是也踩过这些坑？
把它当成大号数据库使劲塞数据，或者干脆当成BI的附属品。
结果呢？
投入不小，用起来却费劲，数据还是散乱一地，分析决策照样难！
数据仓库到底是什么？它真正的价值在哪？
今天，我们就来一次说清楚，抛开复杂的术语，带你真正搞懂数据仓库是什么以及如何搭建。
一、数据仓库是什么其实很多企业做数据仓库的时候，都忽略了数仓和BI、数据库的区别。
不少人就盯着底层数据折腾，不去做数据服务和应用。说白了，这就是把数据仓库搞狭义了。
实际上，数据仓库既不是BI的附属，也不是数据库的简单升级。
你可以这么想：
公司里的各种数据就像一堆零散的文件，数据库就是装这些文件的柜子，不管文件是啥内容、怎么放的，都往里面塞。听着是不是很熟？很多公司的数据库就是这么用的。
但问题来了：
文件多了、种类杂了，想找某个文件，还得一个个柜子翻，这效率太低了，成本也高。
这时候就需要：一个档案室，给每个柜子编号、把文件归类分组，这样找起来就快多了。
这个档案室，就是数据仓库。它的核心不是存数据，而是让数据变得好查、好用。
但企业的数据来源往往不止一个数据库，所以需要数据仓库去抓取多个数据源的数据。这个抓取、整理、存进去的过程，就是大家常说的ETL（extract, transform, load）。这么理解企业的数据架构，是不是就清楚多了？
所以说到底，数据仓库的本质，就是：
整合多个数据源的历史数据，做细粒度、多维度的分析，帮高层管理者或者业务分析人员做商业决策、出业务报表。二、数据仓库的架构简单来说，数据仓库的架构分四个层次：
1.ODS层存原始数据的地方，直接加载原始日志、数据，不做任何处理。
2.DWD层结构和数据颗粒度跟原始表保持一致，主要是对ODS层的数据做清洗，比如去掉重复的、纠正错误的。
3.DWS层以DWD层为基础，做轻度汇总。比如把每天的数据按周汇总一下，方便后续分析。
4.ADS层专门给各种统计报表提供数据，报表需要什么数据，这儿就准备什么数据。
数仓搭建过程中，数据编排能力很重要。
简单来说，就是：
要有多样化的算子和任务调度方式能处理各种不同类型的数据在标准化要求下，得根据各系统原始的指标定义，形成统一的数据处理逻辑。这里有个关键点要注意：
数据仓库架构里，
各个系统的元数据会通过ETL同步到操作性数据仓库ODS里，然后对ODS层的数据按主题域建模，形成DW（也就是数据仓库的主体）。
而DM（数据集市）是针对某一个业务领域建的模型，最后决策层看的报表，就是从DM里生成的。
也就是说，我们平时看到的数据报表，不是直接从最底层数据里抽出来的。
举个例子：
你访问数据仓库的时候，就像让图书管理员帮你找资料，管理员不会让你自己进仓库翻，而是根据你的需求，从整理好的区域拿给你。
而怎么让这个“找资料”的过程更高效，就是数据仓库建设里很重要的工作——数据建模，包括数据怎么存、逻辑上怎么组织、核心概念怎么定义等等。
问题来了：
不同分厂用的信息系统可能是不同厂商的，这就导致数据仓库里的数据来源特别杂：
有前端系统的（比如供应商系统、招标系统）有MES系统的（每个分厂的MES可能还不一样）还有业务系统的（像CRM、OA、SAP这些，不同分厂用的版本、格式可能都有差异）。于是，数据结构、标准、流程流转方式都不一样。这就导致数据根本没法统一管理，参考价值就没了，等于白忙活一场。你是不是也遇到过这种情况？
这种时候，通常的解决办法就是：实现数据中心化、逻辑统一化。
具体来说：
就是从众多跨地域的业务系统里，
通过实时同步增量数据的方式，把分散的数据汇总到统一的数据中心，从业务数据库里原封不动地把表取出来，形成数据仓库的ODS层，给后面的加工处理当原材料。三、数据仓库怎么搭建看到这里，可能有小伙伴好奇，数仓到底该怎么搭建呢？
搭建数据仓库不是拍脑袋就能成的，得一步一步来，每个环节都得考虑清楚。
我用过来人的经验告诉你，千万别上来就闷头建表、导数据，先把前期准备做扎实了，后面能少走很多弯路。
第一步：明确业务目标和需求这是最开始，也是最关键的一步。
你得搞清楚：公司建这个数仓是为了啥？
是给领导看经营报表，还是帮业务部门分析用户行为，还是为了监控业务流程里的问题？很多人跳过这一步，最后建出来的数仓跟业务脱节，没人用，那不就白搭了吗？
具体要做的就是：
跟业务部门、决策层多聊，把他们的需求一条条列出来。确定营收、用户数、转化率这些核心指标，它们会直接影响后面的数据模型设计。明确数据的时间范围，历史数据的多少，会影响存储和计算的方案。需求不明确，后面的架构设计、数据处理都会跑偏。
第二步：梳理数据源知道了要做什么，接下来就得看看数据从哪来。
公司里的数据一般都分散在各个地方：
业务系统：比如ERP（财务数据）、CRM（客户数据）、OA（办公数据）。数据库：MySQL、Oracle这些，里面存着交易记录、用户信息之类的。日志文件：比如网站的访问日志、APP的操作日志，里面有用户的行为数据。第三方数据：比如从合作方那拿的行业数据，或者买的用户画像数据。梳理的时候，要记下来：
每个数据源的格式：是表结构数据，还是JSON、CSV这种文件更新频率：是实时更新，还是每天更新一次数据量大小：是大批量数据还是少量数据数据的质量：有没有缺失值、重复值，字段定义是不是清晰这些信息后面做ETL的时候都得用到。数据源梳理得越细越好，别漏了哪个系统，不然后面分析的时候发现少了关键数据，再回头补就麻烦了。
第三步：设计数据仓库架构前面说过数仓架构分ODS、DWD、DWS、ADS这几层，由于篇幅限制，这里按ODS、DW、DM简单讲一下各层的编排逻辑：
ODS层：数据存储一般会跟着来源业务系统的分类走，原来系统里怎么分类，这儿就怎么存，数据模型完全不变，原样保留。DW层：这是数据仓库的主体。会把ODS层的数据按主题建各种模型，比如销售主题、用户主题，让数据围绕业务主题组织起来。DM层：也就是数据集市或宽表。这一层是面向最终应用的，一般根据前端报表、业务包的需求来设计。所以DM层的表不用考虑复用，一张表就对应一个报表的需求，这样用起来最直接。结语说白了，建数据仓库不是追求技术高大上，而是要实实在在地解决问题。
它能帮你：
把散落在各处的数据汇集起来，清洗干净、整理有序让数据好查、好用真正服务于业务分析和决策但搭建数仓是个循序渐进的过程，别想着一步到位。
可以先从最急迫的业务需求入手，比如先实现几个关键报表，一步步搭建（ODS->DWD->DWS->ADS），跑通流程，再慢慢扩展。
一个贴合业务、能快速响应的数据仓库，才是企业用好数据资产、帮助业务增长的关键一步。
现在，你对数据仓库的定位和价值，是不是更清晰了？