OpenMetadata社区贡献实战从零实现Doris连接器的完整指南第一次在GitHub上看到OpenMetadata项目时我就被它优雅的元数据管理架构所吸引。作为一个长期与数据打交道的开发者我深知统一元数据管理的重要性。然而当我尝试将公司使用的Apache Doris接入时却发现1.2版本尚未支持这个新兴的OLAP引擎。这成为了我向OpenMetadata提交第一个PR的契机——下面我将完整分享这次技术贡献的全过程包括技术实现细节和社区协作经验。1. 理解OpenMetadata连接器架构在动手编码前我花了三天时间系统阅读OpenMetadata的文档和源码。这个项目采用模块化设计每个数据源连接器都由四个核心部分组成JSON Schema定义- 位于openmetadata-spec/src/main/resources/json/schema目录定义连接参数的验证规则前端UI组件- 在openmetadata-ui中实现数据源配置界面Python元数据提取逻辑- 位于ingestion/src/metadata/ingestion/source/database测试用例- 包含连接测试和元数据提取测试以MySQL连接器为参考我梳理出需要实现的文件结构openmetadata-spec/ └── src/main/resources/json/schema/ ├── entity/services/connections/database/ │ └── dorisConnection.json └── entity/data/table.json ingestion/ ├── setup.py └── src/metadata/ingestion/source/database/ └── doris/ ├── __init__.py ├── connection.py ├── metadata.py └── queries.py openmetadata-ui/ └── src/main/resources/ui/src/ ├── assets/img/service-icon-doris.png └── utils/ServiceUtils/ └── ServiceUtil.tsx提示在开始编码前务必仔细阅读项目的CONTRIBUTING.md文件了解代码风格、提交规范等要求。我最初就因为没遵循提交信息规范而被要求修改。2. 定义Doris连接规范创建dorisConnection.json时我参考了MySQL的实现但做了Doris特有的调整。关键配置项包括{ $schema: http://json-schema.org/draft-07/schema#, title: DorisConnection, type: object, properties: { hostPort: { description: 格式为host:portDoris默认FE端口为9030, type: string }, httpPort: { description: HTTP API端口默认为8030, type: integer, default: 8030 }, queryPort: { description: MySQL协议查询端口默认为9030, type: integer, default: 9030 } }, required: [hostPort, queryPort] }Doris特有的数据类型需要在table.json中补充{ definitions: { dataType: { enum: [ HLL, BITMAP, QUANTILE_STATE, LARGEINT, AGG_STATE ] } } }3. 实现Python元数据提取层在Python实现部分核心是继承Source基类并实现以下方法# ingestion/src/metadata/ingestion/source/database/doris/connection.py from metadata.ingestion.source.database.common_db_source import CommonDbSource class DorisSource(CommonDbSource): classmethod def create(cls, config_dict, metadata_config): return cls(config_dict, metadata_config) def get_schema_names(self) - Iterable[str]: query SHOW DATABASES results self.engine.execute(query) return [row[0] for row in results if row[0] not in (information_schema)]Doris特有的元数据查询语句放在queries.py中# queries.py GET_TABLE_STATISTICS SELECT COUNT(*) AS row_count, SUM(data_size) AS data_size FROM information_schema.tables WHERE table_schema %(schema)s AND table_name %(table)s 4. 前端集成实战UI部分需要新增Doris的Logo和配置表单。关键步骤将Doris图标放入src/assets/img目录在ServiceUtil.tsx中注册新的服务类型// ServiceUtil.tsx export enum ServiceTypes { DORIS Doris, // ...其他服务类型 } export const serviceTypesConfig { [ServiceTypes.DORIS]: { label: Apache Doris, value: ServiceTypes.DORIS, logo: /assets/img/service-icon-doris.png, docLink: https://doris.apache.org } };创建连接表单组件Form.Item name{[config, queryPort]} labelQuery Port rules{[{ required: true }]} initialValue{9030} InputNumber min{1} max{65535} / /Form.Item5. 测试与CI/CD挑战编写测试用例时我遇到了几个典型问题连接超时发现Doris的默认连接超时太短需要在测试配置中调整testConnection: timeout: 30000 # 30秒超时类型映射问题Doris的BITMAP类型需要特殊处理def get_column_type(self, column_type: str): if BITMAP in column_type: return ARRAYBIGINT return super().get_column_type(column_type)CI环境依赖需要在.github/workflows中添加pydoris依赖- name: Install dependencies run: | pip install pydoris0.1.0 pip install -e .[doris]6. 社区协作经验PR提交后我与维护者进行了多轮有价值的讨论代码审查意见建议将HTTP端口配置改为可选参数要求补充完整的单元测试覆盖率提示需要更新文档中的支持数据源列表有效沟通技巧对每个审查意见都给出明确回应复杂修改拆分为独立commit在PR描述中详细说明测试方案解决冲突当主干有更新时使用rebase而非mergegit fetch upstream git rebase upstream/main git push -f origin doris-connector最终PR被合并时我总结了几个关键收获提前在GitHub Issue中讨论方案能减少返工保持小颗粒度的提交便于审查完善的测试用例是获得信任的关键及时响应社区反馈能加速合并流程这次贡献经历让我深刻体会到参与开源不仅是提交代码更是学习工程规范和协作文化的过程。当看到自己的代码被合并到主干时那种成就感远超预期。