Meta는 스키마 진화를 지원하는 바이너리 직렬화 프로토콜인 'Tulip'을 소개합니다. 이는 프로토콜 안정성 및 기타 문제를 동시에 해결하고 데이터 도식화를 지원합니다. Tulip에는 여러 레거시 형식이 있습니다. 따라서 Meta의 데이터 플랫폼에서 사용되며 성능과 효율성이 크게 향상되었습니다. 메타의 데이터 플랫폼은 웨어하우스 데이터 저장소, 다양한 실시간 시스템 등 수많은 이기종 서비스로 구성되어 서비스 API를 통해 대량의 데이터를 교환하고 서로 통신합니다. 이러한 ML 모델을 교육하기 위해 데이터를 사용하는 Meta 시스템의 AI 및 기계 학습 ML 관련 작업 부하가 증가함에 따라 데이터 로깅 시스템을 효율적으로 만들기 위해 지속적으로 노력해야 합니다. 데이터의 도식화는 Meta 규모의 데이터를 위한 플랫폼을 만드는 데 큰 역할을 합니다. 이러한 시스템은 모든 결정과 균형이 안정성, 데이터 전처리 효율성, 성능 및 엔지니어의 개발자 경험에 영향을 미친다는 지식을 기반으로 설계되었습니다. 데이터 인프라의 직렬화 형식을 변경하는 것은 큰 선택이지만 장기적으로 플랫폼을 발전시키는 이점을 제공합니다.
데이터 분석 로깅 라이브러리는 웹 계층과 내부 서비스에 존재하며 Meta에서 사용하는 내구성 있는 메시지 큐잉 시스템인 Scribe를 사용하여 분석 및 운영 데이터 로깅을 담당합니다. 데이터는 데이터 플랫폼 수집 서비스 및 실시간 처리 시스템을 포함하는 Scribe에서 읽고 수집됩니다. 데이터 분석 읽기 라이브러리는 데이터를 역직렬화하고 구조화된 페이로드로 다시 수화하는 데 도움이 됩니다. 로깅 스키마는 Meta의 수천 명의 엔지니어에 의해 매월 생성, 업데이트 및 삭제되며 이러한 로깅 스키마 데이터는 Scribe를 통해 매일 페타바이트 범위로 흐릅니다.
도식화는 (de)serializer의 버전에 따라 과거, 현재 또는 미래에 기록된 모든 메시지가 데이터 손실 없이 최고의 충실도로 언제든지 안정적으로 (de)직렬화될 수 있도록 보장하는 데 필요합니다. 역방향 및 순방향 호환성을 통한 안전한 스키마 진화는 이 특성에 지정된 이름입니다. 이 기사의 주요 초점은 데이터 플랫폼에서 최종적으로 처리되는 데이터를 인코딩하는 데 사용되는 온와이어 직렬화 형식에 있습니다. 이전에 사용된 두 가지 직렬화 형식인 Hive Text Delimited 및 JSON 직렬화와 비교할 때 새로운 인코딩 형식은 데이터를 (비)직렬화하는 데 필요한 바이트가 40~85% 더 적고 CPU 주기가 50~90% 더 적기 때문에 더 효율적입니다.
로깅 라이브러리의 애플리케이션은 로깅 스키마에 따라 페이로드를 직렬화하기 위해 C++, Java, Haskell, Hack, Python 등 다양한 언어로 작성되며, 이러한 로깅 스키마는 비즈니스 요구에 따라 정의되며 보다 쉬운 전달을 위해 Scribe에 작성됩니다. . 로깅 라이브러리는 코드 생성 및 일반의 두 가지 유형으로 제공됩니다. 유형이 안전한 사용을 위한 코드 생성 플레이버에서 각 필드에 대해 정적으로 유형이 지정된 세터가 생성됩니다. 최적의 효율성을 위해 사후 처리 및 직렬화 코드도 생성됩니다. 동적으로 유형이 지정된 페이로드의 (역)직렬화를 수행하는 일반 버전에서는 Tulib라는 이름의 C++ 라이브러리가 제공됩니다. 동적 유형을 사용하는 메시지는 로깅 체계에 따라 직렬화됩니다. 애플리케이션 바이너리를 재구축 및 재배포할 필요 없이 메시지의 (비)직렬화를 허용하기 때문에 이 방법은 코드 생성 모드보다 더 유연합니다.
로깅 라이브러리는 여러 백엔드 시스템에 데이터를 전송합니다. 각 백엔드 시스템은 전통적으로 자체 직렬화 규칙을 지정했으며 이러한 형식을 페이로드 직렬화에 사용하는 동안 다양한 문제에 직면하게 됩니다.
- 표준화: 과거에는 직렬화 형식의 표준화가 없었습니다. 각 다운스트림 시스템은 고유한 형식을 가지고 있어 유지 관리 및 개발 비용이 증가했습니다.
- 신뢰성 : 역직렬화 안정성을 유지하기 위해 끝에만 새 열을 추가할 수 있습니다. 기존 열의 중간에 필드를 삽입하거나 열을 제거하려고 하면 다음 열이 모두 이동하여 행을 역직렬화할 수 없게 되고 업데이트된 스키마가 실시간으로 판독기에게 배포됩니다.
- 효율성 : 이진 (비)직렬화와 비교할 때 Hive Text Delimited 및 JSON 프로토콜은 모두 텍스트 기반이며 비효율적입니다.
- 단정: 필드 구분 기호 및 줄 구분 기호는 Hive 텍스트와 같은 텍스트 기반 프로토콜에 대해 이스케이프 및 이스케이프 해제되어야 합니다. 모든 작가와 독자가 이렇게 하므로 도서관 작가에 대한 부담이 가중됩니다. 단순히 이러한 문자의 존재를 찾고 문제가 있는 문자를 피하는 대신 전체 메시지를 거부하는 구식이거나 결함이 있는 구현을 처리하는 것은 어렵습니다.
- 전방 및 후방 호환성: 소비자가 보는 버전 전후에 직렬화 스키마에 의해 직렬화된 페이로드를 사용하는 것이 바람직합니다. Hive 텍스트 프로토콜은 이러한 보증을 제공하지 않습니다.
- 메타 데이터 : 페이로드에 대한 메타데이터 삽입은 Hive 텍스트 직렬화에서 쉽게 지원되지 않습니다. 다운스트림 시스템이 메타데이터의 존재로부터 이익을 얻는 기능을 구현하려면 해당 데이터의 전파가 필수적입니다.
Tulip은 고유한 배포 주기가 있는 서비스 간에 이전 버전과 이전 버전과 호환되는 안전한 스키마 진화 형식을 제공하여 근본적인 문제인 안정성 문제를 해결합니다. Tulip은 이러한 모든 문제를 한 번에 해결하여 사용 가능한 다른 옵션보다 더 나은 투자가 되었습니다.
Thrift의 TCompactProtocol은 이진 직렬화 프로토콜인 Tulip 직렬화 프로토콜에서 페이로드를 직렬화하는 데 사용됩니다. 필드는 Thrift 구조체에서 ID를 변경할 때 엔지니어가 예상하는 것과 동일한 방식으로 ID로 번호가 매겨집니다. 엔지니어는 로깅 스키마를 생성할 때 필드 이름 및 종류 목록을 정의하고 필드 ID는 지정된 엔지니어가 아닌 데이터 플랫폼 관리 모듈에서 관리합니다. 직렬화 스키마 리포지토리에는 로깅 스키마를 직렬화 스키마로 변환한 내용이 포함되어 있습니다. 필드 이름, 필드 유형, 관련 로깅 스키마의 필드 ID 및 필드 기록 목록은 직렬화 구성에 저장됩니다. 엔지니어가 로깅 스키마를 업데이트하려는 경우 직렬화 스키마에서 트랜잭션 작업이 수행됩니다.
참조: https://engineering.fb.com/2022/11/09/developer-tools/tulip-schematizing-metas-data-platform/
가입하는 것을 잊지 마세요 우리의 ML 서브레딧
Avanthy Yeluri는 IIT Kharagpur의 이중 학위 학생입니다. 그녀는 다양한 산업 분야의 수많은 응용 프로그램과 최첨단 기술 발전 및 일상 생활에서 사용되는 방식 때문에 데이터 과학에 큰 관심을 가지고 있습니다.
<!–
–>
