tuningConfig 的配置是可選的,若是你不在這裏對這個參數進行配置的話,Druid 將會使用默認的配置來替代。segmentfault
字段(Field) | 類型(Type) | 描述(Description) | 是否必須(Required) |
---|---|---|---|
type |
String | 索引任務類型, 老是 kafka。 | Y |
maxRowsInMemory |
Integer | 在持久化以前在內存中聚合的最大行數。該數值爲聚合以後的行數,因此它不等於原始輸入事件的行數,而是事件被聚合後的行數。 一般用來管理所需的 JVM 堆內存。 使用 maxRowsInMemory * (2 + maxPendingPersists) 來當作索引任務的最大堆內存。一般用戶不須要設置這個值,可是也須要根據數據的特色來決定,若是行的字節數較短,用戶可能不想在內存中存儲一百萬行,應該設置這個值。 | N(默認=1000000) |
maxBytesInMemory |
Long | 在持久化以前在內存中聚合的最大字節數。這是基於對內存使用量的粗略估計,而不是實際使用量。一般這是在內部計算的,用戶不須要設置它。 索引任務的最大內存使用量是 maxRowsInMemory * (2 + maxPendingPersists) | N(默認=最大JVM內存的 1/6) |
maxRowsPerSegment |
Integer | 聚合到一個段中的行數,該數值爲聚合後的數值。 當 maxRowsPerSegment 或者 maxTotalRows 有一個值命中的時候,則觸發 handoff(數據存盤後傳到深度存儲), 該動做也會按照每 intermediateHandoffPeriod 時間間隔發生一次。 | N(默認=5000000) |
maxTotalRows |
Long | 全部段的聚合後的行數,該值爲聚合後的行數。當 maxRowsPerSegment 或者 maxTotalRows 有一個值命中的時候,則觸發handoff(數據落盤後傳到深度存儲), 該動做也會按照每 intermediateHandoffPeriod 時間間隔發生一次。 | N(默認=unlimited) |
intermediatePersistPeriod |
ISO8601 Period | 肯定觸發持續化存儲的週期 | N(默認= PT10M) |
maxPendingPersists |
Integer | 正在等待但啓動的持久化過程的最大數量。 若是新的持久化任務超過了此限制,則在當前運行的持久化完成以前,攝取將被阻止。索引任務的最大內存使用量是 maxRowsInMemory * (2 + maxPendingPersists) | 否(默認爲0,意味着一個持久化能夠與攝取同時運行,而沒有一個能夠進入隊列) |
indexSpec |
Object | 調整數據被如何索引。詳情能夠見 IndexSpec 頁面中的內容 | N |
indexSpecForIntermediatePersists |
定義要在索引時用於中間持久化臨時段的段存儲格式選項。這可用於禁用中間段上的維度/度量壓縮,以減小最終合併所需的內存。可是,在中間段上禁用壓縮可能會增長頁緩存的使用,而在它們被合併到發佈的最終段以前使用它們,有關可能的值。詳情能夠見 IndexSpec 頁面中的內容。 | N(默認= 與 indexSpec 相同) | |
reportParseExceptions |
Boolean | 已經丟棄(DEPRECATED)。若是爲true,則在解析期間遇到的異常即中止攝取;若是爲false,則將跳過不可解析的行和字段。將 reportParseExceptions 設置爲 true 將覆蓋maxParseExceptions 和 maxSavedParseExceptions 的現有配置,將maxParseExceptions 設置爲 0 並將 maxSavedParseExceptions 限制爲不超過1。 | N(默認=false) |
handoffConditionTimeout |
Long | 段切換(持久化)能夠等待的毫秒數(超時時間)。 該值要被設置爲大於0的數,設置爲0意味着將會一直等待不超時。 | N(默認=0) |
resetOffsetAutomatically |
Boolean | 控制當Druid須要讀取Kafka中不可用的消息時的行爲,好比當發生了 OffsetOutOfRangeException 異常時。 若是爲false,則異常將拋出,這將致使任務失敗並中止接收。若是發生這種狀況,則須要手動干預來糾正這種狀況;可能使用 重置 Supervisor API 。此模式對於生產很是有用,由於它將使您意識到攝取的問題。若是爲true,Druid將根據 useEarliestOffset 屬性的值(true 爲 earliest ,false 爲 latest )自動重置爲Kafka中可用的較早或最新偏移量。請注意,這可能致使數據在您不知情的狀況下被丟棄 (若是useEarliestOffset 爲 false )或 重複 (若是 useEarliestOffset 爲 true )。消息將被記錄下來,以標識已發生重置,但攝取將繼續。這種模式對於非生產環境很是有用,由於它將使Druid嘗試自動從問題中恢復,即便這些問題會致使數據被安靜刪除或重複。該特性與Kafka的 auto.offset.reset 消費者屬性很類似 |
N(默認=false) |
workerThreads |
Integer | supervisor 用於爲工做任務處理 請求/相應(requests/responses)異步操做的線程數。 | N(默認=min(10, taskCount)) |
chatThreads |
Integer | 與索引任務的會話線程數。 | N(默認=10, taskCount * replicas)) |
chatRetries |
Integer | 在任務沒有響應以前,將重試對索引任務的HTTP請求的次數 | N(默認=8) |
httpTimeout |
ISO8601 Period | 索引任務的 HTTP 響應超時的時間。 | N(默認=PT10S) |
shutdownTimeout |
ISO8601 Period | supervisor 嘗試無端障的停掉一個任務的超時時間。 | N(默認=PT80S) |
offsetFetchPeriod |
ISO8601 Period | supervisor 查詢 Kafka 和索引任務以獲取當前偏移和計算滯後的頻率。 | N(默認=PT30S,min == PT5S) |
segmentWriteOutMediumFactory |
Object | 建立段時要使用的段寫入介質。更多信息見下文。 | N (默認不指定,使用來源於 druid.peon.defaultSegmentWriteOutMediumFactory.type 的值) |
intermediateHandoffPeriod |
ISO8601 Period | 段發生切換的頻率。當 maxRowsPerSegment 或者 maxTotalRows 有一個值命中的時候,則觸發handoff(數據存盤後傳到深度存儲), 該動做也會按照每 intermediateHandoffPeriod 時間間隔發生一次。 |
N(默認=P2147483647D) |
logParseExceptions |
Boolean | 若是爲 true,則在發生解析異常時記錄錯誤消息,其中包含有關發生錯誤的行的信息。 | N(默認=false) |
maxParseExceptions |
Integer | 任務中止接收以前可發生的最大分析異常數。若是設置了 reportParseExceptions ,則該值會被重寫。 |
N(默認=unlimited) |
maxSavedParseExceptions |
Integer | 當出現解析異常時,Druid能夠跟蹤最新的解析異常。"maxSavedParseExceptions"決定將保存多少個異常實例。這些保存的異常將在 任務完成報告 中的任務完成後可用。若是設置了reportParseExceptions ,則該值會被重寫。 |
N(默認=0) |