Nhóm gợi ý của Kakao áp dụng Rust
(tech.kakao.com)Nhóm gợi ý của Kakao đang phát triển một nền tảng mới để thay thế nền tảng machine learning hiện có.
Với Python là ngôn ngữ chủ lực trong nhóm, có những điểm hơi khó để đồng thời đảm bảo cả hiệu năng lẫn độ an toàn của ứng dụng.
Nhóm đã đưa Rust vào ứng dụng chỉ số người dùng và tiến hành quy trình kiểm chứng xem việc triển khai ứng dụng bằng Rust có phù hợp hay không.
- Rust xử lý tác vụ nhanh hơn Python khoảng 1,9 lần
- Mức sử dụng bộ nhớ của Python cao hơn Rust khoảng 4,5 lần
- Mức sử dụng CPU của Python cao hơn Rust tối đa 3 lần, trung bình khoảng 2 lần
asynciocủa Python vàtokiocủa Rust được áp dụng cho ứng dụng của từng ngôn ngữ, và ngay cả trong môi trường đơn luồng nơi xử lý bất đồng bộ được triển khai tương đương, tốc độ xử lý message của Rust vẫn nhanh hơn Python khoảng 10 lần.
Một trong những nhược điểm lớn của Rust là chi phí học tập khá cao.
Ngay cả khi phát triển bằng Python, nhóm cũng bắt buộc dùng type annotation. Khi triển khai ứng dụng chỉ số người dùng với hai phiên bản, họ không cảm nhận rõ sự khác biệt lớn về thời gian phát triển giữa Python và Rust.
Khác biệt lớn nhất cảm nhận được về mặt năng suất là thời gian biên dịch. (bao gồm cả thời gian tải package và Docker)
- Rust vào khoảng 340 giây
- Python vào khoảng 100 giây
Khi dùng Python, dữ liệu được tạo từ các thư viện không có thông tin kiểu sẽ mang kiểu Any, khiến việc kiểm tra kiểu bị bỏ qua. Điều này làm giảm độ chính xác của kiểm tra kiểu trong toàn bộ dự án.
Cũng có những khác biệt như Python dùng exception còn Rust dùng kiểu enum Result.
Công cụ phát triển
Với Rust, cargo cung cấp sẵn khá nhiều tính năng theo mặc định.
Công cụ phát triển cho Python đã rất hoàn thiện, chỉ cần cài đặt là có thể dùng tương đối dễ dàng.
4 bình luận
Tôi không có kinh nghiệm với cả Python lẫn Rust, nhưng chỉ xét riêng bài viết thì tôi không cảm nhận được lợi thế lớn nào của việc đưa Rust vào.
Không phải là Rust không tốt, mà là cả thí nghiệm được tiến hành để đưa Rust vào cũng khá sơ sài,
(chỉ dựa vào kết quả xử lý vỏn vẹn 50 message rồi cho rằng nhanh hơn vài lần nên tốt hơn vài lần thì có vẻ là lập luận quá yếu..)
Hơn nữa, họ cũng không so sánh với cùng một logic xử lý (đồng bộ vs bất đồng bộ)..
[thư viện Python hỗ trợ xử lý message bất đồng bộ nhưng không có nhiều reference] vs [ngôn ngữ Rust có chi phí học tập cao và rủi ro bảo trì do ít người phụ trách]
Khi đặt hai tình huống này cạnh nhau, tôi cũng nghi ngờ liệu họ đã thực sự cân nhắc nghiêm túc về tính bền vững trong tương lai hay chưa (ít nhất là cảm nhận của tôi khi đọc bài là vậy)
Với đặc thù của ETL, có lẽ sẽ có nhiều trường hợp cần test ngắn và thường xuyên, nên build time 100 giây vs 300 giây có vẻ sẽ là một điểm nghẽn lớn trong quá trình phát triển.
Bài viết có nhắc rằng incremental build rất tốt, nhưng phần đó lại được thay bằng hyperlink...
Trên thực tế, có lẽ họ đã điều tra và xem xét rất kỹ, nhưng ít nhất theo những gì bài viết truyền tải thì... thật khó để biết chính xác việc đưa Rust vào đã cải thiện điều gì, hiệu quả kỳ vọng là gì, và nó đã giải quyết được vấn đề nào; cũng khó để đồng cảm.
Cá nhân tôi từng thấy nhiều trường hợp chọn công nghệ chỉ vì "công nghệ đang hot gần đây" hoặc để thêm một dòng đẹp cho sự nghiệp, nhưng kết quả thì đa số là đội ngũ cũng không thể bảo trì nổi và cuối cùng nó trở thành nợ kỹ thuật.
Tất nhiên tôi không nói bài viết về Rust ở trên là như vậy, và tôi cũng hy vọng là không phải thế..
Nhưng sau khi nhiều lần trải qua việc cả team phải gánh hậu quả từ những công nghệ được đưa vào mà không có sự cân nhắc nghiêm túc, tôi thấy mình trở nên thận trọng hơn khi đọc những bài viết kiểu quảng bá công nghệ như thế này.
Về cơ bản trông giống như một ETL task, nên tôi muốn biết liệu trong lĩnh vực này mọi người có cân nhắc Java, vốn cũng có thế mạnh bên cạnh Python, hay không; và nếu đã loại trừ để chọn Rust thì tôi muốn biết lý do là gì.
Thật đáng tiếc khi một phần tài liệu so sánh hiệu năng được thu thập thông qua các bài kiểm thử quy mô nhỏ.
Ý nghĩa của bài kiểm tra hiệu năng thay đổi rất nhiều tùy theo đặc tính của workload, nên khá tiếc là không có phần giải thích về cách thiết kế bài test hay các con số đã được thu thập như thế nào.
Ví dụ, tôi tò mò liệu sau khi xử lý 5 triệu bản ghi thì có lấy trung bình cộng dựa trên việc xử lý 50 bản ghi hay không; nếu vậy thì mức sử dụng bộ nhớ được tính thế nào, chênh lệch mức sử dụng CPU được đo ra sao, v.v. (Thời gian chắc là wall-clock time nhỉ?)
Ngoài ra, có nhận định rằng “khi xem mức sử dụng CPU, phần lớn chênh lệch hiệu năng giữa hai ngôn ngữ bắt nguồn từ tác vụ tiêu thụ message Kafka và tác vụ lưu document vào MongoDB, tức các công việc I/O (Input Output, dưới đây gọi là IO)”, nhưng ở phần kết quả thì wall-clock time của Rust chỉ bằng khoảng 1/2, còn mức sử dụng CPU (CPU time?) là 1/4.5, nên tôi hơi khó hiểu logic ở đây: ý là do khác biệt trong cách triển khai liên quan đến I/O, hay là do khác biệt trong quá trình xử lý dữ liệu I/O vốn mang tính CPU-intensive? Thực ra việc Rust có lợi thế với các tác vụ CPU-intensive đã là điều khá quen thuộc, nên nếu là trường hợp sau thì có vẻ cũng không cần thiết phải nhắc riêng đến khác biệt của thư viện. Ngược lại, nếu trong thí nghiệm đó là tác vụ CPU-intensive thì lẽ ra chênh lệch phải lớn hơn nhiều, giống như phần bài viết cũng đã nhắc tới khi so sánh triển khai asyncio/tokio; vì thế tôi nghĩ có lẽ nên hiểu rằng do có I/O nên chênh lệch hiệu năng mới ít hơn, chẳng phải vậy sao.