168大数据

标题: 大数据平台中kudu的地位和价值 [打印本页]

作者: 168主编 时间: 2020-12-28 14:49
标题: 大数据平台中kudu的地位和价值
kudu是什么

kudu和Hbase类似也是一个分布式数据库，据官方给它的定位是提供”fast analytics on fast data”（在更新更及时的数据上做更快的分析）。

据说Cloudera曾经想直接通过修改HBase来支持kudu现在的功能，但是Kudu的数据模型和磁盘存储都与Hbase不同，改造会非常大，所以Cloudera决定干脆开发一个全新的存储系统。

kudu 为什么重要

随着现在大数据平台的不断创新和发展，无论是在企业内部还是开源网站上，新的组件产品的发布都让人应接不暇，大家对此都已经疲惫。但是，在2017年左右，当kudu在各大公司的业务线大规模应用之后，我们重新认识了kudu的独特性和重要性。

原因可以归结为三点：

1.大数据仍然是一项很难的技术。由于对数据的需求以及用户规模的持续增长，hadoop和大数据系统相对来说还是很难用的，越来越复杂化，而其大部分的复杂性来源于存储系统的局限性，而kudu的局限性就小很多。
2.新的应用场景需要kudu。 hadoop的应用场景正在发生变化，其中的一个变化是越来越多的应用集中在机器生成的数据和实时分析领域。而kudu的产生极大的简化了现有的实时分析架构方案。
3.硬件环境正在发生变化。在hadoop诞生初期到现在，很多的硬件都发生了变化，因此我们现在有机会为新的硬件环境创建新的存储系统。

新的应用场景

hadoop的应用场景正在迅速扩展，其本质上是由于以下几个因素合力驱动的：

大数据的的宏观趋势。
物联和信息网的迅速兴起，使得现有的大数据平台需要具备实时分析和快速存储能力。并且于此相关的应用越来越复杂，设计难度在逐步增大。
大数据平台的用户群发生了变化。
在之前，最早的大数据使用人群是软件工程师，随着hive到impala，再到其他各种SQL-on-Hadoop引擎的诞生和发展，没有编程背景的数据分析师和SQL工程师也开始使用Hadoop集群来分析和处理他们的大规模数据。而到目前来看，随着机器学习、深度学习以及数据科学的兴起，大数据平台正在为统计学家、数学家以及更广泛的数据分析人员提供服务。
数据终端用户的期望值提高了
5年以前，他们要求数据平台能做批量处理就行了，毕竟更早之前无法处理大规模的数据量。但是今天来看，能够可扩展的存储和处理数据只能算是最起码的结果，用户更期望能够得到实时结果，而且平台在各种负载场景下都是高性能的。

下面看一下，其中的一些应用场景和他们对存储系统的要求。

物联网

到2022年，全世界预计将会有300亿台联网设备，这些设备拥有你能想到的各种形状和形式，比如联网的汽车，联网的智能家居，智慧医疗等等。数十亿台的联网设备带来了明显的可扩展性问题，也使得hadoop成为了一个好的选择，但是具体的架构方案却不像我i们想的那样清晰明了。

假设目前我们有一台联网的医疗设备，我们想分析来自该设备的数据。先从一组简单的需求开始，我们希望事件数据从联网设备流入存储层------不管这些数据是什么，然后再以一些方式去查询这些数据。
首先我们希望看到设备现在的情况，比如在更新设备的软件之后，我们希望查看设备最近发出的信号，以了解软件更新是否达到预期或者遇到了什么样的问题。
另一种访问设备的方式是分析，我们的数据分析师要研究数据的趋势，以便了解设备性能或者电池使用的情况。

为了实现这些基本的访问模式，存储层需要具备以下能力：

逐行插入
当应用服务器或者网关设备接受一个事件时，需要将这个事件保存在存储系统中，使其立即可读。
低延迟随机读
对设备进行更新之后，需要分析一部分设备在一段时间内的性能，这意味着需要高效的访问一小块范围内的行。
快速分析和扫描
为了满足报表及时查询分析的请求，需要能够高效的扫描存储系统中的大规模数据。

现有的实时分析方案

先看下，在没有kudu的时候，如何成功实现实时数据流分析。

在这个例子中，我们有一个产生连续事件流的数据源，我们需要近乎实时的存储这些事件，因为用户要求这些事件时马上可用的------这些数据的价值在其被创建时是最大的。
这个架构包含了一个数据生产者，生产者从源获取到事件，然后将他们保存在某个特定的存储层，以便业务用户可以通过SQL来分析，而数据科学家和开发者则可以使用Spark来分析数据。

如何为上述应用选择一个合适的存储引擎，是一个需要思考的问题，目前来看可用的方式有以下三个：

HDFS

将数据以Avro文件的格式保存在HDFS中，Avro是基于行的数据存储格式，基于行的格式非常适用于流式系统，因为在写parquet和ORC这样的列存储格式的数据时，需要在内存中缓存大量的行。所以我们需要创建一个hive表，按照日期进行分区，然后生产者持续的将小批次的数据以Avro格式写入到HDFS中。因为用户希望数据被创建之后马上能访问，所以生产者需要频繁的向HDFS写入新文件。这样带来的问题是，HDFS 目录会有成千上万的小文件，结果就是每读一个小文件都需要HDFS做一次磁盘寻址操作，这会严重影响Spark作业和Impala查询性能。

HDFS+HBase

这是大家更为熟悉的一种底层存储方案，结合两个存储引擎各自的优势来组合使用他们。这种架构中有一个 “实时层”，和 “批处理层”。**实时层接收流数据，能够查找最近的数据，可更改，并且最关键的是能够低延迟的读写数据。**对于需要实时数据的用户，实时层可以提供这些数据，在传统的Hadoop生态中，实时层一般使用HBase或者Cassandra来实现，他们都属于“big table”家族。他们的缺点是不能提供HDFS和Parquet的快速分析和扫描性能。

其基本流程如下：
数据不断的流入基于HBase的实时层，当积累了足够多的数据时，会有一个flush的过程，将数据从实时层移到批处理层。“flush”的过程负责从实时层读取数据，将其重写为Parquet，往HDFS添加一个分区，然后通知Hive和Imapala出现了新的分区。架构大致如下：

这种框架的优点是：支持秒级实时数据，支持修改数据和快速扫描。
缺点是：开发和运维十分复杂。并且实时数据和历史数据分散在两个存储系统中，用户很难得到一个统一的视图。

那为什么HBase不适合做分析呢？

HDFS和HBase是大数据最常用的两种存储方式，它们的优缺点非常明显：

HDFS，使用列式存储格式Apache Parquet，Apache ORC，适合离线分析，不支持单条记录级别的update操作，随机读写性能差。这个就不多说了，用过HDFS的同学应该都知道这个特点。

HBase，可以进行高效随机读写，却并不适用于基于SQL的数据分析方向，大批量数据获取时的性能较差。
那为什么HBase不适合做分析呢？

因为分析需要批量获取数据，而HBase本身的设计并不适合批量获取数据

1）都说HBase是列式数据库，其实从底层存储的角度来说它并不是列式的，获取指定列数据时是会读到其他列数据的。看过我之前文章的同学应该比较清楚就不多说了。相对而言Parquet格式针对分析场景就做了很多优化。

2）HBase是LSM-Tree架构的数据库，这导致了HBase读取数据路径比较长，从内存到磁盘，可能还需要读多个HFile文件做版本合并。

LSM 的中心思想就是将随机写转换为顺序写来大幅提高写入操作的性能，但是牺牲了部分读的性能。

随机读写是指对任意一个位置的读和写，磁盘随机读写慢是因为需要寻道，倒带才可以访问到指定存储点，而内存不需要，可以任意指定存储点。

为了让数据平台同时具备随机读写和批量分析能力，传统的做法是采用混合架构(hybrid architecture)，也就是我们常说的T+1的方式，数据实时更新在HBase，第二天凌晨同步到HDFS做离线分析。这样的缺点很明显，时效性差，数据链路长，过程复杂，开发成本高。

实时处理

从目前来看，Hadoop生态的一个趋势是，可扩展的实时流式处理系统正在快速发展。流式处理背后的思想是：在数据流中直接处理数据，而不是将数据保存到存储系统，然后再批量处理。再批处理中，每个批次有明确的开始和结束点，而在流式处理中，数据处理模块是长期运行的，它持续的对流入的小批量数据进行处理。流式处理通常用来观察数据，并且对于如何转换、聚合、筛选数据或者根据数据报警等问题，会立即做出决策。

在实时处理领域里，数据在刚产生时的价值最高，随着时间的推移，其价值会逐步降低。限制实时处理技术落地的一个主要因素是其对存储系统的挑战性需求。

流式处理通常需要外部上下文，这个上下文可能有很多不同的形式，有些时候你会需要历史上下文，因为你想知道现在的数据和历史数据相比较是怎样的，另外一些情况下可能需要引用其他数据，例如欺诈检测十分依仗历史数据和参考数据。历史数据就是过去一段时间的交易数据，参考数据时客户的账号信息和IP地址等等。

目前来看，生态圈的很多组件都提供了实时读取和处理时间的能力，比如Flume、Storm、Spark Streaming等，但是他们还是要依赖于外部系统来存储和访问外部上下文。
例如使用Spark Streaming 可以每隔几秒从Kafka读取微批量事件，但是如果我们希望能够保存结果、读取外部上下文、计算风险评分和更新患者档案，存储系统就需要满足以下需求：

逐行插入
当事件产生时，需要立即存储，并且可供其他工具和流程做分析。
低延迟随机读
当流式引擎处理一个事件时，他可能需要查找与该事件相关的参考数据。比如，如果该事件代表的是医疗设备产生的数据，很有可能就需要查找与病人相关的上下文信息，比如病人所就诊的诊所的名称，或者与病情相关的特定信息。
快速分析和扫描
这个事件和历史数据有怎样的联系？对数据做快速分析和扫描或者SQL查询，得到历史的上下文信息，这种能力对应用来说十分重要。
更新
上下文信息是会发生变化的，例如，来自OLTP（在线事务处理）应用的上下文可能会添加像联系人信息之类的参考数据，而病人的风险评分可能在新的信息被计算出来后发生变化。

其架构大致如下：

分开来看的话，Hbase+HDFS可以完成上述四个功能，现有的单个存储等都难以完全满足上述四个特性。

kudu在大数据生态中的独特位置

和Hadoop中的其他组件一样，Kudu也被设计成可扩展和可容错的。kudu仅仅是一个存储层，因此它并不处理数据，而是依赖于外部的处理引擎比如Imapala、Spark等来处理。kudu把数据按照自己的列存储格式存储在底层的Linux文件系统，不像HBase那样，Kudu不以任何方式使用HDFS。

尽管kudu本身不是SQL引擎，但是它的数据模型与数据库相似，表是由固定数量的拥有类型的列组成的，这些列的子集将构成主键，像在RDBMS中一样，主键保证了行的唯一性。
kudu在磁盘上使用列式存储格式，这样能保证对一部分列进行高效的编码和快速的扫描。
为了实现可扩展性和容错，Kudu的表被水平分隔成很多块，称为tablet，其写操作使用Raft一致性算法在tablet之间复制数据。

Kudu的目标是成为一种各方面条件都适中的选择，既拥有强大而广泛的功能，又对多种负载有较好的性能。具体而言就是，kudu将低延迟随机访问、逐行插入、更新和快速分析扫描融合到一个存储层中。之前的存储层比如HDFS和Hbase等只具备其中一项或者几项能力，没有一个拥有全部能力

如上图所示，HDFS是一个仅支持追加写的文件系统，对于需要顺序扫描大规模数据的处理引擎而言，它表现最好。Hbase非常适用于那种在线、实时、高并发，而且其中大多数操作都是随机读/写或者短扫描的环境。

Kudu的目标是，在扫描性能达到HDFS上的Parquet或者ORCFile格式的两倍；同时，像HBase一样，拥有快速随机读/写的能力，在SSD存储上的读写延迟只有1ms。

与其他生态系统的组件相比

在过去10年中，已经有数百个数据库系统被创造出来，那为什么还需要重新做一个存储系统呢？

kudu与SQL引擎对比

最简单的是与SQL引擎对比，比如Hive、Impala和Spark SQL。kudu并不会完全执行SQL查询，SQL查询的一部分操作可以下推到存储层，比如投影操作和谓词操作，这些确实是在kudu中执行的。然而，SQL引擎需要有解释器、优化器和执行查询的方法，==kudu仅在执行查询的过程中起作用并向优化器提供一些信息。==此外，SQL引擎必须把投影操作和谓词操作下推到Kudu，或者在此过程中与Kudu通信，所以Kudu参与了查询的执行过程，它不仅仅是一个简单的存储引擎。

kudu与传统数据库对比

广义的来说，现在有两种类型的关系型数据库，OLTP(联机事务处理)和OLAP(联机分析处理)。

OLTP数据库用于网站、销售网点系统，以及对响应速度和数据完整性要求很高的其他在线服务应用。但是传统的OLTP数据库的大规模扫描的性能并不好，但是这种操作在分析类应用中是很常见的。OLAP数据库能很快的执行这些类型的查询，因为他们针对扫描做了优化。

通常，OLAP数据库在OLTP数据库适应的场景中表现的很差，比如只选择少量行的操作或者针对数据完整性有要求的场景。任何数据库都会牺牲一定的数据完整性，但是OLAP数据库通常是批量加载数据的，如果出现任何错误，OLAP数据库可以重新加载整个批次的数据，而不会丢失数据。

OLTP数据库使用行格式，OLAP数据库使用列格式。行格式非常适用于全行检索和更新操作，列格式非常适用于扫描所有列中的某几列的场景，典型的OLTP查询是获取到完整的行，典型的OLAP查询是获取到行的一部分。

kudu经常被认为是支持Hive、Impala和Spark SQL等OLAP查询引擎的列存储引擎，然而由于kudu支持根据主键快速检索，并且能够在对表分析查询扫描时连续不断的插入数据，所以它同时具备OLTP和OLAP系统的一些属性，因此可以将Kudu归为第三类存储引擎。

在OLAP和OLTP领域中有很多关系型数据库，kudu与关系型数据库之间有很多共同点。例如，kudu表有一个唯一的主键，HBase却不是这样，但是关系型数据库中常见的特性，比如事务、外键、和非主键的索引等，在kudu中是不支持的，但是这些特征是可能实现的，只是目前还未实现。

kudu现在拥有一些OLAP和OLTP的特性，但是缺少对跨行的原子性、一致性、隔离性、持久性事务的支持，可以把它归结为混合事务/分析处理（HTAP）类型的数据库。例如，kudu支持快速主键检索，并且能够在数据持续输入的同时进行分析。 OLAP在这种场景下性能不好，并且与OLAP相比，kudu的持久性保证与OLTP更相近。=由于kudu实现了基于法定人数（quorum-based）的存储系统，所以它有更强的持久性保证。kudu的quorum能力可以实现一种名为Fractured Mirros的机制：一个或者两个节点使用行存储，另外的节点使用列存储。这样就可以在行存储的节点上执行OLTP操作，在列存储的节点上执行OLAP操作，混合两种负载。

与大数据其他组件对比HDFS、HBase

HDFS ：全表扫描非常出色、不支持随机读写
HBase：擅长随机访问，随机读取或者修改数据。
kudu：扫描性能做到HDFS上parquet格式的两倍以内，随机读的性能接近HBase。

逐一解释，上述组件出现如此特性的原因。

HDFS是一个纯粹的分布式文件系统，其就是设计来执行快速的大规模的扫描的，毕竟这种设计的原始应用场景就是批量构建web索引。HDFS对数据进行分区，并将其分散到大量的物理盘上，以便这些大扫描可以并行利用多个磁盘。
Hbase和kudu比较相近，都提供了随机访问数据的能力，但是在磁盘存储时有所不同，Hbase将数据存储在列族中，而不是采用真正的列式存储，最终的结果是双重的：首先同一类的数据不能再一起编码，难以得到极限的压缩，其次，在扫描列族中的一个列时，必然会物理读取列族中的其他列。
kudu在做大规模扫描时性能高的另一个原因是，它不需要再扫描时进行合并操作。kudu不保证扫描返回的数据是按准确的主键顺序排列的（大多数分析性应用都可以接受这点），因此不需要在不同的RowSet（若干行组成的块）之间执行“合并”操作。

在Hbase中执行“合并”操作，有两个理由：
1.需要保证返回结果的顺序
2.允许字段（cell）拥有版本，新版本字段或者字段的删除都可以覆盖早起的版本。

kudu并不需要上述两个理由，因为kudu不需要保证顺序，kudu也不保存每个字段的不同版本，而是保存base data，然后将这个基线时间点向前和向后的增量数据分开，以多个块的形式存放，如果你有若干次的更新操作，基线时间点之后的增量数据会被压缩合并成REDO日志，而只有基线时间点之前的UNDO日志会被保存。对于当前时间点的查询，我们可以忽略所有基线时间点之前的增量，这样就只需要读取基线数据。

读取基线数据的效率非常高，因为他们是以高密度的列形式存储的。kudu表有schema，这以为着不需要为每一个字段都保存列的名字或者值得长度，而且将增量保存在其他地方，意味着不需要读取时间戳，这使得Kudu的扫描几乎和Parquet一样高效。
kudu比Hbase高效的另一个原因是，kudu避免了很多字段的比较操作，这样就避免了很多CPU分支预测失败。从这个角度来说，Kudu的CPU利用率更高。

原文：https://blog.csdn.net/u012736748/article/details/108167478

欢迎光临 168大数据 (http://www.bi168.cn/)