paint-brush
Deep Lake, Lakehouse cho Deep Learning: Những thách thức hiện tạitừ tác giả@dataology

Deep Lake, Lakehouse cho Deep Learning: Những thách thức hiện tại

dài quá đọc không nổi

Các nhà nghiên cứu giới thiệu Deep Lake, một Lakehouse nguồn mở để học sâu, tối ưu hóa việc lưu trữ và truyền phát dữ liệu phức tạp cho các khung học sâu.
featured image - Deep Lake, Lakehouse cho Deep Learning: Những thách thức hiện tại
Dataology: Study of Data in Computer Science HackerNoon profile picture
0-item

tác giả:

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

(2) Abhinav Tuli, Activeloop, Mountain View, CA, USA;

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

(4) Fariz Rahman, Activeloop, Mountain View, CA, USA;.

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

(6) David Isayan, Activeloop, Mountain View, CA, USA;

(7) Mark McQuade, Activeloop, Mountain View, CA, USA;

(8) Mikayel Harutyunyan, Activeloop, Mountain View, CA, USA;

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

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

(11) Davit Buniatyan, Activeloop, Mountain View, CA, Hoa Kỳ.

Bảng liên kết

2. THÁCH THỨC HIỆN TẠI

Trong phần này, chúng tôi thảo luận về những thách thức hiện tại và lịch sử của việc quản lý dữ liệu phức tạp hoặc phi cấu trúc.

2.1 Các kiểu dữ liệu phức tạp trong cơ sở dữ liệu

Nói chung không nên lưu trữ dữ liệu nhị phân, chẳng hạn như hình ảnh, trực tiếp trong cơ sở dữ liệu. Điều này là do cơ sở dữ liệu không được tối ưu hóa để lưu trữ và phục vụ các tệp lớn và có thể gây ra sự cố về hiệu suất. Ngoài ra, dữ liệu nhị phân không phù hợp với định dạng có cấu trúc của cơ sở dữ liệu, gây khó khăn cho việc truy vấn và thao tác. Điều này có thể dẫn đến thời gian tải chậm cho người dùng. Cơ sở dữ liệu thường đắt hơn để vận hành và bảo trì so với các loại lưu trữ khác, chẳng hạn như hệ thống tệp hoặc dịch vụ lưu trữ đám mây. Do đó, việc lưu trữ lượng lớn dữ liệu nhị phân trong cơ sở dữ liệu có thể tốn kém hơn các giải pháp lưu trữ khác.

2.2 Dữ liệu phức tạp cùng với định dạng bảng

Sự gia tăng khối lượng công việc phân tích và BI trên quy mô lớn đã thúc đẩy sự phát triển của các định dạng có cấu trúc nén như Parquet, ORC, Avro hoặc các định dạng trong bộ nhớ tạm thời như Arrow [79, 6, 20, 13]. Khi các định dạng dạng bảng được áp dụng rộng rãi, các nỗ lực mở rộng các định dạng đó, chẳng hạn như Petastorm [18] hoặc Feather [7] cho deep learning, đã xuất hiện. Theo hiểu biết tốt nhất của chúng tôi, các định dạng này vẫn chưa được áp dụng rộng rãi. Cách tiếp cận này chủ yếu được hưởng lợi từ việc tích hợp riêng với Ngăn xếp dữ liệu hiện đại (MDS). Tuy nhiên, như đã thảo luận trước đây, các công cụ ngược dòng yêu cầu sửa đổi cơ bản để thích ứng với các ứng dụng học sâu.

2.3 Lưu trữ đối tượng cho Deep Learning

Lựa chọn dựa trên nền tảng đám mây hiện tại để lưu trữ các tập dữ liệu phi cấu trúc lớn là lưu trữ đối tượng như AWS S3 [1], Google Cloud Storage (GCS) [3] hoặc MinIO [17]. Lưu trữ đối tượng mang lại ba lợi ích chính so với các hệ thống tệp mạng phân tán. Chúng (a) tiết kiệm chi phí, (b) có thể mở rộng và (c) đóng vai trò là kho lưu trữ không phân biệt định dạng. Tuy nhiên, kho lưu trữ đám mây không phải không có nhược điểm. Thứ nhất, chúng tạo ra chi phí độ trễ đáng kể, đặc biệt là khi lặp qua nhiều tệp nhỏ như văn bản hoặc JSON. Tiếp theo, việc nhập dữ liệu phi cấu trúc mà không có kiểm soát siêu dữ liệu có thể tạo ra "đầm dữ liệu". Hơn nữa, bộ lưu trữ đối tượng có tính năng kiểm soát phiên bản tích hợp; nó hiếm khi được sử dụng trong quy trình làm việc của khoa học dữ liệu. Cuối cùng, dữ liệu về lưu trữ đối tượng sẽ được sao chép sang máy ảo trước khi đào tạo, do đó dẫn đến chi phí lưu trữ và chi phí bổ sung.

2.4 Hồ dữ liệu thế hệ thứ hai

Các hồ dữ liệu thế hệ thứ hai do Delta, Iceberg, Hudi dẫn đầu [27, 15, 10] mở rộng lưu trữ đối tượng bằng cách quản lý các tệp định dạng dạng bảng với các thuộc tính chính sau.


(1) Thao tác cập nhật: chèn hoặc xóa một hàng ở đầu tệp định dạng bảng.


(2) Truyền trực tuyến : nhập dữ liệu xuôi dòng với các thuộc tính ACID và tích hợp ngược dòng với công cụ truy vấn hiển thị giao diện SQL.


(3) Tiến hóa lược đồ: phát triển cấu trúc cột trong khi vẫn duy trì khả năng tương thích ngược.


(4) Theo dõi nhật ký kiểm tra và du hành thời gian: lưu giữ trạng thái lịch sử với thuộc tính khôi phục trong đó các truy vấn có thể được tái tạo. Ngoài ra, hỗ trợ kiểm soát cấp hàng trên dòng dữ liệu.


(5) Tối ưu hóa bố cục: Tính năng tích hợp để tối ưu hóa kích thước tệp và nén dữ liệu với hỗ trợ sắp xếp tùy chỉnh. Tăng tốc đáng kể truy vấn.


Tuy nhiên, các hồ dữ liệu thế hệ thứ hai vẫn bị ràng buộc bởi những hạn chế của các định dạng dữ liệu vốn có được sử dụng trong học sâu, như đã thảo luận trước đây trong phần 2.2. Do đó, trong bài viết này, chúng tôi mở rộng khả năng hồ dữ liệu thế hệ thứ hai cho các trường hợp sử dụng học sâu bằng cách xem xét lại định dạng và các tính năng ngược dòng, bao gồm truy vấn, trực quan hóa và tích hợp gốc vào các khung học sâu để hoàn thành vòng đời ML như trong Hình 2. .


Bài viết này có sẵn trên arxiv theo giấy phép CC 4.0.