将数据湖讲明白了.docx

《将数据湖讲明白了.docx》由会员分享，可在线阅读，更多相关《将数据湖讲明白了.docx（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、作为全局数据汇总及处理的核心功能，数据湖在数据中台建设中必不可少。 那么它与数据仓库、数据中台是什么关系？下列图显示了一个典型的从数据采集到数据湖、数据仓库及数据集市，最后为 数据应用提供服务的流程。可以看到，除了为数据仓库提供原始数据之外， 数据湖也可以直接为上层的数据应用提供服务。与数据湖不同，数据仓库是 针对OLAP需求建设的数据库，可以分析来自交易系统或不同业务部门的结 构化数据。数据仓库中的数据由原始数据经过清理、填充和转换后按照核心 业务逻辑组织生成。数据仓库一般必须预先定义好数据库Schema,重点是实 现更快的SQL驱动的深度报告和分析。数据源数据库日志文件Kafka其他数据源

2、数据湖贴源层结构化数据将吉构化数据三修吉构化数据数据仓库数据集市事实表维度表A集市表数据服务数据应用 可视化报表 交互式编程数据服务大屏展示其他应用从数据采集到提供数据服务的流程图01数据湖的起源与作用 案）和ISO等标准和规范。对于很多企业而言，数据合规是很重要的工 作，数据合规一旦出问题，可能导致巨额罚款或者数据泄露，损害企业的信 誉。数据湖的出现主要是为了解决存储全域原始数据的问题。在捕获来自业务应 用程序、移动应用程序、IoT设备和互联网的结构化和非结构化数据时，实际 上并没有预先定义好数据结构，这意味着可以先存储数据而无须进行精心设 计，也无须明确要进行什么分析，由数据科学家和数据工

3、程师在后续工作中 探索和尝试。这个改动极大推动了大数据的开展，早期大数据系统的一大吸 引力是能够存储大量日志数据供后期探索，很多大数据应用就是在大数据系 统将数据采集上来之后才出现的。为什么一定要单独建立数据湖呢？要回答这个问题，我们先来了解数据湖的 一个重要组成局部一ODS （Operating Data Store,运营数据存储）。在20世 纪90年代数据仓库刚出来的时候，就已经有ODS 了。可以说ODS是数据湖 的先行者，因为ODS和数据湖有两个共同的重要特征：不加转换的原始数 据，可以进行不预先设置的分析。ODS 一般用来存储业务运营数据，也就是 OLTP （联机事务处理）数据的快照和

4、历史，而数据仓库一般用来存储分析数 据，对应OLAP （联机分析处理）需求。下表列出了 OLTP和OLAP的一些 区别。OLTP和OLAP的区另场景i股为高并发、低时延i股为低并发、大吞吐量用户操作人员、一线管理人员分析决策人员、高级管理人员功能用于存储和管理日常操作的数 据.如当前应用的最新日常操作 数据用于分析日常操作的数据,如 历史的、聚集的、多维的、集成 统一的数据DB设计面向事务，主要处理大量用户 下的大量事务.一般不存储历史 数据（MB、GB级别）面向主题，用于分析日常操作 的多维数据库.存储的数据包括 历史数据（GB、TB、PB级别）数据模型i般使用实体对象模型,必须 满足数据库

5、第三范式（3NF）或 更高一般使用维度模型，如星型模 型、雪花模型.：般不需要满足 3NF查询查询语句一般非常简单直接. 以增、删、改、杳（CRUD）为 主，返回少量数据查询语句一般非常复杂,以多 维度钻取、汇聚为主,返回大量 数据OLTPOLAP绝大多数情况下，业务数据库的SQL库表的结构与数据仓库的结构是不一样 的：业务数据库是为OLTP设计的，是系统实时状态的数据；而数据仓库的 数据是为OLAP的需求建设的，是为了深度的多维度分析。这个差异造成基 于数据仓库的数据分析受到以下限制：数据仓库的架构设计是事先定好的，很难做到全面覆盖，因此基于数据仓库 的分析是受到事先定义的分析目标及数据库S

6、chema限制的；从OLTP的实时状态到OLAP的分析数据的转换中会有不少信息损失，例如 某个账户在某个具体时间点的余额，在OLTP系统里一般只存储最新的值， 在OLAP系统里只会存储对账户操作的交易，一般不会专门存储历史余额， 这就使得进行基于历史余额的分析非常困难。因此，在建立数据仓库的时候，我们必须先将OLTP数据导入ODS,然后在 ODS上进行ETL操作，生成便于分析的数据，最后将其导入数据仓库。这也 是为什么ODS有时也被称为数据准备区（staging area）。随着Hadoop的逐渐普及，大家发现数据仓库底层的技术（关系型数据库）无 法处理一些非结构化数据，最典型的就是服务器日志

7、包含的数据。除了这些 分析上的功能缺陷之外，传统数据仓库底层使用的关系型数据库在处理能力 上有很大局限，这也是数据湖，直至整个大数据生态出现的一个主要原因。在Hadoop出现之前，就有Teradata和Vertica等公司试图使用MPP（Massively Parallel Processing,大规模并行处理）数据库技术来解决数据仓 库的性能问题。在Hadoop出现之后，Hive成为一个比拟廉价的数据仓库实 现方式，也出现了 Presto、Impala这些SQL-on-Hadoop的开源MPP系统。从2010年开始，业界逐渐将ODS、采集的日志以及其他存放在Hadoop上的 非结构或半结构化

8、数据统称为数据湖。有时，数据湖中直接存储源数据副本 的局部（包括ODS和日志存储）被称为贴源数据层，意思是原始数据的最直 接副本。从根本上来讲，数据湖的最主要目标是尽可能保持业务的可还原度。例如， 在处理业务交易的时候，数据湖不仅会把OLTP业务数据库的交易记录采集 到数据湖中的ODS,也会把产生这笔交易的相关服务器日志采集到数据湖的 HDFS文件系统中，有时还会把发回给客户的交易凭证作为文档数据存放。 这样，在分析与这笔交易相关的信息时，系统能够知道这笔交易产生的渠道 （从服务器分析出来的访问路径），给客户的凭证是否有不合理的数据格式 （因为凭证的格式很多时候是可以动态变化的）。02数据湖建

9、设的4个目标数据湖的建设方式有很多种，有的企业使用以Hadoop为核心的数据湖实现， 有的企业以MPP为核心加上一些对象存储来实现。虽然建设方式不同，但是 它们建设数据湖的目标是一致的，主要有以下4点。1）高效采集和存储尽可能多的数据。将尽可能多的有用数据存放在数据湖 中，为后续的数据分析和业务迭代做准备。一般来说，这里的“有用数据”就 是指能够提高业务还原度的数据。2）对数据仓库的支持。数据湖可以看作数据仓库的主要数据来源。业务用户 需要高性能的数据湖来对PB级数据运行复杂的SQL查询，以返回复杂的分 析输出。3）数据探索、发现和共享。允许高效、自由、基于数据湖的数据探索、发现 和共享。在很

10、多情况下，数据工程师和数据分析师需要运行SQL查询来分析 海量数据湖数据。诸如Hive、Presto、Impala之类的工具使用数据目录来构 建友好的SQL逻辑架构，以查询存储在选定格式文件中的基础数据。这允许 直接在数据文件中查询结构化和非结构化数据。4）机器学习。数据科学家通常需要对庞大的数据集运行机器学习算法以进行 预测。数据湖提供对企业范围数据的访问，以便于用户通过探索和挖掘数据 来获取业务洞见。基于这几个目标，数据湖必须支持以下特性。数据源的全面性：数据湖应该能够从任何来源高速、高效地收集数据，帮助 执行完整而深入的数据分析。 数据可访问性：以平安授权的方式支持组织/部门范围内的数据

11、访问，包括数 据专业人员和企业等的访问，而不受IT部门的束缚。 数据及时性和正确性：数据很重要，但前提是及时接收正确的数据。所有用 户都有一个有效的时间窗口，在此期间正确的信息会影响他们的决策。 工具的多样性：借助组织范围的数据，数据湖应使用户能够使用所需的工具 集构建其报告和模型。03数据湖数据的采集和存储数据采集系统负责将原始数据从源头采集到数据湖中。数据湖中主要采集如 下数据。1） ODS :存储来自各业务系统（生产系统）的原始数据，一般以定时快照的 方式从生产数据库中采集，或者采用变化数据捕获（Change Data Capture, CDC）的方式从数据库日志中采集。后者稍微复杂一些

12、，但是可以减少数据库服务器的负载，到达更好的实时性。在从生产数据库中采集的时候，建议 设置主从集群并从从库中采集，以防止造成对生产数据库的性能影响。2）服务器日志：系统中各个服务器产生的各种事件日志。典型例子是互联网 服务器的日志，其中包含页面请求的历史记录，如客户端IP地址、请求日期/ 时间、请求的网页、HTTP代码、提供的字节数、用户代理、引用地址等。这 些数据可能都在一个文件中，也可能分隔成不同的日志，如访问日志、错误 日志、引荐者日志等。我们通常会将各个业务应用的日志不加改动地采集到 数据湖中。3）动态数据：有些动态产生的数据不在业务系统中，例如为客户动态产生的 推荐产品、客户行为的埋

13、点数据等。这些数据有时在服务器日志中，但更多 的时候要以独立的数据表或Web Service的方式进行采集。埋点是数据采集 领域（尤其是用户行为数据采集领域）的术语，指的是对特定用户行为或事 件进行捕获、处理和发送的相关技术及其实施过程，比方用户点击某个图标 的次数、观看某个视频的时长等。埋点是用户行为分析中非常重要的环节， 决定了数据的广度、深度、质量，能影响后续所有的环节。因此，这局部埋 点数据应该采集到数据湖中。4）第三方数据：从第三方获得的数据，例如用户的征信数据、广告投放的用 户行为数据、应用商店的下载数据等。采集这些原始数据的常见方式如下。 传统数据库数据采集：数据库采集是通过Sq

14、oop或DataX等采集工具，将数 据库中的数据上传到Hadoop的分布式文件系统中，并创立对应的Hive表的 过程。数据库采集分为全量采集和增量采集，全量采集是一次性将某个源表 中的数据全部采集过来，增量采集是定时从源表中采集新数据。 Kafka实时数据采集：Web服务的数据常常会写入Kafka,通过Kafka快速 高效地传输到Hadoop中。由Confluent开源的Kafka Connect架构能很方便 地支持将Kafka中的数据传输到Hive表中。 日志文件采集：对于日志文件，通常会采用Flume或Logstash来采集。 爬虫程序采集：很多网页数据需要编写爬虫程序模拟登录并进行页面分

15、析来 获取。 Web Service数据采集：有的数据提供商会提供基于HTTP的数据接口，用户 需要编写程序来访问这些接口以持续获取数据。数据湖需要支持海量异构数据的存储。下面是一些常见的存储系统及其适用 的数据类型。 HDFS : 一般用来存储日志数据和作为通用文件系统。 Hive : 一般用来存储ODS和导入的关系型数据。,键-值存储(Key-value Store):例如 Cassandra、HBase、ClickHouse 等， 适合对性能和可扩展性有要求的加载和查询场景，如物联网、用户推荐和个 性化引擎等。 文档数据库(Document Store):例如MongoDB、Couchb

16、ase等，适合对数 据存储有扩展性要求的场景，如处理游戏账号、票务及实时天气警报等。 图数据库(Graph Store):例如Neo4j、JanusGraph等，用于在处理大型数 据集时建立数据关系并提供快速查询，如进行相关商品的推荐和促销，建立 社交图谱以增强内容个性化等。 对象存储(Object Store):例如Ceph、Amazon S3等，适合更新变动较少 的对象文件数据、没有目录结构的文件和不能直接翻开或修改的文件，如图 片存储、视频存储等。一般来讲，数据湖的存储应该支持以下特性。1)可扩展性。企业数据湖充当整个组织或部门数据的集中数据存储，它必须 能够弹性扩展。注意，虽然云原生架

17、构比拟容易支持弹性扩展，但是数据中 心都会有空间和电力限制，准备建设大规模数据湖的企业需要考虑多数据中 心或混合云的架构，否那么就会陷入几年就要“搬家”的窘境。2)数据高可用性。数据的及时性和持续可用性是辅助决策制定的关键，因此 必须使用HDFS、Ceph、GlusterFS等支持多备份、分布式高可用的架构。3)高效的存储效率。数据湖的数据量是以PB计的，而且因为需要多备份(3 份或更多)，其存储效率就非常重要。例如，使用LZO压缩存储HDFS文件 可以到达1：6甚至1：7的压缩比例，而且可以通过系统支持实现透明访问，也 就是说，程序可以直接使用数据而无须先展开到临时空间。另外，列式存储也是一

18、种常用的利于压缩的存储方式。存储效率越高，意味着需要的服务器 越少，使用的电量越少，扩容的时间间隔越长，因此存储效率对数据湖的运 营非常重要。4）数据持久性。数据一旦存储，就不能因为磁盘、设备、灾难或任何其他因 素而丧失。除了使用分布式架构，一般还需要考虑多数据中心和混合云架构 支持的异地备份。5）平安性。对于本地和基于云的企业数据湖来说，平安都是至关重要的，应 将其放在首位。例如，数据必须经过加密，必须不可变（在任何需要的地 方），并且必须符合行业标准；数据系统的访问必须支持端到端的授权和鉴 权集成等。应该从刚开始建设数据湖时就进行平安性的设计，并将其纳入基 本的体系结构和设计中。只有在企业

19、整体平安基础架构和控件的框架内部署 和管理，数据湖的平安性才有保障。6）治理和审计。要能够应用治理规那么及数据不变性，识别用户隐私数据以及 提供完整的数据使用审计日志的能力，这对于满足法规和法定要求至关重 要。7）可以存储任何内容。数据湖在设计之初，有一个主要考虑的因素：存储任 何格式（结构化和非结构化）的数据并提供快速检索。当然，这里的“快速” 并不是说要像面向用户的系统一样提供实时响应，在数据湖上运行的应用对 交互的要求会低一些。即便如此，Presto、Impala等SQL-on-Hadoop的解决 方案正在逐步提高数据湖的交互体验。8）可以支持不同存储文件的大小和格式。在很多场景中，系统

20、需要存储很多 小文件，这些文件的尺寸远小于Hadoop文件系统（HDFS）的默认块大小 128MBO在基于Hadoop的框架中，每个文件在集群的名称节点的内存中均 表示为一个对象，每个对象通常占用150B。这意味着大量文件将消耗大量内 存。因此，大多数基于Hadoop的框架无法有效使用小文件。另一个重要方面 是文件的格式，例如使用列存储（ORC和Parquet）可以加大文件的压缩比 例，在读取时仅解压缩和处理当前查询所需的值，这样可以大大减少磁盘I/O 和查询时间。04数据湖中的数据治理很多人认为数据湖中存储的是原始数据，不需要治理，这其实是个误区。确 切地说，数据湖存储的是未经转换的数据，任

21、何需要支持分析的数据都是需 要治理的。数据治理是指对企业中数据的可用性、完整性和平安性的全面管 理，具体内容主要取决于企业的业务策略和技术实践。比方，我们可以要求写入数据湖的ODS数据经过Schema的检查，确保业务 系统Schema的改变不会未经协调就进入数据湖，造成现有数据湖应用的失 效。再比方合规的要求，数据湖负责全域数据采集，其中往往包括消费者的 个人可识别信息。这些敏感数据必须经过合规处理，以确保系统遵守隐私法 律和法规。因此，从最开始就应将数据治理纳入数据湖的设计中，至少应采 用最低的治理标准。数据湖中的数据治理主要涵盖以下领域。数据目录。由于数据湖中存储的数据量非常大，因此很难跟

22、踪有哪些数据可 用，而且数据容易被淹没。解决方案是维护数据目录。数据目录是元数据的 集合，结合了数据管理和搜索工具，可帮助分析师和其他用户查找数据。数 据目录充当可用数据的清单，并提供信息以评估适用数据的预期用途。最有 效的方法是维护中央数据目录，并在各种处理框架（如Hadoop、Spark以及 其他可用工具）中使用，这样可以应用简单的数据治理规那么来确保元数据的 完整性。数据质量。数据质量系统应该确保数据的完整性、准确性、一致性以及标准 化，否那么基于数据得出的结果是不可靠的，所谓的“垃圾进，垃圾出”（Garbage In, Garbage Out）就是这个意思。现在并没有一个通用的数据质量 管理系统适用于数据湖，但是类似于Delta Lake这样的工程已经在探索如何 解决这些问题。数据合规。根据所运营的业务领域，数据湖必须满足一些合规要求，例如 GDPR （通用数据保护条例）、HIPAA （健康保险便利和责任法