Hadoop在线分析处理(OLAP)

Posted 2020-10-01 yangykaifa

数据处理与联机分析处理 ( OLAP )

        联机分析处理是那些为了支持商业智能，报表和数据挖掘与探索等业务而开展的工作。这类工作的样例有零售商按地区和季度两个维度计算门店销售额，银行按语言和月份两个维度计算手机银行装机量，设备制造商定位有哪些零部件的故障率比期望值高。以及医院研究有哪些事件会引起高危婴儿紧张等。

       假设原始数据来源于 OLTP 系统。典型的做法是将这些数据复制到 OLAP 数据库中，再进行这类“离线”分析任务的处理，这么做有非常多原因。但考虑最多的还是性能因素。

       如果一下，如果一个实体店使用他们的事务处理系统来承担数据分析工作，这样的情况下分析师提交的粗暴查询就可能会实实在在地影响并拉低门店对于那些已经记录在冊等待结算的订单结算率。另外用于事务中的查询类型从根本上就不同于数据分析类查询。

       事务系统典型的查询是基于某个独立的实体，比方某一个客户或某一个用户。比如当一个在线零售站点创建一个交易订单状态页时。数据的查询是针对某一个客户已经提交的特定订单。然而在数据分析的用例中。分析师最感兴趣的却是那些依据时间维度划分查询本身已跨越了订单或用户数据的汇总信息。就如前面提到的那样。依据区域和季度两个维度统计的门店销售额会查询给定时间段内全部订单数据。

      行动之前还有最后一个注意要点。本篇中的数据库并不提供传统关系型数据库用户所期望的那类增删改操作。

与事务系统不同的是。分析类型的查询主要是那些涉及到数百万甚至数亿行数据的 SELECT 查询。分析型数据库的优化也主要环绕着这类负载进行。而这些优化措施却会导致针对小批量数据的增删改操作运行起来代价昂贵。

      即便这类数据库在接口和语义方面都与关系型数据库不同。但他们也确实提供了添加行 （ INSERT ），更新行（ UPDATE ）和删除行（ DELETE ）操作的功能支持。有些读者也许正在问 Hive 系统里近期新添加的 “ ACID ” 相关的问题，容后详禀。

     在 Hive 系统的 “ACID” 功能之外。处理更新操作有两种方式可选，一种是使用数据所在的 HBase 系统本身提供的更新功能。虽然 HBase 常常主要用于 OLTP 业务。但有些 OLAP 系统会使用 HBase 来存储一些小表，典型的称为维度表。这类表须要周期性地更新。另外一种处理更新操作的方式是运行一次合并操作。

    从一个 ETL 开发人员角度出发，一个合并过程会引入额外工作量。因此有个问题一定会被问到，那就是既然 HBase 系统已经提供了更新功能，那这类合并工作就不是必须的。那为什么不直接都用 HBase 呢？原因是扫描查询的处理性能，假设要在基于尾部追加模式的 HDFS 文件系统提供随机更新的功能，HBase 就得在它读取每一行时都做少量的合并操作，这个架构决定了能提供较高的写和随机读性能，但与 HDFS 相比，仅仅能提供较差的扫描查询和顺序读操作性能。

这样一来 HBase 就仅仅能用于存储那些须要频繁更新的小表场合。

这个领域包括几个子文件夹：

• Apache Hive
• Dremel clones
• Spark SQL

Apache Hive

       本项目最初由脸谱公司创建。Hive 是第一个基于 Hadoop 之上的 SQL 引擎。且至今仍是最成熟的。

Hive 原先是构建在MapReduce之上的，也以前被改造过以便执行在 Apache Tez 上，如今正在进行的是为适应 Apache Spark 而进行的改造，基于 Spark 的Hive 改造被称为是最后的工作。但不能与 Spark 项目上的其它 SQL 支持项目相互混淆。关于 Spark 上的其它 SQL 支持项目我会再找个合适时机进行讨论。

      到眼下为止。Hive 拥有最完整的 SQL 功能支持，而且也是拥有最多贡献者的项目，差点儿全部的 Hadoop 用户都会部署Hive，同一时候差点儿 Hadoop 上其它 SQL 引擎使用者也都会部署 Hive ，其实大多数 SQL 引擎都以这样的或那种方式依赖于Hive 。

     大多数 Hadoop 赞助商，包含 Cloudera 和 Hortonworks，都一致认同 Hive 是唯一有能力处理大批量任务和集成多种非标准数据格式的组件。

Hortonworks 与 Cloudera 意见相左的地方在于对 Hive 的性能评价。Clourdera 认为 Hive 的性能简直不能与 Dremel clones 相比。而 Hortonworks 则认为 Hive 能够和 Dremel Clones 一较高下。

Dremel Clones

      就像开源界一样，谷歌内部也创立了多个 SQL 引擎。他们有一个类似于 Hive 的 SQL 引擎叫 Tenzing，还有另外一个系统叫 Dremel。

Hive 的创立者 Facebook 公司也创建了一个 Dremel 的克隆版本号叫 Presto。

      Cloudera Impala 和 Apache Drill 是最杰出的两个 Dremel 克隆版本号，Cloudera 将 Impala 市场定位为最成熟的开源 Dremel 分支，Impala 在2013年年中公布 GA 版本号，MapR 是 Drill 背后的主要赞助商，他把 Drill 的市场角色定位为最灵活的 Dremel 分支。 Impala 能满足在 Hive 系统中存储元数据表的需求。而 Drill 能够直接查询 JSON 和自己定义格式文件，比方 Apache Parquet 和 Avro 文件格式等。

Spark SQL

      虽然有 Hadoop 上有其它多个 SQL 引擎。但 Spark SQL 却有着对其感兴趣的最广泛受众。Spark SQL 是 Spark 引擎上的榜眼。而状元是 Shark。 Shark 由于顾及 Spark SQL 和 Hive on Spark 项目。Shark 眼下已经终止开发，与 Shark 项目曾近是加州伯克利大学的一个研究项目不同，Spark SQL 和 Hive on Spark 已经在 Spark 赞助商们的支持下建立了各自的开源项目；

      基于 Spark 的 Hive 能够简单地说成是前端是 Hive 后端是 Spark ，基于 MR 或 Tez 的 Hive 既实用户能够在原系统与 Hive on Spark 系统之间轻松切换。切换工作只只须要简单地改动下配置參数。

      Spark SQL 是一个完整的新引擎，今天的 Spark SQL 对那些希望把 SQL 嵌入到他们的 Scala，Java 或者 Python 程序的Spark 开发人员而言是最实用的，但 Spark SQL 的主要赞助商 Databricks 对 Spark SQL 还有着更大的雄心。并指望将 Spark SQL 的使用范围扩展到非 Spark 开发人员中去；