* [概述](#概述) * [部署](#部署) * [配置准备](#配置准备) * [主机规划](#主机规划) * [外部资源确认](#外部资源确认) * [Hadoop配置](#hadoop配置) * [外部组件部署](#外部组件部署) * [Victoria Metrics](#victoria-metrics) * [启动脚本](#启动脚本) * [采集配置](#采集配置) * [Loki](#loki) * [配置文件](#配置文件) * [Grafana](#grafana) * [数据源配置](#数据源配置) * [配置数据库](#配置数据库) * [部署配置](#部署配置) * [接口机目录规划](#接口机目录规划) * [脚本生成](#脚本生成) * [启动上传服务](#启动上传服务) * [编译打包项目](#编译打包项目) * [运维](#运维) * [命令行](#命令行) * [Web](#web) * [概览](#概览) * [表任务](#表任务) * [Flink任务详情](#flink任务详情) * [表任务详情](#表任务详情) * [同步情况](#同步情况) * [压缩情况](#压缩情况) * [历史压缩](#历史压缩) * [时间线](#时间线) * [Pulsar队列](#pulsar队列) * [Hudi表结构](#hudi表结构) * [压缩队列](#压缩队列) * [跨天](#跨天) * [同步集群](#同步集群) * [压缩集群](#压缩集群) * [Cloud](#cloud) * [小工具](#小工具) * [查询时间线](#查询时间线) * [提交压缩任务](#提交压缩任务) * [批量提交压缩任务](#批量提交压缩任务) * [停止所有压缩任务](#停止所有压缩任务) * [离线检索](#离线检索) * [查询文件](#查询文件) * [检索最后操作时间](#检索最后操作时间) * [HDFS](#hdfs) * [模块](#模块) * [Hudi 运行代码](#hudi-运行代码) * [sync](#sync) * [运维服务](#运维服务) * [部署工具](#部署工具) * [开发](#开发) # 概述 围绕Hudi同步和压缩流程建立了一整套的工具和流程。 # 部署 > 由于部份配置需要在源码增删，无法通过配置文件修改，**如果部署新集群，建议对master建立分支进行操作，避免配置混淆** ## 配置准备 ### 主机规划 通常来说，应用部署需要逻辑上规划有 - 一台**接口机**；用于操作脚本、存放jar包等。 - 一台**组件机**；用于部署应用配套的外部组件。 - 剩下的作为**应用机**；用于部署应用服务节点。 上述为逻辑规划，原则上对于机器配置没有特别要求，可以混用；如接口机上也用于部署外部组件，同时也作为服务节点部署服务。 组件机上规划有指标和日志汇聚，hudi任务多的情况下，对IO和磁盘有一定的负载要求，建议单独部署。 ### 外部资源确认 - Hadoop3 用于存放Hudi数据、Flink任务业务jar包等 - Yarn集群节点到HDFS的增删改查权限 - 应用部署主机到HDFS的增删改查权限 - Zookeeper 用于hudi同步压缩服务注册，通常可以使用Hadoop3集群附带的zookeeper - Yarn集群节点到zookeeper的网络连通 - 应用部署主机到zookeeper的网络连通 - Yarn 用于运行hudi同步压缩任务 - 应用部署主机提交任务的权限 - MySQL 配置数据库；目前和汇聚平台配置库耦合，不能改，只能直接使用汇聚配置数据库 - 应用部署节点到MySQL的访问连通 - Pulsar 数据源 - Yarn集群节点到pulsar的读取连通 - 应用部署主机到pulsar的client连通和admin连通 - 应用部署主机 部署配套应用服务 - JDK 1.8（实现OpenJDK标准即可） - Kerberos - 接口机到应用机的ssh免密（用于服务启停部署） #### Hadoop配置 在`config`目录下以「hudi数据所有集群名称+hudi同步运行集群名称」的格式建立配置文件夹，如`b2b12`，并将下列配置文件放在这里 - core-site.xml - hdfs-site.xml - yarn-site.xml - viewfs-mount-table.xml（如果需要使用联邦，core-site.xml也需要将引用改为相对路径引用） ### 外部组件部署 _组件安装包放在研发云制品库：[汇聚平台项目-制品库](https://www.srdcloud.cn/artifact/26151/project#generic)_ odcp-snapshot-generic-local/cluster-tools下面 #### Victoria Metrics Victoria Metrics是一款替代Prometheus的开源指标采集应用，支持分布式部署和指标主动推送，完全兼容Prometheus API，提供了接近数倍于Prometheus的性能。 _目前项目采用单节点模式部署，性能还有富裕，后期可根据性能需求，改为分布式部署。_ ``` victoria_metrics-1.98 ├── prometheus.yml 配置文件 ├── start_victoria_metrics.sh 启动脚本 ├── stop_victoria_metrics.sh 停止脚本 ├── version ├── victoria-metrics-prod-amd64 x86架构 └── victoria-metrics-prod-arm64 arm架构 ``` ##### 启动脚本 启动脚本需要根据部署的主机区分CPU架构，修改脚本内容，引用合适的可执行文件。 用户名为`EsCFVuNkiDWv7PKmcF`，密码为`Abf%x9ocS^iKr3tgrd`，用于保护Victoria Metrics的Web页面。 ```Bash nohup $current_path/victoria-metrics-prod-amd64 \ -search.maxQueryLen=1MB \ -promscrape.maxScrapeSize=100MB \ -loggerLevel=ERROR \ -storageDataPath=$current_path/data \ -retentionPeriod=7d \ -httpAuth.username=EsCFVuNkiDWv7PKmcF \ -httpAuth.password=Abf%x9ocS^iKr3tgrd \ -httpListenAddr=":35710" \ -promscrape.config=$current_path/prometheus.yml \ -promscrape.httpSDCheckInterval=15s \ > $current_path/victoria-metrics.log 2>&1 & ``` 启动完成后可以通过脚本指定的端口`35710`访问Web页面，即为启动成功。  ##### 采集配置 Victoria Metrics的配置文件完全兼容Prometheus，可以直接替换使用。 ```yaml global: scrape_interval: 15s scrape_timeout: 15s scrape_configs: # Victoria Metrics 本身的指标 - job_name: 'Victoria Metrics Single Cluster' metrics_path: '/metrics' basic_auth: username: EsCFVuNkiDWv7PKmcF password: Abf%x9ocS^iKr3tgrd static_configs: - targets: - '132.126.207.34:35710' # Loki日志采集 - job_name: 'Loki' metrics_path: '/metrics' static_configs: - targets: - '132.126.207.34:33100' # 集群主机管理，根据需要启用 - job_name: 'Node Exporter' metrics_path: '/metrics' static_configs: - targets: - '132.126.207.124:20110' # 应用服务的指标采集，部署Victoria Metrics的时候可以注释，等应用部署完成后再打开 - job_name: 'Service' metrics_path: '/actuator/prometheus' basic_auth: username: AxhEbscwsJDbYMH2 password: cYxg3b4PtWoVD5SjFayWxtnSVsjzRsg4 # 可以通过service-cloud-query模块动态获取各个服务节点的IP http_sd_configs: - url: http://132.126.207.34:35690/hudi_services/service_cloud_query/cloud/targets basic_auth: username: AxhEbscwsJDbYMH2 password: cYxg3b4PtWoVD5SjFayWxtnSVsjzRsg4 ``` #### Loki Loki是一款日志汇聚工具，Grafana公司出品，可以通过Grafana直接查询日志，相比ELK更为轻量级，不需要额外的日志采集组件，支持应用直接推送日志，对简单的分布式应用更友好。 _根据规划，Loki分为服务日志和Hudi日志，选择两台机器分别部署；Hudi日志较多，如果所有日志划分到一个Loki，可能会影响服务日志查询_ ``` loki-2.9 ├── stop_loki.sh 停止脚本 ├── version ├── loki-linux-amd64 x86架构 ├── loki-linux-arm64 arm架构 ├── loki-config.yml 配置文件 ├── start_loki.sh 启动脚本 └── logs ``` ##### 配置文件 ```yaml # Loki不支持直接配置访问控制，官方建议使用Nginx来实现 auth_enabled: false query_range: parallelise_shardable_queries: false server: # 日志推送端口 http_listen_port: 33100 grpc_listen_port: 39096 log_level: error grpc_server_max_recv_msg_size: 1572864000 grpc_server_max_send_msg_size: 1572864000 common: # 指向规划好的数据盘 path_prefix: /data/datalake/data/loki storage: filesystem: chunks_directory: /data/datalake/data/loki/chunks rules_directory: /data/datalake/data/loki/rules replication_factor: 1 ring: instance_addr: 127.0.0.1 kvstore: store: inmemory table_manager: retention_deletes_enabled: true retention_period: 72h schema_config: configs: - from: 2023-12-06 store: boltdb-shipper object_store: filesystem schema: v11 index: prefix: index_ period: 24h ``` #### Grafana 根据CPU架构选择`grafana-amd64-10.3`或者`grafana-arm64-10.3`部署包。 ``` grafana-amd64-10.3 ├── data ├── start_grafana.sh ├── stop_grafana.sh ├── npm-artifacts ├── packaging ├── plugins-bundled ├── public ├── bin ├── conf ├── storybook ├── tools ├── VERSION ├── LICENSE ├── NOTICE.md ├── README.md └── Dockerfile ``` ##### 数据源配置 根据部署的组件新增数据源，其中Loki区分服务日志和Hudi日志（如果没有部署两个，可以不区分）。  ### 配置数据库 在`database`路径下，有数据库初始化脚本，其中`tb_app_hudi_job_config`和`tb_app_yarn_job_config`两张表提供了预设配置。 _建议为每一个环境创建一个单独的database，避免不同集群的配置混在一起。_ ``` database ├── tb_app_collect_table_info.sql ├── tb_app_collect_table_version.sql ├── tb_app_flink_job_config.sql ├── tb_app_global_config.sql ├── tb_app_hudi_compaction_job.sql ├── tb_app_hudi_compaction_metrics.sql ├── tb_app_hudi_event.sql ├── tb_app_hudi_job_config.sql ├── tb_app_hudi_sync_state.sql └── tb_app_yarn_job_config.sql ``` ### 部署配置 以`service-cli/service-cli-runner/src/main/resources/application-b12.yml`为模版，补全应用部署信息 以`service-web/src/main/resources/static/common/info.js#commonInfo`为模板，补全web页面相关信息 ### 接口机目录规划 选择一个空白目录作为根目录（下文简称「根目录」），创建下列子目录。 ``` . ├── cloud 服务管理脚本 ├── command 应用命令行 ├── data 应用数据 ├── extra 外部组件 ├── logs 应用日志 └── uploader 上传服务 ``` ## 脚本生成 将`bin/generate` 脚本复制到根目录下，根据实际情况改动脚本中指向的一些目录、jdk和jar包路径，执行脚本；正常情况下，脚本将会为`cloud`、`command`、`uploader` 目录生成脚本。 ## 启动上传服务 _如果使用其他文件服务，如YTP，则不需要操作这一步，直接使用其他文件服务即可。_ ``` uploader ├── start.sh 启动脚本 ├── stop.sh 停止脚本 └── update.sh 更新脚本 ``` 执行`start.sh`启动上传服务，默认端口为`36800`。 ## 编译打包项目 将文件服务的url补充到`bin/library.sh`中，执行`bin/build-all.sh`，打包编译全部模块并上传到文件服务。 # 运维 应用提供三部分运维方案： - **命令行**：提供命令行操作，包括同步的启动、停止等，在Web无法使用的情况下做一些简单运维操作； - **Web**：提供表信息、运行总览等，完成常见的运维操作； - **HDFS**：在上述手段出现问题，或无法操作的情况下，直接访问HDFS查看hudi表相关的状态。 ## 命令行 ## Web ### 概览 概览页面可以看到应用的主要运行情况，从上到下分别有： - 表数量 - 逻辑表（根据上游源表名去重得到） - 湖底表（根据目标hudi表路径去重得到） - 嗨福表（根据hive表名去重得到） - Flink运行同步任务数量 - flink任务数 - flink任务下对应表总数 - hudi同步集群情况 - hudi压缩集群情况 - 跨天情况 - 重点表跨天情况 - 普通表跨天情况 - 压缩调度定时策略  ### 表任务 可以按表级别查询到相关配置、运行、周边信息，完成常见的表运维跟踪。  #### Flink任务详情 点击`Flink job id`项目可以打开Flink任务详情页面。  #### 表任务详情 点击`别名`项目可以打开表任务详情页面，在这个页面主要可以查看表本身的配置信息，尤其是字段信息。  ##### 同步情况 查看Flink同步任务的详情和历史情况，方便直接跳转日志查看。  ##### 压缩情况 查看Flink同步任务的详情和历史情况，方便直接跳转日志查看；由于压缩任务运行在多集群，历史任务保留多久，会受到各个集群任务量、配置的限制，如果超出集群保留任务列表的限制（比如b1集群任务列表整个集群最后10000条），就会在这里查询不到，在使用的时候需要注意这一点。  ##### 历史压缩 记录在数据库中的历史压缩情况，由各个服务端维护，方便查询历史压缩情况，不受集群保留历史任务限制。  ##### 时间线 查询实时hudi表时间线，可以更清晰地看到压缩情况和同步情况，对于查询压缩任务启停时间点，以及压缩任务包含文件数，非常有帮助。  ##### Pulsar队列  ##### Hudi表结构  ### 压缩队列  ### 跨天  ### 同步集群  ### 压缩集群  ### Cloud  ### 小工具 #### 查询时间线 #### 提交压缩任务 #### 批量提交压缩任务 #### 停止所有压缩任务 ### 离线检索 #### 查询文件 #### 检索最后操作时间 ## HDFS # 模块 模块主要分为三部分，包含 Hudi 运行代码、运维服务和部署工具。 ## Hudi 运行代码 ### sync sync 模块包含 Hudi 运行的全部业务逻辑，Hudi on flink 的运行模式为 ## 运维服务 ## 部署工具 # 开发