This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @mikolaj_wawrzyniak @jdrpereira @pskorupa @DylanGriffith @nhxnguyen workinggroup clickhouse 2023-02-23

ClickHouse 또는 대체제와 상호 작용하기 위한 추상화 레이어를 고려해보세요

목차

요약

ClickHouse를 설치하지 않을 GitLab 설치에 대한 ClickHouse 또는 대체 제품의 통합 읽기 액세스를 표준화하는 솔루션을 제공합니다. 오픈 소스 도구를 분석하고 내부 솔루션을 빌드하는 옵션과 대조하여 현재 권장되는 접근 방법은 각 데이터 소스에 연결하기 위해 전용 데이터베이스 레벨 드라이버를 사용하는 것을 제안합니다. 추가로, 저장소 패턴을 사용하여 옵션으로 데이터베이스의 가용성 복잡성을 단일 응용 프로그램 레이어로 제한하는 것을 제안합니다.

동기

ClickHouse는 실행에 상당한 리소스가 필요하며 GitLab의 더 작은 설치는 제공된 성능 향상으로는 투자 수익을 얻을 수 없을 수 있습니다. 이는 ClickHouse가 모든 설치에 대해 전역적으로 사용 가능하지 않을 수 있으며 기능이 사용 가능한 다른 데이터 저장소 사이에서 번갈아 가며 필요할 수도 있음을 의미합니다. 이미 제안된 현재 및 미래의 ClickHouse 사용 사례들 중 10개 중 7개가 ClickHouse 이외의 데이터 저장소를 사용합니다. 이러한 맥락을 고려하면 사용 가능한 데이터 저장소와의 상호 작용을 표준화하여 ClickHouse를 채택하려는 노력을 지원하는 것이 중요합니다.

제안된 솔루션은 독립적으로 통합된 툴링을 사용하여 서로 다른 데이터 저장소와의 상호 작용에 대한 통일된 인터페이스를 제공하는 것부터 각 데이터 저장소를 지원하는 라이브러리 집합에 이르기까지 여러 형태로 나타날 수 있습니다. 그것은 구현 규칙과 제한 사항을 기술하고 캡슐화의 경계를 그립니다.

목표

  • 단일 추상화 레이어에서 가용한 데이터 저장소의 전체 GitLab 애플리케이션 코드베이스에 미치는 영향 제한하기
  • 모든 데이터 저장소 특정 기능 지원
  • 주 GitLab 애플리케이션의 위성 서비스와의 통신 지원

비목표

  • 이 제안서는 데이터베이스와의 직접적인 쓰기 통신을 고려하지 않습니다. 이는 보완적 노력의 주제입니다.
  • 이 제안서는 스키마 변경 및 데이터 이전 도전을 직접적으로 고려하지 않습니다.

위의 내용이 비목표임에도 불구하고, 이들이 최종 솔루션에 일부 변경을 요구할 수 있음을 인정합니다. 이는 오픈 질문 섹션의 끝에서 표현되어 있습니다.

가능한 해결책

이전 단락에서 기술한 고수준 목표는 사내 빌드 솔루션으로도, 오픈 소스 도구 채택을 통해서도 달성할 수 있습니다. 다음 섹션에서는 두 가지 방법을 더 자세히 살펴보겠습니다.

권장하는 접근 방법

MVC와 반복의 정신에서, 대응하는 데이터 저장소와 직접적으로 상호 작용하는 드라이버를 활용하는 솔루션부터 시작하는 것이 제안됩니다. 현재 설정 기준을 달성하고 동기 섹션에 나열된 문제를 완화하기 위해 이러한 드라이버들은 정적 코드 분석으로 강제되는 개발 가이드라인 집합을 지원해야 합니다.

이러한 솔루션은 오픈 소스 도구에 의해 부과될 수 있는 제한 사항에 대한 우려를 표명한 워킹 그룹의 다른 구성원들로부터의 피드백을 받은 후에 선정된 것으로, ClickHouse의 모든 기능을 최대한 활용하는 데 그룹들을 막을 수 있는 제한 사항에 대해 우려를 표명함으로써 선정되었습니다. 이 문서에 대해 협조하는 멤버들은 오픈 소스 도구가 부과하는 제한 사항에 의해 모든 기능을 완전히 활용할 수가 없을 수 있다는 우려에 동의합니다. 그들은 그룹들이 계획된 작업 그룹 기준 주변에서 협력하고, 그 우려에 대해 걱정하고 제한 사항을 완화할 수 있는 포괄적인 프로토타입 집합을 빌드하는 데 필요한 시간과 노력은 이 워킹 그룹의 한계를 초과합니다. ClickHouse 채택이 조사 중이며, 그룹들이 아직 그들의 요구 사항을 명시할 수도 없을 수 있음에 중요성을 두어야 합니다.

제안된 드라이버

ClickHouse 문서를 따르면 다음 Ruby 및 Go 드라이버가 있습니다

Ruby
  1. ClickHouse Ruby 드라이버 - 이전에 Observability 그룹의 연구 부분으로 GitLab 사용을 위해 선정되었습니다 (참조: 이슈)
  2. Clickhouse::Activerecord
Go
  1. ClickHouse/clickhouse-go - 공식 SQL 데이터베이스 클라이언트.
  2. uptrace/go-clickhouse - 대체 클라이언트.
제안된 클라이언트 아키텍처

코드베이스를 잘 구성하고 특정 데이터베이스 엔진에 결합되지 않도록 유지하려면, 해당 인터페이스를 상위 레이어에 표시할 단일 애플리케이션 레이어에 데이터 상호 작용을 캡슐화하는 것이 중요합니다. 이렇게 함으로써 ClickHouse 드라이버와 직접 상호 작용하는 일련의 클래스가 최하위 추상화 레이어에서 예상될 수 있으며, Rails에서 구현된 MVC 패턴을 따르는 모델로 분류될 수 있습니다.

모델 수준의 추상화는 기존 패턴과 지침을 잘 적용하지만, 단점은 ClickHouse 데이터베이스 엔진의 선택적 가용성 도전을 해결하지는 못합니다. 함께 주어진 필요성을 다루기 위해 비즈니스 로직 요청을 처리하기 위한 최상위 레벨 인터페이스를 제공할 전용 엔티티를 설계해야 합니다. 이미 제공된 존재하는 추상화 지침에서 Finders가 주어진 요구 사항에 가장 가까운 이유로 인해 선택되었습니다. Finders는 자체 공개 API를 통해 특정 데이터베이스 상호 작용을 캡슐화하여 상위 레이어에서 모든 데이터베이스 공급 업체의 세부 정보를 숨기기 때문에 주어진 요구 사항에 적합합니다.

그러나 이들은 ActiveRecord ORM 프레임워크에 밀접하게 결합되어 있으며, 반환 값으로 ActiveRecord::Relation 객체를 반환하기 위해 기존 GitLab 규칙에 바운드되어 있으며, 그것들이 사용 가능한 ClickHouse에 대한 처리를 하지 못할 수 있습니다. 이러한 이유로 상기의 모든 내용을 고려할 때, 반환된 데이터가 두 개의 다른 데이터베이스에서 나올 수 있고, 서로 호환되지 않을 수도 있기 때문에 Finders가 ClickHouse의 선택적 가용성을 다루기에 적합하지 않습니다.

상기 내용을 모두 고려할 때, 이와 유사한 추상화 레벨에서 존재할 것으로 예상되는 새 엔티티를 추가하는 것이 타당할 수 있으며, 이는 특정 수준에 존재하는 활동 변경을 선택적으로 처리하는 기능을 반환해야 합니다.

필요한 분리 수준은 저장소 패턴을 사용하여 달성될 수 있습니다. 저장소 패턴은 비즈니스/도메인 로직을 데이터 액세스 관련 우려 사항에서 분리하도록 설계되었습니다. 이는 본 제안서가 찾고 있는 것과 정확히 일치합니다. 게다가 저장소 패턴은 전체 기능을 활용할 수 있는 데이터베이스에서 수행할 수 있는 작업의 제한이 없습니다.

저장소 패턴을 구현하기 위해 다음이 생성되어야 합니다.

  1. 각 지원 데이터베이스에 대한 전략, 예를 들어: MyAwesomeFeature::Repository::Strategies::ClickHouseStrategyMyAwesomeFeature::Repository::Strategies::PostgreSQLStrategy. 전략은 기본적으로 접근하는 데이터베이스와의 통신을 구현하는 책임이 있습니다.
  2. 데이터베이스와 상호 작용하는 높은 수준의 인터페이스를 노출하는 저장소. 일부 사전 정의된 기준을 사용하여 사용 가능한 전략을 선택하고 선택된 단일 저장소에 의해 사용되는 전략들. 단일 저장소에 사용되는 전략은 교환 가능하게 사용되어야 하므로 동일한 공개 인터페이스를 공유해야 합니다.
  3. 응용 프로그램 레이어에서 구현된 비즈니스 로직을 나타내는 POLO 모델. 데이터베이스에 대한 특정하지 않은 것이어야 합니다.

저장소 패턴을 기반으로 한 솔루션은 이미 Observability 그룹에 의해 구현되었습니다 (kudos to: @ahegyi, @splattael and @brodock). ErrorTracking::ErrorRepository는 PostgreSQL에서 ClickHouse로 오류 추적 기능을 마이그레이션하기 위한 지원을 제공하고 있으며, API를 통해 ClickHouse와 통합되고 있으며, 데이터베이스 선택 기준으로 기능 플래그 토글을 사용하고 있으며, 선택적 가용성 데이터베이스의 훌륭한 예입니다.

ErrorRepository는 두 가지 전략을 사용합니다.

  1. OpenApiStrategy를 사용하여 API 프록시 엔티티를 통해 ClickHouse와 상호 작용
  2. ActiveRecordStrategy를 사용하여 ActiveRecord 프레임워크를 사용하여 PostgreSQL과 상호 작용

이 두 전략은 각각 다음과 같은 PORO 모델을 사용하여 반환 데이터를 상위 레이어에 돌려주고 있습니다.

  1. Gitlab::ErrorTracking::Error
  2. Gitlab::ErrorTracking::DetailedError

게다가 ErrorRepository는 저장소 패턴이 지원하는 데이터 저장소 유형에 대한 주목할만한 유연성의 훌륭한 예를 제공하여, 단일 통일된 인터페이스 아래 라이브러리와 외부 서비스 API를 통합할 수 있음을 보여줍니다. 이 예제는 미래에 저장소 패턴이 ClickHouse 및 PostgreSQL의 필요를 넘어서 미래에 일부 유즈 케이스가 그것을 요구할 때 더 크게 확장될 수도 있음을 나타내는 가능성을 제시합니다.

이 변경 내용은 observability 그룹에 의해 기존의 ActiveRecord 모델, 서비스 및 Finders 기반의 현재 GitLab 아키텍처 사용에서 저장소 패턴으로의 마이그레이션을 지원하기 위해 문서화되어 있습니다.

클라이언트 아키텍처 강화 가능한 방법

클라이언트 측 아키텍처를 제안하는 것만으로는 완전히 보편적인 관행으로 자리 잡히기에는 충분하지 않습니다. 개발자가 무의식적으로 이에 반하는 것을 줄이기 위해 자동으로 강화해야 합니다. 리포지토리 패턴 구현을 자동으로 확인하기 위한 여러 가지 방법이 있습니다. 다음과 같습니다:

  1. Database::PreventCrossJoins과 유사한 방식으로 ActiveRecord 쿼리 구독자를 활용하여 ClickHouse의 전략 밖에서 실행되는 쿼리를 감지하는 데 사용합니다.
  2. ClickHouse 드라이버의 사용법 외에 Strategies 외부에서 ClickHouse 드라이버의 사용을 감지하도록 CodeReuse 루비 캅을 확장합니다.
  3. ClickHouse 인스턴스 존재를 확인하는 유틸리티 메소드 호출을 감지하는 rubocop 규칙을 생성합니다(예: CurrentSettings.click_house_enabled?) 이는 Repositories 외부에서 실행됩니다.

개발 단계에서 작성자는 모든 나열된 옵션을 실행 가능하고 유망하게 여기며, ClickHouse를 위한 최초 리포지토리 패턴 구현이 나타날 때까지 사용할 옵션 결정은 연기됩니다.

오픈 소스 도구 개요

이 섹션에서는 목표를 달성하기 위한 대체 접근 방식으로 고려된 기존의 제 3자 오픈 소스 솔루션에 대해 개요를 제공합니다. 그러나 권장 접근 방식으로 선택되지 않았습니다.

평가 기준

1. 라이선스 (필수 사항)
  1. 솔루션은 허용 가능한 라이선스에 따라 오픈 소스여야 합니다.
2. 다양한 데이터 저장소 지원 (필수 사항)
  1. 제안된 추상화 레이어가 ClickHouse 및 PostgreSQL을 모두 지원할 수 있는지에 대해 초점을 맞춥니다(필수 사항).
  2. 두 데이터 저장소 이상을 지원하는 경우를 고려할 수도 있습니다.
  3. 솔루션이 PostgreSQL 요구 사항의 최소 요구 버전을 지원해야 합니다.
3. 프로토콜 호환성

모든 추상화 레이어는 일반적인 추상화를 위해 도구의 API에 비해 제한된 API를 제공합니다. 이 탈퇴 기준은 공통 추상화를 위해 도구의 API를 제한하는 데 필요한 정도를 이해하려고 합니다.

  1. PostgreSQL 및 ClickHouse를 통해 수행할 수 있는 읽기 작업을 나열합니다(선택, 결합, 그룹화, 정렬, 연합 등).
  2. 제안된 추상화 레이어를 사용하여 수행할 수 있는 작업을 나열하고, 해당 작업을 실행하는 데 얼마나 복잡한지 및 해당 연산을 네이티브로 실행할 때 성능에 대한 우려사항이 있는지 확인합니다.
  3. 추상화 레이어가 지원하지 않는 경우 데이터 원본에 직접 액세스하는 기능이 여전히 작동하는지 확인하십시오. 예: ActiveRecord#execute를 사용하여 원시 SQL 문자열을 실행할 수 있습니다.
4. 운영 노력
  1. 배포 프로세스: 복잡한가요? 제안된 도구가 스택에 추가되는 라이브러리 도구인지 아니면 GitLab 시스템과 독립적으로 배포되어야 하는 추가 서비스가 필요한지 확인하십시오. 도구가 지원하는 배포 유형(Kubernetes/VM, SaaS/셀프매니지드, 지원되는 OS, 클라우드 제공자)을 확인하십시오. 오프라인 설치를 지원합니까?
  2. 운영에 필요한 하드웨어 리소스 수는 얼마나 되나요.
  3. 안정적이고 성능이 우수한 서비스를 보장하기 위해 복잡한 모니터링 및 운영이 필요합니까?
  4. 유지 관리 및 이에 대한 문서가 충분히 갖춰져 있습니까: 업그레이드, 백업 및 복원, 스케일링
  5. 고가용성 지원. 도구가 커뮤니티 링크 동안 HA 클러스터를 구축하고 셀프매니지드를 위한 장애 조치를 수행하는 방법에 대한 문서가 있습니까? 도구가 제로 다운 타임 업그레이드를 지원합니까?
  6. FIPS 및 FedRAMP 준수
  7. 복제 프로세스 및 새 도구가 GitLab Geo에 어떻게 통합되는지
  8. 개발자 경험

  9. 솔루션은 채택을 용이하게 하고 학습曲선을 줄이기 위해 명확하고 철저하게 문서화된 API를 가져야 합니다.
6. 성숙도 (있으면 좋음)
  1. 이 솔루션은 얼마나 오래되었나요? 자주 사용되는가요? 안정된 커뮤니티를 가지고 있나요? 라이선스가 분기되는 경우 포킹하는 것도 고려해야 합니다.
7. 기술 타당성
  1. 이 솔루션은 GitLab에서 사용하는 프로그래밍 언어 중 하나로 작성되어 있으므로 버그 수정 및 새 기능 추가를 보다 쉽게 할 수 있나요?
8. 상호 운용성 (필수 사항)
  1. 이 솔루션은 루비온레일즈로 작성된 주요 GitLab 애플리케이션과 함께 Go로 작성된 컨테이너 레지스트리와 같은 위성 서비스를 모두 지원할 수 있나요?

오픈 소스 솔루션

1. Cube.dev

평가

  1. 라이선스 Apache 2.0 + MIT ✅
  2. 다양한 데이터 저장소 지원 예 ✅
  3. 프로토콜 호환성 데이터 집계를 위해 OLAP 이론 개념을 사용합니다. 이는 사용량 메트릭 집계와 같은 일부 사용 사례에 유용할 수 있지만 다른 사례에는 유용하지 않을 수 있습니다. SQL 쿼리와 자체 쿼리 형식의 API가 있습니다.
  4. 운영 노력 도커 또는 k8s를 사용하여 별도의 서비스로 배포됩니다. 캐시 및 데이터 구조 저장소로서 Redis를 사용합니다.
  5. 개발자 경험 좋은 문서
  6. 성숙도 헤들리스 BI 도구 자체가 상당히 새로운 아이디어입니다. 그러나 Cube.js는 이 공간에서 주요 오픈 소스 해결책으로 보입니다. 분석 섹션은 제품 분석 스택에 대해 내부적으로 사용합니다.
  7. 기술 타당성 REST 및 GraphQL API를 사용합니다. 자체 쿼리 및 데이터 스키마 형식을 사용하지만 이에 대해 문서화가 잘 되어 있습니다. 데이터 정의는 YAML 또는 JavaScript 중 하나로 작성됩니다.

의견

해당 솔루션은 이미 ~"group::product analytics"에 의해 ClickHouse의 읽기 인터페이스로 사용되고 있으며, 첫 손으로 경험을 얻기 위해 @mwoolf와의 대화가 진행되었습니다. 핵심 결론은 다음과 같습니다:

  1. ClickHouse 드라이버는 cube.dev에 의해 커뮤니티 기반으로 제공되며, 현재 유지 관리자가 없어 새로운 주요 버전이 나올 때까지는 약간의 변경 사항이 있을 수 있지만 적어도 작동해야 합니다.
  2. Cube.dev는 Type Script 및 JavaScript로 작성되었으며, 해당 기술에 대한 엔지니어가 있습니다. 그러나 Cube.dev는 대부분 백엔드 개발자에 의해 사용될 것으로 예상되므로 해당 기술에 대한 경험이 그리 많지는 않을 것입니다.
  3. 간단한 SQL을 위한 추상화 레이어는 백엔드에 따라 올바른 쿼리를 작성할 것으로 예상합니다.
  4. 데이터 저장소별 기능(예: window funnel ClickHouse)은 다른 엔진으로 변환되지 않으므로 동일한 데이터를 나타내기 위해 추가적인 cube 스키마를 작성해야 합니다.
  5. 지금까지 성능에 문제가 되지 않았고 로컬 개발 및 AWS VPS 백만 개의 행 가져오기 부하 테스트 시 성능에 문제가 없었습니다.
  6. 대부분의 엔진에 대해 postgres SQL과 유사한 인터페이스를 노출하지만, ClickHouse에는 그렇지 않으므로 작업 그룹 사용 사례를 위해 JSON API가 더 적합할 수 있습니다.
  7. Cube.dev는 실행 중 선택적 구성 요소를 처리하기 위해 런타임에서 조건부로 사용할 수 있는 스키마를 자동으로 생성할 수 있습니다. 해당 대화의 녹화도 제공됩니다.
2. ClickHouse FDW

평가

  • 포스트그레스큐엘(PostgreSQL)용 ClickHouse 외래 데이터 래퍼입니다. ClickHouse 테이블을 포스트그레스큐엘(PostrgreSQL)에 저장된 것처럼 조회할 수 있습니다. 포스트그레스큐엘(PostgreSQL)이 스케일링을 중단할 때 ClickHouse를 쉽게 도입할 수 있는 선택지가 될 수 있습니다.
  1. 라이센스 Apache 2.0 ✅
  2. 다양한 데이터 저장소 지원 예, 포스트그레스큐엘(PostrgreSQL)을 통해 ClickHouse에 연결 가능합니다. ✅
  3. 프로토콜 호환성 처음 보기에는 SELECT, INSERT 문을 지원합니다. 조인에 대해서는 확실하지 않습니다. 정의에 따라 로우 SQL을 허용합니다.
  4. 운영 노력
    • 포스트그레스큐엘(PostgreSQL) 확장 기능입니다.
    • 두 데이터베이스 간의 매핑이 필요합니다.
    • 클릭하우스의 응답을 대기하면서 실행이 기다리던 CPU 사이클을 낭비하는 경우, 포스트그레스큐엘(PostgreSQL) 성능에 불리한 영향을 줄 수 있습니다.
    • 포스트그레스큐엘(PostgreSQL)과 ClickHouse 배포 간의 연결 노출 및 관리가 필요합니다.
  5. 개발자 경험 미정
  6. 성숙도 몇 년간 사용되어왔으며, ClickHouse 문서에 목록되어 있지만 널리 사용되지는 않는 것으로 보입니다.
  7. 기술 적합성 로우 SQL 문입니다.

코멘트

3. Clickhouse::Activerecord

평가

  1. 라이센스 MIT 라이센스 ✅
  2. 다양한 데이터 저장소 지원 예, 응용프로그램 계층에서 Clickhouse 어댑터를 제공하여 PostgreSQL과 함께 쿼리할 수 있도록 해줍니다. ✅
  3. 프로토콜 호환성 조인에 대해서는 확실하지 않으며 예제도 없습니다.
  4. 운영 노력 루비 온 레일즈 라이브러리 도구이며, ActiveRecord 어댑터 형태로 ORM 인터페이스를 제공합니다.
  5. 개발자 경험 루비 온 레일즈에 익숙한 개발자들에게 쉽게 작업할 수 있습니다.
  6. 성숙도 몇 년간 사용되어 왔지만, 레파지토리의 활동이 드문 편입니다(그 자체로는 나쁜 것은 아닙니다).
  7. 기술 적합성 루비 온 레일즈 라이브러리이므로 예.

코멘트

4. Metriql

평가

DBT를 사용하여 데이터를 소스로하는 헤들레스(BI) 솔루션입니다. 데이터에서 측정 항목을 정의하고 집계를 통해 변환하는 측면에서 Cube.dev와 유사합니다. 작성자는 Metriql과 Cube.js와 같은 기타 BI 도구와의 차이에 대해 FAQ 항목에서 설명합니다.

  1. 라이센스 Apache 2.0 ✅
  2. 다양한 데이터 저장소 지원 DBT를 사용하여 데이터 소스에서 읽기 때문에 CH와 PostgreSQL이 가능합니다.
  3. 프로토콜 호환성 데이터 집계를 위해 OLAP 이론 개념을 사용합니다. REST API를 통해 즉석 SQL 쿼리를 허용합니다.
  4. 운영 노력 별도의 서비스로 배포되며 DBT가 필요합니다.
  5. 개발자 경험 설정 및 사용을 위해 DBT 지식이 필요할 것으로 예상됩니다. 여기에서 REST API가 상당히 간단하게 문서화되어 있습니다.
  6. 성숙도 2021년 5월에 처음 릴리스되었지만, 레파지토리의 활동이 드문 편입니다(그 자체로는 나쁜 것은 아닙니다).
  7. 기술 적합성 REST API 또는 JDBC 어댑터를 통해 BI 도구와 연결합니다. SQL이나 MQL(흔히 알려진 SQL의 서브셋)을 사용하여 쿼리를 허용합니다.

코멘트

5. 거부된 3rd 파티 솔루션

Airflow 및 Meltano와 같은 ETL 전용 솔루션과 Tableau 및 Apache Superset과 같은 시각화 도구는 일반적으로 기준 이외에 명확히 위치하기 때문에 예상 목록에서 제외되었습니다.

pg2ch 논리 복제를 사용하여 PostgreSQL에서 ClickHouse로 미러링을 수행합니다. 레파지토리가 보관되었으며, 별도로 운영용이 아니라고 명시되어 있습니다. 논리 복제는 우리의 규모에서 충분히 효율적이지 않을 수 있습니다. PostgreSQL DB에서 사용하지 않습니다.

Looker BI 도구. 프로프리어터리이며, 소유권이 있습니다.

Hasura 데이터베이스 소스용 GraphQL 인터페이스. 아직 ClickHouse 지원이 없습니다.

dbt Server dbt를 위한 HTTP API. MariaDB 비즈니스 소스 라이선스(BSL) ❌

오픈 질문

  1. 이 제안의 주요 초점은 읽기 인터페이스에 있지만 보완 작업의 결과에 따라 쓰기 인터페이스에 대한 선택 가능성과 관련된 유사한 우려사항이 적용될 수 있습니다. ETL 파이프라인이 쓰기 인터페이스의 선택 가능성 도전을 해결하지 못하는 경우, 이 문서에서 제안된 리포지토리 패턴 구현에 스키마 변경과 데이터 이관에 대한 일부 수정이 필요할 수 있는 것이 신중하게 고려되어야 합니다.
  2. ClickHouse 스키마 변경 및 데이터 이관에 대한 우려사항은 기존 워킹 그룹 기준에서 다루지 않으며, 이러한 문제를 해결하는 것은 일반적으로 이 문서의 범위를 벗어납니다. 그러나 스키마 변경을 지원하기 위해 제안된 리포지토리 패턴 기반 구현에 일부 수정이 필요할 수 있음을 알려주는 것이 현명합니다.