Hi team 👋 — proposing engine-native column-level lineage via the audit log I've opened an RFC + draft PR to emit column-level lineage directly from the FE analyzer into AuditEvent, so downstream tools (DataHub / Atlas / OpenLineage) don't need to re-parse SQL and replicate our catalog logic offline. The gist: • Register source columns during the analyzer pass (new SourceColumn on AnalyzeState) • Propagate through existing relation visitors — tables, views, MVs, CTEs, joins, unions • Unified OutputColumn abstraction across INSERT / CTAS / view creation • Gated behind a session variable, with size caps; estimated <2% analyze-time overhead • Wire format aligned with OpenLineage facets Open questions I'd love input on: 1. Wire format — stick with OpenLineage facets, or something lighter? 2. View expansion depth — fully expand, or stop at the view boundary? 3. Anything else you'd want covered before this lands? Issue / design: https://github.com/StarRocks/starrocks/issues/71920 Any feedback — on the approach, the scope, or the corner cases — would be super helpful. Happy to iterate. 🙏

@Simo Wang please take a look