Google Cloud Platform sẽ sớm phát hành bản phát hành alpha của dịch vụ Dataproc, đặc biệt cho các công việc Apache Spark, chạy trên các cụm Google Kubernetes Engine (GKE).
Apache Spark là một khuôn khổ điện toán cụm được thiết kế để sử dụng như một công cụ xử lý cho các ứng dụng ETL (Extract, Transform, Load) hoặc khoa học dữ liệu. Nó thường được sử dụng với Apache Hadoop, cung cấp Hadoop YARN (Yet Another Resource Negotiator) để quản lý tài nguyên và HDFS để lưu trữ dữ liệu phân tán. Của Google dữ liệu dịch vụ cung cấp Hadoop và Spark trên Google Cloud Platform. Dịch vụ này tương tự như các bản phân phối Hadoop được quản lý trên AWS, có Amazon EMR (Elastic Map Reduce) và Microsoft Azure, có HDInsight.
Google, công ty đã tạo Kubernetes (K8s) để sắp xếp các vùng chứa trên các cụm, hiện đang chuyển Dataproc sang chạy trên K8s - mặc dù YARN sẽ tiếp tục được hỗ trợ dưới dạng một tùy chọn.
Có gì sai với SỢI? James Malone, giám đốc sản phẩm Google Cloud, cho biết: “Đó là một ngăn xếp khá nặng. Reg. “Mọi người đã cố gắng thay thế SỢI trong một thời gian khá dài. YARN ban đầu được thiết kế để chạy trên kim loại trần, nó đã được điều chỉnh để chạy trên máy ảo, nhưng lớp quản lý YARN đang di chuyển với tốc độ chậm hơn so với K8, điều này đã thúc đẩy nhiều khách hàng quan tâm đến K8 ”.
Malone cho biết “có một số điểm khó khăn của khách hàng với YARN” và “sử dụng các thùng chứa trong YARN ngay bây giờ là tốt nhưng không tốt. Nó không được thiết kế từ đầu cho khối lượng công việc được đóng gói. "
Giải pháp của Google bắt đầu bằng việc phát triển một mã nguồn mở Spark trên nhà điều hành Kubernetes.
“Chúng tôi đã làm điều này như một bước đầu tiên để bắt đầu chuyển hệ sinh thái sang bắt đầu chạy trên Kubernetes. Bạn có thể chạy Spark trên K8s ở bất cứ đâu và điều đó là ổn với chúng tôi, ”Malone nói.
Google đã triển khai Apache Spark trên Kubernetes
Theo Malone, việc chạy Spark trên K8s sẽ “quản lý tài nguyên dễ dàng hơn nhiều”. Điều này bao gồm các tính năng như tự động điều chỉnh tỷ lệ và tự động chữa bệnh.
Chuyển sang K8s yêu cầu phải chứa mã Spark của bạn nhưng Google cho rằng đây là một điều tốt. “Nếu tôi thực sự lấy mã Spark của mình và chứa nó, nó sẽ giúp bạn phát triển, thử nghiệm và sản xuất dễ dàng hơn. Điều đó cũng có nghĩa là nếu một phiên bản Spark mới ra mắt, bạn không nhất thiết phải đợi toàn bộ bản phân phối được cập nhật. Bạn chỉ cần cập nhật thành phần đó và sử dụng nó, ”Malone nói.
Bản phát hành hôm nay của Spark trên K8s là alpha, vì vậy chỉ để thử nghiệm và thử nghiệm. “Chúng tôi đang bắt đầu với Spark. Cuối cùng chúng tôi sẽ cung cấp hai phiên bản Dataproc. Một sẽ dựa trên YARN, sẽ tồn tại trong tương lai gần. Chúng tôi cũng sẽ có một hương vị Kubernetes và chúng tôi mong đợi rất nhiều sự phát triển bản dựng mới sẽ có trên K8s vì nó mang lại trải nghiệm phát triển tốt hơn, ”Malone nói với chúng tôi.
Một hàm ý khác là việc tích hợp các thành phần từ các nhà cung cấp bên thứ ba có thể được đơn giản hóa. Theo Malone: “Có thể cài đặt các thành phần của nhà cung cấp tùy chỉnh trên hệ sinh thái YARN, nhưng đó không phải là một trải nghiệm tuyệt vời. Kubernetes làm cho điều đó dễ dàng hơn nhiều. ” Ông nhận xét thêm rằng “đây cũng là nơi chúng tôi thấy mô hình kinh doanh cho rất nhiều thành phần nguồn mở đang hướng tới. Thay vì cố gắng để các công ty này sở hữu trải nghiệm end-to-end, chúng tôi đang cố gắng loại bỏ nhu cầu họ phải đi và phát triển những thứ như công cụ quản lý cụm và công cụ triển khai ”.
Nói cách khác, Malone thấy trước các nhà cung cấp linh kiện bên thứ ba dựa vào các nền tảng đám mây công cộng như của Google, một điều nghe có vẻ tốt cho Google nhưng không nhất thiết tốt cho các bên thứ ba.
Spark chỉ là một trong những dự án mà Google đang tạo ra các nhà khai thác K8s. Những người khác bao gồm Apache Flink, Presto và Apache Druid.
Điều gì sẽ xảy ra nếu bạn muốn chuyển đổi một dự án Dataproc hiện có sang sử dụng K8s? Malone nói rằng cần phải thẳng thắn. “Các mô hình lập trình không thay đổi. Tia lửa là Spark. Bạn có thể phải đóng gói và chứa đựng khối lượng công việc của mình nhưng nói chung điều đó không khó và một khi bạn làm như vậy thì mã của bạn sẽ dễ di chuyển hơn rất nhiều. "
Về phía quản lý, việc sử dụng API Dataproc hoặc bảng điều khiển đám mây của Google sẽ dễ dàng hơn so với việc phải giao dịch trực tiếp với K8s. “Chúng tôi cũng sẽ hỗ trợ sử dụng các công cụ dòng lệnh K8s nếu bạn muốn, nhưng hầu hết khách hàng cuối cùng sử dụng các công cụ khách hàng của chúng tôi vì chúng được hỗ trợ đầy đủ, chúng có rất nhiều kiểm tra lỗi bổ sung, chúng được thiết kế để hỗ trợ hầu hết những gì khách hàng muốn Malone nói.
Một hạn chế trong bản phát hành đầu tiên là “Dataproc sẽ tạo tài nguyên Spark trên một cụm K8s hiện có,” Malone nói với chúng tôi. “Nhưng xét đến việc Dataproc có thể tự tạo và phá hủy các tài nguyên cụm ngày nay, chỉ là vấn đề thời gian trước khi chúng tôi hỗ trợ việc tạo và phá hủy các cụm K8s.”
Trong trường hợp kịch bản kết hợp hoặc đa đám mây, Dự án Anthos của Google giúp bạn linh hoạt về nơi chạy mã của mình. “Tầm nhìn của chúng tôi là Dataproc là mặt phẳng điều khiển duy nhất cho dù bạn đang chạy trên Google Cloud hoặc tại chỗ ở Anthos hay trên một đám mây khác ở Anthos,” Malone nói.
Động lực đằng sau K8s làm cho loại chuyển đổi này không thể tránh khỏi. Google Cloud Platform đứng sau AWS và Microsoft Azure về thị phần, do đó, việc tận dụng vị trí nhà phát minh ra K8s để thúc đẩy việc sử dụng nó cũng là điều đương nhiên. ®
