Đây là bài đăng của khách được đồng sáng tác với Brandon Abear, Dinesh Sharma, John Bush và Ozcan IIikhan từ GoDaddy.

GoDaddy trao quyền cho các doanh nhân hàng ngày bằng cách cung cấp tất cả trợ giúp và công cụ để thành công trực tuyến. Với hơn 20 triệu khách hàng trên toàn thế giới, GoDaddy là nơi mọi người đến nêu ý tưởng, xây dựng trang web chuyên nghiệp, thu hút khách hàng và quản lý công việc của mình.

Tại GoDaddy, chúng tôi tự hào là công ty hoạt động dựa trên dữ liệu. Việc chúng tôi không ngừng theo đuổi những hiểu biết có giá trị từ dữ liệu sẽ thúc đẩy các quyết định kinh doanh của chúng tôi và đảm bảo sự hài lòng của khách hàng. Cam kết của chúng tôi về tính hiệu quả là không thay đổi và chúng tôi đã thực hiện một sáng kiến ​​thú vị nhằm tối ưu hóa công việc xử lý hàng loạt của mình. Trong hành trình này, chúng tôi đã xác định một cách tiếp cận có cấu trúc mà chúng tôi gọi là bảy lớp cơ hội cải tiến. Phương pháp này đã trở thành kim chỉ nam cho chúng tôi trong việc theo đuổi hiệu quả.

Trong bài đăng này, chúng tôi thảo luận về cách chúng tôi nâng cao hiệu quả hoạt động với Amazon EMR không có máy chủ. Chúng tôi chia sẻ kết quả và phương pháp đo điểm chuẩn cũng như thông tin chi tiết về hiệu quả chi phí của EMR Serverless so với công suất cố định Amazon EMR trên EC2 các cụm tạm thời trên quy trình làm việc dữ liệu của chúng tôi được sắp xếp bằng cách sử dụng Quy trình công việc được quản lý của Amazon cho Luồng khí Apache (Amazon MWAA). Chúng tôi chia sẻ chiến lược của mình về việc áp dụng EMR Serverless ở những lĩnh vực mà nó vượt trội. Phát hiện của chúng tôi cho thấy những lợi ích đáng kể, bao gồm giảm hơn 60% chi phí, khối lượng công việc Spark nhanh hơn 50%, cải thiện đáng kể gấp XNUMX lần về tốc độ phát triển và thử nghiệm cũng như giảm đáng kể lượng khí thải carbon của chúng tôi.

Tiểu sử

Vào cuối năm 2020, nền tảng dữ liệu của GoDaddy đã bắt đầu hành trình Đám mây AWS, di chuyển cụm Hadoop 800 nút với 2.5 PB dữ liệu từ trung tâm dữ liệu của mình sang EMR trên EC2. Phương pháp nâng và chuyển đổi này tạo điều kiện so sánh trực tiếp giữa môi trường tại chỗ và đám mây, đảm bảo quá trình chuyển đổi suôn sẻ sang quy trình AWS, giảm thiểu các vấn đề xác thực dữ liệu và độ trễ di chuyển.

Đến đầu năm 2022, chúng tôi đã di chuyển thành công khối lượng công việc dữ liệu lớn sang EMR trên EC2. Bằng cách sử dụng các phương pháp thực hành tốt nhất học được từ chương trình AWS FinHack, chúng tôi đã tinh chỉnh các công việc sử dụng nhiều tài nguyên, chuyển đổi công việc Pig và Hive thành Spark, đồng thời giảm 22.75% chi tiêu khối lượng công việc hàng loạt vào năm 2022. Tuy nhiên, đã xuất hiện những thách thức về khả năng mở rộng do có quá nhiều công việc . Điều này đã thôi thúc GoDaddy bắt tay vào hành trình tối ưu hóa hệ thống, thiết lập nền tảng để xử lý dữ liệu lớn bền vững và hiệu quả hơn.

Bảy lớp cơ hội cải tiến

Trong nỗ lực nâng cao hiệu quả hoạt động, chúng tôi đã xác định được bảy lớp cơ hội riêng biệt để tối ưu hóa trong các công việc xử lý hàng loạt của mình, như minh họa trong hình sau. Các lớp này bao gồm từ các cải tiến cấp mã chính xác đến các cải tiến nền tảng toàn diện hơn. Cách tiếp cận nhiều lớp này đã trở thành kế hoạch chi tiết chiến lược của chúng tôi trong việc không ngừng theo đuổi hiệu suất tốt hơn và hiệu quả cao hơn.

Các lớp như sau:

• Tối ưu hóa mã – Tập trung vào việc tinh chỉnh logic mã và cách tối ưu hóa nó để có hiệu suất tốt hơn. Điều này liên quan đến việc cải thiện hiệu suất thông qua bộ nhớ đệm có chọn lọc, cắt tỉa phân vùng và trình chiếu, tối ưu hóa kết nối và điều chỉnh theo công việc cụ thể khác. Sử dụng giải pháp mã hóa AI cũng là một phần không thể thiếu trong quá trình này.
• Nâng cấp phần mềm - Cập nhật lên các phiên bản mới nhất của phần mềm nguồn mở (OSS) để tận dụng các tính năng và cải tiến mới. Ví dụ: Thực thi truy vấn thích ứng trong Spark 3 mang lại những cải thiện đáng kể về hiệu suất và chi phí.
• Cấu hình Spark tùy chỉnh – Điều chỉnh cấu hình Spark tùy chỉnh để tối đa hóa việc sử dụng tài nguyên, bộ nhớ và tính song song. Chúng ta có thể đạt được những cải tiến đáng kể bằng cách sắp xếp hợp lý các nhiệm vụ, chẳng hạn như thông qua spark.sql.shuffle.partitions, spark.sql.files.maxPartitionBytes, spark.executor.coresvà spark.executor.memory. Tuy nhiên, những cấu hình tùy chỉnh này có thể phản tác dụng nếu chúng không tương thích với phiên bản Spark cụ thể.
• Thời gian cung cấp tài nguyên – Thời gian cần thiết để khởi chạy các tài nguyên như cụm EMR phù du trên Đám mây điện toán đàn hồi Amazon (Amazon EC2). Mặc dù một số yếu tố ảnh hưởng đến thời gian này nằm ngoài tầm kiểm soát của kỹ sư, nhưng việc xác định và giải quyết các yếu tố có thể được tối ưu hóa có thể giúp giảm thời gian cung cấp tổng thể.
• Chia tỷ lệ chi tiết ở cấp độ nhiệm vụ – Tự động điều chỉnh các tài nguyên như CPU, bộ nhớ, ổ đĩa và băng thông mạng dựa trên nhu cầu của từng giai đoạn trong một tác vụ. Mục đích ở đây là để tránh kích thước cụm cố định có thể dẫn đến lãng phí tài nguyên.
• Chia tỷ lệ chi tiết trên nhiều tác vụ trong quy trình làm việc – Vì mỗi tác vụ có các yêu cầu tài nguyên riêng, việc duy trì kích thước tài nguyên cố định có thể dẫn đến việc cung cấp dưới mức hoặc quá mức cho một số tác vụ nhất định trong cùng một quy trình làm việc. Theo truyền thống, kích thước của tác vụ lớn nhất sẽ xác định kích thước cụm cho quy trình làm việc đa tác vụ. Tuy nhiên, việc điều chỉnh linh hoạt các tài nguyên trên nhiều nhiệm vụ và bước trong quy trình làm việc sẽ mang lại kết quả triển khai hiệu quả hơn về mặt chi phí.
• Cải tiến ở cấp độ nền tảng – Các cải tiến ở các lớp trước chỉ có thể tối ưu hóa một công việc hoặc quy trình làm việc nhất định. Cải tiến nền tảng nhằm đạt được hiệu quả ở cấp công ty. Chúng tôi có thể đạt được điều này thông qua nhiều cách khác nhau, chẳng hạn như cập nhật hoặc nâng cấp cơ sở hạ tầng cốt lõi, giới thiệu các khung mới, phân bổ tài nguyên phù hợp cho từng hồ sơ công việc, cân bằng mức sử dụng dịch vụ, tối ưu hóa việc sử dụng Savings Plans và Spot Instances hoặc thực hiện các thay đổi toàn diện khác để tăng cường hiệu quả trên tất cả các nhiệm vụ và quy trình công việc.

Lớp 1–3: Giảm chi phí trước đó

Sau khi di chuyển từ cơ sở sang Đám mây AWS, chúng tôi chủ yếu tập trung nỗ lực tối ưu hóa chi phí vào ba lớp đầu tiên được hiển thị trong sơ đồ. Bằng cách chuyển đổi các quy trình Pig và Hive truyền thống tốn kém nhất của chúng tôi sang Spark và tối ưu hóa cấu hình Spark cho Amazon EMR, chúng tôi đã tiết kiệm được chi phí đáng kể.

Ví dụ: công việc truyền thống của Pig mất 10 giờ để hoàn thành và được xếp hạng trong số 10 công việc EMR đắt nhất. Khi xem xét nhật ký TEZ và số liệu cụm, chúng tôi phát hiện ra rằng cụm này đã được cung cấp quá mức cho khối lượng dữ liệu đang được xử lý và vẫn chưa được sử dụng đúng mức trong hầu hết thời gian chạy. Việc chuyển đổi từ Pig sang Spark hiệu quả hơn. Mặc dù không có sẵn công cụ tự động nào cho việc chuyển đổi nhưng các tối ưu hóa thủ công đã được thực hiện, bao gồm:

• Giảm việc ghi đĩa không cần thiết, tiết kiệm thời gian tuần tự hóa và giải tuần tự hóa (Lớp 1)
• Đã thay thế song song tác vụ Airflow bằng Spark, đơn giản hóa Airflow DAG (Lớp 1)
• Loại bỏ các phép biến đổi Spark dư thừa (Lớp 1)
• Đã nâng cấp từ Spark 2 lên 3, sử dụng Thực thi truy vấn thích ứng (Lớp 2)
• Đã giải quyết các liên kết lệch và tối ưu hóa các bảng kích thước nhỏ hơn (Lớp 3)

Kết quả là chi phí công việc giảm 95% và thời gian hoàn thành công việc giảm xuống còn 1 giờ. Tuy nhiên, cách tiếp cận này tốn nhiều công sức và không thể mở rộng cho nhiều công việc.

Lớp 4–6: Tìm và áp dụng giải pháp điện toán phù hợp

Vào cuối năm 2022, sau những thành tựu đáng kể trong việc tối ưu hóa ở các cấp độ trước đó, chúng tôi đã chuyển sự chú ý sang việc nâng cao các lớp còn lại.

Hiểu trạng thái xử lý hàng loạt của chúng tôi

Chúng tôi sử dụng Amazon MWAA để điều phối luồng công việc dữ liệu trên đám mây ở quy mô lớn. Luồng khí Apache là một công cụ nguồn mở được sử dụng để lập trình, lên lịch và giám sát các chuỗi quy trình và nhiệm vụ được gọi là Luồng công việc. Trong bài viết này, các điều khoản quy trình làm việc và việc làm được sử dụng thay thế cho nhau, đề cập đến Đồ thị không theo chu kỳ có hướng (DAG) bao gồm các nhiệm vụ do Amazon MWAA sắp xếp. Đối với mỗi quy trình công việc, chúng tôi có các nhiệm vụ tuần tự hoặc song song và thậm chí là sự kết hợp của cả hai trong DAG giữa create_emr và terminate_emr các tác vụ chạy trên cụm EMR tạm thời với công suất tính toán cố định trong suốt quá trình chạy quy trình công việc. Ngay cả sau khi tối ưu hóa một phần khối lượng công việc, chúng tôi vẫn còn nhiều quy trình làm việc chưa được tối ưu hóa và chưa được tận dụng tối đa do cung cấp quá mức tài nguyên điện toán dựa trên nhiệm vụ sử dụng nhiều tài nguyên nhất trong quy trình làm việc, như minh họa trong hình sau.

Điều này nêu bật tính không thực tế của việc phân bổ nguồn lực tĩnh và khiến chúng tôi nhận ra sự cần thiết của hệ thống phân bổ nguồn lực động (DRA). Trước khi đề xuất giải pháp, chúng tôi đã thu thập dữ liệu sâu rộng để hiểu kỹ về quy trình xử lý hàng loạt của mình. Phân tích thời gian của bước cụm, ngoại trừ thời gian cung cấp và thời gian nhàn rỗi, đã tiết lộ những hiểu biết quan trọng: phân phối lệch phải với hơn một nửa số quy trình công việc hoàn thành trong 20 phút hoặc ít hơn và chỉ 10% mất hơn 60 phút. Bản phân phối này đã hướng dẫn chúng tôi lựa chọn giải pháp điện toán cung cấp nhanh, giảm đáng kể thời gian chạy của quy trình làm việc. Sơ đồ sau minh họa thời gian của các bước (không bao gồm thời gian cung cấp và thời gian nhàn rỗi) của EMR trên các cụm tạm thời EC2 ở một trong các tài khoản xử lý hàng loạt của chúng tôi.

Hơn nữa, dựa trên sự phân bổ thời gian từng bước (không bao gồm thời gian cung cấp và thời gian nhàn rỗi) của quy trình công việc, chúng tôi đã phân loại quy trình làm việc của mình thành ba nhóm:

• Chạy nhanh lên – Kéo dài từ 20 phút trở xuống
• Chạy trung bình – Kéo dài từ 20–60 phút
• Chạy dài – Quá 60 phút, thường kéo dài vài giờ hoặc hơn

Một yếu tố khác mà chúng tôi cần xem xét là việc sử dụng rộng rãi các cụm tạm thời vì các lý do như bảo mật, tách biệt công việc và chi phí cũng như các cụm được xây dựng theo mục đích. Ngoài ra, có sự khác biệt đáng kể về nhu cầu nguồn lực giữa giờ cao điểm và thời gian sử dụng thấp.

Thay vì các cụm có kích thước cố định, chúng tôi có thể sử dụng quy mô được quản lý trên EMR trên EC2 để đạt được một số lợi ích về chi phí. Tuy nhiên, việc chuyển sang EMR Serverless dường như là một hướng đi mang tính chiến lược hơn cho nền tảng dữ liệu của chúng tôi. Ngoài các lợi ích tiềm năng về chi phí, EMR Serverless còn mang đến các lợi ích bổ sung như nâng cấp chỉ bằng một cú nhấp chuột lên phiên bản Amazon EMR mới nhất, trải nghiệm vận hành và gỡ lỗi đơn giản hóa cũng như tự động nâng cấp lên các thế hệ mới nhất khi triển khai. Các tính năng này đơn giản hóa chung quá trình vận hành nền tảng ở quy mô lớn hơn.

Đánh giá EMR Serverless: Một nghiên cứu điển hình tại GoDaddy

EMR Serverless là một tùy chọn serverless trong Amazon EMR giúp loại bỏ sự phức tạp trong việc định cấu hình, quản lý và thay đổi quy mô các cụm khi chạy các khung dữ liệu lớn như Apache Spark và Apache Hive. Với EMR Serverless, doanh nghiệp có thể tận hưởng nhiều lợi ích, bao gồm hiệu quả về chi phí, cung cấp nhanh hơn, đơn giản hóa trải nghiệm của nhà phát triển và khả năng phục hồi được cải thiện đối với các sự cố của Vùng sẵn sàng.

Nhận thấy tiềm năng của EMR Serverless, chúng tôi đã tiến hành nghiên cứu điểm chuẩn chuyên sâu bằng cách sử dụng quy trình sản xuất thực tế. Nghiên cứu nhằm đánh giá hiệu suất và hiệu quả của EMR Serverless đồng thời tạo ra kế hoạch áp dụng để triển khai trên quy mô lớn. Những phát hiện này rất đáng khích lệ, cho thấy EMR Serverless có thể xử lý khối lượng công việc của chúng tôi một cách hiệu quả.

phương pháp đo điểm chuẩn

Chúng tôi chia quy trình làm việc dữ liệu của mình thành ba loại dựa trên tổng thời gian của các bước (không bao gồm thời gian cung cấp và thời gian nhàn rỗi): chạy nhanh (0–20 phút), chạy trung bình (20–60 phút) và chạy dài (trên 60 phút). Chúng tôi đã phân tích tác động của loại triển khai EMR (Amazon EC2 so với EMR Serverless) trên hai chỉ số chính: hiệu quả chi phí và tổng tốc độ thời gian chạy, được dùng làm tiêu chí đánh giá tổng thể của chúng tôi. Mặc dù chúng tôi không chính thức đo lường mức độ dễ sử dụng và khả năng phục hồi nhưng những yếu tố này đã được xem xét trong suốt quá trình đánh giá.

Các bước cấp cao để đánh giá môi trường như sau:

1. Chuẩn bị dữ liệu và môi trường:
   1. Chọn ba đến năm công việc sản xuất ngẫu nhiên từ mỗi loại công việc.
   2. Thực hiện các điều chỉnh cần thiết để ngăn chặn sự can thiệp vào sản xuất.
2. Chạy thử nghiệm:
   1. Chạy tập lệnh trong vài ngày hoặc qua nhiều lần lặp để thu thập các điểm dữ liệu chính xác và nhất quán.
   2. Thực hiện kiểm thử bằng EMR trên EC2 và EMR Serverless.
3. Xác thực dữ liệu và chạy thử:
   1. Xác thực bộ dữ liệu đầu vào và đầu ra, phân vùng và số lượng hàng để đảm bảo xử lý dữ liệu giống hệt nhau.
4. Thu thập số liệu và phân tích kết quả:
   1. Thu thập các số liệu liên quan từ các bài kiểm tra.
   2. Phân tích kết quả để rút ra những hiểu biết sâu sắc và kết luận.

Kết quả điểm chuẩn

Kết quả điểm chuẩn của chúng tôi cho thấy những cải tiến đáng kể trên cả ba loại công việc về cả tốc độ thời gian chạy và hiệu quả chi phí. Những cải tiến rõ rệt nhất đối với các tác vụ nhanh, trực tiếp đến từ thời gian khởi động nhanh hơn. Ví dụ: quy trình làm việc dữ liệu dài 20 phút (bao gồm cả việc cung cấp và tắt cụm) chạy trên EMR trên cụm tạm thời có công suất điện toán cố định của EC2 sẽ kết thúc sau 10 phút trên EMR Serverless, mang lại thời gian chạy ngắn hơn với lợi ích về chi phí. Nhìn chung, việc chuyển sang EMR Serverless đã mang lại những cải tiến đáng kể về hiệu suất và giảm chi phí trên quy mô lớn trong các nhóm công việc, như trong hình sau.

Trước đây, chúng tôi dành nhiều thời gian hơn để điều chỉnh quy trình làm việc lâu dài của mình. Thật thú vị, chúng tôi đã phát hiện ra rằng các cấu hình Spark tùy chỉnh hiện có cho những công việc này không phải lúc nào cũng chuyển đổi tốt sang EMR Serverless. Trong trường hợp kết quả không đáng kể, cách tiếp cận phổ biến là loại bỏ các cấu hình Spark trước đó liên quan đến lõi thực thi. Bằng cách cho phép EMR Serverless tự động quản lý các cấu hình Spark này, chúng tôi thường nhận thấy kết quả được cải thiện. Biểu đồ sau đây cho thấy thời gian chạy trung bình và mức cải thiện chi phí trên mỗi công việc khi so sánh EMR Serverless với EMR trên EC2.

Bảng sau đây trình bày kết quả so sánh mẫu cho cùng một quy trình làm việc chạy trên các tùy chọn triển khai khác nhau của Amazon EMR (EMR trên EC2 và EMR Serverless).

AWS Graviton2 về đánh giá hiệu năng của EMR Serverless

Sau khi nhận thấy kết quả thuyết phục với EMR Serverless cho khối lượng công việc của mình, chúng tôi quyết định phân tích sâu hơn về hiệu suất của AWS Graviton2 (arm64) trong EMR Serverless. AWS đã có điểm chuẩn Khối lượng công việc Spark trên Graviton2 EMR Serverless sử dụng thang đo TPC-DS 3TB, cho thấy mức cải thiện tổng thể về giá-hiệu suất là 27%.

Để hiểu rõ hơn về lợi ích của việc tích hợp, chúng tôi đã thực hiện nghiên cứu của riêng mình bằng cách sử dụng khối lượng công việc sản xuất của GoDaddy theo lịch hàng ngày và quan sát thấy mức tăng hiệu suất giá ấn tượng 23.8% trên nhiều công việc khi sử dụng Graviton2. Để biết thêm chi tiết về nghiên cứu này, xem Điểm chuẩn của GoDaddy mang lại hiệu suất giá tốt hơn tới 24% cho khối lượng công việc Spark của họ với AWS Graviton2 trên Amazon EMR Serverless.

Chiến lược áp dụng cho EMR Serverless

Chúng tôi đã triển khai một cách chiến lược việc triển khai EMR Serverless theo từng giai đoạn thông qua các vòng triển khai, cho phép tích hợp hệ thống. Cách tiếp cận dần dần này cho phép chúng tôi xác thực các cải tiến và tạm dừng việc tiếp tục áp dụng EMR Serverless nếu cần. Nó vừa đóng vai trò như một mạng lưới an toàn để phát hiện sớm các vấn đề vừa là phương tiện để tinh chỉnh cơ sở hạ tầng của chúng tôi. Quá trình này đã giảm thiểu tác động của sự thay đổi thông qua các hoạt động trơn tru, đồng thời xây dựng kiến ​​thức chuyên môn cho nhóm Kỹ thuật dữ liệu và DevOps của chúng tôi. Ngoài ra, nó còn thúc đẩy các vòng phản hồi chặt chẽ, cho phép điều chỉnh kịp thời và đảm bảo tích hợp EMR Serverless hiệu quả.

Chúng tôi chia quy trình làm việc của mình thành ba nhóm áp dụng chính, như minh họa trong hình ảnh sau:

• Chim hoàng yến – Nhóm này hỗ trợ phát hiện và giải quyết sớm mọi vấn đề tiềm ẩn trong giai đoạn triển khai.
• Những người chấp nhận sớm – Đây là loạt quy trình công việc thứ hai áp dụng giải pháp điện toán mới sau khi các vấn đề ban đầu được nhóm canaries xác định và khắc phục.
• Vòng triển khai rộng – Nhóm vòng lớn nhất, nhóm này đại diện cho việc triển khai giải pháp trên quy mô rộng. Chúng được triển khai sau khi thử nghiệm và triển khai thành công ở hai nhóm trước.

Chúng tôi tiếp tục chia nhỏ các quy trình công việc này thành các vòng triển khai chi tiết để áp dụng EMR Serverless, như minh họa trong bảng sau.

Tóm tắt kết quả áp dụng sản xuất

Kết quả đo điểm chuẩn và áp dụng canary đáng khích lệ đã tạo ra sự quan tâm đáng kể đến việc áp dụng EMR Serverless rộng rãi hơn tại GoDaddy. Đến nay, quá trình triển khai EMR Serverless vẫn đang được tiến hành. Cho đến nay, nó đã giảm chi phí tới 62.5% và tăng tốc độ hoàn thành tổng quy trình làm việc theo lô lên 50.4%.

Dựa trên các tiêu chuẩn sơ bộ, nhóm của chúng tôi mong đợi những lợi ích đáng kể cho công việc nhanh chóng. Thật ngạc nhiên, việc triển khai sản xuất thực tế đã vượt qua dự đoán, nhanh hơn trung bình 64.4% so với dự kiến ​​là 42% và rẻ hơn 71.8% so với dự đoán là 40%.

Đáng chú ý, các công việc chạy trong thời gian dài cũng có sự cải thiện đáng kể về hiệu suất nhờ việc cung cấp nhanh chóng EMR Serverless và khả năng mở rộng quy mô linh hoạt nhờ tính năng phân bổ tài nguyên động. Chúng tôi đã quan sát thấy sự song song hóa đáng kể trong các phân đoạn tài nguyên cao, dẫn đến tổng thời gian chạy nhanh hơn 40.5% so với các phương pháp truyền thống. Biểu đồ sau đây minh họa mức tăng trưởng trung bình cho mỗi loại công việc.

Ngoài ra, chúng tôi quan sát thấy mức độ phân tán cao nhất để cải thiện tốc độ trong danh mục công việc dài hạn, như thể hiện trong biểu đồ hình hộp và râu sau đây.

Quy trình làm việc mẫu được áp dụng EMR Serverless

Đối với một quy trình làm việc lớn được di chuyển sang EMR Serverless, việc so sánh mức trung bình 3 tuần trước và sau di chuyển cho thấy mức tiết kiệm chi phí ấn tượng—giảm 75.30% dựa trên giá bán lẻ và cải thiện 10% trong tổng thời gian chạy, nâng cao hiệu quả hoạt động. Biểu đồ sau minh họa xu hướng chi phí.

Mặc dù các công việc được thực hiện nhanh chóng giúp giảm chi phí trên mỗi đô la ở mức tối thiểu, nhưng chúng mang lại tỷ lệ tiết kiệm chi phí đáng kể nhất. Với hàng nghìn quy trình công việc này chạy hàng ngày, khoản tiết kiệm được tích lũy là rất đáng kể. Biểu đồ sau đây cho thấy xu hướng chi phí cho một khối lượng công việc nhỏ được di chuyển từ EMR trên EC2 sang EMR Serverless. So sánh mức trung bình trong 3 tuần trước và sau di chuyển cho thấy mức tiết kiệm chi phí đáng kể là 92.43% so với giá bán lẻ theo yêu cầu, cùng với mức tăng tốc 80.6% trong tổng thời gian chạy.

Lớp 7: Cải tiến trên toàn nền tảng

Chúng tôi mong muốn cách mạng hóa hoạt động điện toán tại GoDaddy, cung cấp các giải pháp đơn giản nhưng mạnh mẽ cho tất cả người dùng bằng Nền tảng điện toán thông minh của chúng tôi. Với các giải pháp điện toán AWS như EMR Serverless và EMR trên EC2, nó đã cung cấp các khối lượng công việc xử lý dữ liệu và học máy (ML) được tối ưu hóa. Nhà môi giới việc làm được hỗ trợ bởi ML xác định một cách thông minh thời điểm và cách thức thực hiện công việc dựa trên các thông số khác nhau, trong khi vẫn cho phép người dùng thành thạo tùy chỉnh. Ngoài ra, trình quản lý tài nguyên điện toán được hỗ trợ bởi ML sẽ cung cấp trước các tài nguyên dựa trên tải và dữ liệu lịch sử, cung cấp khả năng cung cấp nhanh chóng, hiệu quả với chi phí tối ưu. Điện toán thông minh trao quyền cho người dùng bằng khả năng tối ưu hóa ngay lập tức, phục vụ nhiều đối tượng khác nhau mà không ảnh hưởng đến người dùng thành thạo.

Sơ đồ sau đây minh họa cấp cao về kiến ​​trúc điện toán thông minh.

Thông tin chi tiết và các phương pháp hay nhất được đề xuất

Phần sau đây thảo luận về những hiểu biết sâu sắc mà chúng tôi đã thu thập và các phương pháp hay nhất được đề xuất mà chúng tôi đã phát triển trong giai đoạn áp dụng sơ bộ và rộng hơn.

Chuẩn bị cơ sở hạ tầng

Mặc dù EMR Serverless là một phương pháp triển khai trong EMR nhưng nó yêu cầu một số sự chuẩn bị về cơ sở hạ tầng để tối ưu hóa tiềm năng của nó. Hãy xem xét các yêu cầu sau đây và hướng dẫn thực tế khi thực hiện:

• Sử dụng các mạng con lớn trên nhiều Vùng sẵn sàng – Khi chạy khối lượng công việc EMR Serverless trong VPC của bạn, hãy đảm bảo các mạng con trải rộng trên nhiều Vùng sẵn sàng và không bị ràng buộc bởi địa chỉ IP. tham khảo Định cấu hình quyền truy cập VPC và Thực tiễn tốt nhất để lập kế hoạch mạng con để biết thêm chi tiết.
• Sửa đổi hạn ngạch vCPU đồng thời tối đa – Đối với các yêu cầu tính toán mở rộng, bạn nên tăng số vCPU đồng thời tối đa cho mỗi tài khoản hạn ngạch dịch vụ.
• Khả năng tương thích của phiên bản Amazon MWAA – Khi áp dụng EMR Serverless, hệ sinh thái Amazon MWAA phi tập trung của GoDaddy để điều phối đường ống dữ liệu đã tạo ra các vấn đề về khả năng tương thích từ các phiên bản Nhà cung cấp AWS khác nhau. Trực tiếp nâng cấp Amazon MWAA hiệu quả hơn việc cập nhật nhiều DAG. Chúng tôi đã hỗ trợ việc áp dụng bằng cách tự nâng cấp các phiên bản Amazon MWAA, ghi lại các vấn đề cũng như chia sẻ các phát hiện cũng như ước tính nỗ lực để lập kế hoạch nâng cấp chính xác.
• Nhà điều hành EMR của GoDaddy – Để hợp lý hóa việc di chuyển nhiều DAG Airflow từ EMR trên EC2 sang EMR Serverless, chúng tôi đã phát triển các toán tử tùy chỉnh điều chỉnh các giao diện hiện có. Điều này cho phép chuyển tiếp liền mạch trong khi vẫn giữ được các tùy chọn điều chỉnh quen thuộc. Các kỹ sư dữ liệu có thể dễ dàng di chuyển các quy trình bằng cách nhập tìm-thay thế đơn giản và sử dụng ngay EMR Serverless.

Giảm thiểu hành vi không mong muốn

Sau đây là những hành vi không mong muốn mà chúng tôi gặp phải và những gì chúng tôi đã làm để giảm thiểu chúng:

• Spark DRA mở rộng quy mô tích cực – Đối với một số công việc (8.33% điểm chuẩn ban đầu, 13.6% sản lượng), chi phí đã tăng lên sau khi chuyển sang EMR Serverless. Điều này là do Spark DRA phân công công nhân mới quá mức trong thời gian ngắn, ưu tiên hiệu suất hơn chi phí. Để chống lại điều này, chúng tôi đặt ngưỡng thực thi tối đa bằng cách điều chỉnh spark.dynamicAllocation.maxExecutor, hạn chế một cách hiệu quả hành vi xâm phạm quy mô của EMR Serverless. Khi di chuyển từ EMR trên EC2, chúng tôi khuyên bạn nên quan sát số lượng lõi tối đa trong Giao diện người dùng lịch sử Spark để sao chép các giới hạn điện toán tương tự trong EMR Serverless, chẳng hạn như --conf spark.executor.cores và --conf spark.dynamicAllocation.maxExecutors.
• Quản lý dung lượng ổ đĩa cho các công việc quy mô lớn – Khi chuyển đổi các công việc xử lý khối lượng dữ liệu lớn với sự xáo trộn đáng kể và yêu cầu ổ đĩa quan trọng sang EMR Serverless, chúng tôi khuyên bạn nên định cấu hình spark.emr-serverless.executor.disk bằng cách tham khảo các số liệu công việc Spark hiện có. Hơn nữa, các cấu hình như spark.executor.cores kết hợp với spark.emr-serverless.executor.disk và spark.dynamicAllocation.maxExecutors cho phép kiểm soát kích thước nhân viên cơ bản và tổng dung lượng lưu trữ kèm theo khi thuận lợi. Ví dụ: một công việc nặng về xáo trộn với mức sử dụng đĩa tương đối thấp có thể được hưởng lợi từ việc sử dụng một trình chạy lớn hơn để tăng khả năng tìm nạp ngẫu nhiên cục bộ.

Kết luận

Như đã thảo luận trong bài đăng này, trải nghiệm của chúng tôi khi áp dụng EMR Serverless trên arm64 cực kỳ tích cực. Những kết quả ấn tượng mà chúng tôi đã đạt được, bao gồm giảm 60% chi phí, xử lý khối lượng công việc Spark hàng loạt nhanh hơn 50% và cải thiện đáng kinh ngạc gấp 2 lần về tốc độ phát triển và thử nghiệm, đã nói lên nhiều điều về tiềm năng của công nghệ này. Hơn nữa, kết quả hiện tại của chúng tôi cho thấy rằng bằng cách áp dụng rộng rãi Graviton60 trên EMR Serverless, chúng tôi có thể giảm lượng khí thải carbon tới XNUMX% khi xử lý hàng loạt.

Tuy nhiên, điều quan trọng là phải hiểu rằng những kết quả này không phải là một kịch bản chung cho tất cả. Những cải tiến mà bạn có thể mong đợi tùy thuộc vào các yếu tố bao gồm nhưng không giới hạn ở tính chất cụ thể của quy trình công việc, cấu hình cụm, mức độ sử dụng tài nguyên và sự biến động trong khả năng tính toán. Do đó, chúng tôi đặc biệt ủng hộ chiến lược triển khai dựa trên vòng, dựa trên dữ liệu khi xem xét việc tích hợp EMR Serverless, điều này có thể giúp tối ưu hóa lợi ích của nó một cách tối đa.

Đặc biệt cảm ơn Mukul sharma và Boris Berlin vì những đóng góp của họ cho việc đo điểm chuẩn. Cảm ơn rất nhiều Travis Muhlestein (CDO), Abhijit Kundu (VP Anh), Vincent Yung (Sr. Giám đốc Eng.), và Wai Kin Lau (Sr. Giám đốc Data Eng.) vì sự hỗ trợ liên tục của họ.

Về các tác giả

Brandon Abear là Kỹ sư dữ liệu chính trong tổ chức Dữ liệu & Phân tích (DnA) tại GoDaddy. Anh ấy thích tất cả mọi thứ về dữ liệu lớn. Khi rảnh rỗi, anh thích đi du lịch, xem phim và chơi các trò chơi nhịp điệu.

Dinesh Sharma là Kỹ sư dữ liệu chính trong tổ chức Dữ liệu & Phân tích (DnA) tại GoDaddy. Anh ấy đam mê trải nghiệm người dùng và năng suất của nhà phát triển, luôn tìm cách tối ưu hóa quy trình kỹ thuật và tiết kiệm chi phí. Trong thời gian rảnh rỗi, anh ấy thích đọc sách và là một fan cuồng nhiệt của truyện tranh.

John Bush là Kỹ sư phần mềm chính trong tổ chức Dữ liệu & Phân tích (DnA) tại GoDaddy. Anh ấy đam mê việc giúp các tổ chức quản lý dữ liệu dễ dàng hơn và sử dụng dữ liệu đó để thúc đẩy hoạt động kinh doanh của họ phát triển. Trong thời gian rảnh rỗi, anh ấy thích đi bộ đường dài, cắm trại và đạp xe điện.

Ozcan Ilikhan là Giám đốc Kỹ thuật về Nền tảng Dữ liệu và Máy học tại GoDaddy. Ông có hơn hai thập kỷ kinh nghiệm lãnh đạo đa ngành, từ khởi nghiệp đến doanh nghiệp toàn cầu. Anh có niềm đam mê tận dụng dữ liệu và AI trong việc tạo ra các giải pháp làm hài lòng khách hàng, giúp họ đạt được nhiều thành tựu hơn và nâng cao hiệu quả hoạt động. Ngoài cuộc sống nghề nghiệp của mình, anh thích đọc sách, đi bộ đường dài, làm vườn, tình nguyện và bắt tay vào các dự án DIY.

Varshhan là Kiến trúc sư giải pháp AWS, chuyên về dữ liệu lớn và phân tích. Ông có hơn 8 năm kinh nghiệm làm việc trong lĩnh vực dữ liệu lớn và khoa học dữ liệu. Anh ấy rất nhiệt tình giúp đỡ khách hàng áp dụng các phương pháp hay nhất và khám phá thông tin chuyên sâu từ dữ liệu của họ.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
• PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
• PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
• nguồn: https://aws.amazon.com/blogs/big-data/how-the-godaddy-data-platform-achieved-over-60-cost-reduction-and-50-performance-boost-by-adopting-amazon-emr-serverless/