1. 程式人生 > 資料庫 >《SQL訓練營——基於Presto的華為開源組建openLookeng的SQL語法》

《SQL訓練營——基於Presto的華為開源組建openLookeng的SQL語法》

##

《基於Presto的華為開源查詢元件openLookeng的SQL語法》

看這裡—>>>

0.簡介:

openLooKeng是一款開源的高效能資料虛擬化引擎,提供統一SQL介面,為大資料使用者提供極簡的資料分析體驗,讓使用者像使用“資料庫”一樣使用“大資料”。因此,openLooKeng極致效能是十分重要的一個維度,也是openLooKeng社群一直以來所追求的目標。

1.優點:

極簡資料分析體驗

統一的SQL介面訪問多種資料來源,支援跨資料中心、跨雲資料來源分析

靈活、易擴充套件

可以通過增加Connector來增加資料來源,採集變連線、資料零搬遷

高可靠

全 Active/Active 架構,業務零中斷

2. 缺點:

支援的開源資料庫介面語法開發不完備,缺少支援,功能尚待開發

3.社群貢獻:

openLooKeng喊您登記您的組織資訊嘍
Fred Li | December 8, 2020 | 社群 度量

簡介
首先感謝貢獻者在openLooKeng社群做成貢獻。

為了瞭解各位貢獻者所在的公司/學校/組織的整體貢獻情況,Infrastructure小組開發了一個度量功能,需要各位貢獻者填寫自己所在的公司資訊。

本文是指導貢獻者如何填寫個人的組織資訊。

操作步驟
Fork https://gitee.com/openlookeng/community to your Gitee.

1.on your local PC

git clone [https://gitee.com/YOUR_ID/community.openlookeng](https://gitee.com/YOUR_ID/community.openlookeng)

cd YOUR_FOLDER

git checkout -b NEW_BRANCH_NAME

vi ./om-data/data.yaml

Search your Gitee ID and then edit your profile. Then save it and quit.

git add. 

git commit

git push --set-upstream orgin NEW_BRANCH_NAME

3.Creat a PR on your Gitee.

4.Wait for PR reviewed and merged.

4.資料結構介紹

gitee_id: gitee login id
github_id: generalfuzz

companies:
  - company_name: Huawei
    organization_name: openlookeng
    end_date: '2015-10-31'
user_name: test
emails:
  - [email protected]
  - [email protected]
gitee_id(必選):gitee的login賬號名,比如https://gitee.com/zhongjun2 中的zhongjun2

github_id(可選):github的login賬號名

company_name(必選): 公司名稱,如果不填將會被列入獨立組織(independent)

organization_name(可選): 公司下面的組織名稱

end_date(可選):在這個公司的結束時間,如果不填表示當前一直在該公司,格式:YYYY-MM-DD

user_name(可選): 顯示在統計看板上面的名稱,如果不填展示gitee賬號的名稱,github_id、gitee_id等統一對外顯示成user_name

emails(可選): 使用的email資訊,比如訂閱過maillist的email,註冊gitee的email,註冊github的email

場景,如果您分時段在不同的公司,則這樣填寫companies

companies:
  - company_name: CompanyA
    organization_name: 
    end_date: '2020-10-31'
  - company_name: CompanyB
    organization_name: 
    end_date: '2099-12-31'

如果需要,可以訪問獲取更詳細的資訊。

5.動態:

開源資料虛擬化引擎openLooKeng助力CCF大資料與計算智慧大賽:

6.SQL語言特性

資料型別
openLooKeng有一組內建的資料型別,如下所述。可能通過外掛提供更多的型別。

注意

聯結器不需要支援所有的資料型別。聯結器支援的資料型別,請參見聯結器文件。

布林型別 BOOLEAN 捕獲布林值true和false。

整數型別 TINYINT 一個8位元帶符號的2補碼整數,最小值為-27,最大值為27 - 1。

SMALLINT 一個16位元帶符號的2補碼整數,最小值為-215,最大值為215 - 1。

INTEGER 一個32位元帶符號的2補碼整數,最小值為-231,最大值為231 - 1。該型別也被稱為INT。

BIGINT 一個64位元帶符號的2補碼整數,最小值為-263,最大值為263 - 1。

浮點型別 REAL 一種不精確的可變精度的32位元的資料型別,實現IEEE 754標準定義的二進位制浮點運算。

此型別也被稱為FLOAT。

例如: REAL ‘10.3’, REAL ‘10.3e0’, REAL ‘1.03e1’

DOUBLE 一種不精確的可變精度的64位元的資料型別,它實現了IEEE 754標準定義的二進位制浮點運算。

該型別也被稱為DOUBLE PRECISION。

固定精度型別 DECIMAL 固定精度的十進位制數。精度最高可達38位,但效能最高可達18位。

該型別也被稱為NUMERIC和DEC。

此資料型別有兩個引數:

precision - 表示總位數。 scale - 小數位數。Scale可選,預設為0。 型別定義示例:

DECIMAL(10,3),
> DECIMAL(20)

文字示例:DECIMAL ‘10.3’, DECIMAL ‘1234567890’, 1.1

注意

由於相容性原因,沒有顯式型別說明符的十進位制文字(例如
1.2)預設作為DOUBLE型別的值處理。但在以後的版本中也可能會有變化。此行為受以下控制:

系統屬性: parse-decimal-literals-as-double 會話屬性:
parse_decimal_literals_as_double 字串型別 VARCHAR 可變長度字元資料,最大長度可選。

該型別也被稱為STRING。請注意,STRING定義的是一個無限長的字元資料,您不能指定長度,否則它就成為VARCHAR(length)型別了。

型別定義示例:varchar, varchar(20), string

SQL語句支援簡單文字和Unicode使用:

文字字串: ‘Hello winter !’ 含預設轉義字元的Unicode字串:U&‘Hello winter \2603 !’
含自定義轉義字元的Unicode字串:U&'Hello winter #2603 !'UESCAPE ‘#’
Unicode字串以U&為字首,任何4位Unicode字元前都需要轉義符。 在上例中,\2603和#2603代表雪人符號。
對於6位的Unicode長編碼,需要在程式碼前使用一個加號。例如,您需要在笑臉表情前使用+01F600。

CHAR
固定長度字元。對於不指定長度的CHAR型別,預設長度為1。一個CHAR(x)包含x個字元。例如,將dog轉換為CHAR(7)會增加4個隱式尾部空格。在比較CHAR值時包括前導和尾部空格。因此,兩個不同長度的字元值(CHAR(x)和CHAR(y),其中x
!= y)永遠不會相等。

型別定義示例:char, char(20)

VARBINARY 可變長度二進位制資料。

注意

目前仍不支援帶長度的二進位制字元:varbinary(n)

JSON JSON數值型別,可以是JSON物件、JSON陣列、JSON數字、JSON字串、true、false或null。

日期和時間型別 另見舊時間戳和新時間戳。

DATE 日曆日期(年、月、日)

例如: DATE ‘2001-08-22’

TIME 不帶時區的時間(時、分、秒、毫秒)此型別的值將在會話時區中解析和呈現。

例如: TIME ‘01:02:03.456’

TIME WITH TIME ZONE 帶時區的時間(時、分、秒、毫秒)。此型別的值將使用該值中的時區進行呈現。

例如: TIME ‘01:02:03.456 America/Los_Angeles’

TIMESTAMP 包含日期和時間的即時時間,不包含時區。此型別的值將在會話時區中解析和呈現。

例如: TIMESTAMP ‘2001-08-22 03:04:05.321’

TIMESTAMP WITH TIME ZONE 即時時間,包括日期、時間和時區。此型別的值將使用該值中的時區進行呈現。

例如: TIMESTAMP ‘2001-08-22 03:04:05.321 America/Los_Angeles’

INTERVAL YEAR TO MONTH 年和月的跨度。

例如: INTERVAL ‘3’ MONTH

INTERVAL DAY TO SECOND 天數、小時、分鐘、秒和毫秒的跨度。

例如: INTERVAL ‘2’ DAY

結構型別 ARRAY 指定元件型別的陣列。

例如: ARRAY[1, 2, 3]

MAP 指定元件型別之間的對映。

例如: MAP(ARRAY[‘foo’, ‘bar’], ARRAY[1, 2])

ROW 由混合型別的欄位組成的結構。欄位可以是任何SQL型別。

行欄位預設不命名,但可以指定名稱。

例如: CAST(ROW(1, 2.0) AS ROW(x BIGINT, y DOUBLE))

已命名的行欄位通過欄位引用運算子.訪問。

例如: CAST(ROW(1, 2.0) AS ROW(x BIGINT, y DOUBLE)).x

已命名或未命名的行欄位通過下標運算子[]按位置訪問。位置從1開始且必須是常量。

例如: ROW(1, 2.0)[1]

網路地址 IPADDRESS 可表示IPv4地址或IPv6地址。對內為純IPv6地址。可通過IPv4-mapped IPv6 address
range (RFC
4291#section-2.5.5.2)來支援對IPv4地址的處理。在建立IPADDRESS時,IPv4地址將對映到指定的範圍。格式化IPADDRESS時,在對映範圍內的任何地址都會被格式化為IPv4地址。其他地址將使用RFC
5929中定義的規範格式格式化為IPv6地址。

例如: IPADDRESS ‘10.0.0.1’, IPADDRESS ‘2001:db8::1’

UUID UUID 此型別表示UUID(通用唯一識別符號),也稱為GUID(全域性唯一識別符號),使用RFC 4122中定義的格式。

例如: UUID ‘12151fd2-7586-11e9-8f9e-2a86e4085a59’

HyperLogLog 計算近似的非重複計數比使用HyperLogLog資料草圖進行精確計數成本低得多。 請參見 HyperLogLog
函式。

HyperLogLog HyperLogLog 草圖可高效地計算
approx_distinct()。它開始時是稀疏表示,當效率提高時,就切換到密集表示。

P4HyperLogLog P4HyperLogLog草圖類似於hyperloglog_type,但它從始至終都採用密集表示形式。

分位點摘要 QDigest
分位點摘要(qdigest)是一種摘要結構,它捕捉指定輸入集的資料的近似分佈,並且可以通過查詢從分佈中檢索近似分位點值。
qdigest的準確程度是可調的,使更精確的結果會佔用更多空間。

對於在某一分位數處屬於什麼值的查詢,可用qdigest提供近似回答。qdigest的一個有用的特性是它們是可加的,這意味著它們可以合併在一起而不損失精度。

當approx_percentile的部分結果可以重用時,qdigest就會發揮更大作用。例如,人們可能對在一週內每天讀取的第99百分位數值感興趣。
這種情況下,與其使用approx_percentile計算過去一週的資料,不如使用qdigest。qdigest可以每天儲存,並快速合併以檢索第99個百分位值。

關鍵字 SQL:2016 SQL-92

ALTER	預留	預留
AND	預留	預留
AS	預留	預留
BETWEEN	預留	預留
BY	預留	預留
CASE	預留	預留
CACHE		
CAST	預留	預留
CONSTRAINT	預留	預留
CREATE	預留	預留
CROSS	預留	預留
CUBE	預留	
CURRENT_DATE	預留	預留
CURRENT_PATH	預留	
CURRENT_ROLE	預留	預留
CURRENT_TIME	預留	預留
CURRENT_TIMESTAMP	預留	預留
CURRENT_USER	預留	
DEALLOCATE	預留	預留
DELETE	預留	預留
DESCRIBE	預留	預留
DISTINCT	預留	預留
DROP	預留	預留
ELSE	預留	預留
END	預留	預留
ESCAPE	預留	預留
EXCEPT	預留	預留
EXECUTE	預留	預留
EXISTS	預留	預留
EXTRACT	預留	預留
FALSE	預留	預留
FOR	預留	預留
FROM	預留	預留
FULL	預留	預留
GROUP	預留	預留
GROUPING	預留	
HAVING	預留	預留
IN	預留	預留
INNER	預留	預留
INSERT	預留	預留
INTERSECT	預留	預留
INTO	預留	預留
IS	預留	預留
JOIN	預留	預留
LEFT	預留	預留
LIKE	預留	預留
LOCALTIME	預留	
LOCALTIMESTAMP	預留	
NATURAL	預留	預留
NORMALIZE	預留	
NOT	預留	預留
NULL	預留	預留
ON	預留	預留
OR	預留	預留
ORDER	預留	預留
OUTER	預留	預留
OVERWRITE	預留	
PREPARE	預留	預留
RECURSIVE	預留	
RIGHT	預留	預留
ROLLUP	預留	
SELECT	預留	預留
TABLE	預留	預留
THEN	預留	預留
TRUE	預留	預留
UESCAPE	預留	
UNION	預留	預留
UNNEST	預留	
UPDATE	預留	
USING	預留	預留
VALUES	預留	預留
VACUUM		
WHEN	預留	預留
WHERE	預留	預留
WITH	預留	預留

舊時間戳和新時間戳

新的TIMESTAMP和TIME語義使型別與SQL標準保持一致。詳見以下章節。

注意

新的TIMESTAMP語義仍在試驗中。建議保持原有TIMESTAMP語義為啟用狀態。您可以通過全域性配置或基於每個會話配置新的語義來驗證新語義。在新版本中,可能會廢棄舊版的語義。

配置
可以使用deprecated.legacy-timestamp配置屬性啟用舊語義。將其設定為true(預設)將啟用舊語義,而將其設定為false將啟用新語義。

此外,可以通過legacy_timestamp會話屬性實現基於會話的語義啟用或禁用。

TIMESTAMP語義變化
以前,TIMESTAMP型別描述的是openLooKeng會話時區中的時間例項。現在,openLooKeng將TIMESTAMP值視為一組表示實際時間的欄位:

YEAR OF ERA
MONTH OF YEAR
DAY OF MONTH
HOUR OF DAY
MINUTE OF HOUR
SECOND OF MINUTE - as DECIMAL(5, 3)
因此,除非明確需要某個時區,例如在轉換為TIMESTAMP WITH TIME ZONE 或 TIME WITH TIME ZONE時,TIMESTAMP值不會以任何方式與會話時區連結。在這些情況下,如SQL標準中所約定的,將會使用會話時區的時區偏移量。

TIME語義變化
TIME型別變得與TIMESTAMP型別相似。

TIME with TIME ZONE語義變化
由於相容性要求,TIME WITH TIME ZONE還不可能與SQL標準完全對齊。因此,在計算TIME WITH TIME ZONE的時區偏移量時,openLooKeng使用會話的開始日期和時間。

在使用TIME WITH TIME ZONE的查詢中可以看到,查詢的時區已經發生了時區策略更改或使用了夏令時。例如,會話開始時間為2017-03-01:

查詢: SELECT TIME '10:00:00 Asia/Kathmandu' AT TIME ZONE 'UTC'
舊的查詢結果: 04:30:00.000 UTC
新的查詢結果: 04:15:00.000 UTC