Hệ thống kiểm soát phiên bản cho Khoa học Dữ liệu

Theo dõi các thay đổi mà bạn hoặc cộng tác viên thực hiện đối với dữ liệu và phần mềm là phần then chốt của bất kỳ dự án nào, dù là nghiên cứu, khoa học dữ liệu hay kỹ thuật phần mềm. Khả năng tham chiếu hoặc truy xuất một phiên bản cụ thể của toàn bộ dự án giúp bạn đảm bảo khả năng tái lập trước khi xuất bản, khi phản hồi ý kiến phản biện, và khi cung cấp thông tin bổ trợ cho phản biện, biên tập viên và độc giả.

Các công cụ tốt nhất để theo dõi thay đổi là những hệ thống kiểm soát phiên bản được dùng trong phát triển phần mềm, như Git, Mercurial và Subversion. Chúng ghi lại nội dung nào đã được thay đổi trong một tệp, khi nào và bởi ai, đồng thời đồng bộ thay đổi lên máy chủ trung tâm để nhiều người cùng có thể quản lý thay đổi trên cùng một tập tệp.

Dù các công cụ này giúp việc theo dõi thay đổi dễ dàng hơn, chúng có thể đòi hỏi thời gian học khá nhiều. Để vượt qua đường cong học tập đó, có hai nhóm khuyến nghị: một cách tiếp cận thủ công có hệ thống để quản lý thay đổi và kiểm soát phiên bản đầy đủ, và bạn có thể dùng cách thứ nhất trong khi tiến tới cách thứ hai, hoặc nhảy thẳng vào kiểm soát phiên bản.

Phương pháp hay nhất cho Kiểm soát Phiên bản

Dù bạn chọn khuyến nghị nào, có một số phương pháp hay nhất hoặc khuyến nghị chung mà bạn nên cân nhắc:

1. Sao lưu (gần như) mọi thứ do con người tạo ra ngay khi nó được tạo. Điều này bao gồm mọi loại script và chương trình, các gói phần mềm mà dự án của bạn phụ thuộc vào, và tài liệu. Một vài ngoại lệ cho quy tắc này sẽ được thảo luận bên dưới.

2. Giữ thay đổi ở mức nhỏ. Mỗi thay đổi không nên lớn đến mức làm cho việc theo dõi thay đổi mất ý nghĩa. Ví dụ, một thay đổi duy nhất như Revise script file thêm hoặc sửa vài trăm dòng có lẽ là quá lớn, vì nó không cho phép kiểm tra riêng rẽ các thay đổi ở các thành phần khác nhau của một phân tích. Tương tự, thay đổi cũng không nên bị chia nhỏ thành những phần quá vụn vặt. Theo kinh nghiệm, kích thước hợp lý cho một thay đổi đơn lẻ là một nhóm chỉnh sửa mà bạn có thể hình dung sẽ muốn hoàn tác trong một bước nào đó trong tương lai.

3. Chia sẻ thay đổi thường xuyên. Tất cả những người làm trong dự án nên chia sẻ và tiếp nhận thay đổi từ người khác một cách đều đặn. Đừng để các phiên bản kho dự án của từng người tách rời nhau, vì công sức cần thiết để hợp nhất khác biệt sẽ tăng nhanh hơn kích thước khác biệt. Điều này đặc biệt quan trọng với quy trình phiên bản thủ công mô tả bên dưới, vốn không hỗ trợ hợp nhất các thay đổi đồng thời, có thể xung đột.

4. Tạo, duy trì và sử dụng một danh sách kiểm cho việc lưu và chia sẻ thay đổi của dự án. Danh sách nên bao gồm việc viết thông điệp nhật ký giải thích rõ ràng bất kỳ thay đổi nào, kích thước và nội dung của từng thay đổi, hướng dẫn phong cách cho mã, cập nhật danh sách việc cần làm, và cấm đưa lên những phần việc làm dở hoặc mã bị hỏng.

5. Lưu mỗi dự án trong một thư mục được phản chiếu ra ngoài máy làm việc của nhà nghiên cứu bằng một hệ thống như Dropbox hoặc kho lưu trữ từ xa như GitHub. Đồng bộ thư mục đó ít nhất mỗi ngày. Có thể mất vài phút, nhưng thời gian đó sẽ được đền đáp ngay khi máy tính xách tay bị đánh cắp hoặc ổ cứng hỏng.

Cách tiếp cận Phiên bản thủ công

Cách tiếp cận đầu tiên, trong đó mọi thứ đều làm bằng tay, có hai phần bổ sung.

Trước hết, thêm một tệp tên là CHANGELOG.txt vào thư mục con docs của dự án, và ghi chú có ngày tháng về các thay đổi của dự án trong tệp này theo thứ tự thời gian đảo ngược (tức là mới nhất trước). Tệp này tương đương với sổ tay phòng thí nghiệm, và nên chứa các mục như minh họa bên dưới.

## 2016-04-08

* Switched to cubic interpolation as default.
* Moved question about family's TB history to end of questionnaire.

## 2016-04-06

* Added option for cubic interpolation.
* Removed question about staph exposure (can be inferred from blood test results).

Tiếp theo, sao chép toàn bộ dự án mỗi khi có một thay đổi đáng kể (tức là thay đổi ảnh hưởng thực chất đến kết quả), và lưu bản sao đó trong một thư mục con có tên phản ánh ngày tháng trong khu vực đang được đồng bộ. Cách này dẫn đến việc các dự án được tổ chức như dưới đây:

.
|-- project_name
|   -- current
|       -- ...project content as described earlier...
|   -- 2016-03-01
|       -- ...content of 'current' on Mar 1, 2016
|   -- 2016-02-19
|       -- ...content of 'current' on Feb 19, 2016

Ở đây, thư mục project_name được ánh xạ tới bộ nhớ ngoài (như Dropbox), current là nơi công việc đang diễn ra, và các thư mục khác trong project_name là các phiên bản cũ.

Ưu và nhược điểm của Phiên bản thủ công

Bạn sẽ thường nghe câu "Dữ liệu rẻ, thời gian mới đắt". Sao chép mọi thứ như cách tiếp cận trên có thể có vẻ lãng phí, vì nhiều tệp sẽ không thay đổi, nhưng hãy cân nhắc: một ổ cứng terabyte giá khoảng \$50 bán lẻ, nghĩa là 50 GByte có giá chưa đến $5. Miễn là các tệp dữ liệu lớn được để ngoài khu vực sao lưu (điều này sẽ được bàn chi tiết hơn bên dưới), cách tiếp cận này tốn kém ít hơn thời gian cần để chọn tệp thủ công để sao chép.

Quy trình thủ công này đáp ứng các yêu cầu nêu trên mà không cần công cụ mới. Tuy nhiên, nếu nhiều nhà nghiên cứu cùng làm trên một dự án, họ sẽ cần phối hợp để chỉ một người làm việc trên các tệp cụ thể tại một thời điểm. Cụ thể, họ có thể muốn tạo một tệp changelog cho mỗi người đóng góp, và hợp nhất các tệp đó mỗi khi tạo một bản sao lưu.

Hệ thống Kiểm soát Phiên bản

Điều mà quy trình thủ công trên cần nhất là tính kỷ luật. Những công cụ làm nền tảng cho cách tiếp cận thứ hai của chúng tôi - cách mà chúng tôi dùng trong chính các dự án của mình - không chỉ tăng tốc quy trình thủ công: chúng còn tự động hóa một số bước đồng thời bắt buộc một số bước khác, nhờ đó đòi hỏi ít kỷ luật tự giác hơn mà vẫn cho kết quả tin cậy hơn.

Khó biết công cụ nào được dùng rộng rãi nhất trong nghiên cứu ngày nay, nhưng công cụ được nhắc đến nhiều nhất chắc chắn là Git. Phần lớn là nhờ GitHub, một trang lưu trữ phổ biến kết hợp hạ tầng kỹ thuật cho cộng tác qua Git với giao diện web hiện đại. GitHub miễn phí cho các dự án công khai và mã nguồn mở, cũng như cho người dùng trong học thuật và tổ chức phi lợi nhuận. GitLab là một lựa chọn thay thế được đánh giá cao mà một số người ưa thích, vì chính nền tảng GitLab là phần mềm tự do và mã nguồn mở. Bitbucket cung cấp lưu trữ miễn phí cho cả kho Git và Mercurial, nhưng không có nhiều người dùng trong giới khoa học.

Những gì Không nên đưa vào Kiểm soát Phiên bản

Kích thước và định dạng tệp

Lợi ích của hệ thống kiểm soát phiên bản không áp dụng như nhau cho mọi loại tệp. Đặc biệt, các hệ thống này có thể hữu ích hơn hoặc kém hơn tùy theo kích thước và định dạng tệp.

• Thứ nhất, so sánh tệp trong hệ thống kiểm soát phiên bản được tối ưu cho tệp văn bản thuần, như mã nguồn. Thông thường, khả năng xem các "diff" là một trong những điều tuyệt vời của kiểm soát phiên bản. Đáng tiếc là, dù các tệp Microsoft Office (như tệp .docx dùng bởi Word) hay các tệp nhị phân khác, ví dụ PDF, có thể được lưu trong hệ thống kiểm soát phiên bản, thì không thể xác định chính xác các thay đổi cụ thể giữa các phiên bản. Dữ liệu dạng bảng, như tệp CSV, cũng có thể đưa vào hệ thống như vậy, nhưng thay đổi thứ tự hàng hoặc cột sẽ tạo ra một thay đổi lớn, ngay cả khi bản thân dữ liệu không đổi.

• Thứ hai, dữ liệu thô không nên thay đổi, và vì vậy không cần theo dõi phiên bản. Việc đưa các tệp dữ liệu trung gian và các kết quả khác vào kiểm soát phiên bản cũng không cần thiết nếu bạn có thể tái tạo chúng từ dữ liệu thô và phần mềm. Tuy nhiên, nếu dữ liệu và kết quả nhỏ, nên đưa vào kiểm soát phiên bản để cộng tác viên dễ truy cập và để so sánh giữa các phiên bản.

• Thứ ba, các hệ thống kiểm soát phiên bản ngày nay không được thiết kế để xử lý tệp kích thước megabyte, chưa nói đến gigabyte, nên không nên đưa các tệp dữ liệu hoặc kết quả lớn vào. (Lấy mốc "lớn" làm tham chiếu, giới hạn cho một tệp cá nhân trên GitHub là 100MB.) Một số hệ thống lai mới nổi như Git LFS đưa ghi chú dạng văn bản vào kiểm soát phiên bản, trong khi lưu dữ liệu lớn trên máy chủ từ xa, nhưng chúng chưa đủ trưởng thành để chúng tôi có thể khuyến nghị.

Chia sẻ ngoài ý muốn

Một trường hợp khác mà lợi ích của hệ thống kiểm soát phiên bản không thực sự có lợi cho bạn là trường hợp "chia sẻ ngoài ý muốn". Các nhà nghiên cứu làm việc với dữ liệu chịu ràng buộc pháp lý cấm chia sẻ (như dữ liệu y tế) nên cẩn trọng không đưa dữ liệu lên các hệ thống kiểm soát phiên bản công khai. Một số tổ chức có thể cung cấp quyền truy cập vào các hệ thống riêng tư, vì vậy đáng để bạn kiểm tra với bộ phận CNTT.

Ngoài ra, hãy chắc chắn không vô tình đặt thông tin xác thực bảo mật, như mật khẩu và khóa riêng, vào hệ thống kiểm soát phiên bản nơi người khác có thể truy cập.

Nếu bạn muốn thử tất cả những điều này, vui lòng xem khóa học giới thiệu miễn phí về Git cho Khoa học Dữ liệu của chúng tôi.

Lời cảm ơn

Bài viết này trích từ "Good enough practices in scientific computing" của Greg Wilson, Jennifer Bryan, Karen Cranston, Justin Kitzes, Lex Nederbragt và Tracy K. Teal, https://doi.org/10.1371/journal.pcbi.1005510.