数据湖，比“数据中台”更需要重视的概念｜腾研识者

admin 管理员组

文章数量: 887017

数据湖，比“数据中台”更需要重视的概念｜腾研识者

作者

火雪挺 腾研识者、腾讯CSIG资深架构师

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

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

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

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

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

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

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

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

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

“笛卡尔乘积是指在数学中，两个集合X和Y的笛卡尔积（Cartesianproduct），又称直积，表示为X × Y，第一个对象是X的成员而第二个对象是Y的所有可能有序对的其中一个成员。”

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

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

1 / 面向主题的：

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

2 / 集成的：

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

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

3 / 相对稳定的：

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

事务型数据系统由于直接应对业务的多样性，交易的增加、更改和删除非常频繁，这些变化有时候采用对冲的方式做记录，有时候在原有的记录上直接做更改，导致系统处于一直变化的状态；

而数据仓库通常以时间窗口作为数据批量导入的分区，例如每一小时或一天从事务型系统导入一次数据，在下一次数据导入任务开始之前，系统处于一个相对稳定的状态，有利于进行经营性的业务分析。

4 / 反映历史变化的：

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

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

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

图片来源unsplash

而“数据湖”这个概念，由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年代初为了更好的支持经营的决策分析，数据仓库的技术就油然而生并被广泛应用。

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

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

图片来源unsplash

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

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

技术的革新

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

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

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

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

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

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

3 / 关键能力包括：

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

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

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

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

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

展望：更大想象力空间

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

1 / 更智能的数据接入：

物联网时代信息进一步爆炸，无论是数据量还是数据种类和复杂度都呈指数级发展，数据湖可以成为整个物联网基建的融合汇聚中心，通过数据感知技术，根据接入的数据类型、更新频率、数据量大小以及预设好的使用场景等信息，智能判别数据接入方式、自动化地进行底层协议及技术的匹配，降低接入数据湖的门槛和整体运维的成本。

2 / 更精细的资产管理：

可以从冷热数据（被使用频率低和高的数据）、业务标签等不同角度对数据进行分级分层存储，在预先定义好的数据治理规则和基于日志的机器学习运维任务下，做到半自动甚至全自动的数据管理，合理利用系统资源，实现“数据自治”。

3 / 更灵活的数据分析：

纳入“数据不动计算动”的联邦学习能力，解决数据迁移、数据安全和数据权责的问题；

纳入“既能保证数据事务性又能保证数据分析性”的混合事物/分析处理架构（Hybrid Transaction and Analytical Process），解决从事务性数据库导入到数据仓库产生的时效性和一致性问题；

纳入针对“大宽表”的即席多维度分析能力，解决传统上做多维度分析时需要将数据预先按主题拆分和转换处理过程而导致的分析长链路以及低时效问题等。

4 / 更直观的数据价值：

在数据应用实现商业变现之前，就数据本身而言，纳入灵活但可控的数据共享工具及平台，加速湖内和湖外、组织内和组织外数据的碰撞，共融互通而形成更完整的数据全景从而为业务服务；

纳入数据商业化/社会化运营工具，例如数据沙箱、智能脱敏、自主订阅、用量统计等，撬动数据资产本身的价值。

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

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

数据驱动的数字化转型：从流程驱动到数据驱动

一张图看懂信息化和数字化的本质区别

我们有多少机会将数据、信息、知识转化为智慧？

有一种信息化的死敌，叫数据打通！

数据中的商机

点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！

????分享、点赞、在看，给个3连击吧！????

本文标签： 数据湖，比“数据中台”更需要重视的概念｜腾研识者