오픈 소스 DataHub: LinkedIn의 메타데이터 검색 및 발견 플랫폼

오픈 소스 DataHub: LinkedIn의 메타데이터 검색 및 발견 플랫폼

필요한 데이터를 빠르게 찾는 것은 데이터 기반 의사결정을 내리기 위해 대량의 데이터에 의존하는 모든 회사에 필수적입니다. 이는 데이터 사용자(분석가, 기계 학습 개발자, 데이터 과학자, 데이터 엔지니어 포함)의 생산성에 영향을 미칠 뿐만 아니라 고품질 기계 학습(ML) 파이프라인에 의존하는 최종 제품에도 직접적인 영향을 미칩니다. 또한, 기계 학습 플랫폼을 구현하거나 구축하는 경향은 자연스럽게 기능, 모델, 메트릭, 데이터 세트 등을 내부적으로 검색하는 방법이 무엇인지에 대한 질문을 제기합니다.

이 기사에서는 오픈 라이선스로 데이터 소스를 게시하는 방법에 대해 설명합니다. 데이터허브 프로젝트 초기부터 메타데이터 검색 및 발견 플랫폼에서 어디에어떻게. LinkedIn은 오픈 소스 버전과 별도로 DataHub의 자체 버전을 유지 관리합니다. 두 개의 별도 개발 환경이 필요한 이유를 설명하는 것부터 시작한 다음, 오픈 소스 WhereHows를 사용하는 초기 접근 방식을 논의하고 DataHub의 내부(프로덕션) 버전과 현재 버전을 비교해 보겠습니다. GitHub의. 또한 두 리포지토리를 동기화 상태로 유지하기 위해 오픈 소스 업데이트를 푸시하고 수신하는 새로운 자동화 솔루션에 대한 세부 정보도 공유할 것입니다. 마지막으로 오픈 소스 DataHub를 사용하여 시작하는 방법에 대한 지침을 제공하고 해당 아키텍처에 대해 간략하게 논의하겠습니다.

WhereHows는 이제 DataHub입니다!

이전에 발표된 LinkedIn의 메타데이터 팀 데이터허브 (WhereHows의 후속), LinkedIn의 검색 및 메타데이터 검색 플랫폼을 공개하고 공유 계획을 공유했습니다. 이 발표 직후 우리는 DataHub의 알파 버전을 출시하고 이를 커뮤니티와 공유했습니다. 그 이후로 우리는 저장소에 지속적으로 기여하고 관심 있는 사용자와 협력하여 가장 많이 요청된 기능을 추가하고 문제를 해결했습니다. 이제 공식 출시를 발표하게 되어 기쁘게 생각합니다. GitHub의 DataHub.

오픈 소스 접근 방식

데이터와 그 출처를 찾기 위한 LinkedIn의 원래 포털인 WhereHows는 내부 프로젝트로 시작되었습니다. 메타데이터 팀이 열었습니다 2016년 소스 코드. 그 이후로 LinkedIn 사용 사례를 위해 개발된 모든 제품 기능이 일반적으로 더 광범위한 대상에게 적용되는 것은 아니기 때문에 팀은 오픈 소스용과 LinkedIn 내부용으로 항상 두 개의 서로 다른 코드베이스를 유지해 왔습니다. 또한 WhereHows에는 오픈 소스가 아닌 일부 내부 종속성(인프라, 라이브러리 등)이 있습니다. 그 후 몇 년 동안 WhereHows는 많은 반복과 개발 주기를 거쳤기 때문에 두 코드베이스를 동기화하는 것이 큰 과제가 되었습니다. 메타데이터 팀은 내부 개발과 오픈 소스 개발을 동기화하기 위해 수년에 걸쳐 다양한 접근 방식을 시도했습니다.

첫 번째 시도: "오픈소스 우선"

우리는 처음에 대부분의 개발이 오픈 소스 저장소에서 이루어지고 내부 배포를 위한 변경이 이루어지는 "오픈 소스 우선" 개발 모델을 따랐습니다. 이 접근 방식의 문제점은 코드가 내부적으로 완전히 검토되기 전에 항상 먼저 GitHub에 푸시된다는 것입니다. 오픈 소스 저장소에서 변경이 이루어지고 새로운 내부 배포가 이루어질 때까지 프로덕션 문제는 발견되지 않습니다. 배포가 불량한 경우에도 일괄 변경이 이루어지기 때문에 원인을 파악하기가 매우 어려웠습니다.

또한 이 모델은 모든 변경 사항을 먼저 오픈 소스 저장소에 푸시한 다음 내부 저장소에 푸시해야 했기 때문에 빠른 반복이 필요한 새로운 기능을 개발할 때 팀의 생산성을 감소시켰습니다. 처리 시간을 줄이기 위해 먼저 내부 저장소에서 필요한 수정이나 변경을 수행할 수 있었지만 두 저장소가 동기화되지 않았기 때문에 해당 변경 사항을 오픈 소스 저장소에 다시 병합할 때 큰 문제가 되었습니다.

이 모델은 모든 기능을 갖춘 사용자 정의 웹 애플리케이션보다 공유 플랫폼, 라이브러리 또는 인프라 프로젝트에 대해 구현하기가 훨씬 쉽습니다. 또한 이 모델은 처음부터 오픈 소스를 시작하는 프로젝트에 이상적이지만 WhereHows는 완전히 내부 웹 애플리케이션으로 구축되었습니다. 모든 내부 종속성을 완전히 추상화하는 것이 정말 어려웠기 때문에 내부 포크를 유지해야 했지만 내부 포크를 유지하고 대부분 오픈 소스를 개발하는 것이 제대로 작동하지 않았습니다.

두 번째 시도: “내부 우선”

**두 번째 시도로 우리는 대부분의 개발이 내부에서 이루어지고 정기적으로 오픈 소스 코드가 변경되는 "내부 우선" 개발 모델로 전환했습니다. 이 모델은 우리의 사용 사례에 가장 적합하지만 본질적인 문제가 있습니다. 모든 차이점을 오픈 소스 저장소에 직접 푸시한 다음 나중에 병합 충돌을 해결하려고 시도하는 것은 선택 사항이지만 시간이 많이 걸립니다. 대부분의 경우 개발자는 코드를 검토할 때마다 이렇게 하지 않으려고 노력합니다. 결과적으로 이 작업은 일괄적으로 수행되는 빈도가 훨씬 낮아지므로 나중에 병합 충돌을 해결하기가 더 어려워집니다.

세 번째로 성공했습니다!

위에서 언급한 두 번의 시도 실패로 인해 WhereHows GitHub 저장소가 오랫동안 최신 상태로 유지되었습니다. 팀은 제품의 기능과 아키텍처를 지속적으로 개선하여 LinkedIn용 WhereHows의 내부 버전이 오픈 소스 버전보다 더 발전되었습니다. DataHub라는 새로운 이름도 생겼습니다. 이전에 실패한 시도를 바탕으로 팀은 확장 가능한 장기 솔루션을 개발하기로 결정했습니다.

새로운 오픈 소스 프로젝트의 경우 LinkedIn의 오픈 소스 팀은 프로젝트 모듈이 완전히 오픈 소스로 개발되는 개발 모델을 조언하고 지원합니다. 버전이 지정된 아티팩트는 공개 저장소에 배포된 다음 다음을 사용하여 내부 LinkedIn 아티팩트로 다시 체크인됩니다. 외부 라이브러리 요청(ELR). 이 개발 모델을 따르는 것은 오픈 소스를 사용하는 사람들에게 좋을 뿐만 아니라 더 모듈화되고 확장 가능하며 플러그 가능한 아키텍처를 제공합니다.

그러나 DataHub와 같은 성숙한 백엔드 애플리케이션은 이 상태에 도달하는 데 상당한 시간이 필요합니다. 이는 또한 모든 내부 종속성이 완전히 추상화되기 전에 완벽하게 작동하는 구현을 오픈 소스화할 가능성을 배제합니다. 이것이 바로 우리가 오픈 소스 기여를 더 빠르게, 훨씬 덜 고통스럽게 할 수 있는 도구를 개발한 이유입니다. 이 솔루션은 메타데이터 팀(DataHub 개발자)과 오픈 소스 커뮤니티 모두에 도움이 됩니다. 다음 섹션에서는 이 새로운 접근 방식에 대해 설명합니다.

오픈 소스 출판 자동화

오픈 소스 DataHub에 대한 메타데이터 팀의 최신 접근 방식은 내부 코드베이스와 오픈 소스 저장소를 자동으로 동기화하는 도구를 개발하는 것입니다. 이 툴킷의 고급 기능은 다음과 같습니다.

1. 유사한 LinkedIn 코드를 오픈 소스와 동기화 rsync.
2. 라이센스 헤더 생성, 유사 아파치 쥐.
3. 내부 커밋 로그에서 오픈소스 커밋 로그를 자동으로 생성합니다.
4. 오픈 소스 빌드를 중단시키는 내부 변경을 방지합니다. 종속성 테스트.

다음 하위 섹션에서는 위에서 언급한 흥미로운 문제가 있는 기능을 자세히 살펴보겠습니다.

소스 코드 동기화

단일 GitHub 저장소인 DataHub의 오픈 소스 버전과 달리 DataHub의 LinkedIn 버전은 여러 저장소(내부적으로 호출됨)의 조합입니다. 다중 제품). DataHub 인터페이스, 메타데이터 모델 라이브러리, 메타데이터 웨어하우스 백엔드 서비스 및 스트리밍 작업은 LinkedIn의 별도 저장소에 있습니다. 그러나 오픈 소스 사용자가 더 쉽게 사용할 수 있도록 DataHub의 오픈 소스 버전에 대한 단일 저장소가 있습니다.

그림 1: 리포지토리 간 동기화 링크드인 데이터허브 단일 저장소 데이터허브 오픈 소스

자동화된 빌드, 푸시 및 풀 워크플로를 지원하기 위해 새로운 도구는 각 소스 파일에 해당하는 파일 수준 매핑을 자동으로 생성합니다. 그러나 툴킷에는 초기 구성이 필요하며 사용자는 아래와 같이 상위 수준 모듈 매핑을 제공해야 합니다.

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

모듈 수준 매핑은 키가 오픈 소스 저장소의 대상 모듈이고 값이 LinkedIn 저장소의 소스 모듈 목록인 간단한 JSON입니다. 오픈 소스 저장소의 모든 대상 모듈은 원하는 수의 소스 모듈로 제공될 수 있습니다. 소스 모듈에서 저장소의 내부 이름을 표시하려면 다음을 사용하십시오. 문자열 보간 배쉬 스타일로. 도구는 모듈 수준 매핑 파일을 사용하여 관련 디렉터리의 모든 파일을 검색하여 파일 수준 매핑 파일을 생성합니다.

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

파일 수준 매핑은 도구에 의해 자동으로 생성됩니다. 그러나 사용자가 수동으로 업데이트할 수도 있습니다. 이는 LinkedIn 소스 파일과 오픈 소스 저장소의 파일을 1:1로 매핑한 것입니다. 파일 연결 자동 생성과 관련된 몇 가지 규칙이 있습니다.

• 오픈 소스의 대상 모듈에 대한 여러 소스 모듈의 경우 충돌이 발생할 수 있습니다. FQCN, 둘 이상의 소스 모듈에 존재합니다. 갈등 해결 전략으로 우리 도구는 기본적으로 "마지막 승리" 옵션을 사용합니다.
• "null"은 소스 파일이 오픈 소스 저장소의 일부가 아님을 의미합니다.
• 오픈 소스를 제출하거나 추출할 때마다 이 매핑이 자동으로 업데이트되고 스냅샷이 생성됩니다. 이는 마지막 작업 이후 소스 코드에서 추가 및 삭제된 내용을 식별하는 데 필요합니다.

커밋 로그 생성

오픈소스 커밋에 대한 커밋 로그도 내부 리포지토리의 커밋 로그를 병합하여 자동으로 생성됩니다. 다음은 우리 도구에서 생성된 커밋 로그의 구조를 보여주는 샘플 커밋 로그입니다. 커밋은 해당 커밋에 패키지된 소스 리포지토리 버전을 명확하게 나타내고 커밋 로그 요약을 제공합니다. 이것을 확인해보세요 저지르다 우리 툴킷에서 생성된 커밋 로그의 실제 예를 사용합니다.

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

종속성 테스트

링크드인은 종속성 테스트 인프라이는 내부 다중 제품에 대한 변경으로 인해 종속 다중 제품의 어셈블리가 중단되지 않도록 하는 데 도움이 됩니다. 오픈 소스 DataHub 저장소는 다중 제품이 아니며 다중 제품에 직접 종속될 수 없습니다. 하지만 오픈 소스 DataHub 소스 코드를 가져오는 다중 제품 래퍼의 도움으로 이 종속성 테스트를 계속 사용할 수 있습니다. 따라서 오픈 소스 DataHub 저장소를 제공하는 다중 제품에 대한 모든 변경 사항(나중에 노출될 수 있음)은 쉘 다중 제품에서 빌드 이벤트를 트리거합니다. 따라서 래퍼 제품 빌드에 실패한 모든 변경 사항은 원래 제품을 커밋하기 전에 테스트에 실패하고 되돌려집니다.

이는 오픈 소스 빌드를 중단하고 커밋 시 이를 감지하는 내부 커밋을 방지하는 데 도움이 되는 유용한 메커니즘입니다. 이것이 없으면 DataHub 오픈 소스 저장소에 대한 내부 변경 사항을 일괄 처리하기 때문에 어떤 내부 커밋이 오픈 소스 저장소 빌드 실패를 유발했는지 파악하기가 상당히 어려울 것입니다.

오픈 소스 DataHub와 프로덕션 버전의 차이점

지금까지 두 가지 버전의 DataHub 리포지토리를 동기화하는 솔루션에 대해 논의했지만 우선 두 가지 다른 개발 스트림이 필요한 이유를 아직 설명하지 않았습니다. 이 섹션에서는 DataHub의 공개 버전과 LinkedIn 서버의 프로덕션 버전 간의 차이점을 나열하고 이러한 차이점에 대한 이유를 설명합니다.

불일치의 원인 중 하나는 프로덕션 버전이 LinkedIn의 Offspring(LinkedIn의 내부 종속성 주입 프레임워크)과 같이 아직 오픈 소스가 아닌 코드에 종속되어 있다는 사실에서 비롯됩니다. Offspring은 동적 구성을 관리하는 데 선호되는 방법이므로 내부 코드베이스에서 널리 사용됩니다. 하지만 이는 오픈 소스가 아닙니다. 그래서 우리는 오픈 소스 DataHub에 대한 오픈 소스 대안을 찾아야 했습니다.

다른 이유도 있습니다. LinkedIn의 요구 사항에 맞게 메타데이터 모델에 대한 확장을 만들 때 이러한 확장은 일반적으로 LinkedIn에만 적용되며 다른 환경에는 직접 적용되지 않을 수 있습니다. 예를 들어, 참가자 ID 및 기타 유형의 일치 메타데이터에 대한 매우 구체적인 라벨이 있습니다. 따라서 이제 DataHub의 오픈 소스 메타데이터 모델에서 이러한 확장을 제외했습니다. 우리는 커뮤니티에 참여하고 그들의 요구 사항을 이해하면서 필요한 경우 이러한 확장의 공통 오픈 소스 버전을 개발할 것입니다.

오픈 소스 커뮤니티에 대한 사용 용이성과 더 쉬운 적응 또한 DataHub의 두 버전 간의 일부 차이점에 영감을 주었습니다. 스트림 처리 인프라의 차이가 이에 대한 좋은 예입니다. 내부 버전은 관리형 스트림 처리 프레임워크를 사용하지만, 다른 인프라 종속성을 생성하지 않기 때문에 오픈 소스 버전에 내장된(독립형) 스트림 처리를 사용하기로 선택했습니다.

차이점의 또 다른 예는 오픈 소스 구현에서 여러 GMS가 아닌 단일 GMS(일반화된 메타데이터 저장소)를 갖는 것입니다. GMA(Generalized Metadata Architecture)는 DataHub의 백엔드 아키텍처 이름이고, GMS는 GMA 컨텍스트의 메타데이터 저장소입니다. GMA는 각 데이터 구성(예: 데이터세트, 사용자 등)을 자체 메타데이터 저장소에 배포하거나 레지스트리에 데이터 구조 매핑이 포함되어 있는 한 단일 메타데이터 저장소에 여러 데이터 구성을 저장할 수 있는 매우 유연한 아키텍처입니다. GMS가 업데이트되었습니다. 사용 편의성을 위해 우리는 오픈 소스 DataHub에 다양한 데이터 구성을 모두 저장하는 단일 GMS 인스턴스를 선택했습니다.

두 구현 간의 차이점에 대한 전체 목록은 아래 표에 나와 있습니다.

제품 특징
링크드인 데이터허브
오픈 소스 DataHub

지원되는 데이터 구성
1) 데이터 세트 2) 사용자 3) 지표 4) ML 기능 5) 차트 6) 대시보드
1) 데이터 세트 2) 사용자

데이터세트에 지원되는 메타데이터 소스
1) 앰브리 2) 카우치베이스 3) 달리드 4) 에스프레소 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 피노 12) 프레스토 12) 바다 13) 테라데이타 13) 벡터 14) 베니스
하이브 카프카 RDBMS

게시-구독
링크드인 카프카
컨플루언트 카프카

스트림 처리
관리
임베디드(독립형)

종속성 주입 및 동적 구성
LinkedIn 자손
봄

빌드 툴링
Ligradle(LinkedIn의 내부 Gradle 래퍼)
그래들류

CI / CD
CRT(LinkedIn 내부 CI/CD)
트래비스 CI 과 도커 허브

메타데이터 저장소
분산된 다중 GMS: 1) 데이터 세트 GMS 2) 사용자 GMS 3) 미터법 GMS 4) 기능 GMS 5) 차트/대시보드 GMS
다음을 위한 단일 GMS: 1) 데이터세트 2) 사용자

Docker 컨테이너의 마이크로서비스

도커 다음을 통해 애플리케이션 배포 및 배포를 단순화합니다. 컨테이너화. DataHub 서비스의 모든 부분은 Kafka와 같은 인프라 구성 요소를 포함하여 오픈 소스입니다. 탄성 검색, Neo4j и MySQL의에는 자체 Docker 이미지가 있습니다. 우리가 사용한 Docker 컨테이너를 조정하기 위해 도커 작성.

그림 2: 아키텍처 데이터허브 *오픈 소스**

위 이미지에서 DataHub의 상위 수준 아키텍처를 볼 수 있습니다. 인프라 구성 요소 외에도 XNUMX가지 Docker 컨테이너가 있습니다.

datahub-gms: 메타데이터 저장 서비스

데이터허브 프론트엔드: 애플리케이션 연극, DataHub 인터페이스를 제공합니다.

데이터허브-mce-소비자: 애플리케이션 카프카 스트림, MCE(메타데이터 변경 이벤트) 스트림을 사용하고 메타데이터 저장소를 업데이트합니다.

데이터허브-매-소비자: 애플리케이션 카프카 스트림, 메타데이터 감사 이벤트 스트림(MAE)을 사용하고 검색 색인 및 그래프 데이터베이스를 생성합니다.

오픈 소스 저장소 문서 및 원본 DataHub 블로그 게시물 다양한 서비스의 기능에 대한 자세한 정보가 포함되어 있습니다.

DataHub의 CI/CD는 오픈 소스입니다.

오픈 소스 DataHub 저장소는 다음을 사용합니다. 트래비스 CI 지속적인 통합과 도커 허브 지속적인 배포를 위해. 둘 다 GitHub 통합이 뛰어나고 설정이 쉽습니다. 커뮤니티나 민간 기업이 개발한 대부분의 오픈 소스 인프라(예: 지류), 커뮤니티에서 쉽게 사용할 수 있도록 Docker 이미지가 생성되어 Docker Hub에 배포됩니다. Docker Hub에 있는 모든 Docker 이미지는 간단한 명령으로 쉽게 사용할 수 있습니다. 도커 풀.

DataHub 오픈 소스 저장소에 커밋할 때마다 모든 Docker 이미지가 자동으로 빌드되어 "최신" 태그를 사용하여 Docker Hub에 배포됩니다. Docker Hub가 일부로 구성된 경우 정규식 분기 이름 지정, 오픈 소스 저장소의 모든 태그도 Docker Hub에서 해당 태그 이름과 함께 릴리스됩니다.

DataHub 사용

DataHub 설정 매우 간단하며 세 가지 간단한 단계로 구성됩니다.

1. 오픈 소스 저장소를 복제하고 빠른 시작을 위해 제공된 docker-compose 스크립트를 사용하여 docker-compose로 모든 Docker 컨테이너를 실행합니다.
2. 함께 제공되는 명령줄 도구를 사용하여 저장소에 제공된 샘플 데이터를 다운로드하세요.
3. 브라우저에서 DataHub를 찾아보세요.

적극적으로 추적됨 지터 채팅 또한 빠른 질문을 위해 구성되었습니다. 사용자는 GitHub 저장소에서 직접 문제를 생성할 수도 있습니다. 가장 중요한 것은 모든 피드백과 제안을 환영하고 감사하게 생각한다는 것입니다!

앞으로의 계획

현재 오픈 소스 DataHub의 모든 인프라 또는 마이크로서비스는 Docker 컨테이너로 구축되었으며 전체 시스템은 다음을 사용하여 조정됩니다. 도커 작성. 인기와 대중성을 고려하면 Kubernetes, 가까운 시일 내에 Kubernetes 기반 솔루션도 제공하고 싶습니다.

또한 다음과 같은 공용 클라우드 서비스에 DataHub를 배포하기 위한 턴키 솔루션을 제공할 계획입니다. 하늘빛, AWS 또는 Google 클라우드. LinkedIn이 Azure로 마이그레이션한다는 최근 발표를 고려하면 이는 메타데이터 팀의 내부 우선 순위와 일치할 것입니다.

마지막으로 DataHub 알파 버전을 평가하고 문제를 식별하고 문서를 개선하는 데 도움을 준 오픈 소스 커뮤니티의 모든 DataHub 얼리 어답터들에게 감사드립니다.

출처 : habr.com