paint-brush
딥 러닝을 위한 레이크하우스인 Deep Lake: 현재의 과제~에 의해@dataology

딥 러닝을 위한 레이크하우스인 Deep Lake: 현재의 과제

너무 오래; 읽다

연구원들은 딥 러닝 프레임워크를 위한 복잡한 데이터 스토리지 및 스트리밍을 최적화하는 딥 러닝용 오픈 소스 레이크하우스인 Deep Lake를 소개합니다.
featured image - 딥 러닝을 위한 레이크하우스인 Deep Lake: 현재의 과제
Dataology: Study of Data in Computer Science HackerNoon profile picture
0-item

저자:

(1) Sasun Hambardzumyan, Activeloop, Mountain View, CA, USA;

(2) Abhinav Tuli, Activeloop, 미국 캘리포니아주 마운틴뷰;

(3) Levon Ghukasyan, Activeloop, Mountain View, CA, USA;

(4) Fariz Rahman, Activeloop, 미국 캘리포니아주 마운틴뷰;.

(5) Hrant Topchyan, Activeloop, Mountain View, CA, USA;

(6) David Isayan, Activeloop, 미국 캘리포니아주 마운틴뷰;

(7) 마크 맥퀘이드(Mark McQuade), 미국 캘리포니아주 마운틴뷰 소재 Activeloop;

(8) Mikayel Harutyunyan, Activeloop, 미국 캘리포니아주 마운틴뷰;

(9) Tatevik Hakobyan, Activeloop, Mountain View, CA, USA;

(10) Ivo Stranic, Activeloop, Mountain View, CA, USA;

(11) Davit Buniatyan, Activeloop, Mountain View, CA, USA.

링크 표

2. 현재의 과제

이 섹션에서는 구조화되지 않았거나 복잡한 데이터 관리의 현재 및 역사적 과제에 대해 논의합니다.

2.1 데이터베이스의 복잡한 데이터 유형

일반적으로 이미지와 같은 이진 데이터를 데이터베이스에 직접 저장하는 것은 권장되지 않습니다. 이는 데이터베이스가 대용량 파일을 저장하고 제공하는 데 최적화되어 있지 않아 성능 문제를 일으킬 수 있기 때문입니다. 또한 이진 데이터는 데이터베이스의 구조화된 형식에 잘 맞지 않아 쿼리 및 조작이 어렵습니다. 이로 인해 사용자의 로드 시간이 느려질 수 있습니다. 데이터베이스는 일반적으로 파일 시스템이나 클라우드 스토리지 서비스와 같은 다른 유형의 스토리지보다 운영 및 유지 관리 비용이 더 많이 듭니다. 따라서 대량의 바이너리 데이터를 데이터베이스에 저장하는 것은 다른 스토리지 솔루션보다 비용이 더 많이 들 수 있습니다.

2.2 표 형식을 따른 복잡한 데이터

대규모 분석 및 BI 워크로드의 증가는 Parquet, ORC, Avro와 같은 압축 구조 형식 또는 Arrow [79, 6, 20, 13]와 같은 임시 메모리 내 형식의 개발을 촉진했습니다. 테이블 형식 형식이 채택됨에 따라 딥 러닝을 위한 Petastorm [18] 또는 Feather [7]와 같은 형식을 확장하려는 시도가 나타났습니다. 우리가 아는 한, 이러한 형식은 아직 널리 채택되지 않았습니다. 이 접근 방식은 주로 최신 데이터 스택(MDS)과의 기본 통합을 통해 이점을 얻습니다. 그러나 이전에 논의한 것처럼 업스트림 도구는 딥 러닝 애플리케이션에 적응하기 위해 근본적인 수정이 필요합니다.

2.3 딥러닝을 위한 객체 스토리지

구조화되지 않은 대규모 데이터 세트를 저장하기 위한 현재 클라우드 네이티브 선택은 AWS S3 [1], Google Cloud Storage(GCS) [3] 또는 MinIO [17]와 같은 객체 스토리지입니다. 객체 스토리지는 분산 네트워크 파일 시스템에 비해 세 가지 주요 이점을 제공합니다. (a) 비용 효율적이고, (b) 확장 가능하며, (c) 형식에 구애받지 않는 저장소 역할을 합니다. 그러나 클라우드 스토리지에도 단점이 없는 것은 아닙니다. 첫째, 특히 텍스트나 JSON과 같은 많은 작은 파일을 반복할 때 상당한 대기 시간 오버헤드가 발생합니다. 다음으로, 메타데이터 제어 없이 구조화되지 않은 데이터를 수집하면 "데이터 늪"이 발생할 수 있습니다. 또한 객체 스토리지에는 버전 제어 기능이 내장되어 있습니다. 데이터 과학 워크플로에서는 거의 사용되지 않습니다. 마지막으로, 객체 스토리지의 데이터는 훈련 전에 가상 머신에 복사되므로 스토리지 오버헤드와 추가 비용이 발생합니다.

2.4 2세대 데이터 레이크

Delta, Iceberg, Hudi [27, 15, 10]가 이끄는 2세대 데이터 레이크는 다음과 같은 기본 속성을 사용하여 테이블 형식 파일을 관리하여 객체 스토리지를 확장합니다.


(1) 업데이트 작업: 테이블 형식 파일 위에 행을 삽입하거나 삭제합니다.


(2) 스트리밍 : ACID 속성을 사용한 다운스트림 데이터 수집 및 SQL 인터페이스를 노출하는 쿼리 엔진과의 업스트림 통합.


(3) 스키마 진화: 이전 버전과의 호환성을 유지하면서 열 구조를 진화시킵니다.


(4) 시간 이동 및 감사 로그 추적: 쿼리를 재현할 수 있는 롤백 속성으로 기록 상태를 보존합니다. 또한 데이터 계보에 대한 행 수준 제어를 지원합니다.


(5) 레이아웃 최적화: 사용자 정의 순서 지원을 통해 파일 크기 및 데이터 압축을 최적화하는 기능이 내장되어 있습니다. 쿼리 속도가 크게 향상됩니다.


그러나 2세대 데이터 레이크는 앞서 섹션 2.2에서 논의한 것처럼 여전히 딥 러닝에 사용되는 고유 데이터 형식의 한계에 묶여 있습니다. 따라서 이 백서에서는 쿼리, 시각화, 딥 러닝 프레임워크에 대한 기본 통합을 포함하여 형식과 업스트림 기능을 다시 생각하여 그림 2와 같이 ML 수명 주기를 완료함으로써 딥 러닝 사용 사례를 위한 2세대 데이터 레이크 기능을 확장합니다. .


이 문서는 CC 4.0 라이선스에 따라 arxiv에서 볼 수 있습니다.