近两年，为什么都开始谈论起 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，这样就带来了很多问题，比如：
消息队列的存储时间有限
消息队列没有查询分析的功能
回溯效率比文件系统更差
除了实时数据载体的问题，还有引入实时数仓后，和离线数仓的统一的问题，
比如实时数仓的数据治理、权限管理，是不是要单独做一套？
如何统一实时数据和离线数据的计算口径？
两套数据系统的资源浪费严重，成本提高？