ClickHouse入門實踐--數據字典
數據字典
數據字典是ClickHouse提供的一種很是簡單、實用的存儲媒介，它以鍵值和屬性映射的形式定義數據。字典中的數據會主動或者被動（數據是在ClickHouse啓動時主動加載仍是在首次查詢時惰性加載由參數設置決定）加載到內存，並支持動態更新。因爲字典數據常駐內存的特性，因此它很是適合保存常量或常用的維度表數據，以免沒必要要的JOIN查詢。數據字典分爲內置與擴展兩種形式，顧名思義，內置字典是ClickHouse默認自帶的字典，而外部擴展字典是用戶經過自定義配置實現的字典。在正常狀況下，字典中的數據只能經過字典函數訪問（ClickHouse特別設置了一類字典函數，專門用於字典數據的取用）。可是也有一種例外，那就是使用特殊的字典表引擎。在字典表引擎的幫助下，能夠將數據字典掛載到一張代理的數據表下，從而實現數據表與字典數據的JOIN查詢。關於字典表引擎的更多細節與使用方法將會在後續章節着重介紹。mysql
內置字典sql
ClickHouse目前只有一種內置字典——Yandex.Metrica字典。從名稱上能夠看出，這是用在ClickHouse自家產品上的字典，而它的設計意圖是快速存取geo地理數據。但較爲遺憾的是，因爲版權緣由Yandex並無將geo地理數據開放出來。這意味着ClickHouse目前的內置字典，只是提供了字典的定義機制和取數函數，而沒有內置任何現成的數據。因此內置字典的現狀較爲尷尬，須要遵守它的字典規範自行導入數據。數據庫
外部擴展字典
外部擴展字典是以插件形式註冊到ClickHouse中的，由用戶自行定義數據模式及數據來源。目前擴展字典支持7種類型的內存佈局和4類數據來源。相比內容十分有限的內置字典，擴展字典纔是更加經常使用的功能。數組
準備字典數據緩存
在接下來的篇幅中，會逐個介紹每種擴展字典的使用方法，包括它們的配置形式、數據結構及建立方法，可是在此以前還須要進行一些準備工做。爲了便於演示，此處事先準備了三份測試數據，它們均使用CSV格式。其中，第一份是企業組織數據，它將用於flat、hashed、cache、complex_key_hashed和complex_key_cache字典的演示場景。這份數據擁有id、code和name三個字段，數據格式以下所示：數據結構
第二份是銷售數據，它將用於range_hashed字典的演示場景。這份數據擁有id、start、end和price四個字段，數據格式以下所示：運維
最後一份是asn數據，它將用於演示ip_trie字典的場景。這份數據擁有ip、asn和country三個字段，數據格式以下所示：函數
擴展字典配置文件的元素組成佈局
擴展字典的配置文件由config.xml文件中的dictionaries_config配置項指定：post
在默認的狀況下，ClickHouse會自動識別並加載/etc/clickhouse-server目錄下全部以_dictionary.xml結尾的配置文件。同時ClickHouse也可以動態感知到此目錄下配置文件的各類變化，並支持不停機在線更新配置文件。在單個字典配置文件內能夠定義多個字典，其中每個字典由一組dictionary元素定義。在dictionary元素之下又分爲5個子元素，均爲必填項，它們完整的配置結構以下所示：
在上述結構中，主要配置的含義以下。
name：字典的名稱，用於肯定字典的惟一標識，必須全局惟一，多個字典之間不容許重複。
structure：字典的數據結構。
layout：字典的類型，它決定了數據在內存中以何種結構組織和存儲。目前擴展字典共擁有7種類型。
source：字典的數據源，它決定了字典中數據從何處加載。目前擴展字典共擁有文件、數據庫和其餘三類數據來源。
lifetime：字典的更新時間，擴展字典支持數據在線更新。
擴展字典的數據結構
擴展字典的數據結構由structure元素定義，由鍵值key和屬性attribute兩部分組成，它們分別描述字典的數據標識和字段屬性。structure的完整形式以下所示（在後面的查詢過程當中都會經過這些字段來訪問字典中的數據）：
接下來具體介紹key和attribute的含義。
key
key用於定義字典的鍵值，每一個字典必須包含1個鍵值key字段，用於定位數據，相似數據庫的表主鍵。鍵值key分爲數值型和複合型兩類。（1）數值型：數值型key由UInt64整型定義，支持flat、hashed、range_hashed和cache類型的字典（擴展字典類型會在後面介紹），它的定義方法以下所示。
（2）複合型：複合型key使用Tuple元組定義，能夠由1到多個字段組成，相似數據庫中的複合主鍵。它僅支持complex_key_hashed、complex_key_cache和ip_trie類型的字典。其定義方法以下所示。
attribute
attribute用於定義字典的屬性字段，字典能夠擁有1到多個屬性字段。它的完整定義方法以下所示：
在attribute元素下共有7個配置項，其中name、type和null_value爲必填項。這些配置項的詳細說明如表所示。
擴展字典的類型
擴展字典的類型使用layout元素定義，目前共有7種類型。一個字典的類型，既決定了其數據在內存中的存儲結構，也決定了該字典支持的key鍵類型。根據key鍵類型的不一樣，能夠將它們劃分爲兩類：一類是以flat、hashed、range_hashed和cache組成的單數值key類型，由於它們均使用單個數值型的id；另外一類則是由complex_key_hashed、complex_key_cache和ip_trie組成的複合key類型。complex_key_hashed與complex_key_cache字典在功能方面與hashed和cache並沒有二致，只是單純地將數值型key替換成了複合型key而已。
接下來會結合已準備好的測試數據，逐一介紹7種字典的完整配置方法。經過這個過程，能夠領略到不一樣類型字典的特色以及它們的使用方法。
flat
flat字典是全部類型中性能最高的字典類型，它只能使用UInt64數值型key。顧名思義，flat字典的數據在內存中使用數組結構保存，數組的初始大小爲1024，上限爲500000，這意味着它最多隻能保存500000行數據。若是在建立字典時數據量超出其上限，那麼字典會建立失敗。代碼所示是經過手動建立的flat字典配置文件。
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_flat_dict</name>
<source>
<file>
<path>/chbase/data/dictionaries/organization.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<flat/>
</layout>
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>code</name>
<type>String</type>
<null_value></null_value>
</attribute>
<attribute>
<name>name</name>
<type>String</type>
<null_value></null_value>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
在上述的配置中，source數據源是CSV格式的文件，structure數據結構與其對應。將配置文件複製到ClickHouse服務節點的/etc/clickhouse-server目錄後，即完成了對該字典的建立過程。查驗system.dictionaries系統表後，可以看到flat字典已經建立成功。
SELECT name,type,key,attribute.names,attribute.types FROM system.dictionaries;
hashed
hashed字典一樣只可以使用UInt64數值型key，但與flat字典不一樣的是，hashed字典的數據在內存中經過散列結構保存，且沒有存儲上限的制約。
配置文件以下：
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_hashed_dict</name>
<source>
<file>
<path>/chbase/data/dictionaries/organization.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<hashed/>
</layout>
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>code</name>
<type>String</type>
<null_value></null_value>
</attribute>
<attribute>
<name>name</name>
<type>String</type>
<null_value></null_value>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
一樣將配置文件複製到ClickHouse服務節點的/etc/clickhouse-server目錄後，即完成了對該字典的建立過程。
range_hashed
range_hashed字典能夠看做hashed字典的變種，它在原有功能的基礎上增長了指定時間區間的特性，數據會以散列結構存儲並按照時間排序。時間區間經過range_min和range_max元素指定，所指定的字段必須是Date或者DateTime類型。如今仿照hashed字典的配置，建立一個名爲test_range_hashed_dictionary.xml的配置文件，將layout改成range_hashed並增長range_min和range_max元素。
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_range_hashed_dict</name>
<source>
<file>
<path>/chbase/data/dictionaries/sales.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<range_hashed/>
</layout>
<structure>
<id>
<name>id</name>
</id>
<range_min>
<name>start</name>
</range_min>
<range_max>
<name>end</name>
</range_max>
<attribute>
<name>price</name>
<type>Float32</type>
<null_value></null_value>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
在上述的配置中，使用了一份銷售數據，數據中的start和end字段分別與range_min和range_max對應。將配置文件複製到ClickHouse服務節點的/etc/clickhouse-server目錄後，即完成了對該字典的建立過程。查驗system.dictionaries系統表後，可以看到range_hashed字典已經建立成功：
cache
cache字典只可以使用UInt64數值型key，它的字典數據在內存中會經過固定長度的向量數組保存。定長的向量數組又稱cells，它的數組長度由size_in_cells指定。而size_in_cells的取值大小必須是2的整數倍，如若不是，則會自動向上取爲2的倍數的整數。
cache字典的取數邏輯與其餘字典有所不一樣，它並不會一次性將全部數據載入內存。當從cache字典中獲取數據的時候，它首先會在cells數組中檢查該數據是否已被緩存。若是數據沒有被緩存，它纔會從源頭加載數據並緩存到cells中。因此cache字典是性能最不穩定的字典，由於它的性能優劣徹底取決於緩存的命中率（緩存命中率=命中次數/查詢次數），若是沒法作到99%或者更高的緩存命中率，則最好不要使用此類型。代碼所示是仿照hashed建立的cache字典配置文件。
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_cache_dict</name>
<source>
<executable>
<command>cat /chbase/data/dictionaries/organization.csv</command>
<format>CSV</format>
</executable>
</source>
<layout>
<cache>
<size_in_cells>10000</size_in_cells>
</cache>
</layout>
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>code</name>
<type>String</type>
<null_value></null_value>
</attribute>
<attribute>
<name>name</name>
<type>String</type>
<null_value></null_value>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
在上述配置中，layout被聲明爲cache並將緩存大小size_in_cells設置爲10000。關於cells的取值能夠根據實際狀況考慮，在內存寬裕的狀況下設置成1000000000也是可行的。還有一點須要注意，若是cache字典使用本地文件做爲數據源，則必須使用executable的形式設置。
complex_key_hashed
complex_key_hashed字典在功能方面與hashed字典徹底相同，只是將單個數值型key替換成了複合型。代碼清單所示是仿照hashed字典進行配置後，將layout改成complex_key_hashed並替換key類型的示例。
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_complex_key_hashed_dict</name>
<source>
<file>
<path>/chbase/data/dictionaries/organization.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<complex_key_hashed/>
</layout>
<structure>
<key>
<attribute>
<name>id</name>
<type>UInt64</type>
</attribute>
<attribute>
<name>code</name>
<type>String</type>
</attribute>
</key>
<attribute>
<name>name</name>
<type>String</type>
<null_value></null_value>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
將配置文件複製到ClickHouse服務節點的/etc/clickhouse-server目錄後，即完成了對該字典的建立過程。
complex_key_cache
complex_key_cache字典一樣與cache字典的特性徹底相同，只是將單個數值型key替換成了複合型。如今仿照cache字典進行配置，將layout改成complex_key_cache並替換key類型
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_complex_key_cache_dict</name>
<source>
<executable>
<command>cat /chbase/data/dictionaries/organization.csv</command>
<format>CSV</format>
</executable>
</source>
<layout>
<complex_key_cache>
<size_in_cells>10000</size_in_cells>
</complex_key_cache>
</layout>
<structure>
<key>
<attribute>
<name>id</name>
<type>UInt64</type>
</attribute>
<attribute>
<name>code</name>
<type>String</type>
</attribute>
</key>
<attribute>
<name>name</name>
<type>String</type>
<null_value></null_value>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
將配置文件複製到ClickHouse服務節點的/etc/clickhouse-server目錄後，即完成了對該字典的建立過程。
ip_trie
雖然同爲複合型key的字典，但ip_trie字典卻較爲特殊，由於它只能指定單個String類型的字段，用於指代IP前綴。ip_trie字典的數據在內存中使用trie樹結構保存，且專門用於IP前綴查詢的場景，例如經過IP前綴查詢對應的ASN信息。
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_ip_trie_dict</name>
<source>
<file>
<path>/chbase/data/dictionaries/asn.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<ip_trie/>
</layout>
<structure>
<key>
<attribute>
<name>prefix</name>
<type>String</type>
</attribute>
</key>
<attribute>
<name>asn</name>
<type>String</type>
<null_value></null_value>
</attribute>
<attribute>
<name>country</name>
<type>String</type>
<null_value></null_value>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
經過上述介紹，讀者已經知道了7種類型字典的建立方法。在這些字典中，flat、hashed和range_hashed依次擁有最高的性能，而cache性能最不穩定。最後再總結一下這些字典各自的特色
擴展字典的數據源
數據源使用source元素定義，它指定了字典的數據從何而來。現階段，擴展字典支持3大類共計9種數據源，接下來會以更加體系化的方式逐一介紹它們。
文件類型
文件能夠細分爲本地文件、可執行文件和遠程文件三類，它們是最易使用且最爲直接的數據源，很是適合在靜態數據這類場合中使用。
本地文件
本地文件使用file元素定義。其中，path表示數據文件的絕對路徑，而format表示數據格式，例如CSV或者TabSeparated等。它的完整配置以下所示。
可執行文件
可執行文件數據源屬於本地文件的變種，它須要經過cat命令訪問數據文件。對於cache和complex_key_cache類型的字典，必須使用此類型的文件數據源。可執行文件使用executable元素定義。其中，command表示數據文件的絕對路徑，format表示數據格式，例如CSV或者TabSeparated等。它的完整配置以下所示。
遠程文件
遠程文件與可執行文件相似，只是它將cat命令替換成了post請求，支持HTTP與HTTPS協議。遠程文件使用http元素定義。其中，url表示遠程數據的訪問地址，format表示數據格式，例如CSV或者TabSeparated。它的完整配置以下所示。
數據庫類型
相比文件類型，數據庫類型的數據源更適合在正式的生產環境中使用。目前擴展字典支持MySQL、ClickHouse自己及MongoDB三種數據庫。接下來會分別介紹它們的建立方法。對於MySQL和MongoDB數據庫環境的安裝，因爲篇幅緣由此處再也不贅述，而相關的SQL腳本能夠在本書附帶的源碼站點中下載。
MySQL
MySQL數據源支持從指定的數據庫中提取數據，做爲其字典的數據來源。首先，須要準備源頭數據，執行下面的語句在MySQL中建立測試表：
CREATE TABLE t_organization (
id int(11) NOT NULL AUTO_INCREMENT,
code varchar(40) DEFAULT NULL,
name varchar(60) DEFAULT NULL,
updatetime datetime DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE = InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET =utf8;
接着，寫入測試數據：
INSERT INTO t_organization (code,name,updatetime)
values('a0001','研發部',now()),('a0002','產品部',NOW());
完成上述準備以後，就能夠配置MySQL數據源的字典了。如今仿照flat字典進行配置，建立一個名爲test_mysql_dictionary.xml的配置文件，將source替換成MySQL數據源：
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_mysql_dict</name>
<source>
<mysql>
<port>3306</port>
<user>root</user>
<password>chen2895161</password>
<replica>
<host>192.168.59.133</host>
<priority>1</priority>
</replica>
<db>gmall</db>
<table>t_organization</table>
<!--
<where>id=1</where>
-->
<invalidate_query>select updatetime from t_organization where id = 8</invalidate_query>
</mysql>
</source>
<layout>
<flat/>
</layout>
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>code</name>
<type>String</type>
<null_value></null_value>
</attribute>
<attribute>
<name>name</name>
<type>String</type>
<null_value></null_value>
</attribute>
<attribute>
<name>updatetime</name>
<type>DateTime</type>
<null_value></null_value>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
其中，各配置項的含義分別以下。
❑ port：數據庫端口。
❑ user：數據庫用戶名。
❑ password：數據庫密碼。
❑ replica：數據庫host地址，支持MySQL集羣。
❑ db:database數據庫。
❑ table：字典對應的數據表。
❑ where：查詢table時的過濾條件，非必填項。
❑ invalidate_query：指定一條SQL語句，用於在數據更新時判斷是否須要更新，非必填項。
ClickHouse
擴展字典支持將ClickHouse數據表做爲數據來源，這是一種比較有意思的設計。在配置以前一樣須要準備數據源的測試數據，執行下面的語句在ClickHouse中建立測試表並寫入測試數據：
CREATE TABLE t_organization (
ID UInt64,
Code String,
Name String,
UpdateTime DateTime
) ENGINE = TinyLog;
INSERT INTO t_organization values (1,'a0001','研發部',now()), (2,'a0002','產品部',now()), (3,'a0003','數據部',now()), (4,'a0004','測試部',now()), (5,'a0005','運維部',now()), (6,'a0006','規劃部',now()), (7,'a0007','市場部',now());
ClickHouse數據源的配置與MySQL數據源極爲類似，因此咱們能夠仿照MySQL數據源的字典配置，建立一個名爲test_ch_dictionary.xml的配置文件，將source替換成ClickHouse數據源：
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_ch_dict</name>
<source>
<clickhouse>
<host>192.168.59.136</host>
<port>9000</port>
<user>default</user>
<password></password>
<db>default</db>
<table>t_organization</table>
<!--
<where>id=10</where>
-->
<invalidate_query>SELECT UpdateTime FROM t_organization WHERE ID = 1</invalidate_query>
</clickhouse>
</source>
<layout>
<flat/>
</layout>
<!--大小寫敏感,須要與數據表字段對應-->
<structure>
<id>
<name>ID</name>
</id>
<attribute>
<name>Code</name>
<type>String</type>
<null_value></null_value>
</attribute>
<attribute>
<name>Name</name>
<type>String</type>
<null_value></null_value>
</attribute>
<attribute>
<name>UpdateTime</name>
<type>DateTime</type>
<null_value></null_value>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
其中，各配置項的含義分別以下。
❑ host：數據庫host地址。
❑ port：數據庫端口。
❑ user：數據庫用戶名。
❑ password：數據庫密碼。
❑ db:database數據庫。
❑ table：字典對應的數據表。
❑ where：查詢table時的過濾條件，非必填項。
❑ invalidate_query：指定一條SQL語句，用於在數據更新時判斷是否須要更新，非必填項。
擴展字典的數據更新策略
擴展字典支持數據的在線更新，更新後無須重啓服務。字典數據的更新頻率由配置文件中的lifetime元素指定，單位爲秒：
其中，min與max分別指定了更新間隔的上下限。ClickHouse會在這個時間區間內隨機觸發更新動做，這樣可以有效錯開更新時間，避免全部字典在同一時間內爆發性的更新。當min和max都是0的時候，將禁用字典更新。對於cache字典而言，lifetime還表明了它的緩存失效時間。
字典內部擁有版本的概念，在數據更新的過程當中，舊版本的字典將持續提供服務，只有當更新徹底成功以後，新版本的字典纔會替代舊版本。因此更新操做或者更新時發生的異常，並不會對字典的使用產生任何影響。
不一樣類型的字典數據源，更新機制也稍有差別。整體來講，擴展字典目前並不支持增量更新。但部分數據源可以依照標識判斷，只有在源數據發生實質變化後才實施更新動做。這個判斷源數據是否被修改的標識，在字典內部稱爲previous，它保存了一個用於比對的值。ClickHouse的後臺進程每隔5秒便會啓動一次數據刷新的判斷，依次對比每一個數據字典中先後兩次previous的值是否相同。若相同，則表明無須更新數據；若不一樣且知足更新頻率，則表明須要更新數據。而對於previous值的獲取方式，不一樣的數據源有不一樣的實現邏輯，下面詳細介紹。
文件數據源
對於文件類型的數據源，它的previous值來自系統文件的修改時間，這和Linux系統中的stat查詢命令相似：
當先後兩次previous的值不相同時，纔會觸發數據更新。
MySQL(InnoDB)、ClickHouse和ODBC
對於MySQL（InnoDB引擎）、ClickHouse和ODBC數據源，它們的previous值來源於invalidate_query中定義的SQL語句。例如在下面的示例中，若是先後兩次的updatetime值不相同，則會斷定源數據發生了變化，字典須要更新。
這對源表有必定的要求，它必須擁有一個支持判斷數據是否更新的字段。
MySQL(MyISAM)
若是數據源是MySQL的MyISAM表引擎，則它的previous值要簡單得多。由於在MySQL中，使用MyISAM表引擎的數據表支持經過SHOW TABLE STATUS命令查詢修改時間。例如在MySQL中執行下面的語句，就可以查詢到數據表的Update_time值：
SHOW TABLE STATUS WHERE NAME = 't_organization';
因此，若是先後兩次Update_time的值不相同，則會斷定源數據發生了變化，字典須要更新。
其餘數據源
除了上面描述的數據源以外，其餘數據源目前沒法依照標識判斷是否跳過更新。因此不管數據是否發生實質性更改，只要知足當前lifetime的時間要求，它們都會執行更新動做。相比以前介紹的更新方式，其餘類型的更新效率更低。除了按照lifetime定義的時間頻率被動更新以外，數據字典也可以主動觸發更新。執行下面的語句後，將會觸發全部數據字典的更新：
SYSTEM RELOAD DICTIONARIES
也支持指定某個具體字典的更新：
SYSTEM RELOAD DICTIONARIE [DICT_NAME]
擴展字典的基本操做
至此，咱們已經在ClickHouse中建立了10種不一樣類型的擴展字典。接下來將目光聚焦到字典的基本操做上，包括對字典元數據和數據的查詢，以及藉助字典表引擎訪問數據。
元數據查詢
經過system.dictionaries系統表，能夠查詢擴展字典的元數據信息。例如執行下面的語句就能夠看到目前全部已經建立的擴展字典的名稱、類型和字段等信息：
SELECT name,type,key,attribute.names,attribute.types FROM system.dictionaries;
在system.dictionaries系統表內，其主要字段的含義分別以下。
❑ name：字典的名稱，在使用字典函數時須要經過字典名稱訪問數據。
❑ type：字典所屬類型。
❑ key：字典的key值，數據經過key值定位。
❑ attribute.names：屬性名稱，以數組形式保存。
❑ attribute.types：屬性類型，以數組形式保存，其順序與attribute.names相同。
❑ bytes_allocated：已載入數據在內存中佔用的字節數。
❑ query_count：字典被查詢的次數。
❑ hit_rate：字典數據查詢的命中率。
❑ element_count：已載入數據的行數。
❑ load_factor：數據的加載率。
❑ source：數據源信息。
❑ last_exception：異常信息，須要重點關注。若是字典在加載過程當中產生異常，那麼異常信息會寫入此字段。last_exception是獲取字典調試信息的主要方式。
數據查詢
在正常狀況下，字典數據只能經過字典函數獲取，例以下面的語句就使用到了dictGet('dict_name', 'attr_name', key)函數：
SELECT dictGet('test_flat_dict','name',toUInt64(2));
若是字典使用了複合型key，則須要使用元組做爲參數傳入：
SELECT dictGet('test_ip_trie_dict','asn',tuple(IPv4StringToNum('82.118.230.0')));
除了dictGet函數以外，ClickHouse還提供了一系列以dictGet爲前綴的字典函數，具體以下所示。
❑ 獲取整型數據的函數：dictGetUInt八、dictGetUInt1六、dictGetUInt3二、dictGetUInt6四、dictGetInt八、dictGetInt1六、dictGetInt3二、dictGetInt64。
❑ 獲取浮點數據的函數：dictGetFloat3二、dictGetFloat64。
❑ 獲取日期數據的函數：dictGetDate、dictGetDateTime。
❑ 獲取字符串數據的函數：dictGetString、dictGetUUID。這些函數的使用方法與dictGet大同小異，此處再也不贅述。
字典表
了經過字典函數讀取數據以外，ClickHouse還提供了另一種藉助字典表的形式來讀取數據。字典表是使用Dictionary表引擎的數據表，好比下面的例子：
CREATE TABLE tb_test_flat_dict (
id UInt64,
code String,
name String
) ENGINE = Dictionary(test_flat_dict);
經過這張表，就能查詢到字典中的數據。
使用DDL查詢建立字典
從19.17.4.11版本開始，ClickHouse開始支持使用DDL查詢建立字典，例如：
能夠看到，其配置參數與以前並沒有差別，只是轉成了DDL的形式。
- 1. ClickHouse入門實踐--MergeTree原理解析
- 2. ClickHouse入門實踐--MergeTree表引擎
- 3. clickhouse函數數組實踐
- 4. 數據結構之字典入門
- 5. Clickhouse 入門
- 6. clickhouse入門使用
- 7. HIVE數據導入CLICKHOUSE
- 8. python入門—字典
- 9. 數據庫(MySQL) 入門實踐
- 10. 入門實踐，Python數據分析
- 更多相關文章...
- • Swift 字典 - Swift 教程
- • Thymeleaf項目實踐 - Thymeleaf 教程
- • TiDB 在摩拜單車在線數據業務的應用和實踐
- • YAML 入門教程
-
每一个你不满意的现在，都有一个你没有努力的曾经。