Đây là bài đăng của Diego Benavides và Luis Bendezú, Kiến trúc sư dữ liệu cao cấp, Hướng kiến ​​trúc dữ liệu tại Belcorp.

Belcorp là một trong những công ty hàng tiêu dùng đóng gói (CPG) cung cấp các sản phẩm mỹ phẩm trong khu vực trong hơn 50 năm, được phân bổ cho khoảng 13 quốc gia ở Bắc, Trung và Nam Mỹ (AMER). Ra đời tại Peru và có nhà máy sản xuất sản phẩm riêng tại Colombia, Belcorp luôn dẫn đầu và điều chỉnh mô hình kinh doanh theo nhu cầu của khách hàng, đồng thời củng cố chiến lược của mình theo xu hướng công nghệ, mang đến trải nghiệm khách hàng tốt hơn mỗi lần. Tập trung vào vấn đề này, Belcorp bắt đầu thực hiện chiến lược dữ liệu của riêng mình, khuyến khích việc sử dụng dữ liệu để ra quyết định. Dựa trên chiến lược này, nhóm kiến ​​trúc dữ liệu Belcorp đã thiết kế và triển khai một hệ sinh thái dữ liệu cho phép các nhóm kinh doanh và phân tích sử dụng dữ liệu chức năng mà họ sử dụng để tạo ra các giả thuyết và thông tin chi tiết được cụ thể hóa trong các chiến lược tiếp thị tốt hơn hoặc các sản phẩm mới. Bài đăng này nhằm mục đích trình bày chi tiết một loạt các cải tiến liên tục được thực hiện trong năm 2021 để giảm số lượng sự cố nền tảng được báo cáo vào cuối năm 2020, tối ưu hóa SLA theo yêu cầu của doanh nghiệp và tiết kiệm chi phí hơn khi sử dụng Amazon EMR, dẫn đến tiết kiệm đến 30% cho công ty.

Để đi trước xu hướng, các công ty mạnh hơn đã xây dựng chiến lược dữ liệu cho phép họ cải thiện các chiến lược kinh doanh chính hoặc thậm chí tạo các chiến lược mới, sử dụng dữ liệu làm động lực chính. Là một trong những công ty sản xuất hàng tiêu dùng đóng gói (CPG) chính trong khu vực, Belcorp không phải là một ngoại lệ — trong những năm gần đây, chúng tôi đã nỗ lực triển khai việc ra quyết định dựa trên dữ liệu.

Chúng tôi biết rằng tất cả chiến lược dữ liệu tốt đều phù hợp với mục tiêu kinh doanh và dựa trên các trường hợp sử dụng kinh doanh chính. Hiện tại, tất cả các nỗ lực của nhóm chúng tôi đều tập trung vào người tiêu dùng cuối cùng và hầu như tất cả các sáng kiến ​​kinh doanh đều liên quan đến siêu cá nhân hóa, định giá và tương tác với khách hàng.

Để hỗ trợ các sáng kiến ​​này, bộ phận kiến ​​trúc dữ liệu cung cấp các dịch vụ dữ liệu như tích hợp dữ liệu, chỉ một nguồn trung thực, quản lý dữ liệu và khung chất lượng dữ liệu, tính sẵn có của dữ liệu, khả năng truy cập dữ liệu và thời gian tối ưu hóa để đưa ra thị trường, theo các yêu cầu kinh doanh như các những công ty lớn. Để cung cấp các khả năng tối thiểu để hỗ trợ tất cả các dịch vụ này, chúng tôi cần một hệ sinh thái dữ liệu có thể mở rộng, linh hoạt và tiết kiệm chi phí. Belcorp đã bắt đầu cuộc phiêu lưu này vài năm trước bằng cách sử dụng các dịch vụ AWS như Đám mây điện toán đàn hồi Amazon (Amazon EC2), AWS Lambda, Cổng xa AWS, Amazon EMR, Máy phát điện Amazonvà Amazon RedShift, hiện đang cung cấp dữ liệu cho các giải pháp phân tích chính của chúng tôi.

Khi chúng tôi đang phát triển, chúng tôi phải liên tục cải thiện khung xử lý và thiết kế kiến ​​trúc của mình liên quan đến khối lượng dữ liệu và các yêu cầu giải pháp dữ liệu phức tạp hơn. Chúng tôi cũng phải áp dụng các khuôn khổ giám sát và chất lượng để đảm bảo tính toàn vẹn của dữ liệu, chất lượng dữ liệu và các thỏa thuận mức dịch vụ (SLA). Như bạn có thể mong đợi, đây không phải là một nhiệm vụ dễ dàng và cần có chiến lược riêng. Vào đầu năm 2021, do sự cố nghiêm trọng mà chúng tôi đang phát hiện, sự ổn định hoạt động bị ảnh hưởng, ảnh hưởng trực tiếp đến kết quả kinh doanh. Việc thanh toán cũng bị ảnh hưởng do có thêm nhiều khối lượng công việc phức tạp mới, khiến chi phí nền tảng tăng bất ngờ. Đáp lại, chúng tôi quyết định tập trung vào ba thách thức:

• Hoạt động ổn định
• Hiệu quả chi phí
• Thỏa thuận cấp độ dịch vụ

Bài đăng này trình bày chi tiết một số điểm hành động mà chúng tôi đã thực hiện trong năm 2021 trên khung xử lý dữ liệu của Belcorp dựa trên Amazon EMR. Chúng tôi cũng thảo luận về cách những hành động này đã giúp chúng tôi đối mặt với những thách thức đã đề cập trước đó, đồng thời tiết kiệm kinh tế cho Belcorp, vốn là đóng góp chính của nhóm kiến ​​trúc dữ liệu cho công ty.

Tổng quan về giải pháp

Hệ sinh thái dữ liệu của Belcorp được bao gồm bởi bảy trụ cột năng lực chính (như thể hiện trong sơ đồ sau) xác định thiết kế kiến ​​trúc của chúng tôi và cung cấp cho chúng tôi ít nhiều các tùy chọn linh hoạt về công nghệ. Nền tảng dữ liệu của chúng tôi có thể được phân loại là một phần của thế hệ thứ hai của nền tảng dữ liệu, như đã được Zhamak Dehghani đề cập trong Cách di chuyển ngoài hồ dữ liệu nguyên khối sang lưới dữ liệu phân tán. Trên thực tế, nó có tất cả các hạn chế và hạn chế của cách tiếp cận Lakehouse như đã đề cập trong bài báo Lakehouse: Nền tảng mở thế hệ mới hợp nhất giữa kho dữ liệu và phân tích nâng cao .

Nền tảng dữ liệu của Belcorp hỗ trợ hai trường hợp sử dụng chính. Một mặt, nó cung cấp dữ liệu được sử dụng bằng cách sử dụng các công cụ trực quan, khuyến khích tự phục vụ. Mặt khác, nó cung cấp dữ liệu chức năng cho người dùng cuối, như các nhà khoa học dữ liệu hoặc nhà phân tích dữ liệu, thông qua các kho dữ liệu phân tán và lưu trữ đối tượng phù hợp hơn với thực tiễn phân tích nâng cao.

Thiết kế tham chiếu sau giải thích hai lớp chính chịu trách nhiệm cung cấp dữ liệu chức năng cho các trường hợp sử dụng này. Lớp xử lý dữ liệu bao gồm hai lớp con. Đầu tiên là Trình tích hợp hồ dữ liệu của Belcorp, là một giải pháp Python nội bộ, được tích hợp sẵn với một tập hợp các dịch vụ API REST chịu trách nhiệm tổ chức tất cả các khối lượng công việc dữ liệu và các giai đoạn dữ liệu bên trong các kho lưu trữ phân tích. Nó cũng hoạt động như một điểm kiểm soát để phân phối tài nguyên được phân bổ cho mỗi công việc Amazon EMR Spark. Lớp con xử lý chủ yếu bao gồm cụm EMR, chịu trách nhiệm điều phối, theo dõi và duy trì tất cả các công việc Spark được phát triển bằng khung Scala.

Đối với lớp kho lưu trữ liên tục, chúng tôi sử dụng Dịch vụ lưu trữ đơn giản của Amazon Lưu trữ đối tượng (Amazon S3) như một kho lưu trữ dữ liệu cho khối lượng công việc phân tích, nơi chúng tôi đã thiết kế một tập hợp các giai đoạn dữ liệu có mục đích hoạt động và chức năng dựa trên thiết kế kiến ​​trúc tham chiếu. Thảo luận sâu hơn về thiết kế kho lưu trữ không thuộc phạm vi của bài đăng này, nhưng chúng ta phải lưu ý rằng nó bao gồm tất cả các thách thức chung liên quan đến tính khả dụng của dữ liệu, khả năng truy cập dữ liệu, tính nhất quán của dữ liệu và chất lượng dữ liệu. Ngoài ra, nó đạt được tất cả các nhu cầu của Belcorp theo yêu cầu của mô hình kinh doanh của nó, bất chấp tất cả các hạn chế và hạn chế mà chúng tôi thừa hưởng bởi thiết kế đã đề cập trước đó.

Bây giờ chúng ta có thể chuyển sự chú ý của mình sang mục đích chính của bài đăng này.

Như chúng tôi đã đề cập, chúng tôi đã gặp phải các sự cố nghiêm trọng (một số sự cố đã tồn tại trước đó) và sự gia tăng chi phí bất ngờ vào đầu năm 2021, điều này thúc đẩy chúng tôi hành động. Bảng sau liệt kê một số vấn đề chính thu hút sự chú ý của chúng tôi.

Để đối mặt với những vấn đề này, chúng tôi quyết định thay đổi chiến lược và bắt đầu phân tích từng vấn đề để xác định nguyên nhân. Chúng tôi đã xác định hai dòng hành động dựa trên ba thách thức mà các nhà lãnh đạo muốn chúng tôi thực hiện. Hình sau đây tóm tắt những dòng và thách thức này.

Dòng hành động kiến ​​trúc hồ dữ liệu đề cập đến tất cả các lỗ hổng kiến ​​trúc và các tính năng không dùng nữa mà chúng tôi đã xác định là một phần của các vấn đề chính đang tạo ra sự cố. Dòng hành động về các phương pháp hay nhất về phát triển Spark có liên quan đến giải pháp dữ liệu Spark được phát triển đã gây ra sự không ổn định do các phương pháp sai trong vòng đời phát triển. Tập trung vào các dòng hành động này, các nhà lãnh đạo của chúng tôi đã xác định ba thách thức để giảm số lượng sự cố và đảm bảo chất lượng dịch vụ mà chúng tôi cung cấp: ổn định hoạt động, hiệu quả chi phí và SLA.

Dựa trên những thách thức này, chúng tôi đã xác định ba KPI để đo lường sự thành công của dự án. Sự cố Jira cho phép chúng tôi xác nhận rằng những thay đổi của chúng tôi đang có tác động tích cực; thanh toán mỗi tuần cho các nhà lãnh đạo thấy rằng một phần của những thay đổi mà chúng tôi áp dụng sẽ dần dần tối ưu hóa chi phí; và thời gian chạy cung cấp cho người dùng doanh nghiệp thời gian tốt hơn để tiếp thị.

Tiếp theo, chúng tôi xác định các bước tiếp theo và cách đo lường tiến độ. Dựa trên khung giám sát của mình, chúng tôi xác định rằng hầu hết tất cả các sự cố phát sinh đều liên quan đến việc xử lý dữ liệu và các lớp kho lưu trữ liên tục. Sau đó, chúng tôi phải quyết định làm thế nào để giải quyết chúng. Chúng tôi có thể thực hiện các bản sửa lỗi phản ứng để đạt được sự ổn định trong hoạt động và không ảnh hưởng đến hoạt động kinh doanh hoặc chúng tôi có thể thay đổi cách làm việc thông thường, phân tích từng vấn đề và đưa ra giải pháp cuối cùng để tối ưu hóa khuôn khổ của chúng tôi. Như bạn có thể đoán, chúng tôi đã quyết định thay đổi cách làm việc của mình.

Chúng tôi đã thực hiện phân tích sơ bộ để xác định những tác động và thách thức chính. Sau đó, chúng tôi đề xuất các hành động và cải tiến sau dựa trên các dòng hành động của chúng tôi:

• Kiến trúc hồ dữ liệu - Chúng tôi đã thiết kế lại cụm EMR; chúng tôi hiện đang sử dụng các nút lõi và nút tác vụ
• Các phương pháp hay nhất về phát triển Spark - Chúng tôi đã tối ưu hóa các thông số Spark (bộ nhớ RAM, lõi, CPU và số thực thi)

Trong phần tiếp theo, chúng tôi giải thích chi tiết các hành động và cải tiến được đề xuất để đạt được mục tiêu của chúng tôi.

Hành động và cải tiến

Như chúng tôi đã đề cập trong phần trước, phân tích do nhóm kiến ​​trúc thực hiện đã dẫn đến một danh sách các hành động và cải tiến sẽ giúp chúng tôi đối mặt với ba thách thức: sự ổn định trong hoạt động, hệ sinh thái dữ liệu tiết kiệm chi phí và SLA.

Trước khi đi xa hơn, đây là thời điểm tốt để cung cấp thêm chi tiết về khung xử lý dữ liệu Belcorp. Chúng tôi đã xây dựng nó dựa trên Apache Spark bằng ngôn ngữ lập trình Scala. Khung xử lý dữ liệu của chúng tôi là một tập hợp các tạo tác Scala có thể mở rộng, có thể tham số hóa và tái sử dụng, cung cấp cho các nhóm phát triển một công cụ mạnh mẽ để triển khai các đường ống dữ liệu phức tạp, đạt được các yêu cầu kinh doanh phức tạp nhất bằng cách sử dụng công nghệ Apache Spark. Thông qua khuôn khổ Belcorp DevOps, chúng tôi triển khai từng tạo tác cho một số môi trường phi sản xuất. Sau đó, chúng tôi thúc đẩy sản xuất, trong đó cụm EMR khởi chạy tất cả các quy trình bằng cách sử dụng các tạo tác Scala tham chiếu đến từng lĩnh vực khái niệm bên trong nền tảng phân tích. Phần này của chu trình cung cấp cho các đội một số mức độ linh hoạt và nhanh nhẹn. Tuy nhiên, chúng tôi đã quên mất chất lượng của phần mềm chúng tôi đang phát triển bằng công nghệ Apache Spark.

Trong phần này, chúng tôi đi sâu vào các hành động và cải tiến mà chúng tôi đã áp dụng để tối ưu hóa khung xử lý dữ liệu Belcorp và cải thiện kiến ​​trúc.

Thiết kế lại cụm EMR

Thiết kế và triển khai hồ dữ liệu Belcorp hiện tại không phải là phiên bản đầu tiên. Chúng tôi hiện đang ở phiên bản 2.0 và từ khi bắt đầu triển khai đầu tiên cho đến nay, chúng tôi đã thử các thiết kế cụm EMR khác nhau để triển khai lớp xử lý dữ liệu. Ban đầu, chúng tôi sử dụng một cụm cố định với bốn nút (như thể hiện trong hình sau), nhưng khi khả năng mở rộng quy mô tự động được khởi chạy và khối lượng công việc dữ liệu của Belcorp tăng lên, chúng tôi quyết định chuyển nó đến đó để tối ưu hóa việc sử dụng tài nguyên và chi phí. Tuy nhiên, một cụm EMR được chia tỷ lệ tự động cũng có các tùy chọn khác nhau. Bạn có thể chọn giữa các nút lõi và nút nhiệm vụ với số lượng tối thiểu và tối đa của mỗi nút. Ngoài ra, bạn có thể chọn Phiên bản theo yêu cầu hoặc Phiên bản giao ngay. Bạn cũng có thể triển khai chiến lược phân bổ được tối ưu hóa bằng cách sử dụng nhóm phiên bản EMR để giảm xác suất mất Phiên bản Spot. Để biết thêm thông tin về các chiến lược phân bổ tài nguyên EMR của Amazon, hãy xem Cải tiến tia lửa cho độ đàn hồi và khả năng phục hồi trên Amazon EMR và Tối ưu hóa Amazon EMR để có khả năng phục hồi và chi phí với Phiên bản Spot được tối ưu hóa dung lượng.

Chúng tôi đã thử nghiệm tất cả các khả năng này, nhưng chúng tôi phát hiện ra một số vấn đề.

Đầu tiên, mặc dù AWS cung cấp nhiều khả năng và chức năng xung quanh Amazon EMR, nhưng nếu bạn không có một số kiến ​​thức về công nghệ mà bạn muốn sử dụng, bạn có thể gặp phải nhiều vấn đề khi các trường hợp sử dụng phát sinh. Như chúng tôi đã đề cập, chúng tôi quyết định sử dụng công cụ xử lý dữ liệu Apache Spark thông qua Amazon EMR như một phần của hệ sinh thái dữ liệu Belcorp, nhưng chúng tôi phải đối mặt với nhiều vấn đề. Bất cứ khi nào một sự cố xuất hiện, nó sẽ thúc đẩy nhóm kiến ​​trúc sư dữ liệu phụ trách sửa chữa nó, như một phần của nhiệm vụ vận hành và hỗ trợ. Hầu hết tất cả các bản sửa lỗi phản ứng này đều liên quan đến việc thay đổi cấu hình Amazon EMR để thử các giải pháp thay thế khác nhau nhằm giải quyết hiệu quả những sự cố này.

Chúng tôi phát hiện ra rằng hầu hết tất cả các sự cố đều liên quan đến phân bổ tài nguyên, vì vậy chúng tôi đã thử nghiệm nhiều tùy chọn cấu hình như loại phiên bản, tăng số lượng nút, quy tắc tùy chỉnh để tự động mở rộng quy mô và chiến lược nhóm. Tùy chọn cuối cùng này được sử dụng để giảm tổn thất nút. Vào cuối năm 2020, chúng tôi đã xác nhận rằng một cụm EMR với tính năng tự động mở rộng quy mô được bật với công suất tối thiểu là ba nút lõi Theo yêu cầu 24/7 và khả năng mở rộng quy mô lên đến 25 nút lõi Theo yêu cầu đã cung cấp cho chúng tôi khả năng xử lý dữ liệu ổn định nền tảng. Vào đầu năm 2021, các công việc Spark phức tạp hơn đã được triển khai như một phần của quy trình xử lý dữ liệu bên trong cụm EMR, gây ra sự mất ổn định hoạt động một lần nữa. Ngoài ra, việc thanh toán đã tăng lên một cách bất ngờ, điều này đã cảnh báo các nhà lãnh đạo có nhóm cần thiết kế lại cụm EMR để duy trì sự ổn định hoạt động lành mạnh và tối ưu hóa chi phí.

Chúng tôi sớm nhận ra rằng có thể giảm tới 40% thanh toán hiện tại bằng cách sử dụng Phiên bản Spot, thay vì giữ tất cả các nút cốt lõi ở mức tiêu thụ Theo yêu cầu. Một tối ưu hóa cơ sở hạ tầng khác mà chúng tôi muốn áp dụng là thay thế một số nút lõi bằng các nút tác vụ, vì hầu như tất cả khối lượng công việc dữ liệu Belcorp đều sử dụng nhiều bộ nhớ và sử dụng Amazon S3 để đọc dữ liệu nguồn và ghi tập dữ liệu kết quả. Câu hỏi đặt ra ở đây là làm thế nào để làm điều đó mà không làm mất đi những lợi ích của thiết kế hiện tại. Để trả lời câu hỏi này, chúng tôi đã có sự hướng dẫn của Nhóm tài khoản AWS và AWS Analytics và Chuyên gia dữ liệu lớn SA của chúng tôi, để làm rõ các câu hỏi về vấn đề sau:

• Triển khai Apache Spark trong Amazon EMR
• Các phương pháp hay nhất về nút tác vụ và cốt lõi cho môi trường sản xuất
• Hành vi Spot Instance trong Amazon EMR

Chúng tôi chắc chắn khuyên bạn nên giải quyết ba điểm chính này trước khi áp dụng bất kỳ thay đổi nào vì theo kinh nghiệm trước đây của chúng tôi, việc thực hiện sửa đổi trong bóng tối có thể dẫn đến việc triển khai Amazon EMR kém hiệu quả và tốn kém. Với ý nghĩ đó, chúng tôi đã thiết kế lại cụm EMR để sử dụng Quy mô được quản lý EMR, tự động thay đổi kích thước cụm của bạn để có hiệu suất tốt nhất với chi phí thấp nhất có thể. Chúng tôi đã xác định tối đa 28 đơn vị dung lượng với ba nút lõi Theo yêu cầu luôn bật (24/7) để hỗ trợ khối lượng công việc dữ liệu trong ngày. Sau đó, chúng tôi đặt giới hạn mở rộng tự động gồm sáu lõi Theo yêu cầu để cung cấp khả năng HDFS tối thiểu để hỗ trợ 22 nút tác vụ còn lại bao gồm Phiên bản Spot. Cấu hình cuối cùng này dựa trên lời khuyên từ các chuyên gia AWS rằng chúng tôi có ít nhất một nút lõi để hỗ trợ sáu nút tác vụ, giữ tỷ lệ 1: 6. Bảng sau đây tóm tắt thiết kế cụm của chúng tôi.

Hình sau minh họa thiết kế cụm được cập nhật và hiện tại của chúng tôi.

Điều chỉnh thông số Spark

Như bất kỳ cuốn sách hay nào về Apache Spark có thể cho bạn biết, điều chỉnh tham số Spark là chủ đề chính bạn cần xem xét trước khi triển khai ứng dụng Spark trong sản xuất.

Điều chỉnh thông số Spark là nhiệm vụ thiết lập tài nguyên (CPU, bộ nhớ và số lượng trình thực thi) cho mỗi ứng dụng Spark. Trong bài đăng này, chúng tôi không tập trung vào tài nguyên phiên bản trình điều khiển; chúng tôi tập trung vào những người thực thi vì đó là vấn đề chính mà chúng tôi tìm thấy trong quá trình triển khai của Belcorp.

Sau khi chúng tôi áp dụng các cải tiến xung quanh chiến lược hoạt động kết hợp và bộ nhớ cache trong phát triển ứng dụng Spark, chúng tôi nhận ra rằng một số ứng dụng đó đã được chỉ định với các tài nguyên được đánh giá quá cao trong cụm EMR. Điều đó có nghĩa là các ứng dụng Spark được chỉ định tài nguyên, nhưng chỉ có 30% tài nguyên được sử dụng. Báo cáo Ganglia sau đây minh họa việc đánh giá quá cao việc phân bổ tài nguyên cho một công việc ứng dụng Spark, mà chúng tôi đã thu thập được trong một trong các thử nghiệm của mình.

Một hậu quả lớn của hành vi này là việc triển khai ồ ạt các nút EMR không được sử dụng đúng cách. Điều đó có nghĩa là nhiều nút đã được cấp phép do tính năng tự động mở rộng quy mô theo yêu cầu của một lần gửi ứng dụng Spark, nhưng phần lớn tài nguyên của các nút này được giữ miễn phí. Chúng tôi trình bày một ví dụ cơ bản về điều này sau trong phần này.

Với bằng chứng này, chúng tôi bắt đầu nghi ngờ rằng chúng tôi cần điều chỉnh các thông số Spark của một số ứng dụng Spark của chúng tôi.

Như chúng tôi đã đề cập trong các phần trước, là một phần của hệ sinh thái dữ liệu Belcorp, chúng tôi đã xây dựng Công cụ tích hợp đường ống dữ liệu, có trách nhiệm chính là duy trì kiểm soát tập trung các hoạt động của từng ứng dụng Spark. Để làm điều đó, nó sử dụng tệp JSON có chứa cấu hình tham số Spark và thực hiện từng spark-submit sử dụng dịch vụ Livy, như được hiển thị trong mã ví dụ sau:

'/usr/lib/spark/bin/spark-submit' '--class' 'LoadToFunctional' '--conf' 'spark.executor.instances=62' '--conf' 'spark.executor.memory=17g' '--conf' 'spark.yarn.maxAppAttempts=2' '--conf' 'spark.submit.deployMode=cluster' '--conf' 'spark.master=yarn' '--conf' 'spark.executor.cores=5' 's3://<bucket-name>/FunctionalLayer.jar' '--system' 'CM' '--country' 'PE' '--current_step' 'functional' '--attempts' '1' '--ingest_attributes' '{"FileFormat": "zip", "environment": "PRD", "request_origin": "datalake_integrator", "next_step": "load-redshift"}' '--fileFormat' 'zip' '--next_step' 'load-redshift'

Tệp JSON này chứa cấu hình tham số Spark của mỗi ứng dụng Spark liên quan đến hệ thống nội bộ và quốc gia mà chúng tôi gửi đến cụm EMR. Trong ví dụ sau, CM là tên của hệ thống và PE là mã quốc gia mà dữ liệu đến từ:

"systems" : { "CM" : { "PE" : { "params" : {"executorCores": 15, "executorMemory": "45g", "numExecutors": 50 }, "conf" : { "spark.sql.shuffle.partitions" :120 } }
}

Vấn đề với cách tiếp cận này là khi chúng tôi thêm nhiều ứng dụng hơn, việc quản lý các tệp cấu hình này trở nên phức tạp hơn. Ngoài ra, chúng tôi đã có rất nhiều ứng dụng Spark được thiết lập với cấu hình mặc định đã được xác định từ lâu khi khối lượng công việc ít tốn kém hơn. Vì vậy, người ta mong đợi rằng một số thứ sẽ thay đổi. Một ví dụ về ứng dụng Spark với các tham số chưa được hiệu chỉnh được hiển thị trong hình sau (chúng tôi chỉ sử dụng bốn phiên bản trình thực thi cho ví dụ). Trong ví dụ này, chúng tôi nhận ra rằng chúng tôi đang phân bổ những người thực thi với rất nhiều tài nguyên mà không tuân theo bất kỳ phương pháp hay nhất nào của Spark. Điều này đã gây ra việc cung cấp những kẻ thừa hành béo (sử dụng tiếng lóng Spark) phân bổ từng cái trong số đó trong ít nhất một nút. Điều đó có nghĩa là nếu chúng tôi xác định một ứng dụng Spark được gửi bằng cách sử dụng 10 trình thực thi, chúng tôi yêu cầu ít nhất 10 nút của cụm và sử dụng 10 nút chỉ cho một lần chạy, điều này rất tốn kém đối với chúng tôi.

Khi bạn đối mặt với những thách thức về điều chỉnh thông số Spark, bạn nên làm theo lời khuyên của chuyên gia. Có lẽ một trong những lời khuyên quan trọng nhất liên quan đến số lượng lõi thực thi mà bạn nên sử dụng trong một ứng dụng Spark. Các chuyên gia đề nghị rằng một trình thực thi phải có tối đa bốn hoặc năm lõi. Chúng tôi đã quen với hạn chế này vì trước đây chúng tôi đã phát triển các ứng dụng Spark trong hệ sinh thái Hadoop do các hạn chế I / O của Hệ thống tệp Hadoop. Nghĩa là, nếu chúng ta có nhiều lõi được định cấu hình cho một trình thực thi, chúng ta sẽ thực hiện nhiều hoạt động I / O hơn trong một nút dữ liệu HDFS và ai cũng biết rằng HDFS suy giảm do tính đồng thời cao. Ràng buộc này không thành vấn đề nếu chúng tôi sử dụng Amazon S3 làm bộ nhớ, nhưng đề xuất vẫn còn do JVM quá tải. Hãy nhớ rằng, trong khi bạn có nhiều tác vụ hoạt động hơn, chẳng hạn như hoạt động I / O, JVM của mỗi người thực thi có nhiều việc phải làm hơn, do đó JVM bị giảm chất lượng.

Với những dữ kiện này và những phát hiện trước đó, chúng tôi nhận ra rằng đối với một số ứng dụng Spark của chúng tôi, chúng tôi chỉ sử dụng 30% tài nguyên được giao. Chúng tôi cần hiệu chỉnh lại các thông số công việc Spark để chỉ phân bổ các tài nguyên phù hợp nhất và giảm đáng kể việc sử dụng quá mức các nút EMR. Hình dưới đây cung cấp một ví dụ về lợi ích của cải tiến này, nơi chúng ta có thể quan sát thấy mức giảm 50% nút dựa trên cấu hình trước đó của chúng ta.

Chúng tôi đã sử dụng các thông số tối ưu hóa sau để tối ưu hóa ứng dụng Spark liên quan đến hệ thống CM:

"systems" : { "CM" : { "PE" : { "params" : {"executorCores": 5, "executorMemory": "17g", "numExecutors": 62 }, "conf" : { "spark.sql.shuffle.partitions" :120 } }
}

Kết quả

Trong bài đăng này, chúng tôi muốn chia sẻ câu chuyện thành công của dự án cải thiện hệ sinh thái dữ liệu Belcorp, dựa trên hai dòng hành động và ba thách thức do các nhà lãnh đạo xác định bằng cách sử dụng công nghệ dữ liệu AWS và nền tảng nội bộ.

Chúng tôi đã rõ ràng về các mục tiêu của mình ngay từ đầu dựa trên các KPI đã xác định, vì vậy chúng tôi có thể xác nhận rằng số lượng sự cố JIRA được báo cáo vào cuối tháng 2021 năm 75 đã giảm đáng kể. Các số liệu sau đây cho thấy mức giảm tới XNUMX% so với các tháng trước đó, cho thấy tháng XNUMX là một đỉnh quan trọng.

Dựa trên việc giảm thiểu sự cố này, chúng tôi đã phát hiện ra rằng hầu hết tất cả các quy trình công việc Spark chạy trong cụm EMR đều được hưởng lợi từ việc tối ưu hóa thời gian chạy, bao gồm cả hai công việc Spark phức tạp nhất, với mức giảm lên đến 60%, như được hiển thị trong hình sau.

Có lẽ đóng góp quan trọng nhất của những cải tiến do nhóm thực hiện có liên quan trực tiếp đến việc thanh toán mỗi tuần. Ví dụ: thiết kế lại Amazon EMR, cải tiến hoạt động kết hợp, áp dụng các phương pháp hay nhất về bộ nhớ cache và điều chỉnh tham số Spark — tất cả những điều này đã làm giảm đáng kể việc sử dụng tài nguyên cụm. Như chúng ta đã biết, Amazon EMR tính toán thanh toán dựa trên thời gian mà các nút cụm đã hoạt động, bất kể chúng có thực hiện bất kỳ công việc nào hay không. Vì vậy, khi chúng tôi tối ưu hóa việc sử dụng cụm EMR, chúng tôi cũng đã tối ưu hóa chi phí mà chúng tôi đang tạo ra. Như trong hình sau, chỉ trong 2 tháng, từ tháng 40 đến tháng 26, chúng tôi đã đạt được mức giảm thanh toán lên đến XNUMX%. Chúng tôi ước tính rằng chúng tôi sẽ tiết kiệm tới XNUMX% thanh toán hàng năm sẽ được tạo nếu không có các cải tiến.

Kết luận và các bước tiếp theo

Nhóm kiến ​​trúc dữ liệu phụ trách các cải tiến liên tục của hệ sinh thái dữ liệu Belcorp và chúng tôi luôn được thử thách để đạt được kiến ​​trúc tốt nhất trong phân khúc, tạo ra các thiết kế giải pháp kiến ​​trúc tốt hơn, tối ưu hóa chi phí và tạo ra các khuôn khổ có thể mở rộng.

Đồng thời, chúng tôi đang suy nghĩ về tương lai của hệ sinh thái dữ liệu này — cách chúng tôi có thể thích ứng với các nhu cầu kinh doanh mới, tạo ra các mô hình kinh doanh mới và giải quyết các lỗ hổng kiến ​​trúc hiện tại. Hiện chúng tôi đang làm việc trên thế hệ tiếp theo của nền tảng dữ liệu Belcorp, dựa trên các phương pháp tiếp cận mới như sản phẩm dữ liệu, lưới dữ liệu và nhà hồ. Chúng tôi tin rằng những cách tiếp cận và khái niệm mới này sẽ giúp chúng tôi che lấp những khoảng trống về kiến ​​trúc hiện tại trong thế hệ thứ hai của thiết kế nền tảng dữ liệu của chúng tôi. Ngoài ra, nó sẽ giúp chúng tôi tổ chức tốt hơn các nhóm kinh doanh và phát triển để đạt được sự nhanh nhẹn hơn trong chu kỳ phát triển. Chúng tôi coi các giải pháp dữ liệu như một sản phẩm dữ liệu và cung cấp cho các nhóm một tập hợp các thành phần công nghệ và khuôn khổ tự động mà họ có thể sử dụng làm khối xây dựng.

Lời cảm ơn

Chúng tôi muốn cảm ơn các nhà lãnh đạo của chúng tôi, đặc biệt là Jose Israel Rico, Giám đốc Kiến trúc Dữ liệu Doanh nghiệp và Venkat Gopalan, Giám đốc Công nghệ, Dữ liệu và Kỹ thuật số, những người đã truyền cảm hứng cho chúng tôi lấy khách hàng làm trung tâm, nhấn mạnh vào các tiêu chuẩn cao nhất và hỗ trợ mọi quyết định kỹ thuật dựa trên trên một kiến ​​thức chắc chắn hơn về hiện đại của nghệ thuật.

Về các tác giả

Diego Benavides là Kiến trúc sư Dữ liệu Cao cấp của Belcorp phụ trách thiết kế, triển khai và cải tiến liên tục Kiến trúc Hệ sinh thái Dữ liệu Toàn cầu và Doanh nghiệp. Ông có kinh nghiệm làm việc với dữ liệu lớn và công nghệ phân tích tiên tiến trong nhiều lĩnh vực ngành như viễn thông, ngân hàng và bán lẻ.

Luis Bendezú làm việc với tư cách là Kỹ sư dữ liệu cao cấp tại Belcorp. Anh ấy phụ trách việc cải tiến liên tục và triển khai các tính năng mới của hồ dữ liệu bằng cách sử dụng một số dịch vụ AWS. Anh cũng có kinh nghiệm làm kỹ sư phần mềm, thiết kế API, tích hợp nhiều nền tảng, tách ứng dụng và tự động hóa các công việc thủ công.

Mar Ortiz là một nhà kỹ thuật sinh học làm việc với tư cách là Cộng sự Kiến trúc sư Giải pháp tại AWS. Cô có kinh nghiệm làm việc với máy tính đám mây và các công nghệ đa dạng như phương tiện, cơ sở dữ liệu, máy tính và thiết kế kiến ​​trúc phân tán.

Raúl Hugo là Kiến trúc sư Giải pháp AWS Sr. với hơn 12 năm kinh nghiệm trong các công ty tài chính LATAM và các công ty viễn thông toàn cầu với tư cách là một SysAdmin, kỹ sư DevOps và chuyên gia đám mây.

Nguồn: https://aws.amazon.com/blogs/big-data/how-belcorp-decreased-cost-and-improved-reliability-in-its-big-data-processing-framework-using-amazon-emr- quản lý quy mô /