Architecting Real Time Customer Facing Analytics
๐ Join us for NEXT QUERY 2026 | Free | Virtual | Nov 4 ๐ 20+ practical talks from teams building and operating data + AI infrastructure in production: https://bit.ly/4hBgFGR What does it take to deliver sub-second, real-time analytics on constantly changing dataโwithout pre-joining or preprocessing everything upstream? In this technical session, PhoenixAI breaks down the architecture behind real-time customer-facing analytics, from data freshness and high-frequency updates to fast joins, high concurrency, and workload isolation. See why updates are fundamentally difficult for compressed, immutable columnar storage, and compare how systems including ClickHouse and Apache Iceberg handle changing data through merge-on-read, equality deletes, deletion vectors, and copy-on-write. Then, go deeper into what it takes to query fresh data directly: cost-based query optimization, distributed joins, MPP execution, runtime filters, primary key indexing, and workload isolation. The session also covers how PhoenixAI and StarRocks approach these challenges, with production examples from Pinterest and Coinbase. In this session, youโll learn: ๐ How to achieve low-latency, fresh analytics on constantly changing data ๐ Why real-time updates are difficult for columnar analytical databases ๐ ClickHouse MergeTree vs. Apache Iceberg approaches to updates and deletes ๐ Why pre-joins can create freshness and pipeline bottlenecks ๐ Cost-based optimization, MPP execution, runtime filters, and workload isolation ๐ How PhoenixAI and StarRocks support real-time customer-facing analytics at scale ---------------------------------------------------------------------------------------- Timestamps Introduction & the problem 0:00 Welcome and agenda 2:28 What makes customer-facing analytics different 6:25 Where freshness latency builds up after a source change Why updates are hard 7:37 Why updates are hard for analytical storage 8:06 How OLTP databases update a row 9:45 Columnar files: compressed and immutable 12:50 Two ways to find the old row 13:25 Option 1: The query finds the old row - ClickHouse ReplacingMergeTree with FINAL 16:12 Option 1: The query finds the old row - Apache Iceberg equality deletes 17:51 Opton 2: the writer finds the old row - Iceberg deletion vectors and copy-on-write, ClickHouse mutations: scanning or rewriting 19:54 Query Finds the Old Row vs. Writer Finds the Old Row The pipeline and join problem 20:29 The pipeline problem: pre-joins and preprocessing 23:58 What fast joins need: what the compute architecture needs 28:19 Common approaches and where they fall short 29:13 What the system actually needs How PhoenixAI and StarRocks approach it 30:18 How PhoenixAI and StarRocks approach it 31:55 Architecture: multi-warehouse on object storage 33:00 Updates: the primary key index 36:31 Joins: cost-based optimizer 38:02 MPP execution and runtime filters 39:02 Workload isolation with separate warehouses Customer examples & takeaways 39:30 Case studies: Pinterest: Scaling real-time analytics for customer-facing workloads 40:27 Case studies: Coinbase: Serving fast analytics on fresh, changing data 40:58 Summary Q&A 42:38 Q&A 44:14 Streaming ingestion throughput 45:39 Primary key tables: open source vs. enterprise 48:05 Wrap-up ---------------------------------------------------------------------------------------- Learn more at https://www.phoenixdata.ai/ Connect with us: LinkedIn: https://www.linkedin.com/company/phoenixai-data/ Twitter: https://x.com/phoenixdataai CelerData Website: https://www.phoenixdata.ai/ StarRocks GitHub: https://github.com/StarRocks/StarRocks StarRocks Website: https://www.starrocks.io/ Slack: https://starrocks.io/redirecting-to-slack #RealTimeAnalytics #RealTimeData #DataEngineering #DataInfrastructure #DataArchitecture #OLAP #Database #ApacheIceberg #Lakehouse #StarRocks #OpenSource #StreamingData #ApacheKafka #CDC #DataEngineer