Đường ống khoa học dữ liệu và các mô hình đơn sắc


8

Thông thường, một chủ đề quan trọng trong DevOps là cách chúng tôi chăm sóc việc tạo và phân phối tự động các đồ tạo tác phần mềm.

Với sự phát triển của khoa học dữ liệu, có một loại vật phẩm mới - các đốm nhị phân đơn sắc đại diện cho một mạng lưới thần kinh được đào tạo, ví dụ hoặc các mô hình học máy khác. Một blob như vậy có thể có kích thước nhiều GB và việc tạo ra nó chưa được chuẩn hóa AFAIK, điều này đưa các tổ chức trở lại thời kỳ tiền CI. Tuy nhiên, họ có phiên bản và các bộ sưu tập dữ liệu đào tạo liên quan (cora) có xu hướng phát triển nhanh chóng.

Thực tiễn tốt nhất để giải quyết thách thức mới này bằng phương pháp DevOps là gì - nếu thậm chí có thể?


3
Tôi không thấy sự khác biệt giữa một đốm màu lớn và một uberjar trong bối cảnh java. Thực hành tương tự được áp dụng, kích thước của một vật phẩm có một vài lý do để đi vào chơi.
Tensibai

Xin chào - Tôi nghĩ với uber-jars từ 2gb trở lên, bạn sẽ kể cho họ nghe câu chuyện kiến ​​trúc microservice, hay? .. Nhưng các mô hình blobs chỉ bắt đầu từ đó, 8gb sẽ không còn hiếm.
Peter Muryshkin

1
Tôi chỉ có nghĩa là ảnh chụp nhanh dB của 350Go không phải là một tài sản khác với bình 5Mo, dù sao nó cũng phải được lưu trữ ở đâu đó và kho lưu trữ giả có thể xử lý điều đó
Tensibai

Tôi đồng ý - chỉ vì chương trình kết quả lớn không có nghĩa là nó vẫn chưa được biên dịch, phiên bản và lưu trữ như mọi thứ khác (mặc dù có thể có một vài thách thức về lưu trữ), vì vậy tôi không thấy cách này "đưa các tổ chức trở lại tuổi tiền CI "Nếu một tổ chức nghĩ vậy, tôi không chắc rằng họ thực sự hiểu DevOps / CI.
James Shewey

Câu trả lời:


8

Cá nhân tôi không thấy bất kỳ lý do nào mà Kho lưu trữ nhân tạo - công cụ DevOps được đề xuất trong việc quản lý đồ tạo tác - sẽ không thể áp dụng cho các mạng lưới thần kinh được đào tạo hoặc các đồ tạo tác khác.

Kích thước vật phẩm có thể có một số giới hạn trên đối với kho lưu trữ vật phẩm cụ thể, nhưng trong trường hợp đó, nó sẽ là giới hạn kỹ thuật hoặc chính sách, không phải là giới hạn cơ bản / chính.

Đối với việc áp dụng các phương pháp DevOps cho quy trình sản xuất các đồ tạo tác này, tôi nghĩ hầu hết nếu không phải tất cả chúng đều có thể được áp dụng tốt như nhau, miễn là các đồ tạo tác:

  • được sản xuất từ ​​một số loại đặc tả hỗ trợ thay đổi phiên bản (tương đương với mã nguồn phần mềm)
  • được xây dựng thông qua một quá trình lặp lại và tự động
  • được xác thực bằng cách sử dụng một số loại xác minh có thể lặp lại và tự động hóa (tương tự QA), cuối cùng sử dụng một số dữ liệu hỗ trợ (ví dụ: dữ liệu huấn luyện trong trường hợp này, tương đương với ảnh chụp nhanh DB)

Lưu ý bên lề: việc cung cấp mã phần mềm nguyên khối vẫn còn là một vấn đề lớn và hoàn toàn có thể duy trì được với các phương pháp DevOps (với một chút cẩn thận), không phải mọi thứ đều có thể được phân chia trong microservice. Kích thước không đủ quan trọng để làm cho DevOps không áp dụng.


Câu trả lời hoàn hảo. Tôi lưu trữ tất cả các mô hình nặng của mình vào git lfsvà kéo chúng khi cần thiết [mô hình không có máy chủ] :)
Dawny33

@ Dawny33 nhưng bây giờ bạn có muốn xem xét di chuyển khỏi git lfs không?
Peter Muryshkin

@ J.Doe Cho đến nay rất tốt với lfs. Có lẽ sẽ di chuyển nếu tôi tìm thấy một sự thay thế thực sự tốt hơn.
Dawny33

sau đó tôi không hiểu tại sao bạn nói câu trả lời là "hoàn hảo" trong khi nó gợi ý sử dụng kho lưu trữ vật phẩm?! @ Dawny33
Peter Muryshkin

2
DVC có thể được coi là một sự thay thế tốt hơn chogit-lfs
Shcheklein

4

Tôi sẽ khuyên bạn nên xem DVC - một hệ thống kiểm soát phiên bản nguồn mở cho các dự án khoa học dữ liệu.

Một trong những điều cơ bản mà nó xử lý hoàn hảo là quản lý các tệp dữ liệu (cùng với mã) - đầu vào, đầu ra (mô hình), kết quả trung gian. Về mặt ngữ nghĩa, nó tương tự git-lfsnhưng không giống như git-lfsnó có khả năng quản lý các tệp như 100GB và điều quan trọng hơn là nó không phụ thuộc vào định dạng / lưu trữ độc quyền. Nó hoàn toàn là nguồn mở và tương thích với mọi bộ lưu trữ mạng dưới dạng máy chủ để giữ các tệp dữ liệu - S3, lưu trữ đám mây GCP, SSH, FTP, v.v.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.