Kappa架构下Apache Superset对接Spark/Kafka问题咨询

先澄清几个前置认知误区：

• 关于Superset对接Spark的连接器问题：不用部署全套Hive服务。Spark本身兼容HiveServer2通信协议，只要启动Spark Thrift Server并开启Hive语法支持，就能用impyla这类兼容Hive协议的客户端直接连接，PyHive停更不影响这个链路，impyla是生产环境验证过的可行替代，不用纠结Hive作为独立存储项目的逻辑，这里只是用了它的连接协议而已。
• Kafka的消息存储是追加式日志结构，本身不支持SQL即席查询，所有对Kafka数据的SQL访问都要通过上层计算引擎做映射，不存在绕开计算引擎直接查Kafka的原生SQL方法。

问题1：如何编写查询语句直接查询Kafka中存储的实时数据？ #

核心前提：必须通过你现有栈里的Spark引擎做数据源映射，才能用SQL查询Kafka数据，操作步骤如下：

1. 准备Spark环境：把对应版本的Kafka连接器依赖spark-sql-kafka-0-10放到Spark的jars目录下，重启Spark Thrift Server（就是你对接Superset用的JDBC服务）确保依赖加载生效。
2. 在Spark SQL中创建Kafka数据源映射表，参考代码：

CREATE TABLE kafka_raw_events (
  key BINARY,
  value BINARY,
  topic STRING,
  partition INT,
  offset LONG,
  timestamp TIMESTAMP,
  timestampType INT
) USING kafka
OPTIONS (
  subscribe = '你的业务上报topic名称',
  kafka.bootstrap.servers = 'kafka集群连接地址:9092',
  startingOffsets = 'latest'
);

如果需要查询Kafka留存周期内的所有历史数据，把startingOffsets参数值改成earliest即可，注意超过Kafka保留时长被清理的数据无法查询。
3. 业务事件一般是JSON格式写入Kafka的value字段，默认读出来是二进制类型，可以建持久化视图做自动解析，避免每次查询都写解析逻辑：

CREATE VIEW parsed_events AS
SELECT 
  get_json_object(cast(value AS string), '$.user_id') AS user_id,
  get_json_object(cast(value AS string), '$.event_type') AS event_type,
  get_json_object(cast(value AS string), '$.event_time') AS event_time,
  get_json_object(cast(value AS string), '$.biz_data') AS biz_data,
  timestamp AS kafka_recv_time
FROM kafka_raw_events;

建完之后直接执行SELECT * FROM parsed_events就能查到解析好的实时事件数据。

问题2：如何通过Apache Superset实现和Scala写Spark程序同等的Kafka数据访问操作？ #

你写Scala Spark程序读Kafka做处理，和Superset访问Kafka数据的底层逻辑完全一致：都是通过Spark引擎对接Kafka数据源拉取数据、执行计算逻辑，区别只是Scala程序是硬编码处理逻辑，Superset是通过Thrift协议把页面配置的查询、聚合规则提交给Spark执行，具体操作如下：

1. 按照问题1的步骤，在Spark侧建好Kafka映射表和解析后的持久化视图（不要建TEMP临时视图，否则Spark服务重启后元数据会丢失）。
2. Superset侧不用修改现有数据库连接配置，直接用已经连通的Spark连接，在数据集管理页同步刚才创建的parsed_events视图，就能像查询普通业务表一样做可视化配置：
   • 如果要做实时刷新的大屏/监控面板，在数据集高级配置里把查询缓存时间调整到你需要的粒度，比如10秒、30秒，每次刷新时Spark会自动拉取Kafka最新offset的数据完成计算。
   • 如果要做窗口聚合、指标统计这类复杂计算，不要让Superset每次直接查原始Kafka数据算，提前在Spark侧用Structured Streaming写常驻作业，把固定维度的聚合结果（比如5分钟粒度的PV、UV、转化数据）写成预计算视图或者表，Superset直接查询预计算结果即可，和你写Scala Spark程序做流计算的效果完全一致，性能也更好。

问题3：上述组件的对接方式是否不符合Kappa架构的设计初衷？ #

当前的对接思路完全符合Kappa架构的核心设计，只有性能优化层面的可调整空间，不存在架构方向的偏差。
先明确Kappa架构的三个核心判定标准：

• 所有业务数据以不可变日志的形式统一存储在消息队列（也就是你用的Kafka），作为唯一的事实数据源
• 用同一套流处理引擎承接所有计算需求，不管是实时增量计算还是全量历史重算，都通过消费Kafka日志完成，不单独搭建独立的批处理链路
• 上层查询、可视化服务对接计算层输出的结果，对外提供访问能力
  对照你的栈来看：
• Kafka作为原始事件日志的统一存储，满足唯一事实源的要求
• Spark作为唯一计算引擎，不管是你写的Scala流处理作业，还是Superset提交的即席查询，都通过Spark读Kafka数据完成计算，没有引入第二套批处理引擎，满足计算层要求
• Superset作为可视化层对接Spark的计算结果，满足服务层要求
  唯一可以优化的点是：对于固定的高频查询指标，不要每次都从Kafka原始数据临时计算，用Spark常驻流作业做预计算、把结果写到支持高效查询的存储（比如你现有环境里的PostgreSQL，或者湖仓格式表），Superset直接查预计算结果即可，需要历史重算的时候只要重置Kafka消费offset，重跑一遍流作业就能全量回溯结果，完全符合Kappa架构的重算逻辑。

内容的提问来源于stack exchange，提问作者Sjoerd222888