SelectDB案例 从 ClickHouse 到 Apache Doris

以下是对文档内容的总结，语言简洁明了，重点突出核心观点和关键信息： --- ### 《SelectDB案例：从ClickHouse到Apache Doris》 #### 背景与迁移原因 1. **ClickHouse的局限性**： - 维护两套引擎（ClickHouse和Elasticsearch）的连接与查询成本高，架构复杂。 - 国外开源项目，存在语言障碍和社区支持不及时的问题。 2. **架构1.0的问题**： - 数仓层不支持部分列更新，导致数据时效性下降。 - 加速层存储资源浪费，维护成本高。 - 应用层架构复杂，ClickHouse计算和存储耦合，集群稳定性差。 --- #### Apache Doris的优势 1. **架构与运维**： - 极简架构，只需两个进程（FE和BE），部署和运维简单。 - 兼容MySQL协议，支持标准SQL。 2. **功能特性**： - 支持丰富的数据模型和部分列更新。 - 支持联邦查询，兼容Hive、Iceberg、Hudi等数据湖和MySQL、Elasticsearch等数据库。 - 多样化的数据导入方式，支持实时和批量同步。 3. **社区支持**： - 社区活跃，SelectDB有专职技术支持团队，问题反馈及解决快。 --- #### 数据架构优化 1. **架构2.0**： - **数仓层**：通过Doris的Aggregate数据模型支持部分列实时更新，去除DWM集市层，直接构建宽表，提升数据时效性。 - **加速层**：拆分大宽表为小宽表，优化分区策略，减少存储压力，提升查询吞吐量。 - **应用层**：DataSet统一指向Doris，支持外表查询，直接查询ES引擎。 2. **存在问题**： - DataSet灵活性高，但指标和标签定义缺乏统一管理。 --- #### 架构4.0与语义层应用 1. **语义层作用**： - 数仓层：统一定义计算逻辑，生成SQL命令。 - 加速层：接收配置，触发导入任务。 - 应用层：解耦物理引擎，生成物理SQL。 2. **优势**： - 统一管理核心指标和标签，解耦应用层与物理引擎。 3. **存在问题**： - 自动生成准确的SQL语句难度较大。 --- #### 优化经验 1. **场景需求**： - 支持实时可用、部分更新、性能高效和成本控制。 2. **数据导入方案**： - 选择Flink生成宽表，优化数据写入，减轻Doris压力。 3. **查询优化**： - 场景需求：标签圈选逻辑复杂，支持历史数据查询和聚合分析。 - 采用Doris on ES方案，结合Doris的分布式查询和ES的全文检索能力。 - 优化措施： - 分桶优化：降低网络IO开销，减少数据Shuffle。 - Bitmap压缩：优化数据获取，减少网络开销。 - Join优化：本地Join避免数据传输。 - 效果：百万分群圈选查询时间从60秒缩短至3.7秒。 --- #### 成本优化 1. **冷热数据管理**： - Doris TTL机制：近一年数据存储在Doris，更早数据存储在TDW。 - 分区级副本设置：动态调整副本数量。 - 数据转冷：SSD存储7天内数据，旧数据转存HDD。 - 标签上下线：降低写入和存储成本。 2. **成本降低效果**： - 存储成本降低42%。 - 开发和时间成本降低40%。 --- #### 未来规划 1. **技术探索**： - 自动识别冷热数据，结合Iceberg存储冷数据。 - 物化视图预计算，提升高频标签/指标组合查询性能。 - Doris应用于数仓计算任务，提升时效性。 2. **性能提升**： - 倒排索引功能（2.0版本）：支持文本全文检索，提升性能。 --- 上述总结重点突出SelectDB从ClickHouse迁移至Doris的背景、优化策略、架构演进和成本优化方案，逻辑清晰，内容完整。