数据湖（Data Lake）的概念最早出现在 2011 年福布斯的一篇文章《Big Data Requires a big new Architecture》，该文章中主要提到数据仓库存放的数据都是预先组织和处理过，分析方式也基本定型。但在大数据时代，数据量的庞大、数据来源和类型的多元化、数据价值密度低、数据增长快速等特性使得传统的数据仓库无法承载，因此需要一个新的架构来作为大数据的支撑。

数据湖是一种大型数据存储库和处理引擎，它能够存储大量各种类型的数据，拥有强大的信息处理能力和弹性扩展能力。在 IT 的价值已逐渐从应用往数据转移的趋势下（IT to DT），数据湖技术将是企业各类信息系统的核心部分，是进行科学研究和企业决策管理的重要技术手段。

• 全部采集（Collect Everything）

数据湖采集并存放任意类型和来源的数据。数据类型包含结构化、半结构化和非结构化等数据，数据来源可以是来自企业内部所生成的数据，也可以是来自外部公共数据。

• 随处研究（Dive In Anywhere）

数据湖也是一个大数据分析平台，提供多种计算和调度框架，用户可按照自己的需求和条件跨多种业务单元来对数据进行精炼、探索和分析。

• 灵活访问（Flexible Access）

数据湖为多元化数据访问提供一个共享的基础架构，该架构包含数据存储和数据分析两个层面，为大数据多种场景的提供基础支撑。

1. 所有从内部和外部获取的结构化、半结构化和非结构化数据被存放在数据湖的持久层（Persitent Layer）；

2. 数据科学家和分析师被授予持久层的访问权限并使用分析沙箱（Analytics Sandbox）进行数据研究和实验。数据分析师会将有商业价值的数据进行处理并创建新的数据源（Curated）以提供给业务分析师；

3. 业务分析师继续精炼已处理过的数据，他们会和数据管理团队一起将这些数据转换为更为容易操作和使用的数据，并存放在可操作层（Operational layer）以便得到更广泛的使用。

在数据仓库的建设过程中，相当多的投入会花在分析数据源、理解业务流程和数据模型建立上，目的是为了给最终的表报设计了一个高度结构化的数据原型，这种方式通常被用来简化数据建模和节省数仓所需要的昂贵存储空间。

数据湖则储存所有的数据，不仅是现在需要用到的数据，也包含以后可能会用到或者压根就用不到的数据。所有时间的数据都会被保存起来，使得企业能够追溯到任意时间来数据分析。

存放全部数据的方式能够被实现的是因为数据湖所需要的硬件通常与数仓需要的有很大不同。在数据湖中，使用一些廉价或已退役的服务器外加一些便宜的磁盘即可相当经济的将数据湖扩展到 PB 级别，而数据仓库一般都会使用高性能的服务器和高端集中式存储。

数据仓库中的数据一般由业务系统导出，指标化后再导入数仓，数仓中的数据都经过高度结构化的处理，非传统的数据如日志、文本、图片和影像等数据被大量忽略。这些非结构化数据的价值正在被持续的挖掘和发现，但使用数据仓库来消费和存储它们会比较困难且代价较高。

数据湖的储存方式在包含传统数据的同时也会包含这些非传统的数据类型，它存放不论来源和结构的所有数据。数据在数据湖中保持他们原有的形态，直到准备被使用的时候才会进行转换。

在绝大多数的企业中，80%或更多的用户是业务人员，他们关心的是业务报表及之中的关键性指标。数仓主要适合这些用户，因为数仓中的数据都被结构化得很好，容易使用和理解。

另外10%的用户会对数据做更多的分析。他们把数据仓库作为数据来源但常常也需要回到原有系统中去获取那些数仓没有录入的数据，更有些时候会去企业外去获取一些数据。他们不仅仅只关心业务报表，很多时候会基于自身需求去定义新的报表。数据仓库虽然为他们提供源数据，但是在数据源不够充足的情况下，这类人通常跨出数仓的界限去寻找数据。

剩下的10%用户，会对数据进行更加深入的分析，他们可能创建全新的数据源来进行研究，混合很多不同类型的数据来应答新的问题。他们也会用到数据仓库，但通常会因为他们所需要的数据远远超出数仓的范畴而忽略它。这些用户包含数据分析师、统计学家乃至数据科学家，这类用户可能会用到更加高级的分析工具和更佳全面的数据源。

数据湖支持以上所有用户的需求，满足数据科学家在数据湖中对他们所需要的大量多元化数据进行分析的同时，其他的用户也可以像平时一样利用更加结构化的数据来查看图表。

构建一个完善的数据仓库在前期所需要的投入是可以想象的。原则上来说，一个好的数仓需要能够适应变化，但因复杂的数据录入流和为简化分析和报表所做的一些工作，一旦需要变更数仓的时候则必须投入一些人力和时间。

很多业务层的问题没办法等到数仓团队去完成数据仓库的适配后再给出答案，这些快速增长的需求得以自助的方式来迅速给出应对。

在数据湖中，因为所有的数据以原始的方式存放并且在需要使用的时被转换，用户可以跳出数据仓库的限制来使用全新的方式去浏览数据来寻求问题的解答。

如果数据浏览后发现数据是有价值且可以被重复利用的，那么给予这些数据一个更加合适的使用模式（如将数据结构化之后导入到关系型数据中），使得它们能够得到更加广泛的使用。如果认为数据是没用的，那就无需为这些数据去投入任何人力和时间成本。

因为数据湖包含所有数据和数据类型，并且它能够让用户在数据经过清洗、转换和结构化之前就访问数据，这种方式使得用户能够比传统的数据仓库方式更快的得到结果。

在早期出于数据分析（计算）和存放（存储）的成本考虑，数仓开发团队不会对所有的数据来源来构建数据仓库并进行分析。这好像让用户在一个固定的范围内去浏览和使用他们能看到的数据。但业务人员却不希望这样，他们需要看到最全面的运营报表和指标来辅助他们决策。

关注业务报表的人将可以从数据湖中利用更多的结构化数据视图，就像跟之前在数据仓库里面一样。不同的是这些视图作为元数据存放在数据湖中，而非经过开发者处理后比较死板的报表。

从对比来看数据湖似乎要比数据仓库好很多，但就个人理解，数据湖并非用来替代数据仓库，而是在大数据时代下对数仓的一种补充。两者完全可以基于需求和场景来协同工作，而非二者必居其一。

大数据技术用来支撑和增强现代化的数据分析方式但并非要取代传统的分析系统。我们需要的是一个现代化的数据架构，在包含数据湖所有好处的同时结合传统关系型数据仓库以及OLAP 引擎实现快速查询和分析等功能，借此支持所有级别业务的数据消费，提供所有数据消费者所需要的能力。

上图是 Hortonworks 公司基于 Hadoop 生态构建的数据湖提出的现代化数据架构（Morden Data Architecture），从南向北包含四个层面：

• 数据采集层（Data Acquisition Layer）

数据采集层负责从数据源抽取和移动数据，并将数据存放到数据湖中。采集的数据源包括传统的关系型或事务型系统、用户获取的数据、非结构化或半结构化数据、外部数据或流数据等。

• 数据监管层（Data Curation Layer）

数据监管层负责数据湖中的数据组织、定型并为其他层提供消费，包含数据标准化流程制定，数据创建、脱敏、清洗、转换、维护、管理和展现等工作。

• 数据供应层（Data Provisioning Layer） 

数据供应层采用更适用于业务报表和分析的传统数据储存方式，使用OLAP、数据仓库和数据集市降低数据消费的复杂度并提供快速的交互式查询和分析。

• 数据消费层（Data Consumption Layer）

数据消费层提供所有最终用户的接口，对于不同用户对数据的需求，大量和多元化的工具和技术会被用于该层。

潮汐，是海水在天体引潮力作用下所产生的周期性运动，白天的涨落为潮，晚上的称为汐。企业应用系统的运行也存在类潮汐现象，白天主要响应业务请求，晚上主要进行数据处理。

在“业务潮汐”和“数据湖泊”的理念下，DaoCloud 基于容器化技术引出“计算潮汐”的理念，并将此融入到DCE 应用云平台中形成智能数据湖解决方案。

作为整个智能数据湖平台的核心，该平台通过采用基于 PaaS + Data Lake 的双擎运转模式打通底层硬件资源和顶层应用系统间的壁垒。白天业务繁忙时，会将更多的计算资源向业务应用倾斜，晚上进行大量数据处理时，则将计算资源分配给数据应用，以此来提高应用系统的弹性，实现资源的错峰高效利用。

挖掘大数据的价值好比沙里淘金，想从沙子中获得更多的金子关系到两点：淘金技术和沙子总量。

通过结合云计算和大数据相关技术构建而成的智能数据湖，兼顾大规模、高弹性和可扩展的计算能力和存储能力，计算能力提高“淘金技术”，存储能力增加“沙子总量”，缩短数据生产到数据价值的路径，快速体现数据资产价值，推动业务持续创新。

Q1：数据湖和流处理是什么关系？能在数据湖里做流式计算吗？

A1：数据湖包含分布式存储和分布式处理引擎，流处理属于其中的一种，数据湖中可以基于storm和Spark streaming实现流式计算。所以数据湖和流处理的关系是前者包含后者。

Q2：请问查询MySQL 的时候用set value设置变量，然后查询会有什么负面影响或者边际效应？

A2：变量绑定主要是为了共享SQL，提高代码的通用性和可读性的同时减少SQL的硬解析。需要看一下MySQL有没有类似Oracle Shared Pool的概念，如果有的话对性能方面应该是正面影响。