在阿里数据中台，数仓、数字化转型的“阴影”下，数据湖却更火了

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

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

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

从“数据仓库”到“数据湖”：历史的演变

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

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

此处的定义大多都是针对事务型数据系统而制定的。所谓事务型数据系统，是指记录业务交易的系统，这个名词先是在金融业，特别是银行实施信息化IT系统时使用的。

例如银行的交易流水数据库，每分每秒都有大量的交易被数据库所记录并持久化的保存下来，其最小的颗粒度就是一笔“交易”。后来信息化系统在各行各业开花结果，“业务”渐渐演变为现在的“事务”概念，例如员工刷卡进入办公室，后台就会记录员工的这一“事务行为”。

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

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

后来，数据仓库领域的大师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）。

在这一背景下，已发展成熟的公有云能力为数据湖体系架构的发展奠定基础，催生“数据湖”的概念。

数据仓库与数据湖的对比：数据仓库的数据在被集成时就会被预先分类，并以最优的方式进行存储，以支撑特定的分析；但在大数据时代，我们从源系统抽取数据时可能无法明确知道这些数据的价值，因此无法给出一个最优的存储方式。

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

而现在单纯的数据湖就朝向一个“平台级的方案”而演进。为什么说是方案呢，因为时至今日，数据湖仍是个架构概念，是一种架构设计的理念，而不是一种特定的实施方法，更不是一款特定的产品。

其所要达成的目标囊括了不止一种数据技术，已经从当初的一种“大数据存算方案”进阶到了“大数据存算+处理分析+资产治理+安全隐私+数据变现”的一揽子方案。

10年前，迪克森曾认为“数据湖”是面向企业的最佳大数据解决方案。从技术上来看，其论点是有根据的，但是从商业价值上来看，这个愿景似乎并没有被实现。

实际情况是过去数据仓库的落地实践要远比数据湖来的多和广。而就在现今所有人都在强调数据资产化、资产业务化，强调数据变现和数据商业价值的年代，数据中台的概念似乎又代替了数据湖的概念。

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

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

中台在“数据驱动业务”、“数字化转型”的时代大背景下，它们是和企业的总体业务目标紧密相关的，不再只是一个“旁路IT系统”，不再只是一个业务信息化的支撑系统，而是产生并驱动业务的关键环节。数据中台应当是企业组织和技术架构的有机结合体。

技术商业化应用之动力：业务的诉求

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

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

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

当企业开始迈向全面数字化的阶段，需要处理的数据越来越多、形式越来越杂，原先使用的数据存算方式其成本越来越高，业务对数据处理的效率要求也越来越快。

在这种背景下，企业亟需一种成本更低且效率较高的方式来存算数据、访问数据，因此大数据技术孕育而生。我们通常说的大数据平台就是利用大数据技术而搭建的平台型能力，为企业提供大数据技术服务。

而当企业迈入大数据时代后，纷纷利用大数据技术搭建各自的大数据平台。

为了进一步降低数据存储和处理的成本，提升大数据平台的可用性、可靠性和可运营性，基于数据湖的架构概念，我们又开始在大数据平台上尝试搭建各自的数据湖架构。由此可见，数据湖也是由业务诉求催生出的平台架构概念和能力。

所谓分久必合，当企业的数字化、数据化成为一种常态时，有些企业发现内部存在纷繁复杂的数据源，存在多个所谓大数据平台甚至是数据湖，导致了很多不必要的重复性建设，包括服务、软件和硬件层面的冗余，或是由于部门壁垒而导致数据无法有效统一来支持前端业务，不统一的数据出处又带来数据不一致的问题，亦或是不同部门各起炉灶导致数据技术人员各自分散的问题。

在这种背景下，由高层拍板构建企业级的数据中台，把原有资源剥离和再分配，将共性抽象集成并形成资产，统一面向全组织提供服务。

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

技术的革新

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

在当下时代对“企业是否一定要建设中台”的争论仍在持续着，我认为里面除技术之外，更多地牵涉到企业本身的发展阶段、组织架构和企业文化等问题。

有些管理者能很好的从自身业务和技术角度去辨别组织真正需要的是什么，因此我们回头看数据湖的建设，这个议题仍是舞台上活跃的一份子。而技术的革新，已经使得数据湖的建设目标不止于10年前刚提出时的愿景。

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

1 / 提供高可靠性、高性能、可伸缩的分布式存储系统，在一定程度上降低单位存算成本的同时统一承载海量结构化、半结构化以及非结构化数据。

2 / 提供丰富的数据计算分析引擎，具备对结构化、半结构化和非结构化数据进行多层次融合分析的能力。

3 / 关键能力包括：

混合处理：支持所有类型数据入湖无需预先设计模型，同时支持事务型和分析型的数据处理，数据入湖就能即席分析、持续迭代。

联邦分析：支持多类型数据格式融合分析，无需额外数据搬迁，可通过标准查询语句实现跨源数据探索计算分析。

弹性伸缩：计算层和存储层可独立弹性扩展，具备大容量存储池和“理论上”无限弹性计算资源能力，快速应对数据和业务变化。

分级存储：支持冷热数据分级存储，数据自动管理，合理利用存储，降低成本。

数据探索：具备集成的算法开发能力，能快速地构建算法模型及数据探索任务，甚至与标准数据库查询语句融合，支持采用标准接口完成算法及AI业务的开发。

我们不知道数据湖的概念还能在商业科技的世界里存在多久，亦不知道若干年后我们回头看待它时，能否将之称为“经典”。但这并不妨碍在当下企业参照数据湖的架构概念和功能目标，去搭建大数据处理平台所带来的积极效果。

很显然在目前的信息时代，借助类似于FineBI的这些工具，可以让企业加速融入企业数据分析的趋势。备受市场认可的软件其实有很多，选择时必须要结合实际的情况。一般的情况下，都建议选择市面上较主流的产品，比较容易达到好的效果，目前企业数据分析BI软件市场占有率前列的，就是帆软BI软件——FineBI。