一、背景与挑战

1.1 业务场景概述

某工商信息商业查询平台是国内领先的商业信息服务平台，提供企业工商信息、法律诉讼、知识产权、经营风险等全维度数据查询服务，日均查询量超亿次。其数据来源包括政府公开数据、第三方数据接口、用户上传数据等，数据类型涵盖结构化（如企业注册信息）、半结构化（如司法文书）和非结构化（如企业年报PDF）数据，数据规模达PB级。

1.2 传统架构痛点

在湖仓一体架构落地前，平台采用“数据仓库+数据湖”分离模式：数据仓库基于传统MPP数据库（如Greenplum）构建，负责结构化数据的OLAP分析；数据湖基于Hadoop生态（如HDFS+Hive）构建，存储原始数据并支持离线ETL。该模式存在三大问题：

• 数据孤岛：仓库与湖之间需通过ETL工具同步，延迟高（小时级），无法满足实时查询需求；
• 成本高企：仓库需预分配资源，湖需存储原始数据，双重存储导致存储成本上升；
• 分析效率低：复杂查询需跨仓库与湖联合分析，性能受限于网络传输与计算资源。

1.3 湖仓一体核心需求

为解决上述问题，平台需构建湖仓一体架构，实现：

• 统一存储：支持结构化、半结构化、非结构化数据存储，消除数据搬运；
• 实时分析：支持亚秒级查询响应，满足实时风控、实时推荐等场景；
• 弹性扩展：按需分配计算资源，降低TCO；
• 兼容生态：兼容Hadoop生态工具，降低迁移成本。

二、Apache Doris技术选型依据

2.1 Doris核心特性匹配需求

Apache Doris是一款高性能、实时分析型数据库，其特性与平台需求高度匹配：

• 统一存储引擎：支持列式存储（适合分析）与行式存储（适合点查），可存储JSON、CSV等半结构化数据；
• 实时写入与查询：通过Flink-Doris-Connector实现秒级数据写入，查询延迟<1秒；
• 向量化执行引擎：利用SIMD指令优化计算，复杂查询性能比传统MPP提升3-5倍；
• 弹性资源管理：支持动态扩缩容，计算资源按查询负载分配，降低闲置成本。

2.2 与竞品对比优势

特性	Apache Doris	ClickHouse	StarRocks
实时写入能力	强（支持微批）	弱（需批量）	强
生态兼容性	高（兼容MySQL协议、Hadoop生态）	低（专用协议）	中（兼容MySQL）
运维复杂度	低（单节点部署）	高（需Zookeeper）	中（需FE/BE分离）
适用场景	实时分析+轻量级OLTP	离线分析	高并发点查

Doris在实时性、生态兼容性、运维复杂度上综合优势明显，成为平台首选。

三、湖仓一体架构设计与实践

3.1 整体架构图

[数据源] → [Flink实时采集] → [Doris存储层] → [BI/API服务]
                       ↑
[Hadoop数据湖] → [Spark离线处理] → [Doris增量导入]

• 存储层：Doris作为统一存储，分区按企业ID哈希+时间范围，副本数设为3；
• 计算层：FE（Frontend）负责SQL解析与元数据管理，BE（Backend）负责数据存储与计算；
• 接入层：通过MySQL协议对接BI工具（如Tableau）、API服务（如RESTful接口）。

3.2 关键技术实践

3.2.1 实时数据管道构建

使用Flink-Doris-Connector实现实时数据写入：

// Flink SQL示例：将Kafka数据写入Doris
CREATE TABLE doris_sink (
    id INT,
    name STRING,
    create_time TIMESTAMP
) WITH (
    'connector' = 'doris',
    'fenodes' = 'fe_host:8030',
    'table.identifier' = 'db.table',
    'username' = 'user',
    'password' = 'pass',
    'sink.batch.size' = '1000',
    'sink.batch.interval' = '1s'
);
INSERT INTO doris_sink SELECT * FROM kafka_source;

• 微批优化：设置sink.batch.size=1000和sink.batch.interval=1s，平衡吞吐与延迟；
• 错误重试：启用sink.max-retries=3，避免网络波动导致数据丢失。

3.2.2 离线数据整合

对Hadoop中的历史数据，通过Spark批量导入Doris：

// Spark Scala示例：将Hive数据导入Doris
val spark = SparkSession.builder()
  .appName("HiveToDoris")
  .enableHiveSupport()
  .getOrCreate()
val hiveDF = spark.sql("SELECT * FROM hive_db.hive_table")
hiveDF.write
  .format("doris")
  .option("doris.table.identifier", "db.table")
  .option("doris.fenodes", "fe_host:8030")
  .mode("overwrite")
  .save()

• 分区对齐：确保Hive表分区与Doris分区一致，避免全量扫描；
• 小文件合并：设置spark.hadoop.mapreduce.input.fileinputformat.split.maxsize=256MB，减少Doris导入文件数。

3.2.3 查询性能优化

• 物化视图：对高频查询（如“企业风险查询”）创建物化视图：

  CREATE MATERIALIZED VIEW mv_risk_query AS
  SELECT 
    enterprise_id,
    COUNT(DISTINCT case_id) AS risk_count,
    MAX(case_date) AS latest_risk_date
  FROM risk_table
  GROUP BY enterprise_id;

• 索引优化：对enterprise_id、create_time等查询字段建立Bloom Filter索引：

  ALTER TABLE risk_table ADD INDEX idx_enterprise (enterprise_id) USING BLOOMFILTER;

• 资源隔离：通过SET query_timeout=30限制长查询，避免资源耗尽。

四、实践效果与经验总结

4.1 效果数据

• 查询延迟：90%查询<1秒，复杂查询（如多表JOIN）<3秒；
• 存储成本：数据压缩率达70%，存储成本降低40%；
• 运维效率：从传统架构的5人运维团队缩减至2人，故障恢复时间从小时级降至分钟级。

4.2 经验总结

• 渐进式迁移：先迁移实时查询场景，再逐步替换离线报表，降低风险；
• 监控告警：通过Prometheus+Grafana监控Doris的BE内存使用、查询队列长度等指标，提前发现瓶颈；
• 版本升级：定期升级至Doris最新稳定版（如1.2.4），利用新特性（如异步物化视图刷新）持续优化性能。

五、未来展望

平台计划进一步深化Doris应用：

• AI融合：结合Doris的向量检索能力，构建企业知识图谱，支持智能推荐；
• 多云部署：利用Doris的云原生特性，实现跨云资源调度，提升容灾能力；
• Serverless化：探索Doris与K8s的集成，实现按查询计费的弹性模式。

Apache Doris的湖仓一体实践，为工商信息查询平台提供了高效、低成本的数据分析底座，其经验可为同类企业提供参考。