Exa는 실시간으로 변하는 웹에서도 현대적 웹 검색 인덱스를 질의 가능한 상태로 유지하기 위해 사내 데이터 처리 프레임워크 exa-d를 구축했다. 회사는 검색엔진이 수천억 개 페이지와 페타바이트급 원본 콘텐츠를 수집한 뒤, 사용자 질의가 도착하기 전에 추출 텍스트, 메타데이터, 검색 신호, 임베딩 같은 파생 산출물을 다시 생성해야 한다고 설명했다. 원문은 핵심 웹 데이터 문제로 페이지마다 많은 출력물이 생긴다는 점, HTML 페이지와 PDFs, JavaScript 렌더링 앱, 멀티미디어가 섞인 이질적 콘텐츠, 시간 단위로 바뀌는 뉴스부터 거의 바뀌지 않는 학술 논문까지 다양한 갱신 주기, 그리고 막대한 규모를 제시했다.

Exa는 데이터 웨어하우스, SQL 변환 계층, 오케스트레이터를 검토한 뒤 타입 지정 열, 선언형 의존성, 정밀 업데이트, 전체 재빌드, 효율적 병렬 실행을 중심으로 exa-d를 만들었다고 밝혔다. 엔지니어는 단계별 업데이트 스크립트를 쓰는 대신, 다른 셀을 참조하는 스프레드시트 수식처럼 데이터 사이의 관계를 선언한다. 이 프레임워크는 의존성 그래프, 즉 어떤 출력이 어떤 입력에 의존하는지 보여주는 DAG를 사용해 타입 지정 열 정의가 코드 작성 중 잘못된 변환을 잡아내고, 시스템이 상태와 재시도, 스케줄링을 관리하게 한다.

exa-d는 운영 중인 웹 인덱스를 기본 열과 파생 열로 표현한다. 예시에서 documents 열은 문자열을 담고, documents_tokenized 열은 Tokenizer를 통해 documents에서 텐서를 파생하며, embeddings 열은 EmbeddingModel을 통해 토큰화된 텍스트에서 출력을 파생한다. 원문은 토큰화를 "dog eats bone" 같은 문자열을 [482, 9104, 512] 같은 토큰 ID로 바꾸는 과정으로 설명했으며, 이 값은 [0.023, -0.847, 0.412, ...] 같은 부동소수점 벡터를 출력하는 임베딩 모델에 입력된다. 실행 순서는 그래프에서 나오므로, 각 파이프라인 변형마다 별도 스크립트를 두지 않아도 토큰화된 출력 뒤에 임베딩이 계산된다.

스토리지 계층은 S3의 Lance를 사용하며, Exa가 갱신하려는 수준에서 완전성을 추적한다. Lance는 데이터셋을 부분 스키마를 가진 프래그먼트로 저장하므로, 파생 열을 점진적으로 추가할 때 모든 프래그먼트가 같은 열을 가질 필요가 없다. exa-d는 프래그먼트의 나머지 부분을 다시 쓰지 않고 특정 프래그먼트의 단일 열을 쓰거나 삭제할 수 있다. Exa는 파생 필드 추가, 버그 수정, 유효하지 않은 값 삭제, 전체 인덱스의 새 임베딩 계산 과정에서 대규모 스캔과 불필요한 재작성을 피할 수 있다고 밝혔다.

실행 계층은 데이터셋의 이상적 상태와 Lance에 저장된 실제 상태를 비교한다. 질의 계획은 차이 계산이 되며, 누락되거나 유효하지 않은 열을 식별하고, 위상 정렬로 의존 대상을 피의존 대상보다 먼저 배치해 각 열이 입력 뒤에 실행되게 하며, 작업을 프래그먼트 단위로 실행해 코어나 머신 전체에 병렬화할 수 있게 한다. 원문은 각 프래그먼트 뒤의 체크포인트가 중단된 작업에서 이미 끝난 작업을 다시 하지 않게 하며, 같은 코드 경로가 백필, 증분 업데이트, 새 문서, 변경된 임베딩 모델을 처리한다고 설명했다.

exa-d는 정렬된 열 그래프를 Ray Data 작업으로 변환한다. 프래그먼트 완전성이 스케줄링을 통제하므로 Ray는 계산이 필요한 작업 항목만 받는다. 상태를 가진 작업자로 설명된 Ray Actors는 임베딩 모델을 GPU 메모리에 한 번 적재하고, 항목마다 다시 불러오는 대신 여러 배치에 재사용한다. 별도 Actor 단계는 GPU가 한 프래그먼트를 임베딩하는 동안 CPU가 다음 프래그먼트를 토큰화하고 네트워크가 세 번째 프래그먼트를 가져오게 한다. Exa는 부분 실패 뒤 실행을 다시 돌리면 차이를 다시 계산해 결국 같은 최종 상태로 수렴하며, 요청된 모든 출력이 올바르게 계산된다고 밝혔다.

Exa는 실시간으로 변하는 웹에서도 현대적 웹 검색 인덱스를 질의 가능한 상태로 유지하기 위해 사내 데이터 처리 프레임워크 exa-d를 구축했다. 회사는 검색엔진이 수천억 개 페이지와 페타바이트급 원본 콘텐츠를 수집한 뒤, 사용자 질의가 도착하기 전에 추출 텍스트, 메타데이터, 검색 신호, 임베딩 같은 파생 산출물을 다시 생성해야 한다고 설명했다. 원문은 핵심 웹 데이터 문제로 페이지마다 많은 출력물이 생긴다는 점, HTML 페이지와 PDFs, JavaScript 렌더링 앱, 멀티미디어가 섞인 이질적 콘텐츠, 시간 단위로 바뀌는 뉴스부터 거의 바뀌지 않는 학술 논문까지 다양한 갱신 주기, 그리고 막대한 규모를 제시했다.

Exa는 데이터 웨어하우스, SQL 변환 계층, 오케스트레이터를 검토한 뒤 타입 지정 열, 선언형 의존성, 정밀 업데이트, 전체 재빌드, 효율적 병렬 실행을 중심으로 exa-d를 만들었다고 밝혔다. 엔지니어는 단계별 업데이트 스크립트를 쓰는 대신, 다른 셀을 참조하는 스프레드시트 수식처럼 데이터 사이의 관계를 선언한다. 이 프레임워크는 의존성 그래프, 즉 어떤 출력이 어떤 입력에 의존하는지 보여주는 DAG를 사용해 타입 지정 열 정의가 코드 작성 중 잘못된 변환을 잡아내고, 시스템이 상태와 재시도, 스케줄링을 관리하게 한다.

exa-d는 운영 중인 웹 인덱스를 기본 열과 파생 열로 표현한다. 예시에서 documents 열은 문자열을 담고, documents_tokenized 열은 Tokenizer를 통해 documents에서 텐서를 파생하며, embeddings 열은 EmbeddingModel을 통해 토큰화된 텍스트에서 출력을 파생한다. 원문은 토큰화를 "dog eats bone" 같은 문자열을 [482, 9104, 512] 같은 토큰 ID로 바꾸는 과정으로 설명했으며, 이 값은 [0.023, -0.847, 0.412, ...] 같은 부동소수점 벡터를 출력하는 임베딩 모델에 입력된다. 실행 순서는 그래프에서 나오므로, 각 파이프라인 변형마다 별도 스크립트를 두지 않아도 토큰화된 출력 뒤에 임베딩이 계산된다.

스토리지 계층은 S3의 Lance를 사용하며, Exa가 갱신하려는 수준에서 완전성을 추적한다. Lance는 데이터셋을 부분 스키마를 가진 프래그먼트로 저장하므로, 파생 열을 점진적으로 추가할 때 모든 프래그먼트가 같은 열을 가질 필요가 없다. exa-d는 프래그먼트의 나머지 부분을 다시 쓰지 않고 특정 프래그먼트의 단일 열을 쓰거나 삭제할 수 있다. Exa는 파생 필드 추가, 버그 수정, 유효하지 않은 값 삭제, 전체 인덱스의 새 임베딩 계산 과정에서 대규모 스캔과 불필요한 재작성을 피할 수 있다고 밝혔다.

실행 계층은 데이터셋의 이상적 상태와 Lance에 저장된 실제 상태를 비교한다. 질의 계획은 차이 계산이 되며, 누락되거나 유효하지 않은 열을 식별하고, 위상 정렬로 의존 대상을 피의존 대상보다 먼저 배치해 각 열이 입력 뒤에 실행되게 하며, 작업을 프래그먼트 단위로 실행해 코어나 머신 전체에 병렬화할 수 있게 한다. 원문은 각 프래그먼트 뒤의 체크포인트가 중단된 작업에서 이미 끝난 작업을 다시 하지 않게 하며, 같은 코드 경로가 백필, 증분 업데이트, 새 문서, 변경된 임베딩 모델을 처리한다고 설명했다.

exa-d는 정렬된 열 그래프를 Ray Data 작업으로 변환한다. 프래그먼트 완전성이 스케줄링을 통제하므로 Ray는 계산이 필요한 작업 항목만 받는다. 상태를 가진 작업자로 설명된 Ray Actors는 임베딩 모델을 GPU 메모리에 한 번 적재하고, 항목마다 다시 불러오는 대신 여러 배치에 재사용한다. 별도 Actor 단계는 GPU가 한 프래그먼트를 임베딩하는 동안 CPU가 다음 프래그먼트를 토큰화하고 네트워크가 세 번째 프래그먼트를 가져오게 한다. Exa는 부분 실패 뒤 실행을 다시 돌리면 차이를 다시 계산해 결국 같은 최종 상태로 수렴하며, 요청된 모든 출력이 올바르게 계산된다고 밝혔다.