원래 단어 재작성: 원래 버그로 간주되었던 것이 실제로는 Protobuf 설계의 기능이라는 예상치 못한 발견이 있었습니다.

안녕하세요 여러분, 저는 정말 대단해요.

최근 우리 프로젝트에서는 데이터 저장을 위한 캐리어로 protobuf 형식을 사용합니다. 실수로 큰 구멍을 묻었는데 그것을 발견하는 데 오랜 시간이 걸렸습니다.

protobuf 소개

protobuf의 전체 이름은 Protocal 버퍼입니다. 이는 Google에서 개발했으며 데이터 직렬화를 위한 교차 언어, 교차 플랫폼 및 확장 가능한 메커니즘입니다. XML과 비슷하지만 더 작고, 더 빠르고, 더 간단합니다. 데이터를 어떻게 구성할지 한 번만 정의하면 생성 도구를 사용하여 일부 직렬화 및 역직렬화 작업이 포함된 소스 코드를 생성할 수 있습니다. 구조화된 데이터는 다양한 데이터 스트림에서 다양한 프로그래밍 언어를 사용하여 쉽게 쓰고 읽을 수 있습니다.

proto2 버전은 Java, Python, Objective-C 및 C++에서 코드 생성을 지원합니다. 새로운 proto3 언어 버전에서는 Kotlin, Dart, Go, Ruby, PHP, C# 및 더 많은 언어를 사용할 수도 있습니다.

어떻게 알게 됐나요?

새 프로젝트에서는 protobuf 형식을 사용하여 실행되는 프로젝트의 데이터를 저장합니다. 이러한 방식으로 디버깅 과정에서 당사는 현장에 기록된 데이터를 기반으로 로컬 디버깅을 수행할 수 있습니다.

message ImageData {
// ms
int64 timestamp = 1;
int32 id = 2;
Data mat = 3;
}

message PointCloud {
// ms
int64 timestamp = 1;
int32 id = 2;
PointData pointcloud = 3;
}

message State {
// ms
int64 timestamp = 1;
string direction = 2;
}

message Sensor {
repeated PointCloud point_data = 1;
repeated ImageData image_data = 2;
repeated State vehicle_data = 3;
}

저희는 이러한 데이터 세트를 정의한 다음 저장 시 센서의 세 가지 데이터 소스의 프레임 속도가 다르기 때문에 저장할 때 단일 센서에는 실제로 한 세트의 데이터만 포함되고 다른 두 유형의 데이터가 포함됩니다. 포함되지 않습니다.

싱글팩만 녹음했을 때는 문제가 없었어요. 단일 패킷을 오랫동안 기록할 수 없다고 느낄 때까지 패킷을 분할하는 솔루션을 찾아야 합니다.

당시에는 매우 간단할 것이라고 생각하여 패키지가 500M에 도달하면 후속 데이터를 새 패키지에 저장하도록 설정했습니다. 아주 원활하게 작성을 마치고 데이터 기록을 위해 현장에 올렸습니다. 잠시 녹음한 후 패키지를 다시 가져와 새 프로그램 테스트를 시뮬레이션했습니다. 일부 패키지의 데이터를 구문 분석하는 데 문제가 있는 것으로 나타났습니다. 프로그램이 실행 도중에 멈추게 됩니다. 많은 테스트 후에 일부 패키지에 이 문제가 있는 것으로 나타났습니다.

처음에 의심했던 것은 파일 크기를 판단하는 방법이 잘못되어 하도급에 영향을 미쳤다는 것입니다. 파일 크기를 판단하면 파일이 열리기 때문입니다. 그러나 파일을 열지 못하는 다른 여러 가지 방법을 판단한 후 분할이 수행되었습니다. 기록된 패키지 중 일부에 여전히 문제가 발생했습니다.

그때 나는 protobuf에 데이터 저장을 위한 몇 가지 특별한 요구 사항이 있다고 의심했습니다. 나중에 일부 기사를 읽고 protobuf가 여러 데이터 세트를 하나의 파일에 저장하려면 식별자가 필요하다는 것을 알게 되었습니다. 그렇지 않으면 파일에서 다시 구문 분석할 때 protobuf는 단일 데이터의 중지 문자가 어디에 있는지 알지 못해 데이터 구문 분석 오류가 발생합니다.

여기에 이런 구덩이가 나타납니다. 우리는 구분 작업을 수행하지 않고 일련의 데이터를 단일 패키지에 저장합니다. protobuf가 구문 분석할 때 파일의 모든 콘텐츠가 단일 센서로 구문 분석됩니다. 센서에는 모든 데이터가 포함되어 있으며 protobuf는 저장된 모든 데이터를 적극적으로 병합합니다.

이제 이전에 싱글 패킷을 녹음했을 때 데이터가 모두 정확했다는 것을 발견했습니다. 그것은 정말 행운이었습니다. protobuf가 성공적으로 구문 분석되었습니다.

어떻게 해결하나요?

이제 protobuf가 이런 방식으로 동작한다는 것을 알았으니, protobuf를 어떻게 나누는지만 알면 됩니다. 이 방법은 우리처럼 사용하는 사람이 너무 적기 때문에 찾기가 정말 어렵습니다. 중국어 검색에서는 이 콘텐츠를 전혀 찾을 수 없습니다. 아마도 모든 사람이 protobuf를 사용하여 데이터를 저장하지 않을 수도 있습니다.

결국 stackoverflow의 몇 가지 답변을 통해 답을 찾았습니다. 답변에서 이 솔루션은 protobuf 3.3에서만 공식적으로 병합되었다는 것을 알게 되었습니다. 이 기능은 정말 거의 사용하지 않는 것 같습니다.

bool SerializeDelimitedToOstream(const MessageLite& message,
 std::ostream* output);
bool ParseDelimitedFromZeroCopyStream(
MessageLite* message, io::ZeroCopyInputStream* input, bool* clean_eof);

이 두 가지 방법을 통해 데이터 스트림에 따라 파일을 하나씩 저장하고 읽을 수 있습니다. 더 이상 데이터 병합 및 읽기에 대해 걱정할 필요가 없습니다.

물론 이렇게 저장된 데이터는 원래의 파싱 방식으로는 파싱할 수 없으며, 저장 형식도 완전히 바뀌었습니다. 이 방법은 먼저 이진 데이터의 크기를 저장한 다음 이진 데이터를 저장합니다.

결론

고민 끝에 드디어 이 칸막이 피트를 해결했습니다. 사용 시나리오는 상대적으로 틈새적일 수 있으므로 전혀 찾을 수 없는 많은 정보가 발생할 수 있습니다. 소스 코드를 직접 살펴보면서 이러한 문제를 발견했습니다. C++의 소스 코드는 읽기가 정말 어렵습니다. 템플릿 메소드와 템플릿 클래스가 많아 일부 세부 사항을 놓치기 쉽습니다. 마지막으로 이를 완전히 확인하기 위해 C# 코드를 살펴보았습니다.

위 내용은 원래 단어 재작성: 원래 버그로 간주되었던 것이 실제로는 Protobuf 설계의 기능이라는 예상치 못한 발견이 있었습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!