数据落到 Kafka 之后，多久能进 Greenplum？批处理是 T+1，实时接入要压到秒级。Greenplum 本身不是流数据库，但它提供了几条把外部数据灌进来的通道，选错了延迟、吞吐和维护成本都会难受。
先看四种通道的定位
gp_kafka 是官方 Kafka 连接器，延迟秒级、吞吐高、复杂度中等，适合日志、IoT、点击流这类持续写入的场景。
PXF + Kafka 走外部表流式读取，延迟同样秒级，吞吐中等，适合已经部署了 PXF 的环境，复用现有组件。
JDBC 批量写入由应用直连，延迟在秒到分钟之间，吞吐中等，复杂度最低，适合业务系统自己推数据。
gpcopy 做库到库同步，延迟分钟级，吞吐高，适合 Greenplum 集群之间搬数据。
一句话概括：应用能改代码就 JDBC，有 Kafka 基建就上 gp_kafka，已有 PXF 就复用，跨库同步才考虑 gpcopy。
gp_kafka：官方通道的配置要点
架构很直白：Kafka Topic 进 gp_kafka Connector，再写入 Greenplum 表，连接器内部并行读取并做分区映射。
安装从 Greenplum 官方库下载对应版本的连接器，配置文件在 $GPHOME/connectors/kafka/etc/kafka.properties。核心几项：
bootstrap.servers 列全部 broker，group.id 保证消费组唯一，auto.offset.reset 决定没有位点时从哪读。这里有个坑：auto.offset.reset=earliest 只在消费组第一次没有提交位点时生效，如果之前跑过一次又改了 group.id，会从头重放整个 topic，生产上务必先确认位点。
目标表建议 appendonly + column + zstd，按 order_time 做范围分区，分布键选 order_id 这类高基数列。分区表配合实时写入时，提前建好未来几天的分区，别等写入报错才补。
启动消费的命令带 batch-size 和 flush-interval，前者控制单批条数，后者控制刷新间隔，两个参数共同决定延迟和吞吐的平衡。
Kafka 消息是 JSON 时，可以建 jsonb 列直接落库，由连接器做 JSON 到列的映射；也可以先整条存 jsonb，后续用 Greenplum 的 JSON 函数解析。前者省事，后者灵活，字段经常变就选后者。
PXF + Kafka：复用现有组件的做法
已经装了 PXF 的集群，不必再引入 gp_kafka。建一张 Kafka 外部表，PROFILE 指定 Kafka，formatter 用 pxfwritable_import。
外部表本身不落数据，查询时才去 Kafka 拉。要真正入库，得配合定时任务把外部表内容 INSERT 到本地表，pg_cron 是常见选择。
增量条件用 order_time 大于本地表当前最大值，这个写法简单，但要注意两点：Kafka 里的数据不保证按时间有序，跨分区乱序会导致漏读；重复执行同一时间窗口会重复写入，需要靠主键或去重逻辑兜底。
PXF 的读取是批式的，不是常驻消费者，所以延迟取决于定时任务频率，标称秒级实际取决于调度粒度。
JDBC 批量写入：应用侧最直接的路
应用直连最简单，但写法差别很大。逐条 execute 在生产上不可接受，必须用 addBatch 攒批，每 1000 条左右 executeBatch 一次。
批量提交的坑在于：一条失败整批回滚，错误定位困难。建议批次不要过大，并在应用层记录批次边界。
更快的做法是走 PostgreSQL JDBC 的 CopyManager，用 COPY 协议代替 INSERT。COPY 绕开了逐行解析和部分约束检查，吞吐通常明显高于批量 INSERT。代价是错误处理更粗，格式必须严格对齐，字段里出现分隔符要提前转义。
COPY 的另一个限制是它不走普通的行级触发器逻辑，依赖触发器的业务规则会失效，用之前确认清楚。
调优：几个真正影响表现的参数
批量大小控制在 5000 到 10000 条一批，太小网络往返多，太大内存和失败重试成本高。
刷新间隔 1 到 5 秒，这是实时性和吞吐的平衡点。追求极致低延迟就调小，但写入放大会拖累整体。
分区按小时或天切，好处是清理旧数据直接 DROP PARTITION，比 DELETE 快几个数量级，也不会产生大量死元组。
分布键选高基数列，避免所有数据挤到一个 segment 形成写入热点。如果业务查询经常按 user_id 过滤，而写入按 order_id 分布，就要权衡，必要时用随机分布换写入均匀。
索引只建必要的。每个索引都会让写入变慢，实时表上尤其明显。真需要查询加速，考虑在只读副本或物化视图上做。
实时表单独划资源组，别和报表查询抢资源。一条大查询就能把实时写入拖到分钟级延迟。
选型对照与几个容易忽略的点
日志、IoT、点击流这类大体量持续写入，gp_kafka 是首选；已有 Kafka 基建同样走 gp_kafka。
应用能改代码、数据量中等，JDBC + COPY 最省事，不引入额外组件。
已有 PXF 环境、能接受调度粒度带来的延迟，PXF + Kafka 够用。
分钟级延迟可接受，微批 ETL 反而更稳，运维成本最低。
库到库同步用 gpcopy，它是为 Greenplum 之间搬数据设计的，别拿它当通用实时通道。
几个容易踩的点：Kafka 的 partition 数决定了 gp_kafka 的最大并行度，partition 太少，连接器再多的并行也吃不满；Greenplum 的 segment 数和 Kafka partition 数不匹配时，会出现部分 segment 空闲。
实时写入和批量 ETL 混在同一张表上，容易互相干扰，建议物理分开。
监控上至少盯三个指标：消费 lag、单批写入耗时、segment 间的数据倾斜。lag 持续上涨说明消费能力不足，要么加并行要么调大批次。
从 T+1 到秒级，换的不只是工具，是数据流的组织方式。实时本身不是目的，让数据更快产生价值才是。
