기술나눔

AsiaInfo Technology의 Apache SeaTunnel 기반 2차 개발 및 응용 사례

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

AsiaInfo Technology의 Apache SeaTunnel에서의 실질적인 공유

자기 소개

안녕하세요, 학우 여러분, Apache SeaTunnel 커뮤니티를 통해 여러분과 공유하고 소통하게 되어 영광입니다. 저는 AsiaInfo Technology의 Pan Zhihong입니다. 저는 주로 회사 내부 데이터 센터 제품 개발을 담당하고 있습니다.

파일

이번 공유의 주제는 AsiaInfo Technology의 Apache SeaTunnel 통합 사례입니다. 구체적으로 우리 데이터 센터가 SeaTunnel을 통합하는 방법에 대해 이야기하겠습니다.

콘텐츠 개요 공유

이번 공유에서는 다음 측면에 중점을 둘 것입니다.

  • SeaTunnel을 선택하는 이유
  • SeaTunnel을 통합하는 방법
  • SeaTunnel 통합 중 발생하는 문제
  • SeaTunnel 2차 개발
  • SeaTunnel에 대한 기대

SeaTunnel을 선택하는 이유

먼저 AsiaInfo의 데이터센터 제품 DATAOS의 반복 개발을 주로 담당하고 있다는 점을 소개하겠습니다. DATAOS는 데이터 통합, 데이터 개발, 데이터 거버넌스, 데이터 개방성과 같은 기능 모듈을 다루는 비교적 표준적인 데이터 센터 제품입니다. SeaTunnel과 관련된 가장 중요한 것은 데이터 통합을 주로 담당하는 데이터 통합 ​​모듈입니다.

SeaTunnel을 도입하기 전 데이터 통합 ​​모듈의 기능 아키텍처는 다음과 같았습니다.

파일

  • 일괄 구매: 라이브러리 테이블 수집과 파일 수집으로 구분됩니다.
    • 라이브러리 테이블 컬렉션: 주로 DataX를 사용하여 구현됩니다.
    • 파일 수집: 자체 개발한 DP 엔진.
    • ETLt 수집: 자체 개발한 ETLt 수집 엔진입니다. DataX는 데이터 추출 및 저장 후 복잡한 변환에 적합한 ELT(추출, 로드, 변환)를 선호합니다. 그러나 일부 시나리오에서는 EL small T(추출, 로드, 단순 변환)가 필요하며 DataX는 적합하지 않습니다. 그래서 우리는 Spark SQL 기반의 엔진을 개발했습니다.
  • 리우카이: 로그 수집은 주로 Filebeat를 기반으로 하며, CDC 수집은 주로 Flink CDC를 기반으로 합니다.

우리의 데이터 통합 ​​모듈에서 전체 아키텍처는 데이터 통합 ​​프론트 데스크, 스케줄링 플랫폼 및 데이터 통합 ​​서비스의 세 가지 계층으로 나뉩니다.

파일

각 레이어에 대한 자세한 설명은 다음과 같습니다.

첫 번째 레이어: 데이터 통합 ​​프론트 데스크

데이터 통합 ​​프론트 데스크는 주로 데이터 통합 ​​업무 관리를 담당합니다. 구체적으로는 업무 개발, 스케줄링 개발, 운영 모니터링 등이 포함됩니다. 이러한 작업은 DAG(방향성 비순환 그래프)를 통해 다양한 통합 연산자를 결합하여 복잡한 데이터 처리 프로세스를 구현합니다. 프런트 엔드 인터페이스는 직관적인 작업 관리 인터페이스를 제공하므로 사용자는 데이터 통합 ​​작업을 쉽게 구성하고 모니터링할 수 있습니다.

두 번째 계층: 스케줄링 플랫폼

스케줄링 플랫폼은 작업 작업의 스케줄링 및 관리를 담당합니다. 일괄 처리와 스트림 처리 모드를 모두 지원하며 작업 종속성과 예약 전략에 따라 해당 작업을 가져올 수 있습니다.

세 번째 계층: 데이터 통합 ​​서비스

데이터 통합 ​​서비스는 전체 데이터 센터 서비스의 핵심이며 일련의 주요 기능을 제공합니다.

  • 작업 관리 인터페이스: 작업 생성, 삭제, 업데이트, 조회 등의 기능을 포함합니다.
  • 작업 시작 및 중지 인터페이스: 사용자가 특정 작업을 시작하거나 중지할 수 있습니다.
  • 작업 상태 쿼리 인터페이스: 작업의 현재 상태 정보를 조회하여 모니터링 및 관리를 용이하게 합니다.

데이터 통합 ​​서비스는 특정 작업 실행도 담당합니다. 수집 작업에는 여러 엔진이 포함될 수 있으므로 작업이 실행될 때 다중 엔진 조정과 예약이 필요합니다.

작업 실행 프로세스

작업 실행에는 주로 다음 단계가 포함됩니다.

  1. 작업 예약: 미리 결정된 스케줄링 전략 및 종속성에 따라 스케줄링 플랫폼은 해당 작업을 가져옵니다.
  2. 작업 실행: 작업 실행 중에는 작업의 DAG 구성에 따라 각 연산자가 순차적으로 실행됩니다.
  3. 다중 엔진 조정: 여러 엔진이 포함된 작업(예: DataX 및 Spark 하이브리드 작업)의 경우 작업의 원활한 실행을 보장하기 위해 실행 프로세스 중에 각 엔진의 작동을 조정해야 합니다.
자원 할당

동시에 독립 실행형 작업인 DataX가 분산 방식으로 더 잘 실행되고 리소스 재사용을 달성하기 위해 DataX 작업에 대한 리소스 할당을 최적화했습니다.

  • 분산 스케줄링: 리소스 할당 메커니즘을 통해 DataX 작업은 단일 지점 병목 현상을 방지하고 작업 병렬성과 실행 효율성을 향상시키기 위해 여러 노드에서 실행되도록 분산됩니다.
  • 자원 재사용: 합리적인 자원 관리 및 배분 전략을 통해 다양한 업무에 대한 자원의 효율적인 재사용을 보장하고 자원 낭비를 줄입니다.
작업 실행 에이전트

우리는 작업의 통합 관리 및 모니터링을 달성하기 위해 각 실행 엔진에 해당하는 작업 실행 에이전트를 구현합니다.

  • 실행 엔진 에이전트 : 데이터 통합 ​​서비스에서는 에이전트가 DataX, Spark, Flink CDC 등 다양한 실행 엔진을 관리합니다. 에이전트는 작업의 시작, 중지 및 상태 모니터링을 담당합니다.
  • 통합 인터페이스: 서로 다른 엔진의 작업을 동일한 인터페이스를 통해 관리할 수 있도록 통일된 작업 관리 인터페이스를 제공하여 운영, 유지 관리 작업을 단순화합니다.

파일

기존 데이터 통합 ​​아키텍처의 몇 가지 문제

우리는 DataX, Spark, Flink CDC, Filebeat 등과 같은 일부 오픈 소스 프로젝트를 통합하여 강력한 데이터 통합 ​​서비스 플랫폼을 구성했습니다. 그러나 우리는 또한 몇 가지 문제에 직면합니다:

  • 단일 기계 작동 제한: DataX는 단일 시스템 작업만 지원하므로 이를 기반으로 분산 스케줄링 기능을 구현해야 하므로 시스템이 더욱 복잡해집니다.
  • 기술 스택이 너무 다양함: Spark, Flink 등의 여러 기술 스택을 도입하면 기능이 풍부하지만 연구 개발 비용도 높아집니다. 새로운 기능이 개발될 때마다 여러 기술 스택의 호환성 및 통합 문제를 처리해야 합니다.
아키텍처의 진화

아키텍처를 최적화하고 복잡성을 줄이기 위해 우리는 기존 아키텍처를 발전시켰습니다.

  • 다중 엔진 기능 통합: SeaTunnel 도입 후, 여러 엔진의 기능을 통합하고 단일 플랫폼에서 다양한 데이터 처리 기능을 구현할 수 있습니다.
  • 리소스 관리 단순화: SeaTunnel의 자원 관리 기능은 DataX와 같은 독립형 작업의 분산 스케줄링을 단순화하고 자원 할당 및 관리의 복잡성을 줄입니다.
  • R&D 비용 절감: 통일된 아키텍처와 인터페이스 설계를 통해 다중 기술 스택으로 인한 개발 및 유지 관리 비용을 절감하고, 시스템의 확장성과 유지 관리 용이성을 향상시킵니다.

아키텍처의 최적화와 진화를 통해 DataX 단일 머신 작동 제한과 여러 기술 스택으로 인한 높은 R&D 비용 문제를 성공적으로 해결했습니다.

SeaTunnel을 도입한 후, 하나의 플랫폼에서 여러 데이터 처리 기능을 구현하는 동시에 리소스 관리 및 작업 스케줄링을 단순화하고 시스템의 전반적인 효율성과 안정성을 향상시킬 수 있었습니다.

SeaTunnel을 선택하는 이유는 무엇입니까?

SeaTunnel과의 접촉은 Waterdrop 시대로 거슬러 올라가며 Waterdrop에 대한 많은 적용 사례를 수행했습니다.

파일

SeaTunnel은 작년에 Zeta 엔진을 출시하고 분산 아키텍처를 지원하며 최상위 Apache 프로젝트가 되었습니다. 이를 통해 작년에 적절한 시점을 찾고 심층적인 연구를 수행하여 SeaTunnel 도입을 결정했습니다.

SeaTunnel을 선택한 주요 이유는 다음과 같습니다.

  1. 뛰어난 건축 디자인
    • SeaTunnel은 우리의 요구에 잘 맞는 분산 아키텍처를 갖추고 있습니다.
    • API 설계가 표준화되어 있으며 SPI(Service Provider Interface) 모드를 채택하여 확장 및 통합이 용이합니다.
  2. 적극적인 커뮤니티 지원
    • SeaTunnel은 커뮤니티 분위기가 좋은 최상위 Apache 프로젝트로, 활발한 개발자 및 사용자 그룹이 문제 해결 및 기능 확장을 강력하게 지원합니다.
    • 국내 오픈소스 프로젝트의 배경은 우리의 소통과 협업을 더욱 원활하게 만들어줍니다.
  3. 풍부한 기능 및 데이터 소스 지원
    • SeaTunnel은 다양한 데이터 소스를 지원하며 다양한 데이터 처리 요구 사항을 충족하는 풍부한 기능을 갖추고 있습니다.
    • CDC(Change Data Capture)를 지원하여 실시간 데이터 동기화 및 처리가 가능합니다.
    • 일대다 데이터 전송 모드를 지원하여 데이터 전송의 유연성을 향상시킵니다.
  4. 기술 스택 적합성
    • SeaTunnel은 Java와 호환되며 Flink 및 Spark를 지원하므로 기존 기술 스택에 원활하게 통합하고 적용할 수 있습니다.
    • CDC 데이터 캡처에 Debezium을 사용하면 기술이 성숙하고 안정적입니다.
  5. 다중 엔진 지원
    • SeaTunnel은 Zeta, Flink 및 Spark를 포함한 다양한 컴퓨팅 엔진을 지원하며 특정 요구 사항에 따라 계산에 가장 적합한 엔진을 선택할 수 있습니다.
    • 이는 다양한 시나리오에서 최적의 컴퓨팅 모드를 선택하여 시스템의 유연성과 효율성을 향상시킬 수 있기 때문에 매우 중요합니다.
  6. 뛰어난 성능
    • SeaTunnel은 효율적이고 안정적인 데이터 처리를 보장하기 위해 2단계 커밋, 내결함성 복구, 스레드 공유 등의 성능 최적화 메커니즘을 설계했습니다.
SeaTunnel 도입 후 해결된 문제

SeaTunnel은 앞서 언급한 두 가지 주요 문제를 해결합니다.

  1. 분산 스케줄링
    • DataX는 단일 시스템에서만 실행될 수 있으며 추가적인 분산 스케줄링 기능을 구현해야 합니다. SeaTunnel은 본질적으로 분산 아키텍처를 지원합니다. 컴퓨팅 엔진으로 Zeta, Flink 또는 Spark를 사용하더라도 분산 데이터 처리를 쉽게 구현하여 작업을 크게 단순화할 수 있습니다.
  2. 기술 스택 통합
    • 이전에는 DataX, Spark, Flink CDC 등 다양한 기술 스택을 사용했기 때문에 R&D 비용이 높고 시스템이 복잡했습니다. SeaTunnel은 이러한 기술 스택을 균일하게 캡슐화함으로써 ELT 및 ETL 프로세스를 모두 지원할 수 있는 통합 플랫폼을 제공하여 시스템 아키텍처를 크게 단순화하고 개발 및 유지 관리 비용을 절감합니다.

SeaTunnel을 통합하는 방법

SeaTunnel을 통합하기 전에 우리의 기존 아키텍처는 프런트 데스크, 일정 관리 플랫폼 및 데이터 통합 ​​서비스의 세 가지 계층으로 나누어져 한동안 실행되었습니다. 프론트 데스크는 작업 관리 및 개발을 담당하고, 스케줄링 플랫폼은 작업 스케줄링 및 종속성 관리를 담당하며, 데이터 통합 ​​서비스는 모든 데이터 통합 ​​작업을 실행하고 관리하는 핵심 부분입니다.

다음은 SeaTunnel 통합 후의 새로운 아키텍처입니다.

파일

첫째, DataX와 관련된 기존 아키텍처의 리소스 할당 부분을 제거했습니다. SeaTunnel 자체는 분산 아키텍처를 지원하므로 더 이상 추가적인 리소스 할당 관리가 필요하지 않습니다. 이러한 조정으로 인해 아키텍처가 크게 단순화되었습니다.

기술 스택 교체

우리는 점차적으로 오래된 기술 스택을 SeaTunnel로 교체했습니다. 구체적인 단계는 다음과 같습니다:

  1. 일괄 처리 작업 교체: 먼저 일괄 처리 ETL을 위해 DataX 및 Spark를 사용했던 이전 아키텍처의 일부를 교체했습니다.
  2. 스트림 처리 작업 교체: 다음으로 스트림 처리를 위해 Flink CDC를 사용하여 부품을 점진적으로 교체합니다. 이러한 단계별 접근 방식을 취함으로써 점진적인 전환 과정에서 시스템이 안정적으로 유지되도록 할 수 있습니다.
구성요소화된 SeaTunnel 커넥터

SeaTunnel의 Connector를 기반으로 컴포넌트 기반 설계를 진행하였고, 프론트엔드에서 폼을 통한 구성 및 DAG 오케스트레이션을 수행하였습니다. SeaTunnel Web도 유사한 작업을 수행하고 있지만 기존 시스템과 더 잘 통합하기 위해 자체 요구 사항에 따라 개발을 맞춤화했습니다.

작업 실행 에이전트

에이전트를 실행하는 작업의 경우 SeaTunnel 클라이언트를 통해 작업을 제출하고 SeaTunnel 클라이언트의 상태 및 실행 로그를 모니터링합니다. 이러한 로그를 구문 분석함으로써 작업 실행 상태 정보를 얻고 작업 실행의 모니터링 및 추적성을 보장할 수 있습니다.

다중 엔진 하이브리드 개발

다중 엔진 하이브리드 개발을 지원하고, 첫 페이지의 스케줄링 작업에 대해 다중 엔진 DAG 오케스트레이션을 수행할 수 있습니다. 이러한 방식으로 작업 개발을 위해 하나의 예약 작업에서 동시에 다양한 엔진(예: SQL 엔진 및 DP 엔진)을 사용할 수 있어 시스템의 유연성과 확장성이 향상됩니다.

SeaTunnel 통합 중 발생하는 문제

SeaTunnel을 통합하는 과정에서 몇 가지 문제에 직면했습니다. 다음은 몇 가지 대표적인 문제와 해결 방법입니다.

질문 1: 오류 처리

SeaTunnel을 사용하는 과정에서 프레임워크 코드와 관련된 몇 가지 오류 보고서를 접했습니다. 공식 문서에는 관련 지침이 없기 때문에 커뮤니티 WeChat 그룹에 가입하여 그룹의 개발자에게 도움을 요청하고 문제를 제 시간에 해결했습니다.

질문 2: 작업 전환

이전 수집 작업은 DataX를 사용하여 구현되었습니다. 이를 SeaTunnel로 교체할 때 작업 컷오버 문제를 고려해야 합니다.

우리는 다음 솔루션을 통해 이를 해결합니다.

  • 부품 설계 : 중간 사무실의 데이터 수집 작업은 구성 요소 기반으로 설계되었으며 프런트 엔드 구성 요소와 백엔드 실행 엔진 사이에 변환 레이어가 있습니다. 프런트엔드는 양식을 구성하고 백엔드는 DataX가 변환 계층을 통해 실행하는 데 필요한 JSON 파일을 생성합니다.
  • 유사한 JSON 파일 생성 : SeaTunnel의 구성은 DataX의 구성과 유사합니다. 프런트엔드도 양식을 통해 구성되며, SeaTunnel이 실행해야 하는 JSON 파일이 백엔드에서 생성됩니다. 이러한 방식으로 우리는 이전 작업을 새로운 SeaTunnel 플랫폼으로 원활하게 이전하여 작업의 원활한 전환을 보장할 수 있습니다.
  • SQL 스크립트 변환 : SeaTunnel에 적응할 수 있도록 이전 DataX 작업을 정리하고 변환하는 SQL 스크립트를 작성합니다. 이 방법은 SeaTunnel이 자주 업데이트되고 호환성을 위해 직접 하드 코딩을 작성하는 것은 장기적인 솔루션이 아니기 때문에 더 유연하고 적응성이 뛰어납니다. 스크립트 변환을 통해 작업을 보다 효율적으로 마이그레이션하여 SeaTunnel 업데이트에 적응할 수 있습니다.
질문 3: 버전 관리

SeaTunnel을 사용하는 동안 버전 관리 문제가 발생했습니다. SeaTunnel은 자주 업데이트되므로 우리 팀은 두 번째 버전에 대한 최신 버전을 지속적으로 후속 조치해야 합니다. 우리의 솔루션은 다음과 같습니다.

현지 지점 관리 : SeaTunnel 버전 2.3.2를 기반으로 로컬 브랜치를 뽑아 개인별 요구사항 수정, 임시 버그 수정 등 2차 개발을 진행했습니다. 로컬에서 유지 관리되는 코드의 양을 최소화하기 위해 필요한 변경 사항만 유지하고 다른 부분에는 커뮤니티의 최신 버전을 사용하려고 노력합니다.

정기적으로 통합된 커뮤니티 업데이트 : 우리는 정기적으로 커뮤니티의 새 버전을 로컬 브랜치에 병합합니다. 특히 업데이트하고 변경한 부분과 호환되도록 만듭니다. 이 방법은 불편하기는 하지만 이를 통해 커뮤니티의 최신 기능과 수정 사항을 최신 상태로 유지할 수 있습니다.

지역사회에 환원하세요 : 코드를 더 잘 관리하고 유지하기 위해 일부 변경 사항과 개인화된 요구 사항을 커뮤니티에 제출하여 커뮤니티의 수용과 지원을 위해 노력할 계획입니다. 이는 지역 유지 관리 작업을 줄이는 데 도움이 될 뿐만 아니라 지역 사회가 함께 발전하는 데에도 도움이 됩니다.

SeaTunnel 2차 개발 및 실습

SeaTunnel을 사용하는 동안 우리는 특히 커넥터 수준에서 실제 비즈니스 요구 사항을 기반으로 여러 가지 2차 개발을 수행했습니다. 2차 개발 과정에서 겪었던 문제점과 해결 방법은 다음과 같습니다.

파일

Hive 커넥터 혁신

  • 원래 SeaTunnel Hive 커넥터는 메타 URL을 사용하여 메타데이터를 얻습니다. 그러나 실제 애플리케이션에서는 보안 문제로 인해 많은 타사 사용자가 메타 URL을 제공할 수 없습니다. 이 상황을 처리하기 위해 다음과 같은 변경 사항을 적용했습니다.
    • Hive Server 2의 JDBC 인터페이스를 사용하여 테이블의 메타데이터 정보를 얻으므로 메타 URL에 대한 의존성을 피할 수 있습니다.
  • 이러한 방식으로 우리는 사용자에게 데이터 보안을 보장하면서 Hive 데이터를 보다 유연하게 읽고 쓸 수 있는 기능을 제공할 수 있습니다.

Hangao 데이터베이스 지원

  • Hangao 데이터베이스는 우리 프로젝트에서 널리 사용되므로 Hangao 데이터베이스에 대한 데이터 소스 읽기 및 쓰기 지원을 추가했습니다. 동시에 우리는 Hangao 데이터베이스의 특별한 요구 사항을 충족하기 위해 변환 구성 요소를 개발했습니다.
  • 행에서 열로, 열에서 행으로 같은 복잡한 변환 작업을 지원합니다.
  • 데이터 둔감화 및 기타 작업을 위한 다양한 UDF(사용자 정의 함수)를 작성했습니다.

파일 커넥터 수정

  • 파일 시스템 커넥터는 사용 시 중요한 역할을 하므로 이에 대해 몇 가지 변경 사항을 적용했습니다.
  • HDFS 커넥터: 여러 파일 형식(RC, Sequence, XML, JSON 등) 읽기 및 쓰기를 지원하는 동시에 파일의 디렉터리 재귀 및 정규식 검색 기능을 추가했습니다.
  • FTP 및 SFTP 커넥터: I/O 누출 버그를 수정하고 연결 캐싱 메커니즘을 최적화하여 동일한 IP를 가진 서로 다른 계정 간의 독립성을 보장합니다.
2단계 제출 메커니즘 최적화

SeaTunnel을 사용하는 과정에서 우리는 데이터 일관성을 보장하기 위해 2단계 제출 메커니즘을 심층적으로 이해했습니다. 이 과정에서 발생한 문제와 해결 방법은 다음과 같습니다.파일

문제 설명 : FTP 및 SFTP를 사용하여 파일을 쓸 때 쓰기 권한이 없다는 오류 메시지가 나타납니다. 조사 결과 SeaTunnel은 데이터 일관성을 보장하기 위해 먼저 파일을 임시 디렉터리에 쓴 다음 이동하는 것으로 나타났습니다.

그러나 임시 디렉터리에 다른 계정의 권한 설정으로 인해 쓰기에 실패했습니다.

해결책 : 임시 디렉터리를 생성할 때 모든 계정에 쓰기 권한이 있도록 더 큰 권한(예: 777)을 설정하세요. 동시에 파일 이동 중 파일 시스템 간으로 인해 이름 바꾸기 명령이 실패하는 문제를 해결합니다. 동일한 파일 시스템 아래에 임시 디렉터리를 생성하면 파일 시스템 간 작업이 방지됩니다.

2차 개발 관리

2차 개발 과정에서 우리는 SeaTunnel의 새 버전을 어떻게 관리하고 동기화할지에 대한 문제에 직면했습니다. 우리의 솔루션은 다음과 같습니다:

  • 현지 지점 관리: SeaTunnel 2.3.2 버전을 기반으로 로컬 브랜치를 가져왔습니다.
  • 정기적으로 통합된 커뮤니티 업데이트: 커뮤니티의 새 버전을 정기적으로 로컬 브랜치에 병합하여 적시에 커뮤니티에서 새로운 기능과 수정 사항을 얻을 수 있도록 합니다.
  • 지역사회에 환원하세요: 커뮤니티의 수용과 지원을 얻기 위해 일부 변경 사항과 개인화된 요구 사항을 커뮤니티에 제출하여 로컬 유지 관리 작업량을 줄일 계획입니다.
SeaTunnel 통합 및 애플리케이션

SeaTunnel 통합 과정에서 우리는 주로 다음 사항에 중점을 둡니다.

  • 자원 할당 최적화: SeaTunnel의 분산 아키텍처를 활용하면 자원 할당 문제가 단순화되고 더 이상 추가 분산 스케줄링 기능이 필요하지 않습니다.
  • 기술 스택 통합: DataX, Spark, FlinkCDC 등 다양한 기술 스택의 기능을 SeaTunnel에 통합하고 균일하게 캡슐화하여 ETL과 ELT의 통합을 달성합니다.

위의 단계와 전략을 통해 SeaTunnel을 데이터 통합 ​​서비스에 성공적으로 통합하고 기존 시스템의 몇 가지 주요 문제를 해결했으며 시스템의 성능과 안정성을 최적화했습니다.

이 과정에서 우리는 통합 작업이 원활하게 진행될 수 있도록 커뮤니티에 적극적으로 참여하고 문제에 대한 도움을 구하고 피드백을 제공합니다. 이러한 긍정적인 상호 작용은 기술 수준을 향상시킬 뿐만 아니라 SeaTunnel 커뮤니티의 발전을 촉진합니다.

오픈소스 커뮤니티 참여 경험

저는 SeaTunnel에 참여하면서 다음과 같은 경험을 했습니다.

  • 시간이 딱 맞아 : SeaTunnel의 급속한 개발 단계에서 이 프로젝트를 선택했는데 타이밍이 매우 좋았습니다. SeaTunnel의 개발을 통해 우리는 할 수 있는 일이 많다는 확신을 갖게 되었습니다.
  • 개인적인 목표: 올해 초 오픈소스 커뮤니티에 참여하겠다는 목표를 세우고 적극적으로 실천에 옮겼습니다.
  • 지역사회 친화성 : SeaTunnel 커뮤니티는 매우 친절하며, 모두가 원활하게 의사소통하고 서로를 돕습니다. 이러한 긍정적인 분위기는 제가 그 일부가 되는 것을 매우 가치 있게 만듭니다.

오픈소스 커뮤니티에 늘 참여하고 싶었지만 아직 첫발을 떼지 못한 분들에게 힘찬 도약을 격려하고 싶습니다. 커뮤니티에서 가장 중요한 것은 커뮤니티에 가입하는 한 커뮤니티에 없어서는 안 될 구성원입니다.

SeaTunnel에 대한 기대

마지막으로 SeaTunnel에 대한 몇 가지 기대 사항을 공유하고 싶습니다.

파일

  • 문서 개선: 커뮤니티에서 데이터 소스 버전 목록 및 스트레스 테스트 보고서를 포함하여 문서를 더욱 개선할 수 있기를 바랍니다.
  • 클러스터 관리: SeaTunnel이 클러스터 내에서 리소스 격리를 달성하고 보다 풍부한 클러스터 상태 모니터링 정보를 제공할 수 있기를 바랍니다.
  • 데이터 내결함성: SeaTunnel에는 이미 내결함성 메커니즘이 있지만 앞으로 더욱 최적화될 수 있기를 바랍니다.
  • AI 통합: SeaTunnel이 AI 지원 액세스를 촉진하기 위해 더 많은 인터페이스를 제공할 수 있기를 바랍니다.

SeaTunnel 커뮤니티의 모든 회원 여러분의 노고에 감사드립니다. 그게 제가 공유한 전부입니다. 모두 감사합니다!

이 글의 작성자는 다음과 같습니다. 벨루가 오픈 소스 기술 출판 지원 가능!