1、关系数据库

在计算机系统的初期，业务系统的雏形刚刚开始，比如记录订单的系统。这个时候，连数据仓库都没有出现。那么用户有数据分析的需求怎么做呢？答案很简单，直接从业务系统来处理数据。这样的场景现在依然存在，比如饭店的收银系统，可以导出一天的交易数据。

随着业务系统越来越复杂，数据分析的要求也越来越高。这个时候，继续在业务系统做数据分析就变得不是很合适，原因之一是业务系统的架构并不擅长处理大量的历史数据分析和多维度的数据建模，二是数据分析对业务系统的性能造成非常大的挑战，甚至影响正常交易进行。

2、数据仓库

基于这样一个情况，数据仓库出现了。其实背后的理念非常简单：专业的人做专业的事情。业务系统专门处理交易型需求，数据仓库处理分析型需求。后来还给两种方式起了两个洋名字：OLTP和OLAP。OLTP擅长处理单个的交易数据，特点是非常具体。比如某一个销售记录。OLAP则关注整体，比如一个月的销售额汇总。需求的不同导致业务系统和数据仓库系统的架构设计也不一样。
可以说数据仓库的出现完美的解决了结构化数据时代的数据分析需求。因为，数据在从业务系统抽取到数据系统的时候，已经经过了清洗，转化和整理，因此数据治理发生在数据使用之前。但是，这样带来了巨大的代价。因为在这种先处理再用的思路下，任何接入的数据不管是否要马上用，都需要事先处理好。

3、数据湖

但是，随着大数据时代的到来，环境发生了变化，使得上面这种先处理后使用的方式成本激增。首先，数据量发生了显著的增加，对传统的数据仓库的存储是一个巨大的挑战，其次，数据结构也非常多元化，不再都是结构化数据，而是出现了半结构化数据，甚至语音视频等非结构数据。但是人们同时意识到数据包含巨大的潜在价值，对于很多数据，即使暂时没有明确的需求，也想先留一份，万一以后用得到呢！

所以，妥协的办法出现了，从先处理后用，变成了先存储，以后用的时候再考虑怎么处理。这就是数据湖的方式。这样做有两个好处，一个是保留了原始数据的原汁原味，这样可以避免任何前期的数据加公造成的数据变形。另外一个好处就是节约了前期数据接入时的成本。
这里可以用一个做菜的场景做一个类比。以前数据仓库的时候，好比把原材料都加工好了，比如土豆清洗，去皮，切片，这样炒土豆片的时候直接炒就可以了。数据湖的时候呢，直接把土豆存储进来，这样以后想炒土豆片就切片，想炒土豆丝就切丝。增加了灵活性的同时，省去了前期头都处理的费用。

4、数据治理

当然，有好处也有坏处，这样就带来了一个问题，那就是数据质量的问题。因为在数据接入的时候，没有做任何数据处理，也就自然缺少了数据质量的把控。等以后真要分析数据的时候，对数据是不是靠谱没有信心。所以，现在出现了所谓数据沼泽的提法，数据是有了，但是不能用，不敢用，不会用。这个问题不解决，挖掘数据价值只能是纸上谈兵。
所以现在数据治理非常热，因为这是切切实实的痛点。没有数据治理的大数据，本就是无根之水无本之木。