数据湖是谁？那数据仓库又算什么？

数据湖初识

近两年，为何都开始谈论起 Data Lake 这个”新名词”了？

先说说个人想法，其实仍是用户需求驱动数据服务，你们开始关注 Data Lake 的根本缘由是用户需求发生了质变，过去的数据仓库模式以及相关组件没有办法知足日益进步的用户需求。

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

那么究竟是什么样的需求和挑战驱动了技术的变革，从而致使了新技术的产生呢

数据湖的定义

Wikipedia上说数据湖是一类存储数据天然/原始格式的系统或存储，一般是对象块或者文件，包括原始系统所产生的原始数据拷贝以及为了各种任务而产生的转换数据，包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。

AWS定义数据湖是一个集中式存储库，容许您以任意规模存储全部结构化和非结构化数据。

微软的定义就更加模糊了，并无明确给出什么是Data Lake，而是取巧的将数据湖的功能做为定义，数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户能够存储任意规模、任意类型、任意产生速度的数据，而且能够跨平台、跨语言的作全部类型的分析和处理。

可是随着大数据技术的融合发展，早期的定义可能再也不那么准确了，数据湖不断演变，聚集了各类技术，包括数据仓库、实时和高速数据流技术、数据挖掘、深度学习、分布式存储和其余技术。逐渐发展成为一个能够存储全部结构化和非结构化任意规模数据，并能够运行不一样类型的大数据工具，对数据进行大数据处理、实时分析和机器学习等操做的统一数据管理平台

因此说数据仓库不是曾经的那个仓库了，数据湖也不是曾经的那个"大明湖畔的夏雨荷了"，sorry应该不是那一片绿油油的湖了

趋势

这里聊一个很重要的趋势：数据实时化

固然这里有不少其余的趋势，好比低成本化、设计云原生化等，但整体上我仍是认为数据实时化是近几年来最热门、最明显且最容易让人看到收益的一个趋势。

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

这样的数据仓库设计很清晰，数据也比较容易管理，因此你们开开心心地使用这套理论和作法将近 10 年左右。

在这 10 年的时间里，主流的互联网公司在数据技术上的玩法并无多大的改变，好比推荐须要用到的用户画像、电商里商品的标签、好友传播时用的图、金融风控数据体系，站在更高的一个角度看，咱们会发现，十年前作的事情，好比用户画像表，若是你如今去作推荐服务，仍是须要这个表。这样会产生一个什么现象？十年的互联网行业的人才积累、知识积累、经验积累，让咱们能够更加容易地去作一些事情，好比十年前很难招聘到的懂推荐数据的人才，水平在现在也就是一个行业的平均值罢了。

既然这些事情变得更好作了，人才更多了，咱们就指望在事情上作的更精致。由于从业务上讲，我去推荐短视频，让用户购买东西，这个需求是没有止境的，是能够永远作下去的。因此之前我多是 T+1 才能知道用户喜欢什么，如今这个需求很容易就达到以后，我但愿用户进来 10s 以后的行为就告诉我这个用户的喜爱；之前可能作一些粗粒度的运营，好比全人群投放等，如今可能要转化思路，作更加精细化的运营，给每一个用户提供个性化定制的结果。

技术演进——实时化

数据实时化没问题，可是对应到技术上是什么状况呢？是否是咱们要在实时领域也搭一套相似离线数据仓库的数据体系和模式？

是的，不少公司确实是将实时数据流划分为了避免同层级——也就是咱们说的实时数仓，总体层级的划分思路和离线仓库相似，可是实时数据的载体就不是 Hive 或者 Hdfs 了，而是要选择更加实时的消息队列，好比 Kafka，这样就带来了不少问题，好比：

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

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

• 好比实时数仓的数据治理、权限管理，是否是要单独作一套？
• 如何统一实时数据和离线数据的计算口径？
• 两套数据系统的资源浪费严重，成本提升？

举一个比较现实的例子，假设咱们构造了一个实时计算指标，在发现计算错误后咱们须要修正昨天的实时数据，这种状况下通常是另外写一个离线任务，从离线数仓中获取数据，再从新计算一遍，写入到存储里。这样的作法意味着咱们在每写一个实时需求的同时，都要再写一个离线任务，这样的成本对于一个工程师是巨大的。

技术演进——下降成本化

实时系统的成本太大了，这也是让不少公司对实时需求望而生畏的缘由之一。因此这样去建设实时数仓的思路确定不行啊，等于我要招两倍的人才（可能还不止），花两倍的时间，才能作一个让个人业务可能只提高 10% 的功能。从技术的角度来看，是这两套系统的技术栈不同形成了工程没法统一。那么，Data Lake 就是用来解决这样一个问题，好比我一个离线任务，能不能既产生实时指标，也产生离线指标，相似下图这样：

why-data-lake1

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

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

这块咱们也在积极探索，国内互联网公司的主流作法仍是停留在 【技术演进——下降成本化】 的阶段，相信随着你们的努力，很快就会出现优秀且成功的实践。

技术演进——去结构化

Pentaho的CTO James Dixon 在2011年提出了"Data Lake"的概念。在面对大数据挑战时，他声称：不要想着数据的"仓库"概念，想一想数据 的“湖”概念。数据“仓库”概念和数据湖概念的重大区别是：数据仓库中数据在进入仓库以前须要是事先归类，以便于将来的分析。这在OLAP时代很常见，可是对于离线分析却没有任何意义，不如把大量的原始数据线保存下来，而如今廉价的存储提供了这个可能。

数据仓库是高度结构化的架构，数据在转换以前是没法加载到数据仓库的，用户能够直接得到分析数据。而在数据湖中，数据直接加载到数据湖中，而后根据分析的须要再转换数据。

这里看到数据仓库这种Schema on write 已经不知足日益变化的需求了，数据湖是Schema on read ，可是我的以为与其说是Schema 还不如说是对数据的态度变了，之前咱们只将对当前有用的数据抽取到数仓，而如今咱们但愿数据湖能够容纳全部的数据，即便当前用不到，可是当想用的时候就有数据能够用

数据湖与数据仓库的区别

数据仓库是一种成熟稳定的技术架构。它们存储通过ETL 处理的结构化数据，以便完成整决策支持的过程。数据仓库将数据组合为一种聚合、摘要形式，以在企业范围内使用，并在执行数据写入操做时写入元数据和模式定义。数据仓库一般拥有固定的配置；它们是高度结构化的，所以不太灵活和敏捷。数据仓库成本与在存储前处理全部数据相关，并且大容量存储的费用相对较高。

相较而言，数据湖是较新的技术，拥有不断演变的架构。数据湖存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据。根据定义，数据湖不会接受数据治理，但专家们都认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间建立模式，与数据仓库相比，数据湖缺少结构性，并且更灵活；它们还提供了更高的敏捷性。在检索数据以前无需执行任何处理，并且数据湖特地使用了更加便宜的存储。

数据湖	数据仓库
能处理全部类型的数据，如结构化数据，非结构化数据，半结构化数据等，数据的类型依赖于数据源系统的原始数据格式。	只能处理结构化数据进行处理，并且这些数据必须与数据仓库事先定义的模型吻合。
读取的时候设计schema，存储原始原始数据	写入时设计数据仓库，存储处理后的原始数据
拥有足够强的计算能力用于处理和分析全部类型的数据，分析后的数据会被存储起来供用户使用。	处理结构化数据，将它们或者转化为多维数据，或者转换为报表，以知足后续的高级报表及数据分析需求。
数据湖一般包含更多的相关的信息，这些信息有很高几率会被访问，而且可以为企业挖掘新的运营需求。	数据仓库一般用于存储和维护长期数据，所以数据能够按需访问。

数据湖与数据仓库的差异很明显。 然而，在企业中二者的做用是互补的，不该认为数据湖的出现是为了取代数据仓库，毕竟二者的做用是大相径庭的

1. 数据价值性：数仓中保存的都是结构化处理后的数据，而数据湖中能够保存原始数据也能够保存结构化处理后的数据，保证用户能获取到各个阶段的数据。由于数据的价值跟不一样的业务和用户强相关，有可能对于A用户没有意义的数据，可是对于B用户来讲意义巨大，因此都须要保存在数据湖中。

2. 数据实时性：数据湖支持对实时和高速数据流执行 ETL 功能，这有助于未来自 IoT 设备的传感器数据与其余数据源一块儿融合到数据湖中。形象的来看，数据湖架构保证了多个数据源的集成，而且不限制schema，保证了数据的精确度。数据湖能够知足实时分析的须要，同时也能够做为数据仓库知足批处理数据挖掘的须要。数据湖还为数据科学家从数据中发现更多的灵感提供了可能。

3. 数据保真性：数据湖中对于业务系统中的数据都会存储一份“如出一辙”的完整拷贝。与数据仓库不一样的地方在于，数据湖中必需要保存一份原始数据，不管是数据格式、数据模式、数据内容都不该该被修改。在这方面，数据湖强调的是对于业务数据“原汁原味”的保存。同时，数据湖应该可以存储任意类型/格式的数据。

4. 数据灵活性：数据湖提供灵活的，面向任务的数据绑定，不须要提早定义数据模型，"写入型schema" 和"读取型schema"，其实本质上来说是数据schema的设计发生在哪一个阶段的问题。对于任何数据应用来讲，其实schema的设计都是必不可少的，即便是MongoDB等一些强调“无模式”的数据库，其最佳实践里依然建议记录尽可能采用相同/类似的结构。

数据仓库强调的"写入型schema"背后隐含的逻辑是数据在写入以前，就须要根据业务的访问方式肯定数据的schema，而后按照既定schema，完成数据导入，带来的好处是数据与业务的良好适配；可是这也意味着数仓的前期拥有成本会比较高，特别是当业务模式不清晰、业务还处于探索阶段时，数仓的灵活性不够。

数据湖强调的"读取型schema"背后的潜在逻辑则是认为业务的不肯定性是常态：咱们没法预期业务的变化，那么咱们就保持必定的灵活性，将设计去延后，让整个基础设施具有使数据“按需”贴合业务的能力。所以，我的认为“保真性”和“灵活性”是一脉相承的：既然没办法预估业务的变化，那么索性保持数据最为原始的状态，一旦须要时，能够根据需求对数据进行加工处理。所以，数据湖更加适合创新型企业、业务高速变化发展的企业。同时，数据湖的用户也相应的要求更高，数据科学家、业务分析师（配合必定的可视化工具）是数据湖的目标客户。

总结

离线架构大行其道数十年，互联网数十年技术积淀和业务发展对数据又提出新要求，实时计算技术的发展知足了人们对数据实时性的要求，但未能知足互联网人对低成本高性能的执着追逐，技术的浪潮一波接一波，若是你错过了朝阳和高山，请不要错过了星辰和大海

固然，对于数据湖架构的批评也是不绝于耳。有人批评说，聚集各类杂乱的数据，应该就是数据沼泽。Martin Fowler也对数据湖中数据的安全性和私密性提出了质疑，历史见证了每一次新技术的诞生老是遇到万般挫折与质疑，可是它何曾让你失望过。