大数据查询利器 Hive 01:认识大数据

Posted by YEY on August 1, 2021

1. ⼤数据来源(⼤数据是如何产⽣的)

我们知道:Excel 的一张工作表可以存储 104 万条记录,并且在这种数据量级下其处理速度非常慢;MySQL 单表可以存储 4000 多万条记录,同样也是数据越多处理越慢;与 MySQL 并行存在的 Oracle、SQL Server 的存储能力也是千万级的。但是,随着互联网的发展、万物互联的实现,大数据的到来是必然趋势。随着海量数据的产生,Excel、MySQL 等工具处理起来就显得无能为力了,所以新技术的诞生也就成了必然趋势。因此,我们先来探讨一下海量数据是如何产生的。

在典型的数据分析系统中,要分析的数据种类⽐较丰富,依据来源⼤体可以分为以下⼏部分:

内部数据,也就是公司的产品(例如 App、网站、小程序等)产生的数据,又分为前端数据和后端数据。前端数据就是用户在网站上浏览、点击行为的数据,对于前端数据的获取可以通过 JS 和埋点实现:如果公司的产品是 PC 网站或者 H5,也就是通过 HTTP 协议与服务器进行交互的,那么我们可以通过 JS 获取前端数据;如果公司产品是移动端(例如小程序、App 等),那么我们需要通过埋点获取前端的用户行为数据。后端数据主要是业务系统产生的数据(例如订单数据)则可以通过接口或者日志获取。外部数据主要包括行业数据以及竞品公司数据,对于此类数据的获取方式,可以采用爬虫和搜索引擎。总之,我们的数据来源越丰富,所能开展的数据分析工作就越全面、越具体。

1.1 内部数据

接下来,我们针对不同数据来源,来具体了解一下数据采集方式。

1.1.1 埋点

首先,我们来看一下数据分析师经常参与的埋点数据收集工作:

1.1.2 埋点原理

对基于⽤户⾏为的数据平台来说,发⽣在⽤户界⾯的,能获取⽤户信息的触点就是⽤户数据的直接来源,⽽建⽴这些触点的⽅式就是埋点。当这些触点获取到⽤户⾏为、身份数据后,会通过⽹络传输到服务器端进⾏后续的处理。

1.1.3 埋点分类

埋点从准确性⻆度考虑,分为客户端埋点和服务端埋点。客户端埋点,即客户操作界⾯中,在客户产⽣动作时对⽤户⾏为进⾏记录,这些⾏为只会在客户端发⽣,不会传输到服务器端;⽽服务端埋点则通常是在程序和数据库交互的界⾯进⾏埋点,这时的埋点会更准确地记录数据的改变,同时也会减⼩由于⽹络传输等原因⽽带来的不确定性⻛险。

全埋点

为了能够监测网站或者 App 上的用户行为, 我们需要在网站上的每一页或者 App 上添加一段程序代码:在网站上它被称为 监测代码,在 App 中则被称为 SDK 代码。无论是监测网站还是 App,我们都必须添加这类代码才能收集到用户数据。所以,添加这类代码与是否采用埋点无关,无论是埋点方法还是非埋点方法,只要我们需要对网站或者 App 进行用户行为数据采集,都需要添加监测代码或者 SDK 代码,因此也可以将其称为 基础代码。因此,从采集说明中可以看到,无论是代码埋点、全埋点还是可视化埋点,都需要嵌入 SDK 代码。

代码埋点

另外,在收集数据时,总有一些特殊的用户操作行为是基础代码无法采集的,其中比较典型的就是被称为 “事件” 的这类操作。所谓 事件,在网页中是指 非 HTTP 类型交互,例如 AJAX、Flash 等各种页面插件交互;在 App 中则是指包含用户点击在内的所有交互。可以将其理解为一个规律:凡是支持 HTTP 协议的交互(即普通的网页链接),都可以通过基础代码来监测到用户行为数据;对于非 HTTP 类型的交互,监测代码就无能为力了。因此,App 上的所有点击交互都是事件也就不难理解了,因为 App 遵循的不是 HTTP 协议,所以基础监测代码对其无效。

每一个需要我们监测的事件的互动都被称为一个 监测点。可以想象,Web 上的监测点不会特别多,因为大部分都是 HTTP 交互的,因此基础代码就能搞定;而 App 上则布满了监测点,为了采集这些监测点上的用户互动行为数据,我们必须在这些监测点上部署专用的事件监测代码,这些代码需要手工一个个添加在需要获取数据的监测点上,这个过程被称为 代码埋点

总结一下,就是代码埋点是在全埋点(也就是无埋点)的基础上进行的,因为全埋点只需要添加基础代码就可以了,而代码埋点在此基础上还需要添加事件代码。因此,如果我们的分析需求对于自定义事件属性要求比较高,例如在注册页面添加了哪一个信息、具体添加的内容是什么、需要获取多维数据进行分析,就需要使用前端的代码埋点。显而易见,它的优点是可以根据自身业务需求比较方便地设置自定义事件和属性,传递更丰富的数据到服务器,即采集的业务信息更完整、对数据的分析更聚焦。缺点就是,每次上线新的埋点或者更新原有埋点的时候都会发布新的版本,但是难免有些用户是不更新版本的,因此有些数据就会采集不到,从而对数据质量造成影响;同时,统计代码的引用对性能也会产生一定的影响,例如反应慢、传递速度慢等等;另外,由于每一个事件埋点都需要添加相应的事件代码,这种埋点方式的工作量也是相当巨大的。

可视化埋点

由于代码埋点是在基础 SDK 代码的基础上增加了事件监测代码,从而增加了开发人员的工作量,所以就提出了一个需求:有没有一种方式可以进行圈选式地定义事件,这样运营人员和开发人员就可以自行进行埋点了。因此,我们就有了可视化埋点,它是在基础 SDK 代码的基础上通过可视化圈选的形式来定义事件。所以与代码埋点相比,其优点是可以减小开发人员的工作量,缺点是会增加业务人员的工作量,但总体来看总工作量和难度有所下降。

服务端埋点

服务器端埋点主要进行接口调用和数据结构化。与前端埋点相比,该方式更加灵活、准确,数据上传更及时,但是缺少部分前端数据(例如环境信息等)。

大部分公司通常都是由数据产品经理或者业务线的数据分析师来结合版本迭代过程进行埋点。如果是代码埋点,还需要开发人员的参与。

1.1.4 埋点采集工作流程

接下来,我们来看一下埋点采集数据的工作流程:

首先,当产品变动时会产生需求(通常来自业务方),然后由产品经理或者运营人员基于自己对业务的理解,明确核心关键指标来进行需求确认。需求评审环节主要是为了保证技术研发人员、数据产品经理、业务方等对埋点需求的理解是一致的,避免各类人员在面对不确定的需求时按照自己理解进行埋点,从而导致上线后采集的数据不符合需求。因此,需求评审环节在整个流程中非常重要。

然后,进行需求拆解,在此环节我们需要思考采集分析哪些数据能帮助我们实现需求目标,比如我们想要了解注册页面的注册转化率,我们就需要拆解从进入注册页面到完成注册的每一个步骤的数据:包括每一次输入的数据、完成或者未完成注册用户的一些特征数据、以及在退出页面时完成到了哪一步。在需求拆解完成之后,我们就能够明确需要采集哪些数据,数据分析师就可以设计合理的埋点方案了,这也是整个埋点流程中最重要的一个环节,我们会在后面的内容中详细介绍如何进行埋点设计。

数据相关负责人确定了埋点方案之后,还要组织业务方和技术开发方进行埋点方案的评审, 评审通过后才能进行埋点开发。埋点开发环节主要由技术研发人员来执行,当然数据产品经理也可以适当参与进来。开发团队完成埋点开发后,还要先进行埋点自测。

在埋点工作完成后,需要对埋点的有效性进行测试,这是保证埋点质量的关键一环,通常应该从以下几个方面来进行:1. 埋点代码是否引入,即所有的监测点是否监测到;2. 点击位以及相关事件的参数是否正常加入埋点,即采集的信息是否足够全面;3. 数据是否正常上报,即采集到的数据是否正常上传到服务器端。

在开发团队完成埋点开发及测试后,需要数据团队对数据进行检验,只有验收成功后才能进行正式的部署上线。埋点上线后,业务方和数据团队即可使用数据平台上埋点上报的数据进行监测或者分析,来实现我们最初的需求。

1.1.5 埋点数据采集维度

接下来,我们来看一下埋点采集数据的维度。因为多数情况下,我们都是采集用户行为数据的,也就是什么用户在什么时间、什么地点发生了什么行为,所以我们可以从 4W1H 视角出发来设计事件埋点的维度。

1.1.6 埋点文档输出

我们知道,埋点的目的是为了收集数据,又因为数据的价值在于驱动业务,所以不同业务需求的埋点方式以及上报的信息都是有所差异的。而同一产品的埋点数量又非常多,为了区分、整理、应用这些埋点数据,就需要整理埋点文档,记录好相关的埋点信息。从我们了解的流程以及埋点作用可以看出,埋点中的主要要素包含以下⽅⾯:

埋点文档有助于我们更好地理解埋点数据,以便后期的维护和迭代。在了解了埋点的作用、方式以及工作流程和收集数据的维度后,接下来我们通过一个案例来看一下如何设计埋点。

1.1.7 埋点案例:优惠券营销场景的事件设计

在整个埋点⼯作流程中,埋点设计环节是最关键的⼀环,在这个环节整体可以根据需求梳理和转化路径分为四个阶段:业务分解、分析指标、事件设计、属性设计。其中,业务分解和分析指标,是事件设计和属性设计的关键信息输⼊,通过对业务场景和分析需求的梳理,确认埋点的内容和范围;⽽事件和属性设计,则是将这些业务分析诉求,转换成⾯向开发人员的需求语⾔,让开发人员能看懂需要在什么场景和规则下采集哪些数据。接下来,我们以优惠券营销场景为案例,讲述该如何进⾏埋点设计。

不难发现,我们设计的属性越多,收集的数据就越多,我们的分析就更明确。为了设计好属性(即收集的信息更全面),以埋点采集中常⻅事件属性的类型为例,主要包含四个方面:⽤户属性、事件属性、对象属性、环境属性

企业内部数据主要包含业务系统产生的数据(例如订单数据),另外还有一大部分就是通过埋点收集的用户交互数据。接下来我们来看一下外部数据。

1.2 外部数据

外部数据主要包含竞争对手数据和行业数据。

1.2.1 竞争对手数据

对于竞争对手数据,我们可以自己手动编写爬虫程序或者使用现成的软件(例如火车头、八爪鱼、后羿等)进行数据爬取。 电子商务行业最初对于爬虫的需求来源于比价,而像淘宝平台这种目前已经有了 “生意参谋” 和 “生e经” 这类功能,就不再需要通过爬虫获取数据来进行比价了。

1.2.2 行业数据

对于行业数据,我们可以在国家统计局官网(https://data.stats.gov.cn)进行下载,或者通过友商提供。

1.3 大数据的特点

通过观察数据来源,我们可以发现大数据具有以下五大特点:

  1. Volume(海量性)
  2. Variety(多样性)
  3. Value(低价值密度)
  4. Velocity(高速性)
  5. Veracity(真实性)

2. 数据仓库(数据是如何存储的)

我们已经介绍了大数据的特点,为了高效存储这些种类繁多、体量巨大的数据,数据仓库就应运而生了。但是,数据仓库规模⼤、周期⻓,⼀些规模⽐较⼩的企业⽤户难以承担。因此,作为快速解决企业当前存在的实际问题的⼀种有效⽅法,独⽴型数据集市成为⼀种既成事实。

数据集市(Data Mart),也叫 数据市场,数据集市就是满⾜特定的部⻔或者⽤户的需求,按照多维的⽅式进⾏存储,包括定义维度、需要计算的指标、维度的层次等,⽣成⾯向决策分析需求的数据⽴⽅体。

数据集市主要是 针对⼀组特定的某个主题域、部⻔或者特殊⽤户需求的数据集合。这些数据需要针对⽤户的快速访问和报表展示进⾏优化,优化的⽅式包括对数据进⾏轻量级汇总,以及在数据结构的基础上创建索引。

数据集市的⽬标分析过程包括对数据集市的需求进⾏拆分,按照不同的业务规则进⾏组织,将与业务主题相关的实体组织成主题域,并且对各类指标进⾏维度分析,从⽽形成数据集市⽬标说明书。内容包括详细的业务主题、业务主题域和各项指标及其分析维度。

2.1 什么是数据仓库

数据仓库(Data Warehouse,简称 DW),顾名思义是⼀个很⼤的数据存储集合,出于企业的分析性报告和决策⽀持⽬的⽽创建,对多样的业务数据进⾏筛选与整合。它为企业提供⼀定的 BI(商业智能)能⼒,从而指导业务流程改进。

2.2 数据仓库解决什么问题

数据仓库从⼤的⽅向来说解决三类问题:存储、快速提取、跨部⻔应⽤

当我们将不同数据整合到数据仓库之后,大数据就有了存储的位置,然后不同的部门就可以对这些数据进行不同的应用,例如报表展示、数据分析、数据挖掘、即席查询等。另外,快速提取是我们对数据仓库的基本需求,因此数据仓库在设计之初就应该具备快速提取的功能,具体通过分布式技术实现。

2.3 数据仓库的主要特征

数据仓库的主要特征有以下四点:

  1. 面向主题的

    传统数据库最大的特点就是面向应用进行数据组织,一个业务系统管理一部分企业数据,不同业务系统之间是相互分离的。而数据仓库则是面向主题的,从前面的架构图中可以看到,它对多个业务数据进行整合从而实现面向主题。

  2. 集成的

    集成是指数据仓库中的数据必须是一致的,也就是我们需要通过 ETL 进行转码编辑。数据仓库中的数据是从原有的、分散的多个数据库、用户文件、日志数据中抽取出来的,这里的数据来源可能既有内部数据又有外部数据。数据仓库中的数据是为分析而服务的,而分析又需要多种广泛的不同数据源数据以便进行比较鉴别,因此数据仓库中的数据必须从多个数据源中获取,这些数据源包含前面提到各种内部数据和外部数据, 这些数据通过数据集成转变为数据仓库中的数据。

  3. 稳定的(不易失的)

    数据仓库中的数据反映的是一段相当长的时间内历史数据的内容,是不同时间点的数据库快照的集合,以及基于这些快照进行统计、综合和重组后得到的一个导出数据。一旦数据进入数据仓库后,一般情况下会保留较长时间,并且极少更新。

  4. 时变的(反映历史变化的)

    数据仓库中包含各种粒度的历史数据,这些数据与某个特定的时期(例如星期、月份)是相关的。虽然数据仓库不会修改数据,但这并不意味着数据仓库中的数据是永远不变的,它们也需要更新以适应新的需求。数据仓库中的数据随时间的变化主要表现在以下几个方面:

    • 数据仓库中的数据时限一般要远远长于操作类数据库中的数据时限;
    • 业务系统存储的是当前数据,而数据仓库中的数据是历史数据;
    • 数据仓库中的数据是按照时间顺序进行追加的,因此都带有时间属性,能够反映数据的历史变化。

2.4 数据仓库与数据库的区别

数据库与数据仓库的区别实际讲的是 OLTP(On-Line Ttransaction Processing,联机事务处理)OLAP(On-Line Analytical Processing,联机分析处理)的区别。在对比二者具体差异之前需要明确一点:数据仓库的出现并非要取代数据库,两者有各自的适用场景。

以下是数据库与数据仓库的具体差异项对比:

我们以某银行业务为例来简单说明一下:数据库是事务系统的数据平台,客户在银行的每一笔交易都会写入数据库中记录下来,这里可以简单理解为我们使用数据库来记账;而数据仓库是分析系统的数据平台,它从事务系统(即数据库)获取数据,并进行汇总、加工,为决策者提供决策依据,比如某银行某分行一个月内发生了多少笔交易、该分行当前存款余额是多少,如果存款多、消费交易多,那么该地区就有必要设立 ATM 了。银行的交易量是巨大的,通常以百万甚至千万计算:由于事务系统是实时的,这种场景下要求时效性,比如客户存一笔钱需要几分钟是无法忍受的,这就要求数据库只能存储很短一段时间的数据;而分析系统是事后的,它要提供关注的时间段内的所有有效数据,这些数据是海量的,所以汇总计算起来也要慢一些,但只要能够提供有效的分析数据,目的就达到了。因此,数据仓库是在数据库已经大量存在的情况下,为了进一步挖掘数据资源和决策需要而产生的,而绝不是所谓的大型数据库。

2.5 数据仓库的架构

数据仓库是大数据时代的必然产物,它具有四个特征(面向主题的、集成的、稳定的、时变的),因此我们主要用它来解决三类问题:存储海量数据、快速提取、跨本部门应用。其中,针对跨部门应用和快速提取,我们需要设计好数据仓库的架构,主要从以下四个方面来考虑:性能、质量、成本、效率。

⼤数据系统需要数据模型⽅法来帮助更好地组织和存储数据,以便在性能(例如提取速度快)、成本(例如数据仓库有多少个集群等)、效率和质量这四个方面取得最佳平衡,主流的⽅法是 分层架构

数据仓库的数据来源于不同的源数据(例如 MySQL、Oracle、文档等),并提供各种不同的数据应⽤(例如报表展示、数据分析、数据挖掘等)。数据⾃下层流⼊数据仓库后向上层开放数据应⽤,⽽数据仓库只是中间集成化数据管理的⼀个平台,所以我们在设计数据仓库系统的时候通常采用分层架构。

下面我们介绍一些知名企业的数据仓库架构:

华为:

星环科技:

华为和星环采用的都是分层架构,我们介绍了在进行数据仓库架构设计的时候,需要从性能、质量、成本、效率四个方面平衡考量,分层架构主要是从效率和性能方面进行考量的,而质量方面则是通过 元数据管理数据治理 来保证。

2.6 数据仓库的元数据管理

元数据(MetaData)主要记录数据仓库中模型的定义,各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运⾏状态。⼀般会通过 元数据质量库(Metadata Repository)来统⼀地存储和管理元数据,其主要⽬的是使数据仓库的设计、部署、操作和管理能达成协同和⼀致,保证数据质量。

元数据是数据仓库管理系统的重要组成部分,元数据管理是企业级数据仓库中的关键组件,贯穿数据仓库构建的整个过程,直接影响着数据仓库的构建、使⽤和维护。

构建数据仓库的主要步骤之⼀是 ETL,这时元数据将要发挥重要的作⽤,它定义了源数据系统到数据仓库的映射、数据转换的规则、数据仓库的逻辑结构、数据更新规则、数据导⼊历史记录以及装载周期等相关内容。数据抽取和转换的专家以及数据仓库管理员正是通过元数据⾼效地构建数据仓库。

⽤户在使⽤数据仓库时,通过元数据访问数据,明确数据项的含义以及定制报表数据仓库的规模及其复杂性离不开正确的元数据管理,包括增加或移除外部数据源,改变数据清洗⽅法,控制出错的查询以及安排备份等。

总之,由于数据仓库是数据来源种类比较多(例如 MySQL、日志、外部数据等),在这些源数据进入数据仓库时,要经历 ETL 的抽取、加载、转换等操作步骤,所以元数据实际上定义了这些源数据到数据仓库的映射关系、转换规则等。同理,在数据应用层,即用户在使用数据时,也是通过元数据来访问所需数据的,因为元数据记录了这些数据的位置。同样,在进行数据分析时,我们也需要知道数据清洗的规则。下面我们来看一下元数据具体的工作内容:

元数据分为 技术元数据业务元数据

  1. 技术元数据为开发和管理数据仓库的 IT ⼈员使⽤,它描述了与数据仓库开发、管理和维护相关的数据,包含数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。

  2. 业务元数据为管理层和业务分析⼈员服务,从业务⻆度描述数据包括商务术语、数据仓库中有什么数据、数据的位置和数据的可⽤性等。

元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等,⽽且是整个数据仓库系统运⾏的基础,它把数据仓库系统中各个松散的组件联系起来,组成了⼀个有机的整体。

2.7 数据治理

前面我们提到,我们可以从元数据管理和数据治理两个方面来保证数据仓库中的数据质量。数据治理又可以分为广义上的和狭义上的,这里我们只介绍狭义上的数据治理,即从数据分析的角度来介绍数据治理是如何影响数据质量从而影响分析的。

我们知道,数据是企业的核⼼资产,数据治理能成就企业(特别是数据服务分公司、银⾏等)的未来。它涉及数据质量、数据管理、数据 政策、商业过程管理、⻛险管理等多个领域。这里的治理主要针对的是脏数据,接下来我们来看一下脏数据的种类,以及对于不同种类的脏数据我们是如何处理的。

2.7.1 脏数据的种类

脏数据主要分为以下四大类:

  1. 数据缺失
  2. 数据重复
  3. 数据错误
  4. 数据不可用

2.7.2 数据治理原则

数据治理原则主要包含两个方面:

  1. 约束输入:必须填的数据类型要约束好(即规则要统一);
  2. 规范输出:统一语义(即口径、计算方式要一致),需要构建一个公司级别的语义字典,防止出现数据错误和数据不可用。

3. Hadoop 概述

3.1 Hadoop 简介

到目前为止,我们知道了海量数据的存储使用的是数据仓库,而为了保证数据的质量,我们需要进行元数据管理和数据治理,而为了保证这些数据的性能和使用效率,通常采取分层架构设计。目前市面上使用比较广泛的数据仓库是 Hive,也是我们接下来要学习的主要内容,而 Hive 则是依存于开源分布式计算平台 Hadoop,所以我们需要先了解一下 Hadoop。

Hadoop 是什么?简单来说,Hadoop 旨在解决⼤数据时代下海量数据的存储和分析计算问题。

Hadoop 不是指具体的⼀个框架或者组件,它是 Apache 软件基⾦会下⽤ Java 语⾔开发的⼀个 开源分布式计算平台,实现在⼤量计算机组成的集群中对海量数据进⾏分布式计算,适合⼤数据的分布式存储和计算,从⽽有效弥补了传统数据库在海量数据下的不⾜。

3.2 Hadoop 的优点

  • ⾼可靠性:Hadoop 按位存储和处理数据的能⼒值得⼈们信赖。
  • ⾼扩展性:Hadoop 是在可⽤的计算机集群间分配数据并完成计算任务,这些集群可以⽅便地扩展到数以千计的节点中。
  • ⾼效性:Hadoop 能够在节点之间动态地移动数据,并保持各个节点的动态平衡,因此处理速度⾮常快。
  • ⾼容错性:Hadoop 能够⾃动保存数据的多个副本,并且能够⾃动将失败的任务重新分配。
  • 低成本:Hadoop 是开源的,项⽬的软件成本因⽽得以⼤⼤降低。

3.3 Hadoop ⽣态圈

接下来我们来看一下 Hadoop 的生态圈:

Hadoop 生态圈中的 核心组件HDFSMapReduce,随着处理任务的多样性,Hadoop 生态圈中的组件会越来越多。

3.4 分布式存储(HDFS)

HDFS 就是将⽂件切分成固定⼤⼩的数据块 Block。

注意:⽂件严格按照字节来切分,所以若是最后切得剩⼀点点,也要算单独⼀块,Hadoop 2.x 默认的固定块⼤⼩是 128MB,不同版本的默认值不同,可以通过 Client 端上传⽂件设置。

例如:假设我们有一个 200MB 的文件,HDFS 默认会将其切分 2 个 Block,大小分别为 128MB 和 72MB,并且将它们分别存储在两个不同的 DataNode 上。另外,HDFS 会对每一个 Block 进行备份,默认情况下连同本体会备份 3 份,不同的副本存储在不同的 DataNode 上。另外,如果我们将某数据的两个 Block 存储在同一个 DataNode 上,当我们对该数据进行计算时,可以在一个节点上计算 Block1,另一个节点上计算 Block2 的副本,使得不同节点之间的工作量保持均衡。

正是因为 HDFS 的分布式存储和多副本备份,Hadoop 得以实现其容错性和高效性(工作量均衡)。

3.5 分布式计算(MapReduce)

MapReduce 为海量的数据提供计算,保证了 Hadoop 平台的高效性。

MapReduce 从它名字上来看就⼤致可以看出个缘由,两个动词 Map 和 Reduce:其中 Map 就是将⼀个任务分解成为多个子任务,而 Reduce 就是将分解后的多个子任务处理的结果汇总起来,得出最后的分析结果。MapReduce 采⽤的是 “分⽽治之” 的思想,简单地说,MapReduce就是”任务的分解与结果的汇总”。

回到刚才的例子,当我们需要对这个 200MB 的文件进行计算时,MapReduce 会将该计算任务分发给存有该数据副本 Block 的节点,在这些节点完成计算后,MapReduce 再对其进行整合输出。

3.6 其他组件

我们再来看一下 Hadoop 生态圈的其他组件。

首先,我们来看一下 HBase 组件。对于数据仓库来说,它存储的多数是历史数据,不太支持实时交互。但是,HBase 既可以存储数据,也可以和 HDFS 进行交互,因此 HBase 中存储的数据支持实时交互,这意味着 HBase 可以用来完成 MySQL、Oracle、SQL Server 这类业务型数据库的功能,不过现实场景中这样使用的情况比较少。所以在业务系统中,对于数据需要实时交互的情况,我们还是首选传统数据库。

然后,最上面的 Pig、Hive、ChuKwa 组件都属于应用层,它们主要都是对数据进行处理分析的,只是不同组件适用于不同场景。我们在接下来将主要学习其中的 Hive。

最后,我们来看一下 Zookeeper 组件,它主要是对我们的数据平台进行配置和调度,主要用来解决分布式应用中经常遇到的一些数据管理问题,例如统一命名、状态同步等。它的目标是封装好复杂、易出错的相关服务,为用户提供一个简单易用的系统。

举个例子,假设我们的程序是分布式部署在多台机器上的,即每一台机器上都有相应的应用程序,但是如果我们需要更新就需要逐台更改配置文件,这种做法显然比较麻烦。现在,我们将配置文件全部存储在 Zoopkeeper 上的某个目录中,然后每台机器上的相关应用程序就会监测 Zookeeper,当 Zookeeper 中的配置文件发生变化后,它们就会自动下载更新,这样我们就避免了对逐台机器进行更改。

知识共享许可协议本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。 欢迎转载,并请注明来自:YEY 的博客 同时保持文章内容的完整和以上声明信息!