Microsoft Fabric và Databricks · Phần 3/5
Bài viết này thuộc loạt bài Microsoft Fabric và Databricks gồm năm phần. Anh chị có thể đọc các phần trong loạt bài dưới đây:
Databricks đáng được xem xét nghiêm túc khi công việc dữ liệu có các luồng xử lý phức tạp, nhiều nhóm cùng tham gia hoặc mô hình học máy cần chạy ổn định. Thế mạnh của nền tảng nằm ở năng lực kỹ thuật phía sau báo cáo. Đổi lại, vẫn phải có người chịu trách nhiệm về thiết kế, chất lượng và chi phí. Mua một nền tảng mạnh không làm những trách nhiệm đó biến mất.
Chiều sâu kỹ thuật mang lại điều gì?
Điểm hấp dẫn là đội ngũ có thể xây dựng một quy trình dữ liệu trọn vẹn trên cùng nền tảng: đưa dữ liệu vào, biến đổi, chạy các tác vụ theo lịch và chuẩn bị dữ liệu cho phân tích hoặc mô hình. Bộ công cụ Lakeflow (tài liệu tiếng Anh) của Databricks bao gồm nạp dữ liệu, xử lý theo lô và theo luồng, cùng điều phối tác vụ. Đây là những quy trình giúp số liệu tiếp tục được cập nhật sau buổi trình diễn đầu tiên.
Học máy cũng nằm trong cùng môi trường. MLflow trên Databricks (tài liệu tiếng Anh) hỗ trợ theo dõi, đánh giá và quản lý mô hình cũng như ứng dụng trí tuệ nhân tạo (AI). Điều này quan trọng khi mô hình phải trở thành một dịch vụ được duy trì lâu dài, có bằng chứng về cách nó hoạt động, thay vì chỉ dừng ở một notebook thú vị.
Theo chúng tôi, phạm vi công cụ này tạo ra giá trị khi kỹ thuật dữ liệu là công việc thường xuyên của doanh nghiệp. Nếu đội ngũ chỉ cần vài báo cáo đơn giản, phạm vi đó cũng có thể kéo theo nhiều khái niệm và quyết định vận hành hơn mức dự án cần. Quy mô công ty không phải tiêu chí đủ tốt để lựa chọn. Loại tác vụ và năng lực của đội ngũ là điểm xuất phát phù hợp hơn.
Quản trị là thế mạnh, nhưng vẫn cần thiết kế
Unity Catalog (tài liệu tiếng Anh) cung cấp kiểm soát truy cập, tìm kiếm dữ liệu, truy vết nguồn gốc và quá trình biến đổi dữ liệu, cùng khả năng kiểm tra nhật ký trên các tài sản dữ liệu và AI. Đội ngũ có thể xem một tập dữ liệu được tạo ra như thế nào và quản lý ai được phép sử dụng, thay vì để mỗi notebook trở thành một môi trường riêng biệt.
Đây là nền tảng hữu ích để tạo sự tin cậy. Tuy nhiên, nó không quyết định doanh thu được tính như thế nào, ai chịu trách nhiệm về nguồn dữ liệu hay một phép biến đổi có đúng hay không. Vẫn phải có người thống nhất định nghĩa, cấp quyền phù hợp và điều tra các vấn đề chất lượng.
Đó là sự đánh đổi xuyên suốt: nền tảng cung cấp công cụ để một đội ngũ có năng lực làm việc nhất quán. Nó không thể thay đội ngũ đưa ra những quyết định cần thiết để các công cụ đó phát huy giá trị.
Định dạng mở giúp ích, nhưng không bảo đảm rời nền tảng dễ dàng
Databricks hỗ trợ định dạng bảng Delta Lake và Apache Iceberg (tài liệu tiếng Anh). Nền tảng cũng cung cấp dịch vụ trên Amazon Web Services, Microsoft Azure và Google Cloud. Những lựa chọn này hữu ích khi doanh nghiệp muốn linh hoạt về cách lưu dữ liệu và nền tảng đám mây sử dụng.
Tuy nhiên, cần tách hai câu hỏi: một công cụ xử lý khác có đọc được dữ liệu không, và có thể chuyển toàn bộ giải pháp sang nơi khác không? Định dạng bảng mở hỗ trợ câu hỏi thứ nhất. Câu hỏi thứ hai còn liên quan đến các luồng xử lý, quyền truy cập, thư viện, quy trình triển khai và những tính năng đội ngũ đã chọn. Cần kiểm tra khả năng tương thích và tính năng sẵn có cho đúng công cụ, đám mây và khu vực triển khai.
Chúng tôi xem khả năng chuyển đổi là điều cần thử nghiệm, không phải điều một biểu tượng sản phẩm có thể bảo đảm. Nếu điều đó quan trọng với doanh nghiệp, hãy đưa việc đọc dữ liệu bằng một công cụ bên ngoài hoặc một bài thử di chuyển nhỏ vào giai đoạn thí điểm. Kế hoạch chuyển đổi rõ ràng hữu ích hơn lời hứa chung chung rằng doanh nghiệp sẽ không bị phụ thuộc vào nhà cung cấp.
Hóa đơn phụ thuộc vào tác vụ thực tế
Databricks không có một mức giá duy nhất đủ ý nghĩa để so trực tiếp với gói năng lực xử lý nhỏ nhất của Fabric. Nhiều dịch vụ tính toán được đo bằng Databricks Unit (DBU). Loại tác vụ, lựa chọn tài nguyên tính toán, khu vực và môi trường thực thi đều ảnh hưởng đến số tiền phải trả. DBU không thể quy đổi trực tiếp thành đơn vị năng lực xử lý của Fabric.
Công cụ tính giá Databricks cho thấy một khác biệt quan trọng: ước tính cho serverless, mô hình mà dịch vụ quản lý hạ tầng tính toán, đã gồm chi phí hạ tầng đó, còn ước tính cho mô hình không dùng serverless chưa gồm các dịch vụ đám mây nền bên dưới cần thiết. Một phép so sánh công bằng còn phải tính phần lưu trữ, mạng và những dịch vụ khác có áp dụng. So hai đơn giá nổi bật trên bảng giá không cho biết chi phí để tạo ra cùng một kết quả kinh doanh.
Serverless giảm công việc quản trị hạ tầng. Tuy nhiên, đội ngũ vẫn phải quyết định tác vụ chạy bao lâu một lần, xử lý dữ liệu gì và cần hỗ trợ bao nhiêu hoạt động đồng thời. Một luồng xử lý chạy nhanh nhưng bị chạy lặp lại không cần thiết vẫn có thể tốn kém.
Ngân sách và cảnh báo (tài liệu tiếng Anh) giúp chi phí trở nên rõ ràng hơn. Cần kiểm tra phạm vi và cơ chế thực thi, thay vì mặc định ngân sách là mức trần cứng cho mọi khoản phí. Hãy giao trách nhiệm theo dõi mức sử dụng và đối chiếu với giá trị kinh doanh cho một người cụ thể.
Người dùng nghiệp vụ cần một cách tiếp cận được thiết kế rõ ràng
Sẽ không đúng nếu mô tả Databricks là công cụ chỉ dành cho lập trình viên. Nền tảng có dashboard và Genie Agents (tài liệu tiếng Anh) để người dùng đặt câu hỏi bằng ngôn ngữ tự nhiên. Chuyên viên phân tích cấu hình Genie với dữ liệu, hướng dẫn, ví dụ và các tài sản dữ liệu đáng tin cậy. Người dùng nghiệp vụ vẫn hưởng lợi từ sự chuẩn bị đó; một ô chat không tự làm rõ những định nghĩa còn mơ hồ.
Genie Code (tài liệu tiếng Anh) hỗ trợ người phát triển tạo, hiểu và sửa mã. Đây là công việc khác với giúp người dùng nghiệp vụ tìm hiểu doanh số. Mã do AI tạo vẫn cần được rà soát.
Với Synnoia, Power BI vẫn là lớp báo cáo dù dùng nền tảng xử lý nào. Power BI kết nối được với Databricks (tài liệu tiếng Anh), nên chọn Databricks cho phần kỹ thuật không buộc doanh nghiệp phải thay trải nghiệm báo cáo mà người dùng đã quen. Mô hình dữ liệu, quy tắc truy cập, cách làm mới và hiệu năng vẫn cần được thiết kế có chủ đích.
Chúng tôi sẽ kiểm tra mức độ phù hợp như thế nào?
Chúng tôi sẽ xem xét Databricks sớm khi biến đổi phức tạp, xử lý dữ liệu theo luồng hoặc quy trình mô hình là nhu cầu thực sự, và đã có người chịu trách nhiệm về nền tảng. Với dự án chủ yếu phục vụ báo cáo trên hệ sinh thái Microsoft và có nhu cầu kỹ thuật hạn chế, chúng tôi cũng sẽ thử một thiết kế Fabric đơn giản hơn. Đây là điểm xuất phát cho thử nghiệm, không phải quy tắc áp đặt công ty nào phải mua sản phẩm nào.
- Dùng nhóm tác vụ đại diện. Bao gồm vận hành bình thường, giai đoạn cao điểm và tình huống khôi phục hoặc chạy lại. Đo thời gian cung cấp kết quả, độ tin cậy và tổng chi phí.
- Xác định người chịu trách nhiệm. Làm rõ trách nhiệm về chất lượng dữ liệu, quyền truy cập, triển khai, hỗ trợ và chi tiêu.
- Kiểm tra việc bàn giao cho người dùng nghiệp vụ. Để người dùng mở báo cáo và đặt những câu hỏi thực tế của họ. Kiểm tra xem định nghĩa và thời gian phản hồi có đáp ứng yêu cầu hay không.
Databricks xứng đáng được lựa chọn khi chiều sâu kỹ thuật giải quyết được bài toán mà đội ngũ thực sự có. Quyết định sẽ vững hơn khi thử nghiệm chứng minh được cả mức độ phù hợp về kỹ thuật lẫn khả năng vận hành tốt.
Đây là phần ba của loạt bài so sánh Microsoft Fabric và Databricks. Tiếp theo, chúng tôi sẽ xem hai nền tảng đang tiến gần nhau như thế nào và các khả năng AI làm thay đổi điều gì. Synnoia triển khai trên cả hai nền tảng và cung cấp báo cáo bằng Power BI. Cuộc trò chuyện đầu tiên hoàn toàn miễn phí.
