说明：正文主要引用来源1的内容，只有小结和实际案例是根据政务和医院信息化的实际情况加的。
引用来源：
1、https://www.sohu.com/a/399440434_612370?spm=smpc.null.fd-news.14.1591168052546p2dxjaq “数据湖”：概念、特征、架构与案例 （1、什么是数据湖；2、数据湖的基本特征；3、数据湖基本架构；4、各厂商的数据湖解决方案；5、典型的数据湖应用场景；6、数据湖建设的基本过程；7、总结。）
目录
摘录和小结内容：
1、定义：什么是数据湖
关于数据湖的定义其实很多，但是基本上都围绕着以下几个特性展开。
1、 数据湖需要提供足够用的数据存储能力，这个存储保存了一个企业/组织中的所有数据。
2、 数据湖可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。
3、 数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。
4、 数据湖需要具备完善的数据管理能力（完善的元数据），可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。
5、 数据湖需要具备多样化的分析能力，包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。
6、 数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。
7、 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源，并能从相关的数据源中获取全量/增量数据；然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中，满足不同的应用访问需求。
8、 对于大数据的支持，包括超大规模存储以及可扩展的大规模数据处理能力。
IBM：数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。数据湖从企业的多个数据源获取原始数据，并且针对不同的目的，同一份原始数据还可能有多种满足特定内部模型格式的数据副本。因此，数据湖中被处理的数据可能是任意类型的信息，从结构化数据到完全非结构化数据。企业对数据湖寄予厚望，希望它能帮助用户快速获取有用信息，并能将这些信息用于数据分析和机器学习算法，以获得与企业运行相关的洞察力。
wiki：数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，各类任务包括报表、可视化、高级分析和机器学习。数据湖中包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。数据沼泽是一种退化的、缺乏管理的数据湖，数据沼泽对于用户来说要么是不可访问的要么就是无法提供足够的价值。
阿里云栖号：个人认为数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。
2、数据湖与数据仓库
表1 数据湖与数据仓库比较
上表对比了数据湖与传统数仓的区别，从数据和计算两个层面进一步分析数据湖，应该具备以下特征：
一、数据方面
1）“保真性”。数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。与数据仓库不同的地方在于，数据湖中必须要保存一份原始数据，无论是数据格式、数据模式、数据内容都不应该被修改。在这方面，数据湖强调的是对于业务数据“原汁原味”的保存。同时，数据湖应该能够存储任意类型/格式的数据。
2）“灵活性”： 上表一个点是 “写入型schema” v.s.“读取型schema”，其实本质上来讲是数据schema的设计发生在哪个阶段的问题。对于任何数据应用来说，其实schema的设计都是必不可少的，即使是mongoDB等一些强调“无模式”的数据库，其最佳实践里依然建议记录尽量采用相同/相似的结构。“写入型schema”背后隐含的逻辑是数据在写入之前，就需要根据业务的访问方式确定数据的schema，然后按照既定schema，完成数据导入，带来的好处是数据与业务的良好适配；但是这也意味着数仓的前期拥有成本会比较高，特别是当业务模式不清晰、业务还处于探索阶段时，数仓的灵活性不够。
数据湖强调的“读取型schema”，背后的潜在逻辑则是认为业务的不确定性是常态：我们无法预期业务的变化，那么我们就保持一定的灵活性，将设计去延后，让整个基础设施具备使数据“按需”贴合业务的能力。因此，个人认为“保真性”和“灵活性”是一脉相承的：既然没办法预估业务的变化，那么索性保持数据最为原始的状态，一旦需要时，可以根据需求对数据进行加工处理。因此，数据湖更加适合创新型企业、业务高速变化发展的企业。同时，数据湖的用户也相应的要求更高，数据科学家、业务分析师（配合一定的可视化工具）是数据湖的目标客户。
3）“可管理”：数据湖应该提供完善的数据管理能力。既然数据要求“保真性”和“灵活性”，那么至少数据湖中会存在两类数据：原始数据和处理后的数据。数据湖中的数据会不断的积累、演化。因此，对于数据管理能力也会要求很高，至少应该包含以下数据管理能力：数据源、数据连接、数据格式、数据schema（库/表/列/行）。同时，数据湖是单个企业/组织中统一的数据存放场所，因此，还需要具有一定的权限管理能力。
4）“可追溯”：数据湖是一个组织/企业中全量数据的存储场所，需要对数据的全生命周期进行管理，包括数据的定义、接入、存储、处理、分析、应用的全过程。一个强大的数据湖实现，需要能做到对其间的任意一条数据的接入、存储、处理、消费过程是可追溯的，能够清楚的重现数据完整的产生过程和流动过程。
二、计算方面
5）丰富的计算引擎。从批处理、流式计算、交互式分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。一般情况下，数据的加载、转换、处理会使用批处理计算引擎；需要实时计算的部分，会使用流式计算引擎；对于一些探索式的分析场景，可能又需要引入交互式分析引擎。随着大数据技术与人工智能技术的结合越来越紧密，各类机器学习/深度学习算法也被不断引入，例如TensorFlow/PyTorch框架已经支持从HDFS/S3/OSS上读取样本数据进行训练。因此，对于一个合格的数据湖项目而言，计算引擎的可扩展/可插拔，应该是一类基础能力。
6）多模态的存储引擎。理论上，数据湖本身应该内置多模态的存储引擎，以满足不同的应用对于数据访问需求（综合考虑响应时间/并发/访问频次/成本等因素）。但是，在实际的使用过程中，数据湖中的数据通常并不会被高频次的访问，而且相关的应用也多在进行探索式的数据应用，为了达到可接受的性价比，数据湖建设通常会选择相对便宜的存储引擎（如S3/OSS/HDFS/OBS），并且在需要时与外置存储引擎协同工作，满足多样化的应用需求。
3、数据与大数据平台
简单的数据湖实现几乎等价于定义一个中心数据源，所有的系统都可以使用这个中心数据源来满足所有的数据需求。更好的构建数据湖的策略是将组织及其信息系统作为一个整体来看待，对数据拥有关系进行分类，定义统一的企业模型。
如果数据访问要求提供数据视图，则涉及将数据存储为对应的形式，即数据可以作为视图对外提供，并提供便捷的可管理性和可访问性。最近出现的一个日渐重要的趋势是通过服务（service）来提供数据，它涉及在轻量级服务层上对外公开数据。每个对外公开的服务必须准确地描述服务功能并对外提供数据。此模式还支持基于服务的数据集成，这样其他系统可以消费数据服务提供的数据。
处理架构演变：Hadoop为代表的离线数据处理基础设施--》
“流批一体”的Lambda架构（整个数据流进入平台后一部分走批处理模式，一部分走流式计算模式。最终的处理结果都通过服务层对应用提供，确保访问的一致性。可以保证数据处理的实时性）--》
Kappa架构。（Lambda架构解决了应用读取数据的一致性问题，但是“流批分离”的处理链路增大了研发的复杂性。
目前比较流行的做法就是基于流计算用一套系统来解决所有问题。流计算天然的分布式特征，通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。）
综上，从传统的hadoop架构往lambda架构，从lambda架构往Kappa架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力，大数据平台逐渐演化成了一个企业/组织的全量数据处理平台。当前的企业实践中，除了关系型数据库依托于各个独立的业务系统；其余的数据，几乎都被考虑纳入大数据平台来进行统一的处理。然而，目前的大数据平台基础架构，都将视角锁定在了存储和计算，而忽略了对于数据的资产化管理，这恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。
四、数据湖的组成
大数据基础架构的演进，其实反应了一点：在企业/组织内部，数据是一类重要资产已经成为了共识；为了更好的利用数据，企业/组织需要对数据资产1）进行长期的原样存储；2）进行有效管理与集中治理；3）提供多模式的计算能力满足处理需求；4）以及面向业务，提供统一的数据视图、数据模型与数据处理结果。数据湖就是在这个大背景下产生的，除了大数据平台所拥有的各类基础能力之外，数据湖更强调对于数据的管理、治理和资产化能力。
落到具体的实现上，数据湖需要包括一系列的数据管理组件，包括：1）数据接入；2）数据搬迁；3）数据治理；4）质量管理；5）资产目录；6）访问控制；7）任务管理；8）任务编排；9）元数据管理等。如下图所示，给出了一个数据湖系统的参考架构。对于一个典型的数据湖而言，它与大数据平台相同的地方在于它也具备处理超大规模数据所需的存储和计算能力，能提供多模式的数据处理能力；增强点在于数据湖提供了更为完善的数据管理能力，具体体现在：
1） 更强大的数据接入能力。数据接入能力体现在对于各类外部异构数据源的定义管理能力，以及对于外部数据源相关数据的抽取迁移能力，抽取迁移的数据包括外部数据源的元数据与实际存储的数据。
2） 更强大的数据管理能力。管理能力具体又可分为基本管理能力和扩展管理能力。基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理，是一个数据湖系统所必须的，后面我们会在“各厂商的数据湖解决方案”一节相信讨论各个厂商对于基本管理能力的支持方式。扩展管理能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力。任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务，通常情况下，数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力，定制的系统/模块可以通过读取数据湖的相关元数据，来实现与数据湖系统的融合。而数据质量和数据治理则是更为复杂的问题，一般情况下，数据湖系统不会直接提供相关功能，但是会开放各类接口或者元数据，供有能力的企业/组织与已有的数据治理软件集成或者做定制开发。
3） 可共享的元数据。数据湖中的各类计算引擎会与数据湖中的数据深度融合，而融合的基础就是数据湖的元数据。好的数据湖系统，计算引擎在处理数据时，能从元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息，然后直接进行数据处理，而无需进行人工/编程干预。更进一步，好的数据湖系统还可以对数据湖中的数据进行访问控制，控制的力度可以做到“库表列行”等不同级别。
图1 数据湖组件参考架构
上图的“集中式存储”更多的是业务概念上的集中，本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。事实上，数据湖的存储应该是一类可按需扩展的分布式文件系统，大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。再切换到数据维度，从数据生命周期的视角来看待数据湖对于数据的处理方式，数据在数据湖中的整个生命周期如下图所示。理论上，一个管理完善的数据湖中的数据会永久的保留原始数据，同时过程数据会不断的完善、演化，以满足业务的需要。
图2 数据湖的生命周期
五、 数据湖的建设过程
1） 数据摸底。依然需要摸清楚数据的基本情况，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量。但是，也就需要做这么多了。数据湖是对原始数据做全量保存，因此无需事先进行深层次的设计。
2） 技术选型。根据数据摸底的情况，确定数据湖建设的技术选型。事实上，这一步也非常的简单，因为关于数据湖的技术选型，业界有很多的通行的做法，基本原则个人建议有三个：“计算与存储分离”、“弹性”、“独立扩展”。建议的存储选型是分布式对象存储系统（如S3/OSS/OBS）；计算引擎上建议重点考虑批处理需求和SQL处理能力，因为在实践中，这两类能力是数据处理的关键，关于流计算引擎后面会再讨论一下。无论是计算还是存储，建议优先考虑serverless的形式；后续可以在应用中逐步演进，真的需要独立资源池了，再考虑构建专属集群。
3） 数据接入。确定要接入的数据源，完成数据的全量抽取与增量接入。
4） 应用治理。这一步是数据湖的关键，我个人把“融合治理”改成了“应用治理”。从数据湖的角度来看，数据应用和数据治理应该是相互融合、密不可分的。从数据应用入手，在应用中明确需求，在数据ETL的过程中，逐步形成业务可使用的数据；同时形成数据模型、指标体系和对应的质量标准。数据湖强调对原始数据的存储，强调对数据的探索式分析与应用，但这绝对不是说数据湖不需要数据模型；恰恰相反，对业务的理解与抽象，将极大的推动数据湖的发展与应用，数据湖技术使得数据的处理与建模，保留了极大的敏捷性，能快速适应业务的发展与变化。
从技术视角来看，数据湖不同于大数据平台还在于数据湖为了支撑数据的全生命周期管理与应用，需要具备相对完善的数据管理、类目管理、流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等能力。在计算能力上，目前主流的数据湖方案都支持SQL和可编程的批处理两种模式（对机器学习的支持，可以采用Spark或者Flink的内置能力）；在处理范式上，几乎都采用基于有向无环图的工作流的模式，并提供了对应的集成开发环境。
数据湖的主要用户是数据科学家和数据分析师，探索式分析和机器学习是这类人群的常见操作；流式计算（实时模式）多用于在线业务，严格来看，并非数据湖目标用户的刚需。但是，流式计算（实时模式）是目前大多数互联网公司在线业务的重要组成部分，而数据湖作为企业/组织内部的数据集中存放地，需要在架构上保持一定的扩展能力，可以很方便的进行扩展，整合流式计算能力。
5） 业务支撑。虽然大多数数据湖解决方案都对外提供标准的访问接口，如JDBC，市面上流行的各类BI报表工具、大屏工具也都可以直接访问数据湖中的数据。但是在实际的应用中，我们还是建议将数据湖处理好的数据推送到对应的各类支持在线业务的数据引擎中去，能够让应用有更好的体验。
六、应用实例
1、政务信息化--基于数据湖架构的时空大数据与云平台解决方案
2、医院信息化（待续）