現在用不到沒關系，先收藏，防止后面找不到哦。
#大數據##大數據學習#
1、group by 使用內存限制
錯誤信息如下：
Code: 241.DB::Exception: Memory limit (for query) exceeded:would use 9.37 GiB (attempt to allocate chunk of 134217760 bytes), maximum: 9.31 GiB.定位到該查詢中的 SQL 中使用了 group by ，默認的配置中沒有對 group by 做內存限制。
解決方案：
執行 SQL 之前，在客戶端進行如下設置
set max_memory_usage=32000000000;set max_bytes_before_external_group_by=16000000000;-- 下面是 sql 內容在進行group by的時候，內存使用量已經達到了max_bytes_before_external_group_by的時候就進行寫磁盤(基於磁盤的group by相對於基於磁盤的order by性能損耗要好很多的)，一般max_bytes_before_external_group_by設置為max_memory_usage / 2，原因是在clickhouse中聚合分兩個階段：查詢並且建立中間數據；合並中間數據 寫磁盤在第一個階段，如果無須寫磁盤，clickhouse在第一個和第二個階段需要使用相同的內存。https://clickhouse.tech/docs/en/sql-reference/statements/select/group-by/#select-group-by-in-external-memory
2、寫入數據失敗
1.錯誤信息如下：
Too many parts (300). Merges are processing significantly slower than inserts...使用 Flink 實時消費 Kafka 的數據，Sink 到 ClickHouse ，策略是一條一條插入，任務上線一段時間之后，ClickHouse 扛不住數據插入的壓力了(
是因為MergeTree的merge的速度跟不上 data part 生成的速度。)，就報錯了上述的報錯信息。
解決方案：
優化 FLink ClickHouse Sink邏輯， 根據時間和數據量做觸發，滿足其一才會執行插入操作。
2.錯誤信息如下
Code: 252, e.displayText() = DB::Exception: Too many partitionsfor single INSERT block (more than 100). 大概意思就是單次插入的數據分區太多了，超過默認配置的 100 個了。
解決方案：
1.合理設置分區字段 2.修改這個 max_partitions_per_insert_block 參數，調大這個值。
3、刪除數據失敗
錯誤信息如下：
Code: 359,e.displayText()=DB::Exception: Table or Partition in xxx was not dropped.Reason:1. Size (158.40 GB) is greater than max_[table/partition]_size_to_drop (50.00 GB)2. File '/data/clickhouse/clickhouse-server/flags/force_drop_table' intended to force DROP doesn't exist從報錯信息中的原因 1 可以看到，刪除的數據實際大小已經超過了配置的大小。原因 2 說明是可以跳過配置檢查，進行強制刪除的，但是沒找到這個文件 /data/clickhouse/clickhouse-server/flags/force_drop_table，所以不能跳過檢查，也就是不能強制刪除。
根據錯誤提示2 ，在所在的節點執行：
sudo touch '/data/clickhouse/clickhouse-server/flags/force_drop_table' && sudo chmod 666 '/data/clickhouse/clickhouse-server/flags/force_drop_table' 然后再次執行 刪除操作就可以了。
需要注意的是，這個標識文件有效期只有一次，執行刪除完畢之后，這個文件就會消失。
4、Join 誤用
關聯兩張表，對於未關聯的行，使用該字段的默認值填充，而不是使用 null 填充。
在 system.settings 表中可以找到參數 join_use_nulls
這和我們在 Mysql 或者 Hive 等使用習慣上不一致，如果想要改成一樣的，需要修改這個參數 join_use_nulls 為 1。
准備數據
-- 建表 1create table st_center.test_join_1( id String, name String) engine = MergeTree() order by tuple() SETTINGS index_granularity = 8192;-- 建表 2create table st_center.test_join_2( id String, name String) engine = MergeTree() order by tuple() SETTINGS index_granularity = 8192;-- 插入測試數據insert into test_join_1(id, name) values ('1','大數據學習指南');insert into test_join_1(id, name) values ('2','大數據進階之路');insert into test_join_2(id, name) values ('1','大數據學習指南');數據准備好了，下面我們測試一下。
select * from st_center.test_join_1 as t1all left join st_center.test_join_2 as t2on t1.id = t2.id關聯結果如下，未連接的行使用默認值填充的。String類型就填充空字符串，數值類型就填充 0
修改參數，在 SQL 最后加入 settings join_use_nulls = 1
select * from st_center.test_join_1 as t1all left join st_center.test_join_2 as t2on t1.id = t2.idsettings join_use_nulls = 1關聯結果如下，和我們在 mysql 等中的使用習慣一樣了。
如果對你有幫助，歡迎點贊收藏轉發，關注我，不迷路，帶你學習大數據！
一、異常
1）DB::Exception: Nested type Array(String) cannot be inside Nullable type (version 20.4.6.53 (official build))
原因：字段類型是Nullable(String)，在使用一些字符串函數如splitByString，他們對Nullable類型是不支持的，需要轉成String。
解決：使用cast強轉一下字段類型就行：
select splitByString(',',cast(col as String)) col from test
2）DB::Exception: Cannot convert NULL value to non-Nullable type: while converting source column second_channel to destination column second_channel (version 20.4.6.53 (official build))
原因：字段類型是非空類型，insert null值到非空字段second_channel會報錯。
解決：可以將非空類型改成Nullable(String)，但是要注意Nullable字段不允許用於order by。
3）DB::Exception: Memory limit (total) exceeded: would use 113.20 GiB (attempt to allocate chunk of 134200512 bytes), maximum: 113.14 GiB: While executing CreatingSetsTransform. (version 20.4.6.53 (official build))
原因：單次查詢出來的數據量，大於單台機器的剩余內存。
解決：可以將查詢范圍縮小，比如添加查詢條件對查詢結果取余，也可以清理或者添加物理機內存。
5）DB::Exception: Table columns structure in ZooKeeper is different from local table structure (version 20.12.3.3 (official build))
原因：Replicated（副本）表刪表重建，但zk中表結構刪除操作是異步的，默認為五分鍾。
解決：重啟該節點的ck，或者選擇等待幾分鍾內。
6）Too many parts (300). Merges are processing significantly slower than inserts...
原因：使用 Flink 實時消費 Kafka 的數據，Sink 到 ClickHouse ，策略是一條一條插入，任務上線一段時間之后，ClickHouse 扛不住數據插入的壓力了(是因為MergeTree的merge的速度跟不上 data part 生成的速度)。
解決：優化 FLink ClickHouse Sink邏輯， 根據時間和數據量做觸發，滿足其一才會執行插入操作。
7）Caused by: org.apache.spark.memory.SparkOutOfMemoryError: error while calling spill() on org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter@5915c8a5
原因：磁盤空間不足。
8）spark sql unsupported type array
原因：因為數據源的數組類型和spark sql的數組類型不一致，可以將數組轉為string
解決：
select toString(field) from tablet
二、錯誤碼
1）Code: 48
Received exception from server (version 21.1.2.15):
Code: 48. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Mutations are not supported by storage Distributed.
原因：分布式表不能進行更新，ALTER TABLE UPDATE/DELETE不支持分布式DDL
解決：需要在分布式環境中手動在每個節點上local的進行更新/刪除數據。
2）Code:1002
2021-02-22 07:31:31,656 ERROR [main] execute clickhouse Query Error
ru.yandex.clickhouse.except.ClickHouseUnknownException: ClickHouse exception, code: 1002, host: xxxx, port: 8123; xxxx:8123 failed to respond
原因： JDBC client端和server端對 http connection , header `keep-alive` 不一致。
解決：升級clickhouse-jdbc 驅動jar或者pom引入依賴版本到0.2.6 。
3）Code: 159，read timeout
原因：查詢超時導致報錯。
解決：執行某些SQL很耗時導致最后報錯讀超時，這是因為clickhouse執行單次SQL的默認最大等待時間是30s，如果有比較耗時的SQL， 可以通過將JdbcURL的socket_timeout參數值設置的大一點來解決這個問題（注意這個參數的時間單位是毫秒，默認是30000）。
4）Code 62，Max query size exceeded
原因：Select語句中使用in方式查詢報錯。
解決：
這其實是因為查詢語句特別的大造成的，而默認的max_query_size最大是256 KiB。打開/etc/clickhouse-server/users.xml（只配置了一些常用的用戶）。max_query_size這種配置，就需要在profiles部分中配置修改。
注意這里的單位是bytes(字節),我這里設置了102410241024=1,073,741,824,就解決問題了。如果是sql創建的用戶，需要通過sql修改配額，修改方式參考https://www.cnblogs.com/MrYang-11-GetKnow/p/15896355.html。
5）Code: 168，AST is too big，Maximum: 50000
原因：AST太大了。
解決：
在users.xml配置文件中添加相應配置，或者通過sql修改，具體步驟參照修改權限文檔即可。
<max_ast_elements>10000000</max_ast_elements> <max_expanded_ast_elements>10000000</max_expanded_ast_elements>
6）Code: 221，db::exception: no interserver io endpoint named…
復制副本數據時報錯導致無法同步數據，直接在err.log日志文件看到的報錯是：auto DB::StorageReplicatedMergeTree::processQueueEntry(ReplicatedMergeTreeQueue::SelectedEntryPtr)::(anonymous class)::operator()(DB::StorageReplicatedMergeTree::LogEntryPtr &) const: Poco::Exception. Code: 1000, e.code() = 111, Connection refused
原因：沒有指定interserver_http_host參數，clickhouse配置文件中關於對這個參數的描述我翻譯過來大概意思就是這個參數是其他副本用於請求此服務器的主機名；如果未指定，則與“hostname-f”命令類似確定，此設置可用於將復制切換到另一個網絡接口（服務器可以通過多個地址連接到多個網絡）。不指定該參數的話，服務器就會試圖連接到自己，而對應的端口號未提供服務時就會報Connection refused這樣的錯誤了。
7）Code: 253， Replica /clickhouse/tables/XXX/XXX/replicas/dba07 already exists
原因：建立副本表（ReplicatedMergeTree）的時候，如果數據庫的引擎是Atomic，則在刪除表之后馬上重建會報這個錯。刪除的時候clickhouse是通過異步線程清除掉zookeeper上的數據的，立馬新建的話可能異步線程還沒開始執行，如果不想做其他操作的話，等一會再執行創建語句就不會報這個錯了，也可以通過指定如下參數設置清除zookeeper上數據操作的延遲時間：
<!-- 修改參數 database_atomic_delay_before_drop_table_sec = 0 ，解決刪除副本表立馬重建會報錯的問題 --> <database_atomic_delay_before_drop_table_sec>0</database_atomic_delay_before_drop_table_sec>
8）Code: 252
Code: 252, e.displayText() = DB::Exception: Too many partitions ,for single INSERT block (more than 100).
原因：單次插入的數據分區太多了，超過默認配置的 100 個了。
解決：
1.合理設置分區字段 。
2.修改這個 max_partitions_per_insert_block 參數，調大這個值。
3.避免同一批次寫入包含太多分區的數據。
9）Code: 359
Code: 359,e.displayText()=DB::Exception: Table or Partition in xxx was not dropped.
Reason:
1. Size (158.40 GB) is greater than max_[table/partition]_size_to_drop (50.00 GB)
2. File '/data/clickhouse/clickhouse-server/flags/force_drop_table' intended to force DROP doesn't exist
原因：
1） 可以看到，刪除的數據實際大小已經超過了配置的大小。
2） 說明是可以跳過配置檢查，進行強制刪除的，但是沒找到這個文件 /data/clickhouse/clickhouse-server/flags/force_drop_table，所以不能跳過檢查，也就是不能強制刪除。
解決：
根據錯誤提示2 ，在所在的節點執行：
sudo touch '/data/clickhouse/clickhouse-server/flags/force_drop_table' && sudo chmod 666 '/data/clickhouse/clickhouse-server/flags/force_drop_table'
然后再次執行 刪除操作就可以了。需要注意的是，這個標識文件有效期只有一次，執行刪除完畢之后，這個文件就會消失。
10）Code: 117
Code: 117, e.displayText() = DB::Exception: Unexpected NULL value of not Nullable type String (version 20.8.3.18)
原因：因為null值導致的,hive底層存儲null值是用\N表示,而clickhouse處理null值的方式不一致,因為需要在建表時特殊說明。
解決：參照處理null值文檔
11）Code: 62
ERROR ApplicationMaster: User class threw exception: ru.yandex.clickhouse.except.ClickHouseException: ClickHouse exception, code: 62, host: 127.0.0.1, port: 8123; Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 1432 (end of query): . Expected one of: ENGINE, storage definition (version 20.8.3.18)ru.yandex.clickhouse.except.ClickHouseException: ClickHouse exception, code: 62, host: 127.0.0.1, port: 8123; Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 1432 (end of query): . Expected one of: ENGINE, storage definition (version 20.8.3.18)
原因：表不存在
解決：創建相關表
12）Code: 241
Code: 241. DB::Exception: Received from localhost:9000. DB::Exception: Memory limit (for query) exceeded: would use 9.31 GiB (attempt to allocate chunk of 4223048 bytes), maximum: 9.31 GiB: While executing MergeTreeThread: While executing CreatingSetsTransform.
原因：內存使用超出限制,默認的最大限制是10G。
解決：sql設置單次查詢內存或者設置用戶配額（sql設置或者users.xml設置調整max_memory_usage = 20000000000000）
13）Code: 202
ClickHouse exception, code: 202, host: xxxxx, port: 8123; Code: 202, e.displayText() = DB::Exception: Too many simultaneous queries. Maximum: 100
原因：最大並發為100。
解決：修改config.xml文件:<max_concurrent_queries>100</max_concurrent_queries>。
14）Code: 252
ru.yandex.clickhouse.except.ClickHouseException: ClickHouse exception, code: 252, host: xxxx, port: 8123; Code: 252, e.displayText() = DB::Exception: Too many parts (308). Merges are processing significantly slower than inserts. (version 20.8.3.18)
原因：插入的速度太快了,clickhouse合並的速度太慢。
解決：調小並行度,減少批次處理的條數。
15）Code: 159
Code: 159. DB::Exception: Received from localhost:9000. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000002 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 3 unfinished hosts (0 of them are currently active), they are going to execute the query in background.
原因：ck端口是否寫錯
解決：檢查metrika.xml文件中ck端口