[大数据]大数据基础知识

• 作为一名数据的规划者，我们肯定希望自己的数据能够有秩序地流转，数据的整个生命周期能够清晰明确被设计者和使用者感知到。大多数情况下，我们完成的数据体系却是依赖复杂、层级混乱的。

  • 

  • • 清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解
    • 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
    • 统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
    • 复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题
    • 屏蔽原始数据的异常：不必改一次业务就需要重新接入数据。
    • 数据血缘追踪：能够快速准确地定位到问题，并清楚它的危害范围。

  • 为了满足前面提到数据分层带来的好处，我们将数据模型分为三层：数据运营层（ ODS ）、数据仓库层（DW）和数据应用层（APP）。ODS层存放的是接入的原始数据，DW层是存放我们要重点设计的数据仓库中间层数据，APP是面向业务定制的应用数据。

  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T0Vg5hG2-1629710397045)(C:\Users\Sunlight-E3B\AppData\Roaming\Typora\typora-user-images\image-20210803101643940.png)]

• 数据运营层：ODS（Operational Data Store）

  • “面向主题的”数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。
  • 一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。

• 数据仓库层：DW（Data Warehouse）

  • 数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。DW层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和DWS（Data WareHouse Servce）层。
    • 数据明细层：DWD（Data Warehouse Detail）
      • 该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
    • 数据中间层：DWM（Data WareHouse Middle）
      • 该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。
    • 数据服务层：DWS（Data WareHouse Servce）
      • 又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

• 数据应用层：APP（Application）

  • 主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

• 维表层：（Dimension）

  • 维表层主要包含两部分数据：

    • 高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
    • 低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WzV4qTZ6-1629710397047)(C:\Users\Sunlight-E3B\AppData\Roaming\Typora\typora-user-images\image-20210803102737424.png)]

  • 结合实例再学习

    • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QrDTR0lo-1629710397049)(C:\Users\Sunlight-E3B\AppData\Roaming\Typora\typora-user-images\image-20210803103007140.png)]

• 数据仓库建模的意义

  • 数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，最能够说明数据模型的重要性。只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。

  • • 性能：帮助我们快速查询所需要的数据，减少数据的I/O吞吐，提高使用数据的效率，如宽表。
    • 成本：极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低存储和计算成本。
    • 效率：在业务或系统发生变化时，可以保持稳定或很容易扩展，提高数据稳定性和连续性。
    • 质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。数据模型能够促进业务与技术进行有效沟通，形成对主要业务定义和术语的统一认识，具有跨部门、中性的特征，可以表达和涵盖所有的业务。
    • 大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡！

  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-L3Kv4yRr-1629710397051)(C:\Users\Sunlight-E3B\AppData\Roaming\Typora\typora-user-images\image-20210803104344397.png)]

  • 两种经典的数据仓库建模方法

    1. 关系建模

       • 从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象。是数据仓库之父Inmon推崇的，它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。
       • 当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。
       • 雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。
       • 雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。
       • 建模方法
         • 关系建模常常需要全局考虑，要对上游业务系统的进行信息调研，以做到对其业务和数据的基本了解，要做到主题划分，让模型有清晰合理的实体关系体系，以下是方法的示意：
         • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tQpGz9vj-1629710397052)(C:\Users\Sunlight-E3B\AppData\Roaming\Typora\typora-user-images\image-20210803105540194.png)]

    2. 维度建模

       • 维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。
       • 通常需要选择某个业务过程，然后围绕该过程建立模型，其一般采用自底向上的方法，从明确关键业务过程开始，再到明确粒度，再到明确维度，最后明确事实，非常简单易懂。
       • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tSJERytQ-1629710397052)(C:\Users\Sunlight-E3B\AppData\Roaming\Typora\typora-user-images\image-20210803105106218.png)]
       • 案例：阿里的OneData的建模工作流。

    3. 建模方法比较

       • 一般来讲，维度模型简单直观，适合业务模式快速变化的行业，关系模型实现复杂，适合业务模式比较成熟的行业，阿里原来用关系建模，现在基本都是维度建模的方式了。运营商以前都是关系建模，现在其实边界越来越模糊，很多大数据业务变化很快，采用维度建模也比较方便，不需要顶层设计。

       • 属性	维度模型	关系模型
         数据总量	多	少
         可读性	容易	差
         表数	少	多
         查询速度	快	慢
         冗余度	高	低
         扩展性	差	好
         实施难度	低	高
         开发周期	短	长
         场景应用	快速变化行业，直面客户（战术性）	成熟行业，面向运营商（战略性）

• Kerberos认证流程详解

  • Kerberos是诞生于上个世纪90年代的计算机认证协议，被广泛应用于各大操作系统和Hadoop生态系统中。了解Kerberos认证的流程将有助于解决Hadoop集群中的安全配置过程中的问题。
  • 简单地说，Kerberos提供了一种单点登录(SSO)的方法。考虑这样一个场景，在一个网络中有不同的服务器，比如，打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求。很自然的，不可能让每个服务器自己实现一套认证系统，而是提供一个中心认证服务器（AS-Authentication Server）供这些服务器使用。这样任何客户端就只需维护一个密码就能登录所有服务器。因此，在Kerberos系统中至少有三个角色**：认证服务器（AS），客户端（Client）和普通服务器（Server）。客户端和服务器将在AS的帮助下完成相互认证。在Kerberos系统中，客户端和服务器都有一个唯一的名字，叫做Principal。同时，客户端和服务器都有自己的密码，并且它们的密码只有自己和认证服务器AS**知道。

• 产品测试上线

  • 在企业级（比如：银行）软件的测试过程中，经常会划分为三个阶段——单元测试，SIT和UAT，如果开发人员足够，通常还会在SIT之前引入代码审查机制（Code Review）来保证软件符合客户需求且流程正确。
  • ST（System Test）即软件测试分类中的系统测试，它是将软件作为一个整体来进行测试，主要关注计算机硬件、外部设备、第三方软件、数据和人员等系统元素及环境因素等等。
  • 代码审查机制（Code Review）:被广泛认为是一个好的机制（idea），大量的程序员都需要严格执行。
  • SIT (System Integration Testing) 系统集成测试：在单元测试以后和在系统测试之前。集成测试在已经被单元测试检验后进行作为它的输入模式，组织它们在更大的集合，和递送，作为它的输出，集成系统为系统测试做准备。集成测试的目的是校验功能、性能和可靠性要求，配置在主设计项目中。
  • UAT (User Acceptance Testing)用户验收测试：由最终软件的用户（通常这些用户不了解软件的具体逻辑，而对业务逻辑却相当熟悉）进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。
  • 从时间上看，UAT要在SIT后面，UAT测试要在系统测试完成后才开始。
  • 从测试人员看，SIT由公司的测试员来测试，而UAT一般是由用户来测试。它们两个之间的专注点是不一样的.UAT主要是从用户层面这些去考虑和着手测试,而SIT主要是系统的各个模块的集成测试.这在整个软件过程理论的基础知识中相当重要的.理论上讲SIT是由专业的测试人员去完成,UAT是由用户去做的。
  • PAT(Process action Teams)即过程行动小组。软件工程中，CMMI的过程改进中，凡是参加项目组的过程改进的都称之为PAT的成员。

Hive基本概念

• Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供类SQL查询功能。

• Hive的特点

• • 可扩展：Hive可以自由的扩展集群的规模，一般情况下不需要重启服务。
  • 延展性：Hive支持用户自定义函数，用户可以根据自己的需求来实现自己的函数。
  • 容错：良好的容错性，节点出现问题SQL仍可完成执行。

• 架构图

  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RcFsmlu4-1629710397053)(C:\Users\Sunlight-E3B\AppData\Roaming\Typora\typora-user-images\image-20210803154900169.png)]

• 基本组成

  • 用户接口：包括 CLI、JDBC/ODBC、WebGUI。
    • CLI为shell命令行；JDBC/ODBC是Hive的JAVA实现，与传统数据库JDBC类似；WebGUI是通过浏览器访问Hive。
  • 元数据存储：通常是存储在关系数据库如 mysql , derby中。
    • Hive 将元数据存储在数据库中。Hive 中的元数据包括表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在目录等。
  • 解释器、编译器、优化器、执行器。
    • 完成 HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划的生成。生成的查询计划存储在 HDFS 中，并在随后有 MapReduce 调用执行。

• Hive利用HDFS存储数据，利用MapReduce查询数据

  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ptp6PhQ7-1629710397053)(C:\Users\Sunlight-E3B\AppData\Roaming\Typora\typora-user-images\image-20210803155148528.png)]

• Hive与传统数据库对比

  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bctscO0x-1629710397054)(C:\Users\Sunlight-E3B\AppData\Roaming\Typora\typora-user-images\image-20210803155249430.png)]
  • hive具有sql数据库的外表，但应用场景完全不同，hive只适合用来做批量数据统计分析

• Hive的数据存储

  • Hive中所有的数据都存储在 HDFS 中，没有专门的数据存储格式（可支持Text，SequenceFile，ParquetFile，RCFILE等）

  • 只需要在创建表的时候告诉 Hive 数据中的列分隔符和行分隔符，Hive 就可以解析数据。

  • Hive 中包含以下数据模型：DB、Table，External Table，Partition，Bucket。

    • db：在hdfs中表现为${hive.metastore.warehouse.dir}目录下一个文件夹
    • table：在hdfs中表现所属db目录下一个文件夹
    • external table：外部表, 与table类似，不过其数据存放位置可以在任意指定路径
    • 普通表: 删除表后, hdfs上的文件都删了External外部表删除后, hdfs上的文件没有删除, 只是把文件删除了
    • partition：在hdfs中表现为table目录下的子目录
    • bucket：桶, 在hdfs中表现为同一个表目录下根据hash散列之后的多个文件, 会根据不同的文件把数据放到不同的文件中

• 数据库外表

  • 外表(external table)就像普通的表对像一样，可以select等，只是它是只读的，数据库中只保存了表结构的描述，表数据却没有存放在数据库内，而是存放在了文件系统上。当用户想偶尔使用数据库外的结构化数据时，用起外表来就非常方便，甚至比sqlldr都要方便的多。
  • 外部表是在数据库以外的文件系统上存储的只读表，例如EXCEL、CSV等文件
  • 外部表无法使用insert、update、delete等操作，要修改其数据只能通过修改数据文件。
  • 外部表不能建立索引，如要建立，则需要先create table XX as select * from TestTable
  • 创建的语法类似于： “CREATE TABLE … ORGANIZATION EXTERNAL”

• Hadoop

  • 官网：http://hadoop.apache.org/docs/r1.0.4/cn/

  • Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。Hadoop实现了一个分布式文件系统（ Distributed File System），其中一个组件是HDFS（Hadoop Distributed File System）。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，而MapReduce则为海量的数据提供了计算 。

  • hadoop优点

    • Hadoop是一个能够对大量数据进行分布式处理的软件框架。 Hadoop 以一种可靠、高效、可伸缩的方式进行数据处理。
    • Hadoop 是可靠的，因为它假设计算元素和存储会失败，因此它维护多个工作数据副本，确保能够针对失败的节点重新分布处理。
    • Hadoop 是高效的，因为它以并行的方式工作，通过并行处理加快处理速度。
    • Hadoop 还是可伸缩的，能够处理 PB 级数据。
    • Hadoop 依赖于社区服务，因此它的成本比较低，任何人都可以使用

  • Hadoop得以在大数据处理应用中广泛应用得益于其自身在数据提取、变形和加载(ETL)方面上的天然优势。Hadoop的分布式架构，将大数据处理引擎尽可能的靠近存储，对例如像ETL这样的批处理操作相对合适，因为类似这样操作的批处理结果可以直接走向存储。Hadoop的MapReduce功能实现了将单个任务打碎，并将碎片任务(Map)发送到多个节点上，之后再以单个数据集的形式加载(Reduce)到数据仓库里 。

  • Hadoop 由许多元素构成。其最底部是 Hadoop Distributed File System（HDFS），它存储 Hadoop 集群中所有存储节点上的文件。HDFS的上一层是MapReduce 引擎，该引擎由 JobTrackers 和TaskTrackers 组成。通过对Hadoop分布式计算平台最核心的分布式文件系统HDFS、MapReduce处理过程，以及数据仓库工具Hive和分布式数据库Hbase的介绍，基本涵盖了Hadoop分布式平台的所有技术核心 。

    • MapReduce
      • 最简单的 MapReduce应用程序至少包含 3 个部分：一个 Map 函数、一个 Reduce 函数和一个 main 函数。main 函数将作业控制和文件输入/输出结合起来。在这点上，Hadoop 提供了大量的接口和抽象类，从而为 Hadoop应用程序开发人员提供许多工具，可用于调试和性能度量等。
      • MapReduce 本身就是用于并行处理大数据集的软件框架。MapReduce 的根源是函数性编程中的 map 和 reduce 函数。它由两个可能包含有许多实例（许多 Map 和 Reduce）的操作组成。Map 函数接受一组数据并将其转换为一个键/值对列表，输入域中的每个元素对应一个键/值对。Reduce 函数接受 Map 函数生成的列表，然后根据它们的键（为每个键生成一个键/值对）缩小键/值对列表。
    • HDFS
      • 对外部客户机而言，HDFS就像一个传统的分级文件系统。可以创建、删除、移动或重命名文件，等等。
      • 存储在 HDFS 中的文件被分成块，然后将这些块复制到多个计算机中（DataNode）。这与传统的 RAID 架构大不相同。块的大小（1.x版本默认为 64MB，2.x版本默认为128MB）和复制的块数量在创建文件时由客户机决定。NameNode 可以控制所有文件操作。HDFS 内部的所有通信都基于标准的 TCP/IP 协议 。

m/重命名)文件，等等。
- 存储在 HDFS 中的文件被分成块，然后将这些块复制到多个计算机中（DataNode）。这与传统的 RAID 架构大不相同。块的大小（1.x版本默认为 64MB，2.x版本默认为128MB）和复制的块数量在创建文件时由客户机决定。NameNode 可以控制所有文件操作。HDFS 内部的所有通信都基于标准的 TCP/IP 协议 。