文章指出，盡管BI報表類產(chǎn)品不斷擴(kuò)展能力邊界，即席查詢類產(chǎn)品因其專注于數(shù)據(jù)查詢分析而具有獨特價值。正如彼得·德魯克所說：“知識的關(guān)鍵在于應(yīng)用?！北疚膶⒅笇?dǎo)你如何有效地應(yīng)用即席查詢工具，以提高數(shù)據(jù)探索的效率和準(zhǔn)確性。

2024年12月16日 22:32 北京

在找到數(shù)據(jù)之后，確定了哪些表是需要的，是符合預(yù)期的，就需要進(jìn)行數(shù)據(jù)查詢探索。

即席查詢的定位

如果說報表或者數(shù)據(jù)服務(wù)API是固定需求的數(shù)據(jù)展示和數(shù)據(jù)獲取。那么即席查詢即是靈活的數(shù)據(jù)探索。一個是固定場景，一個是靈活數(shù)據(jù)探索。探索過程中用戶能夠獲取什么都是未知的，而且大部分都是臨時性的。

這就涉及到另一個問題，數(shù)據(jù)消費者是不是有能力、有意愿進(jìn)行數(shù)據(jù)查詢，因為畢竟數(shù)據(jù)查詢的過程是需要寫SQL的。不可否認(rèn)的是，寫SQL對于一部分?jǐn)?shù)據(jù)消費者是有一定門檻的，但是也需要確定的是，一部分?jǐn)?shù)據(jù)消費者是有查詢需求的。針對高門檻的可以使用拖拽式、使用NLP2SQL來降低一下門檻。針對于有述求的用戶這個產(chǎn)品就很是和他們需求契合了。

即席查詢的基本界面

另外此類產(chǎn)品開源的界面也很多。一類是上面是編輯框，下面展示結(jié)果，開源的類似hue、Superset、Redash等。一類一行編輯框， 一行執(zhí)行結(jié)果，如Zeppelin。（此類型接觸的較少），主要介紹第一類。

即席查詢在界面上，和離線開發(fā)中的SQL類任務(wù)開發(fā)是類似甚至可以完全一樣的。

左邊內(nèi)容

在左邊的內(nèi)容中，主要保存查詢?nèi)蝿?wù)、和有權(quán)限查詢的表以及表的字段信息。

中間內(nèi)容

中間內(nèi)容中主要的就是一個編輯框了，在編輯框中能夠進(jìn)行SQL編輯，這個編輯框里面編輯的內(nèi)容需要能夠有關(guān)鍵字提示、高亮、局部代碼執(zhí)行、規(guī)范化顯示等等。

中間內(nèi)容的下半部分的話就是執(zhí)行的代碼的顯示了。直接顯示出來執(zhí)行結(jié)果。

執(zhí)行結(jié)果這里有一個問題，就是針對異步執(zhí)行的查詢，當(dāng)關(guān)閉顯示框的時候，如何能夠?qū)⒅皥?zhí)行的查詢的狀態(tài)、結(jié)果顯示出來那?？梢詥为氂幸粋€歷史查詢界面，如果能夠拿到查詢?nèi)蝿?wù)和底層執(zhí)行的對應(yīng)關(guān)系的話，直接在每個查詢結(jié)果顯示界面顯示歷史也是可以的。

即席查詢的低門檻

操作上的低門檻

在操作門檻上可以把表進(jìn)行拖拽，之后將拖拽的內(nèi)容生成對應(yīng)的SQL，進(jìn)行數(shù)據(jù)查詢。

當(dāng)然，也可以將SQL關(guān)鍵字都進(jìn)行抽象，從而實現(xiàn)拖拽式的低門檻。

結(jié)合大模型的低門檻

2023年大模型的火熱感覺燒到了各個角落里。其中如果和即席查詢結(jié)合的話，大模型能提供什么能力？上面也說到過數(shù)據(jù)消費者可能存在一部分人不悔寫SQL的問題，那么是不是可以讓這部分人僅僅寫自然語言，然后通過大模型將自然語言轉(zhuǎn)換為SQL那。答案是肯定的。在輸入特定prompt之后，大模型就能很方便的轉(zhuǎn)化為SQL語句。

table_info = “””

CREATE TABLE ods_dev.tb_scrm_customer_d (

[[‘zip_code’ ‘string’ ‘郵編’]

[‘wechat_uuid’ ‘string’ ‘微信uuid’]

[‘wechat_name’ ‘string’ ‘微信號名稱’]

[‘wechat_head_portrait’ ‘string’ ‘微信頭像’]

[‘uuid’ ‘string’ ‘微信的uuid’]

[‘update_time’ ‘datetime’ ‘更新時間’]

[‘update_by’ ‘string’ ‘更新人’]

[‘telephone’ ‘string’ ‘固化電話’]

[‘short_name’ ‘string’ ‘公司簡稱’]

[‘shop_name’ ‘string’ ‘虛擬店名稱’]

[‘shop_id’ ‘string’ ‘虛擬店id’]

[‘sex’ ‘bigint’ ‘性別’]

[‘retained_capital_city’ ‘string’ ‘用戶留資城市’]

[‘residential_address’ ‘string’ ‘用戶居住地址’]

[‘resident_province’ ‘string’ ‘常駐省份’]

)

“””

I would like you to be my data anlysts and generate accurate hive sql query for the question

– Make sure the query is postgres compitiable

– Ensure case sensistivity

– Do not add any special information or comment, just return the query

The expected output is code only. Always use table name in column reference to avoid ambiguity

但是大模型不能保證百分之百的準(zhǔn)確，而且準(zhǔn)確率依賴輸入的字段備注等信息。所以個人對于這類chat2SQL的產(chǎn)品是否能夠真正落地是存在疑問的。

和可視化類產(chǎn)品間的關(guān)系

隨著BI報表類產(chǎn)品能力邊界的不斷擴(kuò)展，在BI類產(chǎn)品中也都會出現(xiàn)數(shù)據(jù)探索的即席查詢的能力，也會有已經(jīng)有了BI產(chǎn)品為什么還要有單獨的即席查詢類的數(shù)據(jù)探索產(chǎn)品。但個人認(rèn)為，因為最終的目標(biāo)不同，在能力發(fā)展上也會有區(qū)別，可視化類的更加偏重界面的展示，即席查詢類的主要就是數(shù)據(jù)查詢分析。

而且對接的數(shù)據(jù)源上，BI類產(chǎn)品一般因為效率的原因都是對接MySQL或者HOLO此類的數(shù)據(jù)庫，不會對接Hive等真正存儲大量數(shù)據(jù)的系統(tǒng)。

當(dāng)然，這兩個產(chǎn)品如果能更好的聯(lián)動起來的話，比如使用即席查詢分析完數(shù)據(jù)之后，能夠很方便的使用BI產(chǎn)品進(jìn)行可視化的展示，算是更好的聯(lián)動了。

說到聯(lián)動，這里也提一下可以和數(shù)據(jù)服務(wù)API的聯(lián)動。在2、基于SQL創(chuàng)建 中提到，如果創(chuàng)建API的過程是使用SQL來創(chuàng)建一個數(shù)據(jù)服務(wù)API。那么是不是也可以使用即席查詢和數(shù)據(jù)服務(wù)API的創(chuàng)建過程聯(lián)動起來。當(dāng)然，如果這樣的話就需要再劃分下數(shù)據(jù)服務(wù)誰開發(fā)的問題，在數(shù)據(jù)服務(wù)開發(fā)篇中，這些數(shù)據(jù)服務(wù)是有數(shù)據(jù)加工者開發(fā)完成的。而這里使用即席查詢的過程是數(shù)據(jù)消費者。但是，工具流程上可以這么打通。

異構(gòu)融合查詢

跨源異構(gòu)，通俗來說就是能把兩種不同類型的表間關(guān)聯(lián)起來進(jìn)行查詢。不過，是這樣的話就又涉及到，這個功能是放在離線開發(fā)部分讓數(shù)據(jù)加工者來進(jìn)行異構(gòu)融合查詢合適，還是放在數(shù)據(jù)運營部分，讓數(shù)據(jù)消費者合適。

很顯然，數(shù)據(jù)消費者之需要消費已經(jīng)加工好的數(shù)據(jù)，而已經(jīng)加工好的數(shù)據(jù)，存儲在單一的類型上是更合理的。所以個人認(rèn)為如果有數(shù)據(jù)的異構(gòu)融合查詢，那么放在離線開發(fā)部分可能更合適。也就是說在數(shù)據(jù)消費者領(lǐng)域，異構(gòu)融合查詢的需求是不是真實存在，是可以探討一下的問題。