基本數(shù)據(jù)類型：
| 數(shù)據(jù)類型 | 長度 | 例子 |
|---|---|---|
| TINYINT | 1byte有符號整數(shù) | 20 |
| SMALLINT | 2byte有符號整數(shù) | 20 |
| INT | 4byte有符號整數(shù) | 20 |
| BIGINT | 8byte有符號整數(shù) | 20 |
| BOOLEAN | 布爾類型，true或者false | TRUE |
| FLOAT | 單精度浮點數(shù) | 3.14159 |
| DOUBLE | 雙精度浮點數(shù) | 3.14159 |
| STRING | 字符系列.可以指定字符集。可使用單引號或者雙引號 | 'now is the time',"for all good time" |
| TIMESTAMP(v0.8.0+) | 整數(shù)，浮點數(shù)或者字符串 | 1327882394(Unix 新紀元秒),1327882394.123456789（Unix新紀元并跟隨有納秒數(shù)）和"2012-02-03 12:34:56.123456789"(JDBC所兼容的java.sql.Timestamp時間格式 |
| BINARY(v0.8.0+) | 字節(jié)數(shù)組 |
集合數(shù)據(jù)類型：
| 數(shù)據(jù)類型 | 描述 | 字母語法示例 |
|---|---|---|
| STRUCT | 和C語言中的struct或者"對象"類似，都可以通過"點"符號訪問元素內(nèi)容。例如,如果某個列的數(shù)據(jù)類型是STRUCT{first STRING,last STRING},那么第1個元素可以通過 字段名.first 來引用 | struct('John','Doe') |
| MAP | MAP是一組鍵-值對元素集合，使用數(shù)組表示法(例如['key'])可以訪問元素。例如，如果某個列的數(shù)據(jù)類型是MAP，其中鍵->值對是 'first'->'John'和'last'->'Doe',那么可以通過 字段名['last']獲取最后1個元素 | map('first','John','last','Doe') |
| ARRAY | 數(shù)組是一組具有相同類型和名稱的變量的集合。這些變量稱為數(shù)組的元素，每個數(shù)組元素都有一個編號，編號從零開始。例如，數(shù)組值為['John','Doe'],那么第2個元素可以通過 數(shù)組名[1]進行引用 | Array('John','Doe') |
大多數(shù)的關系型數(shù)據(jù)庫如Oracle,SQL Server,MySQL并不支持這些集合數(shù)據(jù)類型，因為使用它們會趨向于破壞標準格式。例如，在傳統(tǒng)數(shù)據(jù)模型中，structs可能需要多個不同的表拼裝而成，表間需要適當?shù)厥褂猛怄I來進行連接。
破壞標準格式所帶來的一個實際問題是會增大數(shù)據(jù)冗余的風險，進而導致消耗不必要的磁盤空間，還有可能造成數(shù)據(jù)不一致，因為當數(shù)據(jù)
發(fā)生改變時冗余的拷貝數(shù)據(jù)可能無法進行相應的同步。
然而，在大數(shù)據(jù)系統(tǒng)中，不遵循標準格式的一個好處是可以提供更高吞吐量的數(shù)據(jù)。當處理的數(shù)據(jù)的量級是T或者P時，以最少的"頭部尋址"來從磁盤上掃描數(shù)據(jù)是非常不要的。按數(shù)據(jù)集進行封裝的話可以通過減少尋址次數(shù)來提供查詢的速度。而如果根據(jù)外鍵關系關聯(lián)的話則需要磁盤間的尋址操作，這樣會有非常高的性能消耗。
我們以創(chuàng)建一張表的數(shù)據(jù)演示一下如何使用這些數(shù)據(jù)類型：
CREATE TABLE employees(
name STRING,
salary FLOAT,
subordinates ARRAY<STRING>,
deductions MAP<STRING,FLOAT>,
address STRUCT<street:STRING,city:STRING,state:STRING,zip:INT
);
