一件事物若能经得起时间的推敲，经得起历史的选择，回过头去看仍能矗立在长河之中，那我们通常会称它为“经典”。

​

10年前，Pentaho公司（一家开源BI公司）的CTO詹姆斯·迪克森在他的博客中第一次提出“数据湖”（Data Lake）的概念；10年后的今天，在业界“数据中台”大火的时代背景下，再来讨论“数据湖”，应该别有一番韵味。

本文将会以“数据湖”为中心，展开讨论数据仓库、数据湖和数据中台这几个概念之间的藕断丝连。

事物总是在不断演化的，唯一不变的就是变化，因此为了讨论这些概念，我们首先要了解其历史流变。

“数据仓库”，由比尔·恩门（Bill Inmon）于1990年提出，其被广泛接受的定义是，一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策，通常也被认为是决策支持型应用的必要条件。

此处的定义大多都是针对事务型数据系统而制定的。所谓事务型数据系统，是指记录业务交易的系统，这个名词先是在金融业，特别是银行实施信息化IT系统时使用的。例如银行的交易流水数据库，每分每秒都有大量的交易被数据库所记录并持久化的保存下来，其最小的颗粒度就是一笔“交易”。后来信息化系统在各行各业开花结果，“业务”渐渐演变为现在的“事务”概念，例如员工刷卡进入办公室，后台就会记录员工的这一“事务行为”。

事务性数据系统存在诸多劣势：试想，如果一个银行的分行长想知道今天到目前为止共有多少现钞存款入账，那么系统就需要遍历今天截止到目前的所有交易行为，并筛选其中的存款行为进行汇总。查询交易的行为需要遍历当前系统的所有记录，因此当这一行为频率变高时，会对数据系统造成巨大的读取压力。

其次，当分析业务时需要的信息变多，也就是查询行为的数据对象范围变广时，例如分行长想知道今天一共有多少人民币现汇（包括外币购汇）入账时，系统需要将每笔外汇交易换算成人民币，再进行全部交易的汇总。假设有一百种外币进行了一万次的交易，数据系统内的计算空间会呈“笛卡尔积”般的增长，造成资源上的重大消耗。

除开查询或分析任务对事务型数据系统造成的资源压力外，系统执行任务时，返回的结果只代表着任务开始运行那一刻的数据状态，假设执行查询任务消耗了1分钟，这1分钟内很有可能发生多次的交易撤销、额度修改，增加交易等行为。有些数据系统允许在读取数据的同时写入数据，那么查询任务返回的结果并不能代表最新的状态；有些数据系统则有“读锁”，即在读取数据的时候不允许写入数据，那么这个长达1分钟的查询任务会使得业务交易失败或者暂缓进入数据系统，如果其中发生业务中断，这些交易数据可能面临丢失的风险。

当然，我们可以通过技术手段来避免或缓解事务型数据系统的不足，因此事务型的数据库并不是不能做业务分析，只是当决策者需要进行经营性的分析和决策时，大多数时候它并非最优方案。此时，数据仓库面向主题且便于分析的优势就体现出来了：

相对于事务型系统将交易类型（存款）、交易币种（人民币或外币）、交易数值（存款额）以一条事务（Transcation）的方式存储，数据仓库通常会将一条事务中的不同信息拆分到不同的主题域中分别存储，例如交易类型表、交易币种表和交易额度表等。

不同主题域中的信息之间以统一的ID，如交易流水号为标识进行链接。

这样的好处是当分行长想知道今天到目前为止一共有多少人民币存款入账时，只需要先筛选出交易类型为存款，交易币种为人民币的交易流水号，再基于这些流水号去汇总交易额度，比起原先需要遍历全部交易记录后才能汇总的方式大大节约了系统资源的开销。

通常数据仓库和事务型数据系统会被物理隔离在不同的硬件资源上，前者注重数据的查询（读取），后者注重数据的录入（写入），避免了单一数据系统读写冲突的问题。

正是由于通常数据仓库中的数据是基于预先设定好的时间窗口从事务型系统中获取数据，无论是一分钟、一小时还是一天、一周，它都是可以反映数据整体历史变化的，分行长可以清楚地知道今天银行的人民币存款入账环比昨天增长或减少了多少，同比上个月的今天又发生了什么变化。

因此，比起事务型的数据系统，数据仓库能更有效地对业务数据进行统计分析，无论是在提高效率、稳定性还是降低资源成本上都有其优势，所以被广为接受而大行其道。我们可以清楚地看到，数据仓库是数据处理中一种特定的实施方法。

后来，数据仓库领域的大师Ralph Kimball又演化出“维度建模”的概念，认为数据仓库是一系列数据集市的集合。如果说数据仓库中包含着许多不同的主题域，那么数据集市可以理解为主要面向业务应用的单一主题域。比如，分行长可以建设面向存储部门的、专门提供存款数据的“存款数据集市”，面向商业贷款部门的“贷款数据集市”，面向信用卡部门的“信用卡数据集市”等，其数据都源自数据仓库，但数据集市的汇总程度更高、更注重业务表示。例如“环比存款增长率”这个指标在数据仓库中可能表示为“上月存款额”和“本月存款额”两个不同的数值，而在数据集市或者数据仓库的“集市层”中，就表示为计算后的一个数值，可以直接被业务所用而无需再做多余的计算。

而“数据湖”这个概念，由Pentaho公司的CTO詹姆斯·迪克森于2010年提出，这里渐渐开始有了商业的味道。他认为：

因为当时业界正兴起“XaaS”的风潮，例如软件即服务（SaaS，Software as a Service），平台即服务（PaaS，Platform as a Service），基础设施即服务（Iaas，Infrastructure as a Service），甚至还有解决方案即服务（SolaaS，Solution as a Service）以及数据中心即服务（DCaaS，Data Center as a Service）。在这一背景下，已发展成熟的公有云能力为数据湖体系架构的发展奠定基础，催生“数据湖”的概念。

接着在2011年，福布斯在文章《Big Data Requires a Big, New Architecture》中报道了“data lake”这个词，并给出了数据仓库与数据湖的对比：数据仓库的数据在被集成时就会被预先分类，并以最优的方式进行存储，以支撑特定的分析；但在大数据时代，我们从源系统抽取数据时可能无法明确知道这些数据的价值，因此无法给出一个最优的存储方式。

例如，分行长从交易系统中将所有的数据都抽取过来，但并不知道业务部门想做什么类型反映业务历史的变化。因此建议将这些数据先保存在一个海量的数据库中。由于数据来源的格式五花八门而且会越存越多，因此这个数据库需要具备容易访问且存储成本低（允许硬件资源扩容的成本而尽可能降低其他成本，例如软件使用费用、人工维护费用等）的特性，需要进行分析时，再来组织和筛选所需数据，这个数据库就是数据湖（Data Lake）。

彼时的数据湖概念更多地是关于当企业在处理海量异构的数据时，如何在数据产生实际的应用价值之前，为海量数据构建一个易访问且成本低的存储方式，和数据资产化、资产服务化等当下热点名词并没有太大关系。

但事物都是在不断演化的，2014年福布斯杂志上刊登了一篇名为《The Data Lake Dream》的文章，文章作者EddDumbill描述了数据湖的愿景：

从这个时候开始，单纯的数据湖就朝向一个“平台级的方案”而演进。为什么说是方案呢，因为时至今日，数据湖仍是个架构概念，是一种架构设计的理念，而不是一种特定的实施方法，更不是一款特定的产品。其所要达成的目标囊括了不止一种数据技术，已经从当初的一种“大数据存算方案”进阶到了“大数据存算+处理分析+资产治理+安全隐私+数据变现”的一揽子方案。

10年前，迪克森曾认为“数据湖”是面向企业的最佳大数据解决方案。从技术上来看，其论点是有根据的，但是从商业价值上来看，这个愿景似乎并没有被实现。实际情况是过去数据仓库的落地实践要远比数据湖来的多和广。而就在现今所有人都在强调数据资产化、资产业务化，强调数据变现和数据商业价值的年代，数据中台的概念似乎又代替了数据湖的概念。

数据中台，由于受到从业者的追捧并在这两年疯狂流行，隔着屏幕应该都可以嗅到浓重的商业气息，但目前对其仍然没有清晰明朗的定义。当大多数人努力想要为数据中台做名词解释时，我倒认为这个局面十分恰当且正常。

首先，数据中台的概念如同数据湖一样，是一种架构概念；其次，它不仅是工程设计上的技术架构，还包括了组织架构的变革，因为中台通常会强调其作为一个企业组织运作的“独立性”、“中央性”和“统一性”。

中台作为抽离原来各个数据部门共性业务、由技术和人员并提供统一数据、产品及服务的“共享业务事业部”，无论在业务功能上还是工程技术上都会有其独立运作，数据权威和统一分发的诉求，因此其组织承载的考核目标及衡量标准较原先的数据仓库、数据湖等技术概念而有所不同，特别是在“数据驱动业务”、“数字化转型”的时代大背景下，它们是和企业的总体业务目标紧密相关的，不再只是一个“旁路IT系统”，不再只是一个业务信息化的支撑系统，而是产生并驱动业务的关键环节。数据中台应当是企业组织和技术架构的有机结合体。

科学技术的发展有其自有的原发性，而商业世界里对一项技术的认可并将其广泛商业化应用的动力，仍来自于商业目的的要求。数据技术也是如此，业务诉求的发展推进了技术的革新。

大数据平台，数据湖，数据仓库和数据中台这些概念有什么不同，到底是谁代替了谁？我相信非专业领域的从业人员每当看到这些词汇的时候或多或少有这样的困惑。我认为，这里并没有谁代替了谁，所谓孰优孰劣只是从不同的业务需求出发得出的不同结论而已。

当企业的信息化发展到一定程度，企业流程得以用数据的形式持久化的留存下来，决策者们的判断依据慢慢从经验主义过渡到数据主义，因此90年代初为了更好的支持经营的决策分析，数据仓库的技术就油然而生并被广泛应用。

当企业开始迈向全面数字化的阶段，需要处理的数据越来越多、形式越来越杂，原先使用的数据存算方式其成本越来越高，业务对数据处理的效率要求也越来越快。在这种背景下，企业亟需一种成本更低且效率较高的方式来存算数据、访问数据，因此大数据技术孕育而生。我们通常说的大数据平台就是利用大数据技术而搭建的平台型能力，为企业提供大数据技术服务。

而当企业迈入大数据时代后，纷纷利用大数据技术搭建各自的大数据平台。为了进一步降低数据存储和处理的成本，提升大数据平台的可用性、可靠性和可运营性，解决大数据时代数据分析链路越来越长、数据探索复杂度越来越高、数据资产管理越来越难以及数据变现的路径尚不清晰等问题，基于数据湖的架构概念，我们又开始在大数据平台上尝试搭建各自的数据湖架构。由此可见，数据湖也是由业务诉求催生出的平台架构概念和能力。

所谓分久必合，当企业的数字化、数据化成为一种常态时，有些企业发现内部存在纷繁复杂的数据源，存在多个所谓大数据平台甚至是数据湖，导致了很多不必要的重复性建设，包括服务、软件和硬件层面的冗余，或是由于部门壁垒而导致数据无法有效统一来支持前端业务，不统一的数据出处又带来数据不一致的问题，亦或是不同部门各起炉灶导致数据技术人员各自分散的问题。在这种背景下，由高层拍板构建企业级的数据中台，把原有资源剥离和再分配，将共性抽象集成并形成资产，统一面向全组织提供服务。这里的服务包括了数据资产、产品软件、算法算力甚至是技术人力。

因此，我认为这三者没有谁对谁错或是谁替代了谁，只是企业不同的发展背景形成了不同的建设目标，各自有不一样的业务诉求罢了。

业务诉求会推动技术的发展，有时技术本身的革新也会带给业务发展更多的想象空间。

如同前文所述，随着时代的发展，技术也在不断演化，但其演化历程通常是具有连续性而非跳跃性的。当然，跳跃性的原始创新会被历史所铭记并开创一个新的时代，成为时代的主角，例如蒸汽机，发电机，计算机和互联网。但循序渐进的集成创新才是平凡日子里的重要配角，小步蓄力以期待下一次的飞跃。因此大多数时候新概念的产生通常会带有前任的影子而导致傻傻分不清楚，或被误认为是“老瓶装新酒”的现象。

在当下时代对“企业是否一定要建设中台”的争论仍在持续着，我认为里面除技术之外，更多地牵涉到企业本身的发展阶段、组织架构和企业文化等问题。有些管理者能很好的从自身业务和技术角度去辨别组织真正需要的是什么，因此我们回头看数据湖的建设，这个议题仍是舞台上活跃的一份子。而技术的革新，已经使得数据湖的建设目标不止于10年前刚提出时的愿景。

目前在建设数据湖的时候，企业通常会展望以下几个技术目标：

在万物互联的时代构想数据湖的未来，不乏有许多引人想象的可发展空间，举例来说：

虽然无论在功能目标还是项目建设方面，数据湖总体仍处于不断发展的阶段。

我们不知道数据湖的概念还能在商业科技的世界里存在多久，亦不知道若干年后我们回头看待它时，能否将之称为“经典”。但这并不妨碍在当下企业参照数据湖的架构概念和功能目标，去搭建大数据处理平台所带来的积极效果，即使在所谓的“数据中台时代”来反观数据湖的概念，每一个从业者仍有必要保持不断学习的谦逊态度，每一个参与方仍要以包容和发展的目光来审视过去、展望未来。