数据运营篇 | 面向探索分析的数据查询

文章指出，尽管BI报表类产品不断扩展能力边界，即席查询类产品因其专注于数据查询分析而具有独特价值。正如彼得·德鲁克所说：“知识的关键在于应用。”本文将指导你如何有效地应用即席查询工具，以提高数据探索的效率和准确性。

2024年12月16日 22:32 北京

在找到数据之后，确定了哪些表是需要的，是符合预期的，就需要进行数据查询探索。

即席查询的定位

如果说报表或者数据服务API是固定需求的数据展示和数据获取。那么即席查询即是灵活的数据探索。一个是固定场景，一个是灵活数据探索。探索过程中用户能够获取什么都是未知的，而且大部分都是临时性的。

这就涉及到另一个问题，数据消费者是不是有能力、有意愿进行数据查询，因为毕竟数据查询的过程是需要写SQL的。不可否认的是，写SQL对于一部分数据消费者是有一定门槛的，但是也需要确定的是，一部分数据消费者是有查询需求的。针对高门槛的可以使用拖拽式、使用NLP2SQL来降低一下门槛。针对于有述求的用户这个产品就很是和他们需求契合了。

即席查询的基本界面

另外此类产品开源的界面也很多。一类是上面是编辑框，下面展示结果，开源的类似hue、Superset、Redash等。一类一行编辑框， 一行执行结果，如Zeppelin。（此类型接触的较少），主要介绍第一类。

即席查询在界面上，和离线开发中的SQL类任务开发是类似甚至可以完全一样的。

左边内容

在左边的内容中，主要保存查询任务、和有权限查询的表以及表的字段信息。

中间内容

中间内容中主要的就是一个编辑框了，在编辑框中能够进行SQL编辑，这个编辑框里面编辑的内容需要能够有关键字提示、高亮、局部代码执行、规范化显示等等。

中间内容的下半部分的话就是执行的代码的显示了。直接显示出来执行结果。

执行结果这里有一个问题，就是针对异步执行的查询，当关闭显示框的时候，如何能够将之前执行的查询的状态、结果显示出来那。可以单独有一个历史查询界面，如果能够拿到查询任务和底层执行的对应关系的话，直接在每个查询结果显示界面显示历史也是可以的。

即席查询的低门槛

操作上的低门槛

在操作门槛上可以把表进行拖拽，之后将拖拽的内容生成对应的SQL，进行数据查询。

当然，也可以将SQL关键字都进行抽象，从而实现拖拽式的低门槛。

结合大模型的低门槛

2023年大模型的火热感觉烧到了各个角落里。其中如果和即席查询结合的话，大模型能提供什么能力？上面也说到过数据消费者可能存在一部分人不悔写SQL的问题，那么是不是可以让这部分人仅仅写自然语言，然后通过大模型将自然语言转换为SQL那。答案是肯定的。在输入特定prompt之后，大模型就能很方便的转化为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

但是大模型不能保证百分之百的准确，而且准确率依赖输入的字段备注等信息。所以个人对于这类chat2SQL的产品是否能够真正落地是存在疑问的。

和可视化类产品间的关系

随着BI报表类产品能力边界的不断扩展，在BI类产品中也都会出现数据探索的即席查询的能力，也会有已经有了BI产品为什么还要有单独的即席查询类的数据探索产品。但个人认为，因为最终的目标不同，在能力发展上也会有区别，可视化类的更加偏重界面的展示，即席查询类的主要就是数据查询分析。

而且对接的数据源上，BI类产品一般因为效率的原因都是对接MySQL或者HOLO此类的数据库，不会对接Hive等真正存储大量数据的系统。

当然，这两个产品如果能更好的联动起来的话，比如使用即席查询分析完数据之后，能够很方便的使用BI产品进行可视化的展示，算是更好的联动了。

说到联动，这里也提一下可以和数据服务API的联动。在2、基于SQL创建 中提到，如果创建API的过程是使用SQL来创建一个数据服务API。那么是不是也可以使用即席查询和数据服务API的创建过程联动起来。当然，如果这样的话就需要再划分下数据服务谁开发的问题，在数据服务开发篇中，这些数据服务是有数据加工者开发完成的。而这里使用即席查询的过程是数据消费者。但是，工具流程上可以这么打通。

异构融合查询

跨源异构，通俗来说就是能把两种不同类型的表间关联起来进行查询。不过，是这样的话就又涉及到，这个功能是放在离线开发部分让数据加工者来进行异构融合查询合适，还是放在数据运营部分，让数据消费者合适。

很显然，数据消费者之需要消费已经加工好的数据，而已经加工好的数据，存储在单一的类型上是更合理的。所以个人认为如果有数据的异构融合查询，那么放在离线开发部分可能更合适。也就是说在数据消费者领域，异构融合查询的需求是不是真实存在，是可以探讨一下的问题。