在批评数据湖的时候，你有没有想过，它并不是取代数据仓库的

数据湖初识

近两年&＃xff0c;为什么都开始谈论起 Data Lake 这个”新名词”了&＃xff1f;

先说说我的想法&＃xff0c;其实还是用户需求驱动数据服务&＃xff0c;大家开始关注 Data Lake 的根本原因是用户需求发生了质变&＃xff0c;过去的数据仓库模式以及相关组件没有办法满足日益进步的用户需求。

数据湖概念的诞生&＃xff0c;源自企业面临的一些挑战&＃xff0c;如数据应该以何种方式处理和存储。最开始&＃xff0c;企业对种类庞杂的应用程序的管理都经历了一个比较自然的演化周期。

那么到底是什么样的需求和挑战驱动了技术的变革&＃xff0c;从而导致了新技术的产生呢&＃xff1f;

数据湖的定义

AWS定义数据湖是一个集中式存储库&＃xff0c;允许您以任意规模存储所有结构化和非结构化数据。

微软的定义就更加模糊了&＃xff0c;并没有明确给出什么是Data Lake&＃xff0c;而是取巧的将数据湖的功能作为定义&＃xff0c;数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力。

但是随着大数据技术的融合发展&＃xff0c;早期的定义可能不再那么准确了&＃xff0c;数据湖不断演变&＃xff0c;汇集了各种技术&＃xff0c;包括数据仓库、实时和高速数据流技术、数据挖掘、深度学习、分布式存储和其他技术。

逐渐发展成为一个可以存储所有结构化和非结构化任意规模数据&＃xff0c;并可以运行不同类型的大数据工具&＃xff0c;对数据进行大数据处理、实时分析和机器学习等操作的统一数据管理平台。

所以说数据仓库不是曾经的那个仓库了&＃xff0c;数据湖也不是曾经的那个"大明湖畔的夏雨荷了"&＃xff0c;sorry应该不是那一片绿油油的湖了。

趋势

这里聊一个很重要的趋势&＃xff1a;数据实时化。

当然这里有很多其他的趋势&＃xff0c;比如低成本化、设计云原生化等&＃xff0c;但总体上我还是认为数据实时化是近几年来最热门、最明显且最容易让人看到收益的一个趋势。

数据仓库过去的模式大家可能都很了解&＃xff0c;将整个数据仓库划分为 ODS、DWD、DWS&＃xff0c;使用 Hive 作为数据存储的介质&＃xff0c;使用 Spark 或者 MR 来做数据清洗的计算。

这样的数据仓库设计很清晰&＃xff0c;数据也比较容易管理&＃xff0c;所以大家开开心心地使用这套理论和做法将近 10 年左右。

在这 10 年的时间里&＃xff0c;主流的互联网公司在数据技术上的玩法并没有多大的改变&＃xff0c;比如推荐需要用到的用户画像、电商里商品的标签、好友传播时用的图、金融风控数据体系。

站在更高的一个角度看&＃xff0c;我们会发现&＃xff0c;十年前做的事情&＃xff0c;比如用户画像表&＃xff0c;如果你现在去做推荐服务&＃xff0c;还是需要这个表。这样会产生一个什么现象&＃xff1f;

十年的互联网行业的人才积累、知识积累、经验积累&＃xff0c;让我们可以更加容易地去做一些事情&＃xff0c;比如十年前很难招聘到的懂推荐数据的人才&＃xff0c;水平在如今也就是一个行业的平均值罢了。

既然这些事情变得更好做了&＃xff0c;人才更多了&＃xff0c;我们就期望在事情上做的更精致。因为从业务上讲&＃xff0c;我去推荐短视频&＃xff0c;让用户购买东西&＃xff0c;这个需求是没有止境的&＃xff0c;是可以永远做下去的。

所以以前我可能是 T&＃43;1 才能知道用户喜欢什么&＃xff0c;现在这个需求很容易就达到之后&＃xff0c;我希望用户进来 10s 之后的行为就告诉我这个用户的喜好&＃xff1b;以前可能做一些粗粒度的运营&＃xff0c;比如全人群投放等&＃xff0c;现在可能要转化思路&＃xff0c;做更加精细化的运营&＃xff0c;给每个用户提供个性化定制的结果。

技术演进——实时化

数据实时化没问题&＃xff0c;但是对应到技术上是什么情况呢&＃xff1f;是不是我们要在实时领域也搭一套类似离线数据仓库的数据体系和模式&＃xff1f;

是的&＃xff0c;很多公司确实是将实时数据流划分为了不同层级——也就是我们说的实时数仓&＃xff0c;整体层级的划分思路和离线仓库类似&＃xff0c;但是实时数据的载体就不是 Hive 或者 Hdfs 了&＃xff0c;而是要选择更加实时的消息队列&＃xff0c;比如 Kafka&＃xff0c;这样就带来了很多问题&＃xff0c;比如&＃xff1a;

• 消息队列的存储时间有限&＃xff1b;
• 消息队列没有查询分析的功能&＃xff1b;
• 回溯效率比文件系统更差&＃xff1b;

除了实时数据载体的问题&＃xff0c;还有引入实时数仓后&＃xff0c;和离线数仓的统一的问题&＃xff0c;

• 比如实时数仓的数据治理、权限管理&＃xff0c;是不是要单独做一套&＃xff1f;
• 如何统一实时数据和离线数据的计算口径&＃xff1f;
• 两套数据系统的资源浪费严重&＃xff0c;成本提高&＃xff1f;

举一个比较现实的例子&＃xff0c;假设我们构造了一个实时计算指标&＃xff0c;在发现计算错误后我们需要修正昨天的实时数据&＃xff0c;这种情况下一般是另外写一个离线任务&＃xff0c;从离线数仓中获取数据&＃xff0c;再重新计算一遍&＃xff0c;写入到存储里。

这样的做法意味着我们在每写一个实时需求的同时&＃xff0c;都要再写一个离线任务&＃xff0c;这样的成本对于一个工程师是巨大的。

技术演进——降低成本化

实时系统的成本太大了&＃xff0c;这也是让很多公司对实时需求望而生畏的原因之一。所以这样去建设实时数仓的思路肯定不行啊&＃xff0c;等于我要招两倍的人才&＃xff08;可能还不止&＃xff09;&＃xff0c;花两倍的时间&＃xff0c;才能做一个让我的业务可能只提升 10% 的功能。

从技术的角度来看&＃xff0c;是这两套系统的技术栈不一样造成了工程无法统一。那么&＃xff0c;数据湖就是用来解决这样一个问题&＃xff0c;比如我一个离线任务&＃xff0c;能不能既产生实时指标&＃xff0c;也产生离线指标&＃xff0c;类似下图这样&＃xff1a;

满足上面最重要的一个前提就是我的数据源是实时的&＃xff0c;这样对我们的大数据存储主要就是HDFS 和 S3 又提出了新的挑战——数据实时更新&＃xff0c;如果原有技术或者组件不能满足需求&＃xff0c;新的技术在需求的驱动下就此诞生。

除了计算层面上&＃xff0c;在数据管理上&＃xff0c;比如中间表的 schema 管理&＃xff0c;数据权限管理&＃xff0c;能否做到统一&＃xff0c;在架构上实现统一后&＃xff0c;我们在应对实时需求时&＃xff0c;可以将实时离线的冗余程度降到最低&＃xff0c;甚至能够做到几乎没有多余成本。

数据湖与数据仓库的区别

数据仓库是一种成熟稳定的技术架构。它们存储经过ETL 处理结构化数据&＃xff0c;以便完成整决策支持的过程。数据仓库将数据组合为一种聚合、摘要形式&＃xff0c;以在企业范围内使用&＃xff0c;并在执行数据写入操作时写入元数据和模式定义。

数据仓库通常拥有固定的配置&＃xff1b;它们是高度结构化的&＃xff0c;因此不太灵活和敏捷。数据仓库成本与在存储前处理所有数据相关&＃xff0c;而且大容量存储的费用相对较高。

相较而言&＃xff0c;数据湖是较新的技术&＃xff0c;拥有不断演变的架构。数据湖存储任何形式&＃xff08;包括结构化和非结构化&＃xff09;和任何格式&＃xff08;包括文本、音频、视频和图像&＃xff09;的原始数据。根据定义&＃xff0c;数据湖不会接受数据治理&＃xff0c;但专家们都认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。

数据湖在数据读取期间创建模式&＃xff0c;与数据仓库相比&＃xff0c;数据湖缺乏结构性&＃xff0c;而且更灵活&＃xff1b;它们还提供了更高的敏捷性。在检索数据之前无需执行任何处理&＃xff0c;而且数据湖特意使用了更加便宜的存储。

数据湖与数据仓库的差别很明显。 然而&＃xff0c;在企业中两者的作用是互补的&＃xff0c;不应认为数据湖的出现是为了取代数据仓库&＃xff0c;毕竟两者的作用是截然不同的。

总结

离线架构大行其道数十年&＃xff0c;互联网数十年技术积淀和业务发展对数据又提出新要求&＃xff0c;实时计算技术的发展满足了人们对数据实时性的要求&＃xff0c;但未能满足互联网人对低成本高性能的执着追逐。

当然&＃xff0c;对于数据湖架构的批评也是不绝于耳。有人批评说&＃xff0c;汇集各种杂乱的数据&＃xff0c;应该就是数据沼泽。

历史见证了每一次新技术的诞生总是遇到万般挫折与质疑&＃xff0c;但是它何曾让你失望过。