终于有人把数据湖解释清楚了。转载本文请联系数据仓库宝贝图书馆公众号。本文主要介绍了数据湖的建设目标，以及在此建设目标下数据湖中的数据治理。数据湖作为全球数据汇聚和处理的核心功能，在数据中心建设中不可或缺。那么它和数据仓库、数据中台是什么关系呢？下图展示了一个典型的从数据采集到数据湖、数据仓库和数据集市，最后为数据应用提供服务的流程。可见，数据湖除了为数据仓库提供原始数据外，还可以直接为上层数据应用提供服务。与数据湖不同，数据仓库是为OLAP需求而构建的数据库，可以分析来自交易系统或不同业务部门的结构化数据。数据仓库中的数据是对原始数据进行清洗、填充、转换后，按照核心业务逻辑组织生成的。通常，数据仓库必须预先定义数据库模式，重点是实现更快的SQL驱动的深度报告和分析。从数据采集到数据服务提供的流程图01数据湖的由来和作用数据湖的出现主要是为了解决全球原始数据的存储问题。当从业务应用程序、移动应用程序、物联网设备和互联网捕获结构化和非结构化数据时，几乎没有预定义的数据结构，这意味着数据可以在没有仔细设计的情况下存储，也没有明确的分析是为了进行，数据科学家和数据工程师将在后续工作中进行探索和尝试。这种变化极大地促进了大数据的发展。早期的大数据系统的一个吸引人的地方就是它可以存储大量的日志数据，以供后期探索。很多大数据应用都是在大数据系统收集数据之后才出现的。为什么要单独建一个数据湖？要回答这个问题，我们先来了解一下数据湖的一个重要部分——ODS（OperatingDataStore，运营数据存储）。1990年代数据仓库刚出来的时候，已经有了ODS。可以说ODS是数据湖的先行者，因为ODS和数据湖有两个重要的共同点：原始数据无需转换，分析无需预设。ODS一般用于存储业务运行数据，即OLTP（OnlineTransactionProcessing）数据的快照和历史，而数据仓库一般用于存储分析数据，对应OLAP（OnlineAnalyticalProcessing）需求。下表列出了OLTP和OLAP之间的一些差异。OLTP和OLAP的区别在大多数情况下，业务数据库的SQL库表结构与数据仓库的结构是不同的：业务数据库是为OLTP设计的，是系统的实时数据；而数据仓库的数据是为OLAP的需要而构建的，是为了进行多维度的深度分析。这种差异导致基于数据仓库的数据分析受到以下限制：数据仓库的架构设计是预先确定的，难以实现全覆盖。因此，基于数据仓库的分析受限于先前定义的分析目标和数据库模式；从OLTP的实时状态到OLAP的分析数据的转换，会有大量的信息丢失。比如一个账户在特定时间点的余额，一般OLTP系统只存最新值，OLAP系统只存最新值。账户操作的交易一般不会专门存储历史余额，这使得根据历史余额进行分析非常困难。因此，在构建数据仓库时，首先要将OLTP数据导入ODS，然后对ODS进行ETL操作，生成易于分析的数据，最后导入数据仓库。这就是为什么ODS有时被称为数据准备区（stagingarea）的原因。随着Hadoop的逐渐普及，我们发现数据仓库（关系型数据库）的底层技术无法处理一些非结构化数据，最典型的就是服务器日志中包含的数据。除了这些在分析上的功能性缺陷，传统数据仓库底层使用的关系型数据库在处理能力上有很大的局限性，这也是数据湖乃至整个大数据生态系统出现的一大原因。在Hadoop出现之前，Teradata、Vertica等公司尝试使用MPP（MassivelyParallelProcessing）数据库技术来解决数据仓库的性能问题。Hadoop出现后，Hive成为一种相对廉价的数据仓库实现方式，Presto、Impala等SQL-on-Hadoop开源MPP系统也出现了。从2010年开始，业界逐渐将存储在Hadoop上的ODS、采集日志等非结构化或半结构化数据统称为数据湖。有时，数据湖中直接存储源数据（包括ODS和日志存储）副本的部分称为粘性数据层，即原始数据的最直接副本。从根本上讲，数据湖的主要目标是尽可能保持业务的可还原性。例如，在处理业务交易时，数据湖不仅会将OLTP业务数据库的交易记录收集到数据湖中的ODS中，还会将产生交易的相关服务器日志收集到数据的HDFS文件系统中湖。发回给客户的交易凭证也将作为单据数据存储。这样，系统在分析这笔交易的相关信息时，就可以知道这笔交易是从什么渠道产生的（从服务器分析出的访问路径），给客户的凭证是否有不合理的数据格式（因为凭证的格式通常可以动态更改）。02数据湖建设的四大目标数据湖的建设有很多种方式。有的公司以Hadoop为核心实现数据湖，有的公司以MPP为核心加入一些对象存储。虽然建设方式不同，但他们建设数据湖的目标是一致的，主要有以下四点。1)高效地收集和存储尽可能多的数据。将尽可能多的有用数据存储在数据湖中，为后续的数据分析和业务迭代做准备。一般来说，这里的“有用数据”指的是能够提高业务恢复程度的数据。2)支持数据仓库。数据湖可以看作是数据仓库的主要数据源。业务用户需要高性能数据湖来对PB级数据运行复杂的SQL查询，以返回复杂的分析输出。3)数据探索、发现和共享。允许高效、免费、基于数据湖的数据探索、发现和共享。在很多情况下，数据工程师和数据分析师需要运行SQL查询来分析海量数据湖数据。Hive、Presto、Impala等工具使用数据目录来构建友好的SQL逻辑模式，以查询存储在选定格式文件中的基础数据。这允许直接在数据文件中查询结构化和非结构化数据。4）机器学习。数据科学家通常需要在庞大的数据集上运行机器学习算法来进行预测。数据湖提供对企业范围数据的访问，以便用户可以探索和挖掘数据以获得业务洞察力。基于这些目标，数据湖必须支持以下功能。数据来源的全面性：数据湖应该能够高速高效地收集来自任何来源的数据，以帮助进行完整而深入的数据分析。数据可访问性：以安全和授权的方式支持组织/部门范围内的数据访问，包括数据专业人员和企业的访问，不受IT部门的约束。数据的及时性和正确性：数据很重要，但前提是及时收到正确的数据。所有用户都有一个有效的时间窗口，在此期间正确的信息可以影响他们的决定。工具的多样性：对于组织范围内的数据，数据湖应该使用户能够使用他们需要的工具集来构建他们的报告和模型。03数据湖数据采集与存储数据采集系统负责将源头的原始数据采集到数据湖中。数据湖主要收集以下数据。1）ODS：存储各种业务系统（生产系统）的原始数据，通常以定时快照的形式从生产数据库中采集，或者以ChangeDataCapture（CDC）的形式从数据库日志中采集。后者稍微复杂一点，但是可以减轻数据库服务器的负载，达到更好的实时性。从生产库采集时，建议搭建主从集群，从从库采集，避免对生产库性能造成影响。2）服务器日志：系统中各个服务器产生的各种事件日志。一个典型的例子是Internet服务器的日志，其中包含页面请求的历史记录，例如客户端IP地址、请求的日期/时间、请求的页面、HTTP代码、服务的字节数、用户代理、引荐来源网址等。这些数据可能都是在一个文件中，也可能分离到不同的日志中，比如访问日志、错误日志、referrer日志等。我们通常会将各种业务应用的日志原封不动地收集到数据湖中。3）动态数据：一些动态产生的数据是不在业务系统中的，比如为客户动态产生的推荐商品，客户行为的埋点数据等。这些数据有时在服务器日志中，但更多的时候是收集在以独立数据表或WebService的形式。埋点是数据采集领域（尤其是用户行为数据采集领域）的一个术语，指的是对特定用户行为或事件进行捕获、处理和发送的相关技术和实现过程，如次数用户点击一个图标，一个视频看了多长时间等。埋点是用户行为分析中非常重要的一个环节，它决定了数据的广度、深度和质量，并且可以影响到后续的所有环节。因此，应将这部分埋点数据采集到数据湖中。4）第三方数据：从第三方获取的数据，如用户信用数据、用户广告行为数据、应用商店下载数据等。这些原始数据的常见采集方式如下。传统数据库数据采集：数据库采集是通过Sqoop或DataX等采集工具将数据库中的数据上传到Hadoop的分布式文件系统，并创建对应的Hive表的过程。数据库采集分为全量采集和增量采集。全量采集是一次性采集一个源表中的所有数据，增量采集是每隔一段时间从源表中采集新的数据。Kafka实时数据采集：Web服务数据往往写入Kafka，通过Kafka快速高效传输到Hadoop。Confluent开源的KafkaConnect架构可以轻松支持Kafka到Hive表的数据传输。日志文件收集：对于日志文件，通常使用Flume或者Logstash来收集。爬虫程序采集：需要通过编写爬虫程序来获取大量的网页数据，模拟登录并进行页面分析。WebService数据采集：一些数据提供者提供基于HTTP的数据接口，用户需要编写程序访问这些接口来不断获取数据。数据湖需要支持海量异构数据的存储。以下是一些常见的存储系统及其适用的数据类型。HDFS：一般用于存储日志数据，作为通用的文件系统。Hive：一般用于存储ODS和导入的关系数据。Key-valuestore：如Cassandra、HBase、ClickHouse等，适用于对性能和扩展性有要求的加载和查询场景，如物联网、用户推荐、个性化引擎等。DocumentStore：如MongoDB、Couchbase等，适用于需要数据存储可扩展性的场景，如处理游戏账号、票务、实时天气预警等。GraphStore：如Neo4j、JanusGraph等，用于在处理大数据集时建立数据关系和提供快速查询，如推荐和推广相关产品，建立社交图增强内容个性化等。ObjectStore：例如Ceph、AmazonS3等，适用于更新变化不大的目标文件数据、没有目录结构的文件、不能直接打开或修改的文件，如图片存储、视频存储等。一般来说，数据湖存储应支持以下功能。1）可扩展性。企业数据湖充当整个组织或部门数据的集中式数据存储，并且它必须能够弹性扩展。需要注意的是，虽然云原生架构相对容易支持弹性扩展，但是数据中心会有空间和功率的限制。计划建设大规模数据湖的企业需要考虑多数据中心或混合云架构，否则几年就会卡壳。move”的困境。2）数据高可用。数据的时效性和持续可用性是辅助决策的关键，因此必须使用HDFS、Ceph、GlusterFS等支持多备份和分布式高可用的架构。3）高效存储效率，数据湖的数据量以PB为单位，由于需要多次备份（3个以上），所以存储效率非常重要。例如，使用LZO压缩存储HDFS文件，可以达到1:6甚至1:7的压缩比，并且通过系统支持可以实现透明访问，即程序可以直接使用数据而无需先扩展到临时空间。另外，列式存储也是一种常用的有利于压缩的存储方式。更高的存储效率意味着需要更少的服务器，使用更少的电力，并且扩容的时间间隔更长。因此，存储效率对于数据湖的运行非常重要。4）数据持久化。数据一旦存储，就不会因为磁盘、设备、灾难或其他任何因素而丢失。除了采用分布式架构，一般还需要考虑多数据中心、混合云架构支持的异地备份。5)安全。安全性至关重要，应该成为本地和基于云的企业数据湖的重中之重。例如，数据必须加密，必须是不可变的（任何需要的地方），并且必须符合行业标准；对数据系统的访问必须支持端到端的授权和身份验证集成等。安全性应该从一开始就设计到数据湖中，并融入到基本架构和设计中。只有在企业整体安全基础设施和控制框架内部署和管理数据湖，它才能是安全的。6)治理和审计。应用治理规则和数据不变性、识别用户私有数据并提供完整的数据使用审计日志的能力对于满足法规和法定要求至关重要。7)可以存储任何内容。在数据湖设计之初，有一个主要考虑因素：以任何格式（结构化和非结构化）存储数据并提供快速检索。当然，这里的“快”并不是说需要像面向用户的系统那样提供实时响应，运行在数据湖上的应用对交互的要求会更低。尽管如此，Presto、Impala等SQL-on-Hadoop解决方案正在逐步提升数据湖的交互体验。8)可以支持不同大小和格式的存储文件。在很多场景下，系统需要存储很多小文件，这些文件的大小远小于Hadoop文件系统(HDFS)中默认的块大小128MB。在基于Hadoop的框架中，每个文件在集群名称节点的内存中表示为一个对象，每个对象通常占用150B。这意味着大量的文件会消耗大量的内存。因此，大多数基于Hadoop的框架都不能有效地利用小文件。另一个重要方面是文件的格式。比如使用列存储（ORC和Parquet）可以提高文件的压缩率，读取时只解压处理当前查询需要的值，可以大大减少磁盘I/O和查询时间.04数据湖中的数据治理很多人认为数据湖存储的是原始数据，不需要治理，其实是一种误解。准确地说，数据湖存储的是未转换的数据，任何需要支撑分析的数据都需要被治理。数据治理是指对企业数据的可用性、完整性和安全性的综合管理，具体内容主要取决于企业的业务战略和技术实践。比如我们可以要求写入数据湖的ODS数据经过schema校验，保证业务系统schema的变更不会在没有协调的情况下进入数据湖，导致现有数据湖应用失效。另一个例子是合规性要求。数据湖负责全球数据收集，其中通常包括消费者的个人身份信息。必须合规处理这些敏感数据，以确保系统符合隐私法律法规。因此，数据治理应该从一开始就构建到数据湖的设计中，至少要有最低的治理标准。数据湖中的数据治理主要包括以下几个方面。数据目录。由于数据湖中存储的数据量巨大，因此很难跟踪哪些数据可用，而且很容易不知所措。解决方案是维护一个数据目录。数据目录是元数据的集合，结合了数据管理和搜索工具，可帮助分析师和其他用户查找数据。数据目录充当可用数据的清单，并提供信息以评估适用数据的预期用途。最有效的方法是维护一个中央数据目录，并在各种处理框架（如Hadoop、Spark和其他可用工具）中使用它，以便可以应用简单的数据治理规则来确保元数据的完整性。数据质量。数据质量体系要保证数据的完整性、准确性、一致性和标准化，否则基于数据得出的结果是不可靠的，这就是所谓的“垃圾进，垃圾出”（GarbageIn，GarbageOut）方法。数据湖没有通用的数据质量管理体系，但像DeltaLake这样的项目已经在探索如何解决这些问题。数据合规性。根据其运营的业务领域，数据湖必须满足某些合规性要求，例如GDPR(《通用数据保护条例》)、HIPAA(《健康保险便利和责任法案》)和ISO等标准和规范。对于很多公司来说，数据合规是一项非常重要的工作。一旦数据合规性出现问题，可能会导致巨额罚款或数据泄露，进而损害公司声誉。本书节选自《云原生数据中台：架构、方法论与实践》，经出版社授权发布。
