举一个比较现实的例子，假设我们构造了一个实时计算指标，在发现计算错误后我们需要修正昨天的实时数据，这种情况下一般是另外写一个离线任务，从离线数仓中获取数据，再重新计算一遍，写入到存储里。这样的做法意味着我们在每写一个实时需求的同时，都要再写一个离线任务，这样的成本对于一个工程师是巨大的。
技术演进——降低成本化实时系统的成本太大了，这也是让很多公司对实时需求望而生畏的原因之一。所以这样去建设实时数仓的思路肯定不行啊，等于我要招两倍的人才（可能还不止），花两倍的时间，才能做一个让我的业务可能只提升 10% 的功能。从技术的角度来看，是这两套系统的技术栈不一样造成了工程无法统一。那么，Data Lake 就是用来解决这样一个问题，比如我一个离线任务，能不能既产生实时指标，也产生离线指标，类似下图这样：
满足上面最重要的一个前提就是我的数据源是实时的，这样对我们的大数据存储主要就是HDFS 和 S3 又提出了新的挑战——数据实时更新，如果原有技术或者组件不能满足需求，新的技术在需求的驱动下就此诞生
除了计算层面上，在数据管理上，比如中间表的 schema 管理，数据权限管理，能否做到统一，在架构上实现统一后，我们在应对实时需求时，可以将实时离线的冗余程度降到最低，甚至能够做到几乎没有多余成本。
这块我们也在积极探索，国内互联网公司的主流做法还是停留在 【技术演进——降低成本化】 的阶段，相信随着大家的努力，很快就会出现优秀且成功的实践。
技术演进——去结构化Pentaho的CTO James Dixon 在2011年提出了"Data Lake"的概念。在面对大数据挑战时，他声称：不要想着数据的"仓库"概念，想想数据 的“湖”概念。数据“仓库”概念和数据湖概念的重大区别是：数据仓库中数据在进入仓库之前需要是事先归类，以便于未来的分析。这在OLAP时代很常见，但是对于离线分析却没有任何意义，不如把大量的原始数据线保存下来，而现在廉价的存储提供了这个可能。
数据仓库是高度结构化的架构，数据在转换之前是无法加载到数据仓库的，用户可以直接获得分析数据。而在数据湖中，数据直接加载到数据湖中，然后根据分析的需要再转换数据。
这里看到数据仓库这种Schema on write 已经不满足日益变化的需求了，数据湖是Schema on read ，但是个人觉得与其说是Schema 还不如说是对数据的态度变了，以前我们只将对当前有用的数据抽取到数仓，而现在我们希望数据湖可以容纳所有的数据，即使当前用不到，但是当想用的时候就有数据可以用
数据湖与数据仓库的区别数据仓库是一种成熟稳定的技术架构。它们存储经过ETL 处理的结构化数据，以便完成整决策支持的过程。数据仓库将数据组合为一种聚合、摘要形式，以在企业范围内使用，并在执行数据写入操作时写入元数据和模式定义。数据仓库通常拥有固定的配置；它们是高度结构化的，因此不太灵活和敏捷。数据仓库成本与在存储前处理所有数据相关，而且大容量存储的费用相对较高。
相较而言，数据湖是较新的技术，拥有不断演变的架构。数据湖存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据。根据定义，数据湖不会接受数据治理，但专家们都认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模式，与数据仓库相比，数据湖缺乏结构性，而且更灵活；它们还提供了更高的敏捷性。在检索数据之前无需执行任何处理，而且数据湖特意使用了更加便宜的存储。
数据湖 数据仓库能处理所有类型的数据，如结构化数据，非结构化数据，半结构化数据等，数据的类型依赖于数据源系统的原始数据格式。 只能处理结构化数据进行处理，而且这些数据必须与数据仓库事先定义的模型吻合。
读取的时候设计schema，存储原始原始数据 写入时设计数据仓库，存储处理后的原始数据
拥有足够强的计算能力用于处理和分析所有类型的数据，分析后的数据会被存储起来供用户使用。 处理结构化数据，将它们或者转化为多维数据，或者转换为报表，以满足后续的高级报表及数据分析需求。
数据湖通常包含更多的相关的信息，这些信息有很高概率会被访问，并且能够为企业挖掘新的运营需求。 数据仓库通常用于存储和维护长期数据，因此数据可以按需访问。