【DataHub】現代資料棧的中繼資料平台--如何快速驗證所有元件容器都在正确的運作?

databub中的元件較多，并且都在docker 容器中運作，那麼如何快速驗證所有元件容器都在正确的運作呢？

本文提供如下3類檢查方式

使用datahub内置工具檢查
使用docker 指令檢查
檢查元件資料初始化是否正常？

最後針對檢查出的常見問題，提供解決方案。

1. 使用datahub内置工具檢查

如果安裝了datahub CLI工具，可以使用内置的檢查工具:

datahub docker check

此工具檢查步驟如下：

檢查記憶體總量【“MemTotal”】是否大于3.8GB
檢查必須的9個容器是否存在（詳見 REQUIRED_CONTAINERS 清單)
檢查3個setup容器是否成功運作并退出 (詳見 ENSURE_EXIT_SUCCESS 清單)
檢查必須的9個容器的運作狀态【正常是running】和健康狀态【正常是healthy】
如果檢查不符合預期，将檢查結果追加到issues清單
如果issues清單為空，則顯示✔ No issues detected，否則列印不符合預期的清單

REQUIRED_CONTAINERS = [
    "elasticsearch-setup",
    "elasticsearch",
    "datahub-gms",
    "datahub-frontend-react",
    "kafka-setup",
    "schema-registry",
    "broker",
    "mysql",
    "zookeeper",
]

ENSURE_EXIT_SUCCESS = [
    "kafka-setup",
    "elasticsearch-setup",
    "mysql-setup",
]

【DataHub】現代資料棧的中繼資料平台--如何快速驗證所有元件容器都在正确的運作?

2. 使用docker 指令檢查

2.1.檢視容器清單

docker container ls

2.2.檢視容器資源使用情況

docker container stats

【DataHub】現代資料棧的中繼資料平台--如何快速驗證所有元件容器都在正确的運作?

2.3.檢視docker 日志

檢視最新的10行日志，看日志是否有報錯資訊

docker logs -n 100 datahub-frontend-react
docker logs -n 100 datahub-gms

3. 檢查元件資料初始化是否正常？

3.1. 檢查MXE Kafka topics是否建立？

3.1.1.使用kafka内置指令檢視

# 進入容器内容
docker exec -it broker /bin/bash
# 檢視topic 清單
kafka-topics --bootstrap-server broker:29092 --list 
# 檢視消費組清單
kafka-consumer-groups --bootstrap-server broker:29092 --list 
# 檢視所有消費組的消費情況
kafka-consumer-groups --bootstrap-server broker:29092 --describe --all-groups
# 檢視具體一個消費組的消費情況
kafka-consumer-groups --bootstrap-server broker:29092 --describe --group datahub-usage-event-consumer-job-client
# 檢視消費組的成員情況
kafka-consumer-groups --bootstrap-server broker:29092 --describe --all-groups --members
kafka-consumer-groups --bootstrap-server broker:29092 --describe --group datahub-usage-event-consumer-job-client --members

【DataHub】現代資料棧的中繼資料平台--如何快速驗證所有元件容器都在正确的運作?

3.1.2.使用kcat指令檢視

alias kcat='docker run -it --network=host edenhill/kcat:1.7.1 -b localhost:9092'
kcat -L

确認MetadataChangeEvent、MetadataAuditEvent、MetadataChangeProposal_v1和MetadataChangeLog_v1 這些topic存在

注意：

_schemas

是元件schema-registry使用的

Metadata for all topics (from broker 1: localhost:9092/1):
 1 brokers:
  broker 1 at localhost:9092 (controller)
 11 topics:
  topic "MetadataChangeLog_Timeseries_v1" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1
  topic "MetadataAuditEvent_v4" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1
  topic "MetadataChangeEvent_v4" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1
  topic "_schemas" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1
  topic "MetadataChangeProposal_v1" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1
  topic "FailedMetadataChangeEvent_v4" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1
  topic "FailedMetadataChangeProposal_v1" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1
  topic "MetadataChangeLog_Versioned_v1" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1
  topic "DataHubUsageEvent_v1" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1
  topic "__confluent.support.metrics" with 1 partitions:
    partition 0, leader 1, replicas: 1, isrs: 1

3.2. 檢查Elasticsearch的搜尋索引是否建立？

ES索引生命周期的定義，詳見參見ilm-index-lifecycle

# 檢視叢集資訊
http://172.25.21.22:9200/_cat/health?v

# 檢視節點情況
http://172.25.21.22:9200/_cat/nodes?v

# 檢視索引資訊
http://172.25.21.22:9200/_cat/indices?bytes=b&s=store.size:desc&v
http://172.25.21.22:9200/_cat/indices?v

# 檢視生命周期政策
http://172.25.21.22:9200/_ilm/policy?pretty

# 檢視索引模闆
http://172.25.21.22:9200/_index_template?pretty

确認存在datasetindex_v2和corpuserindex_v2索引

cat指令的使用詳見：elasticsearch 7.9 cat

health status index                                       uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   datajobindex_v2                             sWbMCfazSX6OgBK3WvSOeg   1   1          2            9     16.2kb         16.2kb
yellow open   dataset_datasetprofileaspect_v1             ZxhiYfytQZamggIepIMpgQ   1   1          2            0        5kb            5kb
yellow open   dataflowindex_v2                            zTrSO6IYTDOq2TwU9snX3Q   1   1          1            3     14.4kb         14.4kb
yellow open   mlmodelgroupindex_v2                        XW-7TRgMQmq0-khgiptAqg   1   1          0            0       208b           208b
yellow open   mlmodelindex_v2                             oISkmpIHTIWbOgHdBrmSwQ   1   1          1            4     14.5kb         14.5kb
yellow open   datahubpolicyindex_v2                       72bKZt6GSs-OKqDkwnOGcw   1   1          0            0       208b           208b
yellow open   corpuserindex_v2                            vXBLDUG4Q1mPw3KD_tzeBQ   1   1          2            0      7.2kb          7.2kb
yellow open   dataprocessindex_v2                         8m42drTgTdSz7roEyIk9Aw   1   1          0            0       208b           208b
yellow open   chartindex_v2                               _S8TajdHQkKo4WabK9UdcQ   1   1          2            6     11.9kb         11.9kb
yellow open   tagindex_v2                                 3ZDB11c5TfGr2lukKUMSQw   1   1          2            1      7.4kb          7.4kb
yellow open   mlmodeldeploymentindex_v2                   _s2FMAG8TbSoJefnRKzT9A   1   1          0            0       208b           208b
yellow open   datajob_datahubingestioncheckpointaspect_v1 6KeX8-eWSeGwwriBKIXoXw   1   1          0            0       208b           208b
yellow open   dashboardindex_v2                           kiy095WLSCuVZvlYrrFt9w   1   1          1            3     12.1kb         12.1kb
yellow open   .ds-datahub_usage_event-000001              8xdgcXa6RuiNMawv66hpwQ   1   1        760            0    360.6kb        360.6kb
yellow open   datasetindex_v2                             9tB6_Vo9T6e_GoXUjdGF0Q   1   1         15            3     45.9kb         45.9kb
yellow open   .ds-datahub_usage_event-000002              GTnjGvnJRBKGgmt4cz37dQ   1   1          0            0       208b           208b
yellow open   mlfeatureindex_v2                           g807UdvfQSq_gFuVgKKfIw   1   1         20           19     23.2kb         23.2kb
yellow open   datajob_datahubingestionrunsummaryaspect_v1 JSXa6cIrQniVLfHlPPO8ug   1   1          0            0       208b           208b
yellow open   dataplatformindex_v2                        7MEHkVpVRbuy8jCjreJYlA   1   1          0            0       208b           208b
yellow open   glossarynodeindex_v2                        tv04G0-qTH-uZJzYZS5SqA   1   1          1            1      9.5kb          9.5kb
yellow open   datahubretentionindex_v2                    a7P-OLDET8yXJYjSLtDioQ   1   1          0            0       208b           208b
yellow open   graph_service_v1                            9e4UyQIBQOWbCc8gnUCnlA   1   1        118            0       33kb           33kb
yellow open   system_metadata_service_v1                  j4HBXC64T3-drbfDcnjcXQ   1   1        353            5     65.5kb         65.5kb
yellow open   dataset_operationaspect_v1                  JeyNL03bSbapiRTnW_BVlA   1   1          0            0       208b           208b
yellow open   schemafieldindex_v2                         mDoCdT78TUm_ytOGBRstTg   1   1          0            0       208b           208b
yellow open   mlfeaturetableindex_v2                      5PDKM36rQFeCp9wFP08Qkw   1   1          5           14     11.8kb         11.8kb
yellow open   glossarytermindex_v2                        Pn4S_NWYR2G_d0ptgwXslA   1   1          3            8     13.5kb         13.5kb
yellow open   mlprimarykeyindex_v2                        Hab0cMlVQBu5UrkxFK0hpQ   1   1          7            0      9.5kb          9.5kb
yellow open   corpgroupindex_v2                           9P1iPOOBTUSoVnXsvM9xXA   1   1          3            2     13.8kb         13.8kb
yellow open   dataset_datasetusagestatisticsaspect_v1     DcCcNpRkQTCupcRm5uAeog   1   1          4            0      8.9kb          8.9kb

3.3. 檢查資料是否正确寫入MySQL?

docker exec -it mysql /usr/bin/mysql datahub --user=datahub --password=datahub
select * from metadata_aspect_v2 limit 10;

檢查metadata_aspect_v2表的内容，這個表存儲所有實體對象aspect的内容。

【DataHub】現代資料棧的中繼資料平台--如何快速驗證所有元件容器都在正确的運作?

4.檢查出的問題如何解決

4.1.docker資源不夠産生的問題

問題現象：elasticsearch 或 kafka broker 容器因錯誤退出或長時間卡住。

在容器日志中看到如下錯誤，很可能的原因是：給docker提供的資源不夠。請確定至少配置設定8GB RAM + 2GB交換空間。

datahub-gms     | 2022/01/03 14:34:26 Problem with request: Get http://elasticsearch:9200: dial tcp 172.19.0.5:9200: connect: connection refused. Sleeping 1s
broker          | [2022-01-03 14:34:42,398] INFO Client session timed out, have not heard from server in 6874ms for sessionid 0x10000023fa60002, closing socket connection and attempting reconnect (org.apache.zookeeper.ClientCnxn)
schema-registry | [2022-01-03 14:34:48,518] WARN Client session timed out, have not heard from server in 20459ms for sessionid 0x10000023fa60007 (org.apache.zookeeper.ClientCnxn)

4.2. bind: address already in use

網絡端口被占用（被其它程序或失敗的容器），在啟動容器前，請檢查使用的端口是否被占用，如果被占用，需要kill掉占用端口的程序

lsof -i :3306
kill -15 <PID found in step1>

4.3. 登入時報datahub.metadata_aspect表不存在

這表示mysql docker容器啟動時，資料庫沒有正确的初始化。需要運作下面的指令手工初始化：

docker exec -i mysql sh -c 'exec mysql datahub -udatahub -pdatahub' < docker/mysql/init.sql

4.4. 搞砸了datahub的環境，如何重新開始？

運作以下腳本會删除建立的所有容器和卷。注意：會删除所有資料（包括 zk,elasticsearch,mysql中的資料）

datahub docker nuke

此指令執行的操作如下：

将所有container删除
如果不資料資料，将所有volume上的資料删除
将所有network删除

4.5. java.lang.IllegalStateException: Duplicate key 主鍵沖突

在DataHub GMS container 的日志中報如下錯誤：

Caused by: java.lang.IllegalStateException: Duplicate key [email protected]

這與SQL列排序【column collation】問題有關。DataHub在2021年10月26日之前，URN字段預設排序規則使用的是不區分大小寫的utf8mb4_unicode_ci。目前預設排序規則使用區分大小的utf8mb4_bin)。

可以使用如下指令修改預設排序規則：

ALTER TABLE metadata_aspect_v2 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

附錄

如何使用kcat?

kcat安裝

注意：建立指令别名中的localhost:9092，根據需要調整為實際的kafka broker位址，如果配置多個，以

分隔

# 拉取鏡像
docker pull edenhill/kcat:1.7.1
# 建立指令别名
alias kcat='docker run -it --network=host edenhill/kcat:1.7.1 -b localhost:9092'
# 檢視幫助
kcat -h

kcat使用

詳見參見kcat running-in-docker

檢視topic 清單資訊 kcat -L
消費某一個topic的消息，如從topic MetadataChangeProposal_v1 中讀取最新的2000條消息後退出的指令: kcat -C -t MetadataChangeProposal_v1 -p 0 -o -2000 -e
消費某一個topic的消息，并按指定格式輸出： kcat -C -t MetadataChangeLog_Timeseries_v1 -f 'Topic %t[%p], offset: %o, key: %k, payload: %S bytes: %s\n'
消費某一個topic的消息，以jons方式輸出： kcat -C -t MetadataChangeLog_Timeseries_v1 -J

參考

how-can-i-confirm-if-all-docker-containers-are-running-as-expected-after-a-quickstart

【DataHub】現代資料棧的中繼資料平台--如何快速驗證所有元件容器都在正确的運作?

1. 使用datahub内置工具檢查

2. 使用docker 指令檢查

2.1.檢視容器清單

2.2.檢視容器資源使用情況

2.3.檢視docker 日志

3. 檢查元件資料初始化是否正常？

3.1. 檢查MXE Kafka topics是否建立？

3.1.1.使用kafka内置指令檢視

3.1.2.使用kcat指令檢視

3.2. 檢查Elasticsearch的搜尋索引是否建立？

3.3. 檢查資料是否正确寫入MySQL?

4.檢查出的問題如何解決

4.1.docker資源不夠産生的問題

4.2. bind: address already in use

4.3. 登入時報datahub.metadata_aspect表不存在

4.4. 搞砸了datahub的環境，如何重新開始？

4.5. java.lang.IllegalStateException: Duplicate key 主鍵沖突

附錄

如何使用kcat?

kcat安裝

kcat使用

參考

繼續閱讀

艱難安裝LDAP,SSL認證

《Linux指令行與Shell腳本程式設計大全第2版.布盧姆》pdf

MySQL的4種隔離級别？出現問題

XX系統實施過程問題總結

無元件上傳圖檔到資料庫中，最完整解決方案

【MySQL資料庫】資料庫索引事務1.索引2.事務

neo4j之cypher使用文檔

Ambari介紹和架構原理

30天了解30種技術系列---(10)面向Cloud的搜尋引擎 ElasticSearch

CentOS 7,docker安裝

NOSQL安全攻擊

mybatis_入門程式Mybatis入門

【Docker】端口映射問題操作步驟

登入plsql 報錯 the account is locked --使用者被鎖

SequoiaDB巨杉資料庫C++驅動概述

win10本地scala和spark安裝安裝scala安裝spark

【DataHub】 現代資料棧的中繼資料平台--如何快速驗證所有元件容器都在正确的運作?

1. 使用datahub内置工具檢查

2. 使用docker 指令檢查

2.1.檢視容器清單

2.2.檢視容器資源使用情況

2.3.檢視docker 日志

3. 檢查元件資料初始化是否正常？

3.1. 檢查MXE Kafka topics是否建立？

3.1.1.使用kafka内置指令檢視

3.1.2.使用kcat指令檢視

3.2. 檢查Elasticsearch的搜尋索引是否建立？

3.3. 檢查資料是否正确寫入MySQL?

4.檢查出的問題如何解決

4.1.docker資源不夠産生的問題

4.2. bind: address already in use

4.3. 登入時報datahub.metadata_aspect表不存在

4.4. 搞砸了datahub的環境，如何重新開始？

4.5. java.lang.IllegalStateException: Duplicate key 主鍵沖突

附錄

如何使用kcat?

kcat安裝

kcat使用

參考

繼續閱讀

【DataHub】現代資料棧的中繼資料平台--如何快速驗證所有元件容器都在正确的運作?