目的

记录使用Doris进行数据治理过程中的经验技巧

背景

项目需要，使用Doris作为数据湖仓，进行数据治理。在数据集成的过程中，业务上需要将存储在ES中的海量告警数据接入到数仓原始层。

痛点

原方案选择物理入库，即将数据从ES拉到Doris中再存一份，存在诸多弊端：

1. 数据集成过程耗时耗力耗资源

   • 耗时：海量告警数据的同步读写很耗时
   • 耗力：两边数据对账耗费人力
   • 耗资源：海量数据的读写耗费计算资源、存储资源

2. 数据同步不及时

   • 新产生的告警，需要定时任务拉取，才能入湖，存在时间延迟

3. 数据对账困难

   • 经常出现数据量不一致的情况：工具Bug、增量逻辑不合理、原始数据难增量获取等原因

4. 稳定性差

   • 即使使用成熟高效的数据同步工具，也会偶现数据同步任务异常的情况。

5. 复杂度高

   • 相比逻辑入湖，物理入湖复杂度高，增加了数据同步组件，且需要专门设计原始层的目标表，要考虑分区逻辑

解决方案

四个字：逻辑入湖！！！

这似乎很简单，显得之前的技术决策很没有水平，实则不然

Catalog方案（我所在业务中不可行）

Doris要想实现ES数据的逻辑入湖，按照官方文档，只推荐使用Catalog这一种方式，但使用此catalog存在严重缺陷：

1. 部分数据类型映射异常
   在实际业务ES的索引中，存在较多nested、join等特殊的数据类型，无法使用catalog映射（执行查询会报错），但数据治理需要（重要信息丢失，不可接受）

2. 多索引查询问题
   业务ES中，将每个月的告警存储在一个自动创建的单独的索引中（分区表的逻辑），catalog方案会将一个索引映射到一张表，会导致后续数据加工清洗困难（只能看到分区表，而看不到分区表之上的完整逻辑表）

要使用catalog方案，需满足两个条件：
1、索引稳定，以确保数据映射到一张固定的表
2、重要业务数据不会存储在Doris不支持的特殊类型中（join、地理信息类型、数组类型）

外部表方案（可行）

官方文档中在介绍catalog时，提到V2.1之前的Doris版本使用外部表，且提到catalog是外部表的增强版，然后对外部表方式未做其他介绍。

实际上，在对ES的连接中，Catalog虽有增强，却也丢失了外部表的一些关键优点:
1、可以自定义数据类型（不能解析的类型，可以强制转换）
2、可以模糊匹配多个索引，映射到一张表

示例代码

CREATE EXTERNAL TABLE public.biz_es_event( // 业务ES中的事件数据
	_id varchar comment "ES的doc id", -- 字段名固定为_id，可惜索引_index不能直接映射（注意，该ID未必唯一，因为是在多个索引中查询）
	uid varchar comment "数据的UUID",
	event_id varchar comment "事件ID",
	event_kind varchar comment "事件类型", -- int转成了string
	evnt_rel varchar comment "事件关联信息",-- join转成了string（catalog不能支持这一点）
	device_list json comment "设备列表" -- nested转成json
) engine=elasticsearch -- 指定引擎为ES
properties(
	"hosts"="http://192.168.9.101:9200",
	"index"="biz_es_event*",-- 模糊匹配多个索引，如biz_es_event-202501、biz_es_event-202502
	"user"="xxx", -- 若无认证，则删除此配置
	"password"="xxx", -- 若无认证，则删除此配置
	"enable_docvalue_scan"="false" -- 建议关闭，因为数仓需要所有的原始字段
)

外部表方案的缺点：

1. 数据对象不宜太多，否则一个个创建外部表很费劲
2. 数据对象的字段不宜太多，否则一个个写映射很费劲
3. 数据对象的字段不宜频繁变动（增删改），否则前期写好的映射会失效

尽管有以上缺点，但在我所在的业务场景下，外部表逻辑入湖方案仍能节省大量人力，值得推广