参考：c人工智能 - StarRocks+Paimon落地阿里日志采集：万亿级实时数据秒级查询 - 阿里云大数据AI技术 - SegmentFault 思否
综合考虑几种日志查询解决方案，包括 MaxCompute 15分钟批处理、StarRocks 内表存算一体方案、StarRocks 和 Paimon 方案
但考虑到 Paimon 数据湖存储的扩展性，StarRocks 的高效数据湖分析能力，选择 Paimon 存储+ StarRocks 计算。
参考：【数据库】Apache Paimon数据湖查询引擎StarRocks_paimon数据库-CSDN博客
StarRocks 是一款专为在线分析处理（OLAP）场景设计的高性能、开源分布式 SQL 数据库。它基于 MPP（大规模并行处理）架构，融合了多种现代数据库技术的优势，致力于提供卓越的查询性能和高并发处理能力。
StarRocks 不仅支持从多种实时和离线数据源高效导入数据，还能够直接分析数据湖中各种格式的数据。其兼容 MySQL 协议，用户可以通过 MySQL 客户端和常用 BI 工具轻松连接。此外，StarRocks 具备水平扩展、高可用性、高可靠性和易于运维等特性，广泛应用于实时数据仓库、OLAP 报表生成和数据湖分析等场景。
StarRocks 的架构设计简洁高效，整个系统仅由前端（FE）和后端（BE 或 CN）两种组件构成。前端节点负责协调和管理，而后端节点则根据存储模式的不同分为 BE（本地存储）和 CN（计算节点，用于存算分离场景，数据存储在对象存储或 HDFS 中）。
StarRocks 的核心特性：
MPP 架构：依托大规模并行处理技术，将查询任务动态分配到多个节点并行执行，显著提升查询效率。
向量化引擎：采用先进的向量化计算技术，最大化 CPU 利用率，进一步优化查询性能。
存算分离：支持计算与存储的完全解耦，实现计算节点的弹性扩缩容，并内置高性能热数据缓存机制，灵活应对不同业务需求。
CBO 优化器：基于成本的查询优化器（Cost-Based Optimizer）智能分析查询场景，自动选择最优执行计划，确保高效查询。
列式存储：采用列式存储格式，针对大数据集优化读取效率，尤其适用于仅涉及部分列的查询场景，大幅减少 I/O 开销。
物化视图：通过预先计算的聚合表（物化视图），加速复杂查询的执行，显著提升分析效率。
数据湖分析：借助 StarRocks 提供的 External Catalog 功能，用户可直接查询 Apache Hive、Apache Iceberg、Apache Hudi、Delta Lake 等数据湖中的数据，无需繁琐的数据迁移，简化分析流程。
CloudCanal + Apache Paimon + StarRocks 实时构建湖仓一体架构 | 让数据流动更简单、精确、稳定、实时，丰富业务数据应用场景
Apache Paimon 介绍
Apache Paimon 是一个开源的、面向流计算的湖仓存储格式，源于 Apache Flink 社区（原 Flink Table Store）。它的核心创新在于将 湖存储格式 与 日志结构合并树（LSM-tree） 技术融合，为数据湖带来了强大的实时流式更新能力，这使得高吞吐、低延迟的数据摄取、变更日志追踪和高效的即时分析成为可能。
核心能力：
-
流批一体处理：支持 Streaming Write / Snapshot Read
-
主键支持：高效 UPSERT / DELETE
-
Schema 演进：新增、删除、修改列，无需重写旧数据
-
ACID 事务保障：支持并发读写一致性
-
生态兼容：支持 StarRocks、Flink、Spark 等引擎
-
对象存储兼容 ：支持 S3 、OSS 等文件系统
-
Paimon 的解决方式（LSM-tree）
Paimon 从架构层面对这一痛点进行了优化，引入类似数据库的主键更新能力。
- 订单在交易库（如 MySQL）中状态变更。
- 变更事件（如 UPDATE orders SET status = '已发货' WHERE order_id = '123'）实时写入 Paimon。
- Paimon 基于 LSM-tree ，更新后读取，通常可在 秒级 内完成。
- 实际效果
下游如 StarRocks 等分析引擎可以秒级查询到更新后的状态，从而确保实时大屏始终反映业务的最新动态。
Paimon 在实时更新、变更频繁的场景中具备更直接的能力优势 ，而 Iceberg 则在批量处理、版本治理和生态成熟度方面表现更稳健。
构建湖仓一体架构
- 外部数据源：企业的核心交易库（如 MySQL, PostgreSQL）、日志数据（Kafka）等。
- CloudCanal ：
- 基于日志实时捕获数据的变更，流式批量写入 ，实现秒级延迟。
- 支持 结构自动迁移 和 DDL 同步。
- 支持数据迁移同步、数据校验与订正、断点续传、任务监控、告警。
- Apache Paimon ：
- 作为湖仓底座，承接 CloudCanal 写入的实时数据流。
- 采用 LSM-tree 架构自动去重合并，管理数据分区与后台 Compaction。
- 基于 S3、OSS 等其他对象存储，构建存算分离架构。
- StarRocks：直接进行实时查询分析，无需额外的数据导入或转换。
参考：Paimon x StarRocks 助力喜马拉雅构建实时湖仓_StarRocks_InfoQ写作社区
在尝试 Flink + Kafka 模式时，我们发现其开发和运维的复杂度较高。对于直播数据来说，我们需要跟踪用户的行为，从用户充值到最终产生公司收入的整个链路都需要进行监控。因此，当涉及大量流式数据的 join 操作时，如果这些数据与离线数据出现不一致的情况，排查问题会变得极其困难。
此外，Kafka 的数据生命周期相对较短，这使得在需要进行数据回溯时变得更加困难。这些因素往往导致排查问题的周期延长，增加了运维的复杂性。
流处理中存在大量的流式 Join 操作。如果仅使用 Flink + Kafka，需要持续保留各个流之间的状态信息，这可能导致状态膨胀问题。当任务需要重启时，这些大状态会导致重启失败。如果这种情况发生在活动期间，可能会影响对数据的实时感知。
至于为什么不使用 Flink + StarRocks，是因为如果将所有数据（包括明细数据）都导入 StarRocks，整体成本将会非常高。
对 ClickHouse 和 StarRocks 进行了全面对比。
在使用 ClickHouse 的过程中，我们遇到了几个比较棘手的问题。首先，ClickHouse 缺乏对高频率、低延迟的修改或删除已存在数据的能力。它只支持更新，但不支持删除操作。此外，它无法自动化更新视图。
更关键的是，ClickHouse 不支持多表关联，因此我们不得不建立大宽表来存储数据。但对于我们来说，无论是自助取数还是构建看板模型，通常都需要多表关联才能实现展示和分析。相比之下，使用 StarRocks 时，这些场景都能得到很好地支持和兼容。
StarRocks 在基表变动时，物化视图能够自动更新和维护。此外，它支持多种格式的 Join 方式，对于新型雪花模型的关联性能表现更加优越。同时，StarRocks 对多并发查询的支持也非常出色。
实时湖仓架构
对于数据源，如 MySQL 和埋点流量日志，我们通过 Flink CDC 直接将数据写入 Paimon，Paimon 作为 ODS 层，为离线和实时处理提供数据支持。
在实时处理部分，我们使用 Flink 进行数据清洗后，再写入 Paimon，Paimon 进行表间关联，最终将结果写入 StarRocks。
StarRocks 利用物化视图和 OLAP 功能，为下游应用提供快速查询支持。
在离线部分，Paimon 同样作为 ODS 层，凭借其组件化更新特性，解决了传统离线处理中的数据延迟问题。
我们使用的是自研的 Binlog 链进行数据落盘，后来替换为 Flink CDC。这一替换实现了全量和增量数据的无缝衔接，且增量数据部分支持自动扩容。这样极大简化了架构，提高了稳定性，确保数据的精准性与横向扩展能力，同时也提升了数据同步能力。Flink CDC 还支持 schema 字段变更的自动透传至下游，并且不同任务间相互独立运行，保证了数据同步的隔离性。
Paimon 的流读功能：大大提升了实时数据处理的效率。
Paimon 的永久日志保存：不仅支撑了实时库的建设，还作为离线数据存储的 ODS 层基石。
基于组件的更新机制：例如订单状态频繁变更时，Paimon 能够通过组件进行自动更新，避免重复刷新过去半个月的数据。即使主从同步出现延迟，昨天的数据也会通过 T+1 的机制确保次日更新到表中。
首先，Paimon 的流与流 Join 加载速度慢，尤其是在活动上线时需要更改逻辑。重启任务后，数据无法正常刷新。最初我们怀疑是资源不足，进行了资源倾斜和小文件合并，但问题依然存在。最后发现是没有限定增量读或指定日期读，导致任务每次重启都会从历史分区开始读取。加上参数后问题得以解决，数据刷新速度大大提升。
其次，在 Paimon 表 Join 维度表时，刚开始运行稳定，但几天后出现丢数据的情况。经过排查，发现维度表未持久化，导致过期而丢失数据。通过参考官方文档，使用 Lookup 格式解决了这个问题。
参考：
https://blog.csdn.net/weixin_44904816/article/details/143018900
StarRocks内部有统一的 Catalog 机制，不论是 StarRocks 的内表，多种格式的湖上外表，还是 JDBC 外表，在逻辑上都是这样一个 Catalog 的概念。也就是说，StarRocks 单一引擎就能够同时访问包括但不限于内表、Paimon 为代表的湖上外表、MySQL 为代表的 JBBC 外表等多种数据源，并且能够支持跨数据源的 Join。
只要用户需要，任意一个数据源的数据都可以写入 StarRocks 内表，实现统一的数据加工和处理，非常方便。
此外内外表的数据访问还能够通过 StarRocks 的 RBAC 机制进行统一的权限管理。
StarRocks 做到了把数据留在 HDFS 或者对象存储上，在读取的时候从这些文件系统中获取需要的数据，后续的查询与分析过程都和内表别无二致。
StarRocks 这边就不一样，外表 Catalog 默认就是动态创建和配置的，可以做到开箱即用，只要我们保证网络是畅通的，就可以在客户端通过写SQL的方式直接创建一个外表 Catalog，我们看到上面我创建了一个 type 是 Paimon 的 Catalog，这个 Catalog 和 Paimon 自己的那个 Catalog 是一一对应的
数据湖分析加速、湖仓分层建模、冷热融合以及全链路 ELT
场景一：数据湖分析加速
场景四：全链路ETL
StarRocks 不仅是一个查询引擎，他也是能够写的。换句话说， StarRocks 具有一定的轻量 ETL 能力。首先 StarRocks 近期对 Spill，也就是当内存不足时将查询的中间结果向磁盘溢写这个能力进行了大幅度的优化，这可以说是 ETL 必备的能力了。然后 StarRocks 可以通过 VVP 也就是 Flink进行 CTAS 或 CDAS，导入各种数据，打造适合大批量数据的全链路的实时数仓，不止如此，StarRocks也是可以写湖的，社区对 Iceberg 和 Hive 支持的比较好，也可以直接将 ORC 或者 Parquet 文件写到文件系统中。
存算一体就是比较传统的，大家最常遇到的那个版本，数据都存放在云盘或本地盘上，好处是读写性能非常高，适合追求高效率和高并发的大数据分析的用户；存算分离是指存储在 OSS 上，能够节约大量存储成本，并且存算分离集群的缓存做的也是很不错的，对于经常访问的热数据，能够做到查询性能对齐存算一体；数据湖分析版本则是纯数据湖查询的版本
Deletion Vector则是用 Bitmap 来标记，我数据文件中的哪些列是被 Upsert 掉了需要删除的，也就不需要合并，只要跳过就可以了。
多了一个 index 路径，以及 manifest 路径下面多了一个 index manifest。
index 就是哪个 bitmap，用来标记哪些行是需要被删掉的，index meta则是index的元数据，用来表示 index 里的这段 bitmap 对应的是哪个数据文件
我创建了一个 t1 t2 join 的物化视图，之后我执行了一个t1 t2 t3三个表 join 的查询，查的是原表。这种情况下，StarRocks 发现，这个查询中有一个 join 命中了物化视图，然后这一部分的查询就会自动被改写到物化视图上，这个过程用户是不感知的，也就是所谓透明加速。
然后是 Unified Catalog。有人可能会觉得，我所有湖格式的外表都在一个统一的 Metastore 里，我要给每种湖格式都建一个 catalog，我觉得这还是太麻烦了，怎么办？StarRocks提供了 Unified Catalog 这个功能，专门就针对这种情况，这是一个特殊的外表 catalog，里面什么表都有，只要元数据一样，就都能查。Paimon也是支持了 unified catalog，目前支持的元数据类型是 hms 和 dlf
