关于hive:CloudCanal-x-Hive-构建高效的实时数仓

111次阅读

共计 1836 个字符,预计需要花费 5 分钟才能阅读完成。

简述

CloudCanal 最近对于全周期数据流动进行了初步摸索,买通了
Hive 指标端的实时同步,为实时数仓的构建提供了反对,这篇文章简要做下分享。

  • 基于长期表的增量合并形式
  • 基于 HDFS 文件写入形式
  • 长期表对立 Schema
  • 工作级的长期表

基于长期表的增量合并形式

Hive 指标端写入形式和 Doris
类似,须要在指标表上额定增加一个 __op(0:UPSERT,1:DELETE)字段作为标记位,理论写入时会先将源端的变更先写入长期表,最终合并到理论表中。

CloudCanal 的设计外围在于,每个同步表对应两张长期表,通过交替合并的形式,确保在一张长期表进行合并时,另一张可能接管新变更,从而晋升同步效率和并发性。

Hive 提供了两种合并形式:INSERT OVERWRITE(所有版本均反对),MERGE INTO(Hive 2.2.0 之后反对且须要是 ACID 表)

-- INSERT OVERWRITE 语法
INSERT OVERWRITE [LOCAL] DIRECTORY directory1
  [ROW FORMAT row_format] [STORED AS file_format]
SELECT ... FROM ...

-- MERGE INTO 语法
MERGE INTO <target table > AS T USING < source expression / table > AS S
ON <boolean expression1>
    WHEN MATCHED [AND <boolean expression2>] THEN
UPDATE SET <set clause list>
    WHEN MATCHED [AND <boolean expression3>] THEN
DELETE
    WHEN NOT MATCHED [AND <boolean expression4>] THEN INSERT VALUES<value list>

工作级的长期表

在大数据场景下,多表汇聚的状况非常广泛,CloudCanal 在构建长期表时,利用源端的订阅 Schema Table 信息,创立不同的长期表。

通过这种形式,无论是雷同或不同的工作、雷同或不同的 Schema(源端)、雷同或不同的 Table(源端),都能将数据写入不同的长期表,最终合并到同一个理论表中,相互之间不会产生影响。

基于 HDFS 文件的写入形式

Hive 是建设在 Hadoop 体系上的数据仓库,而理论的数据存储在 HDFS 中。

如果间接通过 HQL 将增量数据写入 Hive,Hive 会将 HQL 转化为 MR Job,因为每一个 MR Job 处理速度绝对较慢,这将导致增量性能极其差。

CloudCanal 在进行数据写入的时候,抉择的是绕过 Hive 这层,间接写入 HDFS 文件系统。

目前反对 HDFS 文件格式:Text、Orc、Parquet。

长期表对立 Schema

基于长期表构建的增量形式,如果长期表扩散在不同的 Schema 中,将给 DBA 的治理带来不便。

为了简化治理,CloudCanal 将所有长期表构建在对立的 Schema 下,并容许用户自定义其长期表门路。

示例

筹备 CloudCanal

  • 下载安装 CloudCanal 公有部署版本

增加数据源

  • 数据源治理 -> 增加数据源,增加 MySQL、Hive

创立同步工作

  • 抉择源端 MySQL 和指标端 Hive,同步的 SchemaTable,高级参数含意参考 MySQL -> Hive

  • 工作创立第四步,点击 配置分区键
  • 抉择 分区键类型 以及 HDFS 文件类型

  • 点击下一步,创立工作即可

    将来方向

文件 Append 写入形式

目前 HDFS 文件写入解决,是每批数据写到一个文件中,并不会解决历史数据文件,更加正当的形式是基于历史文件进行 Append
追加,写满之后再切换为下一个文件。

提供参数优化 MR 处理速度

目前 CloudCanal 并没有提供参数入口用于优化 MR 处理速度,而是主动应用用户所配置的,将来 CloudCanal 将提供一个参数入口用于用户自定义每一个
MR Job 的解决并行度等优化参数。

反对 MERGE INTO 合并形式

目前 CloudCanal 仅反对 INSERT OVERWRITE 的合并形式,这种形式更为通用,而 MERGE INTO 此种合并形式速度更快,但限度较多,将来
CloudCanal 也会反对此种合并形式。

反对自定义分区键

目前 CloudCanal 仅反对依照日期抉择分区键,目前临时不反对更多分区键的抉择,将来 CloudCanal 会提供更多分区键的抉择。

总结

本篇文章简略介绍 CloudCanal 对于全生命周期的数据流动的初步摸索,并通过 MySQL -> Hive 示例介绍其应用。

正文完
 0