华为云用户手册

  • 建议 一次只插入一个分区内的数据 如果数据属于不同的分区,则每次插入,不同分区的数据会独立生成part文件,导致part总数量膨胀,建议一批插入的数据属于同一个分区。 写入速率 单节点写入速度为50~200MB/S,如果写入的数据每行为1Kb,那么写入的速度为50,000到200,000行每秒,如果行数据容量更小,那么写入速度将更高,如果写入性能不够,可以使用多个副本同时写入,同一时间每个副本写入的数据保持均衡。 慎用分布式表批量插入 写分布式表,数据会分发到集群的所有本地表,每个本地表插入的数据量是总插入量的1/N,batch size可能比较小,导致data part过多,merge压力变大,甚至出现异常影响数据插入; 数据的一致性问题:数据先在分布式表写入节点的主机落盘,然后数据被异步地发送到本地表所在主机进行存储,中间没有一致性的校验,如果分布式表写入数据的主机出现宕机,会存在数据丢失风险; 对于数据写分布式表和数据写本地表相比,分布式表数据写入性能也会变慢,单批次分布式表写,写入节点的磁盘和网络IO会成为性能瓶颈点。 分布式表转发给各个shard成功与否,插入数据的客户端无法感知,转发失败的数据会不断重试转发,消耗CPU。 大批量数据导入要分时、分节点、扩容 如果数据盘为SATA盘,当大批量数据集中插入时候,会抢占磁盘,使得磁盘长时间处于繁忙状态,影响其他alter类操作的效率。 尽量避免批量导数据的SQL并发执行,会给磁盘和ClickHouse并发能力带来冲击。 Kafka数据入库 不建议建ClickHouse kafka表引擎,进行数据同步到ClickHouse中,当前CK的kafka引擎有会导致kafka引擎数据入库产生性能等诸多问题,通过用户使用经验,需要应用侧自己写kafka的数据消费,攒批写入ClickHouse,提升ClickHouse的入库性能。 使用分区替换或增加的方式写入数据 为避免目标表写入脏数据导致的删改,先将数据写入临时表,再从临时表写入目标表。 操作步骤如下: 创建一张与目标表table_dest结构、分区键、排序键、主键、存储策略、引擎都一致的临时表table_source。 先把数据写到临时表,一次只写入一个分区的数据,检查临时表的数据准确无误。 使用以下SQL查看目标表的分区: SELECT partition AS `partition`,sum(rows) AS `count` FROM system.parts WHERE active AND database=='数据库名' AND table=='表名' GROUP BY partition ORDER BY partition ASC; 如果目标表存在该分区,将分区替换到目标表,语法如下: ALTER TABLE table_dest [ON CLUSTER cluster] REPLACE PARTITION partition_expr FROM table_source; 如果目标表不存在该分区,将分区增加到目标表,语法如下: ALTER TABLE table_dest [ON CLUSTER cluster] REPLACE PARTITION tuple() partition_expr FROM table_source;
  • 内容介绍 本文主要描述ClickHouse数据管理全生命周期过程中,数据库规划、建模设计、开发、调优、运维的规则建议和指导。 通过这些约束和建议,指导开发者在ClickHouse数据库开发使用过程中能够最大化发挥数据库的优势,保障ClickHouse数据库高性能、稳定可靠运行。用户可更专注于上层业务,释放数据更大的价值。 本文档主要包含以下内容: 项目 描述 数据库规划 集群业务规划、容量规划、数据分布。 数据库设计 Database设计、宽表设计、分布式表设计、本地表设计、分区设计、索引设计、物化视图设计。 数据库开发 简单查询、聚合查询、join查询、数据增/删/改等SQL开发。 数据库调优 调优思路、参数调优、系统调优、SQL改写调优。 数据库运维 监控、告警、日志、系统表/视图。
  • 日志详细信息 日志类型 日志文件名 描述 ClickHouse相关日志 /var/log/Bigdata/clickhouse/clickhouseServer/clickhouse-server.err.log ClickHouseServer服务运行错误日志文件路径。 /var/log/Bigdata/clickhouse/clickhouseServer/checkService.log ClickHouseServer服务运行关键日志文件路径。 /var/log/Bigdata/clickhouse/clickhouseServer/clickhouse-server.log /var/log/Bigdata/clickhouse/clickhouseServer/ugsync.log 用户角色同步工具打印日志。 /var/log/Bigdata/clickhouse/clickhouseServer/prestart.log ClickHouse预启动日志。 /var/log/Bigdata/clickhouse/clickhouseServer/start.log ClickHouse启动日志。 /var/log/Bigdata/clickhouse/clickhouseServer/checkServiceHealthCheck.log ClickHouse健康检查日志。 /var/log/Bigdata/clickhouse/clickhouseServer/checkugsync.log 用户角色同步检查日志。 /var/log/Bigdata/clickhouse/clickhouseServer/checkDisk.log ClickHouse磁盘检测日志文件路径。 /var/log/Bigdata/clickhouse/clickhouseServer/backup.log ClickHouse在Manager上执行备份恢复操作的日志文件路径。 /var/log/Bigdata/clickhouse/clickhouseServer/stop.log ClickHouse停止日志。 /var/log/Bigdata/clickhouse/clickhouseServer/postinstall.log ClickHouse的postinstall.sh脚本调用日志。 /var/log/Bigdata/clickhouse/balance/start.log ClickHouseBalancer服务启动日志文件路径。 /var/log/Bigdata/clickhouse/balance/error.log ClickHouseBalancer服务运行错误日志文件路径。 /var/log/Bigdata/clickhouse/balance/access_http.log ClickHouseBalancer服务运行http日志文件路径。 /var/log/Bigdata/clickhouse/balance/access_tcp.log ClickHouseBalancer服务运行tcp日志文件路径。 /var/log/Bigdata/clickhouse/balance/checkService.log ClickHouseBalancer服务检查日志。 /var/log/Bigdata/clickhouse/balance/postinstall.log ClickHouseBalacer的postinstall.sh脚本调用日志。 /var/log/Bigdata/clickhouse/balance/prestart.log ClickHouseBalancer服务预启动日志文件路径。 /var/log/Bigdata/clickhouse/balance/stop.log ClickHouseBalancer服务关闭日志文件路径。 /var/log/Bigdata/clickhouse/clickhouseServer/auth.log ClickHouse服务认证日志。 /var/log/Bigdata/clickhouse/clickhouseServer/cleanService.log 重装实例异常产生的记录日志。 /var/log/Bigdata/clickhouse/clickhouseServer/offline_shard_table_manager.log ClickHouse入服/退服日志。 /var/log/Bigdata/clickhouse/clickhouseServer/traffic_control.log ClickHouse主备容灾流量控制日志。 /var/log/Bigdata/clickhouse/clickhouseServer/clickhouse_migrate_metadata.log ClickHouse元数据搬迁日志。 /var/log/Bigdata/clickhouse/clickhouseServer/clickhouse_migrate_data.log ClickHouse业务数据搬迁日志。 /var/log/Bigdata/clickhouse/clickhouseServer/changePassword.log ClickHouse修改用户密码日志。 数据迁移日志 /var/log/Bigdata/clickhouse/migration/数据迁移任务名/clickhouse-copier_{timestamp}_{processId}/copier.log 参考使用ClickHouse数据迁移工具,使用迁移工具时产生的运行日志。 /var/log/Bigdata/clickhouse/migration/数据迁移任务名/clickhouse-copier_{timestamp}_{processId}/copier.err.log 参考使用ClickHouse数据迁移工具,使用迁移工具时产生的错误日志。 /var/log/Bigdata/tomcat/clickhouse/auto_balance/数据迁移任务名/balance_manager.log 参考使用ClickHouse数据迁移工具,勾选一键均衡产生的运行日志。 clickhouse-tomcat日志 /var/log/Bigdata/tomcat/clickhouse/web_clickhouse.log ClickHouse自定义UI运行日志。 /var/log/Bigdata/tomcat/audit/clickhouse/clickhouse_web_audit.log clickhouse的数据迁移审计日志。 ClickHouse审计日志 /var/log/Bigdata/audit/clickhouse/clickhouse-server-audit.log ClickHouse的审计日志文件路径。 父主题: 数据库运维
  • 日志路径 ClickHouse相关日志的默认存储路径为:“${BIGDATA_ LOG _HOME}/clickhouse”。 ClickHouseServer运行相关日志:“/var/log/Bigdata/clickhouse/clickhouseServer/ *.log”。 ClickHouseBalancer运行日志:“/var/log/Bigdata/clickhouse/balance/*.log”。 ClickHouseServer审计日志:“/var/log/Bigdata/audit/clickhouse/clickhouse-server-audit.log”。 ClickHouse数据迁移日志:“/var/log/Bigdata/clickhouse/migration/${task_name}/clickhouse-copier_{timestamp}_{processId}/copier.log”。
  • 数据修改 建议慎用delete、update的mutation操作 标准SQL的更新、删除操作是同步的,即客户端要等服务端反回执行结果(通常是int值);而ClickHouse的update、delete是通过异步方式实现的,当执行update语句时,服务端立即返回执行成功还是失败结果,但是实际上此时数据还没有修改完成,而是在后台排队等着进行真正的修改,可能会出现操作覆盖的情况,也无法保证操作的原子性。 业务场景要求有update、delete等操作,建议使用ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree引擎,使用方式参见:https://clickhouse.tech/docs/zh/engines/table-engines/mergetree-family/collapsingmergetree/。 建议少或不增删数据列 业务提前规划列个数,如果将来有更多列要使用,可以规划预留多列,避免在生产系统跑业务过程中进行大量的alter table modify列操作,导致不可以预知的性能、数据一致性问题。 对于批量数据清理,建议根据分区来操作: ALTER TABLE table_name DROP PARTITION partition_name; 禁止修改索引列 对索引列的修改会导致现有索引失效,触发重建索引,期间查询数据不准确。 如果业务场景必须修改索引列,推荐用ReplacingMergeTree引擎建表,使用数据写入+去重引擎代替数据更新场景:https://clickhouse.tech/docs/zh/engines/table-engines/mergetree-family/collapsingmergetree/。
  • 数据查询建议 建议查询指定分区 通过指定分区字段会减少底层数据库扫描的文件数量,提升查询性能,实际经验:700个分区的千列大表,需要查询一个分区中有7000万数据,其他699个分区中无数据,虽然只有一个分区有数据,其他分区无数据,但是查询指定分区为百毫秒级性能,没有指定分区查询性能为1~2秒左右,性能相差20倍。 慎用final查询 在查询语句的最后跟上final,通常是对于ReplacingMergeTree引擎,数据不能完全去重情况下,有些开发人员习惯写final关键字进行实时合并去重操作(merge-on-read),保证查询数据无重复数据。可以通过argMax函数或其他方式规避此问题。
  • HBase组件端口 表5 HBase组件端口 配置参数 默认端口(HBase1.x和HBase 2.x版本) 端口说明 hbase.master.port 16000 HMaster RPC端口。该端口用于HBase客户端连接到HMaster。 hbase.regionserver.port 16020 RS (RegoinServer) RPC端口。该端口用于HBase客户端连接到RegionServer。
  • 数据分布设计 Shard数据分片均匀分布 建议用户的数据均匀分布到集群中的多个shard分片,如图1所示有3个分片。 假如有30 GB数据需要写入到集群中,需要将30 GB数据均匀切分后分别放到shard-1、shard-2和shard-3的3个分片节点中,以充分发挥MPP查询时并行计算能力,避免数据在shard间倾斜计算出现木桶效应,导致SQL查询性能较差。 可通过弹性负载均衡(Elastic Load Balance,简称ELB)访问ClickHouse,来实现数据均匀。 Shard内数据副本高可靠存储 数据写入单shard中的一个副本后,ClickHouse会自动异步将数据同步到其他副本,如图1中的shard-3。 如果将10GB数据导入ClickHouse Node 5节点副本,ClickHouse会自动异步将数据同步到ClickHouse Node 6节点副本,保证shard-3分片数据的高可靠性存储。
  • ClickHouse容量规划设计 为了能够更好的发挥ClickHouse分布式查询能力,在集群规划阶段需要合理设计集群数据分布存储。 当前ClickHouse能力为单机磁盘容量达到80%后会上报告警信息,磁盘容量达90%后集群会处于只读状态。 出现磁盘告警信息后需要考虑是否是容量不足问题,如果是容量不足问题需要尽快考虑集群扩容,提升集群整体容量存储。 ClickHouse节点及容量规划如下: 磁盘规划 由于ClickHouseServer业务数据主要存储在本地磁盘上,数据量可能会随着集群使用时间增长而增长,通常建议ClickHouse数据盘单独挂载,元数据盘共享第一个数据盘目录。 磁盘实际容量 由于磁盘存在1MB = 1024KB或者1000KB的不同算法,一般来说,磁盘实际可用容量 = 磁盘标注容量 * 0.9。 例如磁盘标注容量为1.2 TB,实际容量为1200 * 0.9 = 1080 GB。 计算公式 假设历史数据量为H,每日增量为A,单节点磁盘容量为C,数据保留M天,集群副本数为R,则ClickHouseServer物理节点数计算公式如下: ClickHouseServer物理节点数N = [R * (H + A * M)] / C 父主题: 集群规划
  • 调优思路 ClickHouse的总体性能调优思路为性能瓶颈点分析、关键参数调整以及SQL调优。在调优过程中,需要综合系统资源、吞吐量、集群负载等各种因素来分析,定位性能问题,设定调优目标,调优达到客户所需目标即可。 ClickHouse调优人员需要系统软件架构、软硬件配置、数据库架构原理及配置参数、并发控制、查询处理和数据库应用有广泛而深刻的理解和认识,才能在调优过程中找到关键瓶颈点,解决性能问题。 图1 调优流程 表1 调优流程说明 流程 描述 系统调优 对OS操作系统级参数和数据库的调优,充分地利用主机的CPU、内存、I/O和网络资源,提升整个系统查询的吞吐量,同时数据库参数也调整到最优状态。 SQL调优 审视业务所用SQL语句是否存在可优化空间,包括: 分析数据分布是否有倾斜,对于大表数据是否平均分布在各个shard。 分析建表语句,查看是否有建立分区、一级索引、二级索引、排序键是否指定等。 分析查询SQL是否使用了分区和索引,检查查询过滤条件比较频繁的列是否安排在建表时指定的索引及排序键的靠前位置。 数据库参数调优 通过调优数据参数,提升数据库性能,保障数据库稳定运行。 更多信息可参考ClickHouse社区文档相关调优内容https://clickhouse.com/docs/en/intro。 父主题: 数据库调优
  • 物化视图概述 由于TTL规则不会从原始表中同步到物化视图表,因此源表中带有TTL规则时,物化视图表同样需要配置TTL规则,并且建议与源表保持一致。 表1 普通物化视图与projection对比 物化视图类型 原表数据与物化视图一致性 灵活性 物化视图开发及维护复杂度 普通物化视图 数据从原表同步到物化视图需要时间窗。 灵活性较高,有新的业务可开发新的物化视图。 可开发复杂逻辑SQL语句的物化视图。 复杂度较高,需要开发很多物化视图,每个物化视图都需要单独去管理和维护。 projection 数据实时同步,数据写入即可查询到物化视图最新数据。 创建表时指定的物化视图语法,新的SQL业务需要修改表结构。 不需要开发很多物化视图,任意查询SQL会自动重写命中物化视图。 Projection仅在 MRS 3.2.0及以上的版本集群中支持。 父主题: 物化视图设计
  • 参数调整最佳实践 参数名 参数描述 默认值 建议值 是否需要重启生效 max_memory_usage_for_all_queries 单台服务器上所有查询的内存使用量,默认没有限制。建议根据机器的总内存,预留一部分空间,防止内存不够导致服务或者机器宕机。 0 机器总内存的80% 否 max_memory_usage 单个查询在单台服务器的能使用的最大内存。 10G 50GB 否(新版本可通过多租户方式配置) max_bytes_before_external_group_by 确定了在GROUP BY中启动将临时数据转存到磁盘上的内存阈值。默认值为0表示这项功能将被禁用。一般:设置为max_memory_usage/2。 0 25GB 否 max_execution_time 单次查询耗时的最长时间,单位为秒。默认没有限制。 0 300 否 max_threads 执行请求的最大线程数。默认情况下是按照机器CPU核数自动确定的。单并发情况下线程数越大越好(该值要小于CPU核数),多并发情况建议设置为CPU核数/2的值。 CPU核数/2 64 否 max_result_rows 限制返回结果行数,默认为0不限制。 0 100000 否 distributed_product_mode 默认SQL中的子查询不允许使用分布式表,修改为local表示将子查询中对分布式表的查询转换为对应的本地表。 deny 根据场景定: deny/local/global/allow 否 background_pool_size 后台用于merge的线程池大小。 16 64 否 log_queries system.query_log表的开关。默认值为0,不存在该表。修改为1,系统会自动创建system.query_log表,并记录每次query的日志信息。 0 1 否 skip_unavailable_shards 当通过分布式表查询时,遇到无效的shard是否跳过。默认值为0表示不跳过,抛异常。设置值为1表示跳过无效shard。 0 建议使用默认值。异常时,调整为1,提供有损服务。 否 max_bytes_before_external_sort 如果没有足够的内存,可以使用该参数来设置外部排序(在磁盘中创建一些临时文件)。默认为0表示禁用外部排序功能,当内存不够时直接抛错,设置了该值order by可以正常完成,但是速度非常慢。 0 25GB 否 keep_alive_timeout 服务端与客户端保持长连接的时长,单位为秒。 10 600 否 max_concurrent_queries 最大支持的查询并发。 100 150 否 session_timeout_ms Clickhouse服务和ZooKeeper保持的会话时长,超过该时间ZooKeeper还收不到Clickhouse的心跳信息,会将与Clickhouse的session断开。 3000 120000 否 父主题: 数据库调优
  • projection定义 CREATE TABLE test_projection_table( level String, type String, name String, city String, time DateTime64, PROJECTION projection_1( SELECT level, count() GROUP BY level ), PROJECTION projection_2( SELECT type, count() GROUP BY type ) ) ENGINE = MergeTree() ORDER BY (name, level, type)
  • 通过表属性修改方式创建projection 在创建好projection后还可以对projection进行修改,具体语句如下: ALTER TABLE test_projection_table ADD PROJECTION projection_3( SELECT type, level GROUP BY type, level )
  • Projection的使用 如下SQL查询的时候会走表达式: SELECT type, count() FROM test_projection_table WHERE type = 'A' GROUP BY type; 而如下SQL不会走projection,因为city不在projection的定义中。 SELECT city, count() FROM test_projection_table WHERE type = 'A' GROUP BY city; 具体可以通过explain查看执行计划,如果出现ReadFromStorage (MergeTree(with projection)) ,表示命中projection。
  • 场景介绍 本章节适用于将线下IDC机房或者公有云Hadoop集群中的数据(支持数据量在几十TB级别或以下的数据量级)迁移到华为云MRS服务。 本章节以通过华为云 CDM 服务 2.9.1.200版本进行数据迁移为例介绍。不同版本操作可能有差异,具体操作详情以实际版本对应的操作指导为准。 CDM服务支持迁移的数据源可参考支持的数据源,数据源为Apache HDFS时,建议使用的版本为2.8.X、3.1.X,请执行搬迁前务必确认是否支持搬迁。 图1 Hadoop数据迁移示意
  • 场景介绍 本章节适用于将线下IDC机房或者公有云HBase集群中的数据(支持数据量在几十TB级别或以下的数据量级)迁移到华为云MRS服务。 本章节以通过华为云CDM服务 2.9.1.200版本进行数据迁移为例介绍。不同版本操作可能有差异,具体操作详情以实际版本对应的操作指导为准。 图1 HBase数据迁移示意 HBase会把数据存储在HDFS上,主要包括HFile文件和WAL文件,由配置项“hbase.rootdir”指定在HDFS上的路径,华为云MRS集群的默认存储位置是“/hbase”文件夹下。 HBase自带的一些机制和工具命令也可以实现数据搬迁,例如通过导出Snapshots快照、Export/Import、CopyTable方式等,可以参考Apache官网相关内容。 CDM服务支持迁移的数据源可参考支持的数据源,数据源为Apache HBase时,建议使用的版本为2.1.X、1.3.X,请执行搬迁前务必确认是否支持搬迁。
  • 增量数据迁移 在业务割接前,如果源端集群上有新增数据,需要定期将新增数据搬迁到目的端集群。一般每天更新的数据量在GB级别可以使用CDM的“整库迁移”指定时间段的方式进行HBase新增数据迁移。 当前使用CDM的“整库迁移”功能时的限制:如果源HBase集群中被删除操作的数据无法同步到目的端集群上。 场景迁移的HBase连接器不能与“整库迁移”共用,因此需要单独配置“HBase”连接器。 参考全量数据迁移的1~7步骤新增两个“HBase”连接器,连接器类型根据实际集群来选择。 例如选择连接器类型时分别为源端集群和目的端集群选择“MRS HBase”和“Apache HBase”。 图6 HBase增量迁移连接 选择“作业管理”的“整库迁移”页签,单击“新建作业”。 进入作业参数配置界面,作业相关信息配置完成后单击“下一步”。 作业名称:用户自定义作业名称,例如hbase-increase。 源端作业配置:源连接名称请选择新创建的到源端集群的连接名称,并展开高级属性配置迁移数据的时间段。 目的端作业配置:目的连接名称请选择新创建的到目的端集群的连接名称,其他不填写。 图7 HBase增量迁移作业配置 选择要迁移的数据表, 单击“下一步”,单击“保存”。 选择“作业管理”的“整库迁移”页签,在待运行作业的“操作”列单击“运行”,即可开始HBase数据增量迁移。
  • 操作步骤 登录CDM管理控制台。 创建CDM集群,该CDM集群的安全组、虚拟私有云、子网需要和迁移目的端集群保持一致,保证CDM集群和MRS集群之间网络互通。 在“集群管理”页面单击待操作集群对应“操作”列的“作业管理”。 在“连接管理”页签,单击“新建连接”。 参考CDM服务的新建连接页面,分别添加到迁移源端集群和迁移目的端集群的连接。 连接类型根据实际集群来选择,如果是MRS集群,连接器类型可以选择“MRS Hive”,如果是自建集群可以选择“Apache Hive”。 图2 创建Hive连接 在迁移目的端集群中创建数据迁移后的存储数据库。 选择“作业管理”的“表/文件迁移”页签,单击“新建作业”。 进入作业参数配置界面,配置作业名称,并分别为源连接和目的连接选择5中创建的对应数据连接并选择要迁移的数据库和表名,单击“下一步”。 图3 Hive作业配置 配置源字段和目的字段的映射关系, 并单击“下一步”。 进入任务配置页面,不做修改,直接单击“保存”。 选择“作业管理”的“表/文件迁移”页签,在待运行作业的“操作”列单击“运行”,即可开始Hive数据迁移。 迁移完成后,可以在目的端集群和源端集群的Hive Beeline命令行中,通过同样的查询语句,对比查询结果进行验证。 例如在目的端集群和源端集群上通过查询catalog_sales表的记录数来确认数据条数是否一致。 select count(*) from catalog_sales; 图4 源端集群数据记录 图5 目的端集群数据记录 (可选)如果源端集群中有新增数据需要定期将新增数据迁移至目的端集群,则根据数据新增方式进行不同方式的迁移。配置定期任务增量迁移数据,直到所有业务迁移至目的端集群。 Hive表数据修改、未新增删除表、未修改已有表的数据结构:此时Hive表已经创建好,仅需迁移Hive存储在HDFS或OBS上的文件即可,请参考Hadoop数据迁移到华为云MRS服务页面新增数据迁移方式进行数据迁移。 Hive表有新增:请选择“作业管理”的“表/文件迁移”页签,在Hive迁移作业的“操作”列单击“编辑”,选择新增的数据表进行数据迁移。 Hive表有删除或已有表的数据结构有修改:请在目的端集群中手动删除对应表或手动更新变更的表结构。
  • 场景介绍 本章节适用于将线下IDC机房或者公有云Hive集群中的数据(支持数据量在几十TB级别或以下的数据量级)迁移到华为云MRS服务。 Hive数据迁移分两部分内容: Hive的元数据信息,存储在MySQL等数据库中。MRS Hive集群的元数据会默认存储到MRS DBService组件,也可以选择RDS(MySQL)作为外置元数据库。 Hive的业务数据,存储在HDFS文件系统或OBS对象存储中。 使用华为云CDM服务“场景迁移功能”可以一键式便捷地完成Hive数据的迁移。 本章节以通过华为云CDM服务 2.9.1.200版本进行数据迁移为例介绍。不同版本操作可能有差异,具体操作详情以实际版本对应的操作指导为准。 CDM服务支持迁移的数据源可参考支持的数据源,数据源为Apache Hive时,不支持2.x版本,建议使用的版本为1.2.X、3.1.X,请执行搬迁前务必确认是否支持搬迁。 图1 Hive数据迁移示意
  • 表引擎选择建议 自助报表分析、行为数据分析,在不涉及重复数据聚合的情况下,建议使用ReplicatedMergeTree表引擎。 涉及到物化视图等聚合函数的场景,建议使用ReplicatedAggregatingMergeTree表引擎。 经常有数据去重或有update修改数据的场景下,建议使用ReplacingMergeTree表引擎,配合使用argMax函数获取最新数据。 表1 应用场景列表 引擎名称 应用场景 MergeTree ClickHouse中最重要的引擎,基于分区键(partitioning key)的数据分区分块存储、前缀稀疏索引(order by和primary key)。 ReplacingMergeTree 相对于MergeTree,它会用最新的数据覆盖具有相同主键的重复项。 删除老数据的操作是在分区异步merge的时候进行处理,只有同一个分区的数据才会被去重,分区间及shard间重复数据不会被去重,所以应用侧想要获取到最新数据,需要配合argMax函数一起使用。 SummingMergeTree 当合并SummingMergeTree表的数据片段时,ClickHouse会把所有具有相同主键的行进行汇总,将同一主键的行替换为包含sum后的一行记录。 如果主键的组合方式使得单个键值对应于大量的行,则可以显著的减少存储空间并加快数据查询的速度。 AggregatingMergeTree 该引擎继承自MergeTree,并改变了数据片段的合并逻辑。 ClickHouse会将一个数据片段内所有具有相同主键(准确的说是排序键)的行替换成一行,这一行会存储一系列聚合函数的状态。可以使用AggregatingMergeTree表引擎来做增量数据的聚合统计,包括物化视图的数据聚合。 CollapsingMergeTree 在创建时与MergeTree基本一样,除了最后多了一个参数,需要指定Sign位(必须是Int8类型)。 CollapsingMergeTree会异步地删除(折叠)除了特定列Sign1和-1值以外的所有字段的值重复的行。 VersionedCollapsingMergeTree 是CollapsingMergeTree的升级,使用不同的collapsing算法,该算法允许使用多个线程以任何顺序插入数据。 Replicated*MergeTree 只有Replicated*MergeTree系列引擎是上面介绍的引擎的多副本版本,为了提升数据和服务的可靠性,建议使用副本引擎: ReplicatedMergeTree ReplicatedSummingMergeTree ReplicatedReplacingMergeTree ReplicatedAggregatingMergeTree ReplicatedCollapsingMergeTree ReplicatedVersionedCollapsingMergeTree ReplicatedGraphiteMergeTree
  • ClickHouse集群业务规划 集群规模 建议单集群不超过256节点规模。 集群负载 对于不同业务负载的业务,需要分开集群部署,便于不同负载的业务进行资源隔离。 集群并发 由于ClickHouse单个SQL会最大化使用每个主机上的CPU/内存/IO资源,对于复杂SQL查询(复杂聚合、复杂join计算)能够支持50~100并发,对于简单的SQL查询,支持100~200左右查询。 如果集群有混合负载(要求极致性能的点查/范围查询和有大数据量聚合及join查询),建议将不同类型的负载拆分到不同集群;对于集群规划有远远超过100个并发业务系统,也需要设计将业务分摊到不同的集群。 父主题: 集群规划
  • 打通数据传输通道 当源集群与目标集群部署在同一区域的不同VPC时,请创建两个VPC之间的网络连接,打通网络层面的数据传输通道。请参见VPC对等连接。 当源集群与目标集群部署在同一VPC但属于不同安全组时,在VPC管理控制台,为每个安全组分别添加安全组规则。规则的“协议”为“ANY”,“方向”为“入方向”,“源地址”为“安全组”且是对端集群的安全组。 为源集群的安全组添加入方向规则,源地址选择目标集群的安全组。 为目标集群的安全组添加入方向规则,源地址选择源集群的安全组。 当源集群与目标集群部署在同一VPC同一安全组且两个集群都开启了Kerberos认证,需为两个集群配置互信。
  • Snapshots 对表执行snapshot操作生成快照,既可以作为原表的备份,当原表出现问题的时候可以回滚恢复,也可以作为跨集群的数据备份工具。执行快照会在当前HBase上的根目录(默认为/hbase)生成“ .hbase-snapshot”目录,里面有每个快照的详细信息。当执行ExportSnapshot导出快照时,会在本地提交MR任务,将快照信息以及表的HFile分别拷贝到备集群的/hbase/.hbase-snapshot和/hbase/archive中。详情请参考http://hbase.apache.org/2.2/book.html#ops.snapshots。 该方式数据备份的优点: 单表备份效率高,在线数据本地/远程备份,不中断主集群和备集群业务,可以灵活配置map的个数和限制流量,MapReduce的执行节点可不在主备集群(不占资源)。 该方式数据备份的缺点和限制: 只能单表操作,备份的表名在snapshot中已经指定无法更改,且无法增量备份,运行MR需要占用本地集群资源。 在主集群执行如下操作: 对表创建快照。例如对表member创建快照member_snapshot。 snapshot 'member','member_snapshot' 将快照拷贝到备集群上。 hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot member_snapshot -copy-to hdfs://备集群HDFS服务主NameNode节点IP:端口号/hbase -mappers 3 备集群的数据目录必须为HBASE根目录(/hbase) mappers表示MR任务需要提交的map个数 在备集群执行如下操作: 使用restore命令在备集群自动新建表,以及与archive里的HFile建立link。 restore_snapshot 'member_snapshot' 如果只是备份表数据的话,建议使用此种方式备份,SnapshotExport会在本地提交MR任务,将Snapshot和HFile拷贝到备集群,之后可以在备集群直接加载数据,效率比其他方式高很多。
  • CopyTable 拷贝表功能与导出功能类似,拷贝表也使用HBase API创建了一个MapReduce任务,以便从源表读取数据。不同的地方是拷贝表的输出是hbase中的另一张表,这张表可以在本地集群,也可以在远程集群。详情请参考http://hbase.apache.org/2.2/book.html#copy.table。 该方式数据备份的优点: 操作简单,在线拷贝不中断业务,可以指定备份数据的startrow/endrow/timestamp。 该方式数据备份的缺点和限制: 只能单表操作,远程拷贝数据量大时效率较低,MapReduce需要占用本地资源,MapReduce的map个数以表region的个数划分。 在备集群执行如下操作: 执行create命令在备集群上新建与主集群相同结构的表,例如member_copy。 在主集群执行如下操作: 执行CopyTable的命令拷贝表。 hbase org.apache.hadoop.hbase.mapreduce.CopyTable [--starttime=xxxxxx] [--endtime=xxxxxx] --new.name=member_copy --peer.adr=server1,server2,server3:2181:/hbase [--families=myOldCf:myNewCf,cf2,cf3] TestTable starttime/endtime为待拷贝数据的时间戳。 new.name为备集群中目的表的表名,默认为和原来表名相同。 peer.adr为备集群zookeeper节点的信息,格式为quorumer:port:/hbase。 families为待拷贝的表的family列。 如果是拷贝数据到远端集群,此种方式导入数据会在主机群上提交MapReduce任务,读取原始表的全量/部分数据之后采用put的方式写入远端集群,所以如果表的数据量很大(远程拷贝不支持bulkload),则效率会比较低。
  • Offline backup of HDFS data 离线备份HDFS数据,即关闭HBase服务并手工在HDFS上拷贝数据。 该方式数据备份的优点: 可以把主集群上所有数据(包含元数据)整个复制到备集群。 由于是通过Distcp直接拷贝的,所以数据备份的效率相对较高。 实际操作时可以根据具体的需求灵活拷贝,可以只拷贝其中一个表的数据,也可以拷贝region中的其中一个HFile等。 该方式数据备份的缺点和限制: 此操作会覆盖备集群上的HDFS的数据目录。 如果主备集群间的HBase版本不同,HDFS目录直接拷贝可能会出现问题,例如MRS上的hbase1.3版本新增了系统表index,如果使用老版本的HDFS目录直接覆盖,会找不到该数据表。所以此种方案在执行前需要慎重考虑。 此操作对用户使用HBase的能力有一定的要求,如出现异常情况需要根据实际情况执行恢复。 在主集群执行如下操作: 执行如下命令将当前集群内存中的数据持久化到HDFS中。 flush 'tableName' 停止HBase服务。 使用distcp命令拷贝当前集群HDFS上的数据到备集群上。 hadoop distcp -i /hbase/data hdfs://备集群HDFS服务主NameNode节点IP:端口号/hbase hadoop distcp -update -append -delete /hbase/ hdfs://备集群HDFS服务主NameNode节点IP:端口号/hbase/ 第二条命令为增量拷贝除了data目录以外的文件,例如archive里面的数据可能还有被数据目录所引用。 在备集群执行如下操作: 重启HBase服务,使数据迁移生效。在启动过程中,HBase会加载当前HDFS上的数据并重新生成元数据。 启动完成后,在Master节点客户端执行如下命令加载HBase表数据。 $HBase_Home/bin/hbase hbck -fixMeta -fixAssignments 命令执行完成后,重复执行如下命令查看HBase集群健康状态直至正常。 hbase hbck 当用户使用了HBase协处理器,自定义jar包放在主集群的regionserver/hmaster上时,在备集群重启HBase之前,需要把这些自定义jar包也拷贝过来。
  • Replication Replication备份是在HBase上建立主备集群的容灾关系,当数据写入主集群,主集群通过WAL来主动push数据到备集群上,从而达到主备集群的实时同步。详情请参考http://hbase.apache.org/2.2/book.html#_cluster_replication。 该方式数据备份的优点: 使用replication有别于其他几种数据备份导入方式,当配置了集群间的主备关系后,数据可以实时同步(无需人为操作)。 相对而言,“备份”的动作占用集群的资源较少,对集群的性能影响小。 数据同步可靠性较高,如果备集群停止一段时间后再恢复,这中间主机群的数据依然会同步到备集群。 该方式数据备份的缺点和限制: 如果客户端写入的数据设置不写WAL,则数据无法备份到备集群。 由于占用的资源少,后台是通过异步的方式同步数据,实际数据没有实时同步。 对于开启表replication同步之前,主集群就已经存在的数据无法同步,需要借助其他方式导入的备集群。 bulkload方式写入到主集群的数据无法同步(MRS上的HBase对replication做了增强,支持bulkload on replication)。 具体的使用和配置方法请参考配置HBase备份和使用ReplicationSyncUp工具来进行备份数据。
  • 数据迁移到MRS前网络准备 进行大数据迁移时,需要保证源端集群和目的端集群之间的网络互通,例如使用hadoop distcp命令跨集群复制数据时需要所有DataNode节点网络互通。根据不同的迁移场景需要使用不通的方式先打通两套集群之间网络连接。 客户线下数据中心迁移数据到华为云MRS集群,通过云专线服务为用户搭建本地数据中心与云上VPC之间的专属连接通道。可以使用华为云的云专线服务或使用第三方的云专线服务来连通华为云网络。 图1 线下数据中心迁移 客户在华为云上自建大数据集群(或老版本的MRS集群)需要迁移到华为云MRS集群,且在同一个Region区域和VPC子网,可以使自建集群和MRS集群使用相同安全组、VPC、子网网络,从而保证网络连通。 图2 线上同Region同VPC迁移 客户在华为云上自建大数据集群(或老版本的MRS集群)需要迁移到华为云MRS集群,且在同一个Region区域,但是使用不同VPC子网。需要使用VPC对等连接方式配置网络连通。 图3 线上同Region不同VPC迁移 客户在华为云上自建大数据集群(或老版本的MRS集群)需要迁移到华为云MRS集权,但在不同Region区域,可以通过使用云连接构建跨区域VPC的网络连接。 图4 线上不同Region迁移 父主题: 数据迁移
  • 步骤1:创建MRS集群 创建并购买一个包含有Kafka组件的MRS集群,详情请参见购买自定义集群。 本文以购买的MRS 3.1.0版本的集群为例,组件包含Hadoop、Kafka组件,集群未开启Kerberos认证。 集群购买成功后,在MRS集群的任一节点内,安装集群客户端,具体操作可参考安装并使用集群客户端。 例如客户端安装在主管理节点中,安装目录为“/opt/client”。 客户端安装完成后,在客户端内创建“lib”目录,用于放置相关jar包。 将安装客户端过程中解压的目录中Kafka相关jar包复制到“lib”目录。 例如客户端软件包的下载路径为主管理节点的“/tmp/ FusionInsight -Client”目录,执行以下命令: mkdir /opt/client/lib cd /tmp/FusionInsight-Client/FusionInsight_Cluster_1_Services_ClientConfig scp Kafka/install_files/kafka/libs/* /opt/client/lib
  • Doris UDF开发规则 UDF中方法调用必须是线程安全的。 UDF实现中禁止读取外部大文件到内存中,如果文件过大可能会导致内存耗尽。 需避免大量递归调用,否则容易造成栈溢出或oom。 需避免不断创建对象或数组,否则容易造成内存耗尽。 Java UDF应该捕获和处理可能发生的异常,不能将异常给服务处理,以避免程序出现未知异常。可以使用try-catch块来处理异常,并在必要时记录异常信息。 UDF中应避免定义静态集合类用于临时数据的存储,或查询外部数据存在较大对象,否则会导致内存占用过高。 应该避免类中import的包和服务侧包冲突,可通过grep -lr "完全限定类名"命令来检查冲突的Jar包。如果发生类名冲突,可通过完全限定类名方式来避免。
共100000条