Đây là bài đăng của khách mời Miguel Chin, Giám đốc kỹ thuật dữ liệu tại OLX Group và David Greenshtein, Kiến trúc sư giải pháp chuyên gia cho Analytics, AWS.

Nhóm OLX là một trong những mạng lưới thị trường trực tuyến phát triển nhanh nhất thế giới, hoạt động tại hơn 30 quốc gia trên thế giới. Chúng tôi giúp mọi người mua và bán ô tô, tìm nhà ở, kiếm việc làm, mua và bán đồ gia dụng, v.v.

Chúng ta đang sống trong một thế giới sản xuất dữ liệu và khi các công ty muốn trở thành định hướng dữ liệu, thì ngày càng cần phải phân tích nhiều dữ liệu hơn. Những phân tích này thường được thực hiện bằng cách sử dụng kho dữ liệu. Tuy nhiên, một vấn đề phổ biến về kho dữ liệu với khối lượng dữ liệu ngày càng tăng là giới hạn lưu trữ và hiệu suất giảm sút đi kèm với nó. Kịch bản này rất quen thuộc với chúng tôi trong Tập đoàn OLX. Kho dữ liệu của chúng tôi được xây dựng bằng Amazon Redshift và được nhiều nhóm nội bộ sử dụng để cung cấp năng lượng cho các sản phẩm và quyết định kinh doanh dựa trên dữ liệu của họ. Do đó, điều quan trọng là phải duy trì một cụm có tính khả dụng và hiệu suất cao đồng thời tiết kiệm chi phí lưu trữ.

Trong bài đăng này, chúng tôi chia sẻ cách chúng tôi hiện đại hóa Amazon RedShift kho dữ liệu bằng cách di chuyển sang các nút RA3 và cách nó cho phép chúng tôi đạt được kỳ vọng kinh doanh của mình. Hy vọng rằng bạn có thể học hỏi từ kinh nghiệm của chúng tôi trong trường hợp bạn đang cân nhắc làm điều tương tự.

Hiện trạng trước khi di cư

Tại OLX Group, Amazon Redshift đã là lựa chọn của chúng tôi cho kho dữ liệu trong hơn 5 năm. Chúng tôi đã bắt đầu với một cụm Amazon Redshift nhỏ gồm 7 nút DC2.8xlarge và khi mức độ phổ biến cũng như việc áp dụng cụm này tăng lên trong cộng đồng dữ liệu của OLX Group, cụm này đã phát triển một cách tự nhiên.

Trước khi di chuyển sang RA3, chúng tôi đã sử dụng cụm 16 nút DC2.8xlarge với tính năng quản lý khối lượng công việc (WLM) được điều chỉnh cao và hiệu suất hoàn toàn không phải là vấn đề. Tuy nhiên, chúng tôi liên tục đối mặt với những thách thức về nhu cầu lưu trữ do có nhiều người dùng hơn, nhiều nguồn dữ liệu hơn và dữ liệu được chuẩn bị sẵn nhiều hơn. Hầu như ngày nào chúng tôi cũng nhận được thông báo rằng dung lượng ổ đĩa của chúng tôi đã gần đạt 100%, tương đương với khoảng 40 TB dữ liệu.

Phương pháp thông thường của chúng tôi để giải quyết các vấn đề về lưu trữ trước đây chỉ đơn giản là tăng số lượng nút. Nhìn chung, chúng tôi đã đạt đến kích thước cụm gồm 18 nút. Tuy nhiên, giải pháp này không đủ hiệu quả về mặt chi phí vì chúng tôi đã bổ sung công suất điện toán cho cụm mặc dù công suất điện toán chưa được sử dụng đúng mức. Chúng tôi coi đây là một giải pháp tạm thời và chủ yếu chúng tôi làm như vậy để câu giờ nhằm khám phá các giải pháp thay thế hiệu quả về chi phí khác, chẳng hạn như các nút RA3.

Các nút RA3 của Amazon Redshift cùng với Lưu trữ được quản lý Redshift (RMS) cung cấp sự tách biệt giữa lưu trữ và điện toán, cho phép chúng tôi mở rộng quy mô lưu trữ và điện toán một cách riêng biệt để đáp ứng tốt hơn các yêu cầu kinh doanh của mình.

Kho dữ liệu của chúng tôi có cấu hình sau trước khi di chuyển:

• 18 nút DC2.8xlarge
• 250 người dùng hoạt động hàng tháng, liên tục tăng
• 10,000 truy vấn mỗi giờ, 30 truy vấn song song
• 40 TB dữ liệu, không ngừng tăng lên
• Sử dụng 100% không gian đĩa

Hiệu suất của cụm này nói chung là tốt, ETL (trích xuất, chuyển đổi và tải) và các truy vấn tương tác hầu như không có bất kỳ thời gian xếp hàng nào và 80% trong số đó sẽ hoàn thành sau chưa đầy 5 phút.

Đánh giá hiệu suất của các cụm Amazon Redshift với các nút RA3

Trong phần này, chúng tôi thảo luận về cách chúng tôi tiến hành đánh giá hiệu suất của các nút RA3 với cụm Amazon Redshift.

Môi trường thử nghiệm

Để tự tin với hiệu suất của các nút RA3, chúng tôi đã quyết định kiểm tra căng thẳng chúng trong môi trường được kiểm soát trước khi đưa ra quyết định di chuyển. Để đánh giá các nút và tìm cấu hình cụm RA3 tối ưu, chúng tôi đã hợp tác với AllCloud, đối tác tư vấn hàng đầu của AWS. Các số liệu sau đây minh họa cách tiếp cận mà chúng tôi đã thực hiện để đánh giá hiệu suất của RA3.

Chiến lược này nhằm tái tạo khối lượng công việc thực tế trong các cấu hình cụm RA3 khác nhau và so sánh chúng với cấu hình DC2 của chúng tôi. Để làm điều này, chúng tôi yêu cầu như sau:

• Ảnh chụp nhanh cụm tham chiếu – Điều này đảm bảo rằng chúng tôi có thể phát lại bất kỳ bài kiểm tra nào bắt đầu từ cùng một trạng thái.
• Một tập hợp các truy vấn từ cụm sản xuất – Bộ này có thể được xây dựng lại từ nhật ký Amazon Redshift (STL_QUERYTEXT) và được làm giàu bằng siêu dữ liệu (STL_QUERY). Cần lưu ý rằng chúng tôi chỉ xem xét các loại truy vấn SELECT và FETCH (để đơn giản hóa giai đoạn kiểm tra hiệu năng đầu tiên này). Biểu đồ sau đây cho thấy hồ sơ của bộ thử nghiệm của chúng tôi trông như thế nào.

• Một công cụ phát lại để sắp xếp tất cả các hoạt động truy vấn – AllCloud đã phát triển một ứng dụng Python cho chúng tôi cho mục đích này.

Để biết thêm chi tiết về phương pháp chúng tôi đã sử dụng, bao gồm cả việc sử dụng Tiện ích Phát lại đơn giản của Amazon Redshift, tham khảo So sánh các loại nút khác nhau cho khối lượng công việc của bạn bằng Amazon Redshift.

Tiếp theo, chúng tôi đã chọn cấu hình cụm nào chúng tôi muốn kiểm tra, loại RA3 nào và số lượng nút. Để biết thông số kỹ thuật của từng loại nút, hãy tham khảo Định giá Amazon Redshift.

Đầu tiên, chúng tôi quyết định thử nghiệm cùng một cụm DC2 mà chúng tôi đã có trong quá trình sản xuất như một cách để xác thực môi trường thử nghiệm của mình, tiếp theo là cụm RA3 sử dụng các nút RA3.4xlarge với số lượng nút khác nhau. Chúng tôi đã sử dụng RA3.4xlarge vì nó giúp chúng tôi linh hoạt hơn trong việc tinh chỉnh số lượng nút chúng tôi cần so với phiên bản RA3.16xlarge (1 x nút RA3.16xlarge tương đương với 4 x nút RA3.4xlarge xét về CPU và bộ nhớ) . Với suy nghĩ này, chúng tôi đã thử nghiệm các cấu hình cụm sau và sử dụng công cụ phát lại để đo lường hiệu suất của từng cụm.

Những kết quả này cho thấy cách cụm DC2 so sánh với các cấu hình RA3 khác. Đối với 50% truy vấn nhanh hơn (50% lượng tử), chúng chạy nhanh hơn trên DC2. Về số lượng nút RA3, sáu nút rõ ràng là chậm hơn, đặc biệt đáng chú ý trên lượng tử 75% thời lượng truy vấn.

Chúng tôi đã sử dụng các bước sau để triển khai các cụm khác nhau:

1. Sử dụng 18 x DC2.8xlarge, được khôi phục từ ảnh chụp ban đầu (18 x DC2.8xlarge).
2. Lấy số đo 18 x DC2.
3. Sử dụng 18 x RA3.4xlarge, được khôi phục từ ảnh chụp ban đầu (18 x DC2.8xlarge).
4. Lấy số đo 18 x RA3 (trước khi thay đổi kích thước cổ điển).
5. Sử dụng 6 x RA3.4xlarge, thay đổi kích thước cổ điển từ 18 x RA3.4xlarge.
6. Chụp ảnh nhanh từ 6 x RA3.4xlarge.
7. Lấy số đo 6 x RA3.
8. Sử dụng 6 x RA3.4xlarge, được khôi phục từ ảnh chụp nhanh 6 x RA3.4xlarge.
9. Sử dụng 18 x RA3.4xlarge, thay đổi kích thước đàn hồi từ 6 x RA3.4xlarge.
10. Lấy số đo 18x RA3.

Mặc dù đây là những kết quả đầy hứa hẹn nhưng vẫn có một số hạn chế trong thiết lập môi trường thử nghiệm. Chúng tôi lo ngại rằng chúng tôi đã không nhấn mạnh đủ các cụm, các truy vấn chỉ chạy theo trình tự bằng cách sử dụng một ứng dụng khách duy nhất và việc chúng tôi chỉ sử dụng các loại truy vấn CHỌN và TÌM HIỂU đã khiến chúng tôi rời xa khối lượng công việc thực tế. Do đó, chúng tôi đã tiến hành giai đoạn thứ hai của các thử nghiệm của mình.

Kiểm tra căng thẳng đồng thời

Để nhấn mạnh các cụm, chúng tôi đã thay đổi công cụ phát lại của mình để chạy song song nhiều truy vấn. Các truy vấn được trích xuất từ ​​các tệp nhật ký được xếp hàng đợi với tần suất giống như chúng được chạy ban đầu trong cụm tham chiếu. Tối đa 50 khách hàng nhận truy vấn từ hàng đợi và gửi chúng tới Amazon Redshift. Thời gian của tất cả các truy vấn được ghi lại để so sánh với cụm tham chiếu.

Hiệu suất của cụm được đánh giá bằng cách đo tiến trình thời gian của truy vấn đồng thời. Nếu một cụm có hiệu suất ngang bằng với cụm tham chiếu, thì đồng thời sẽ theo sát đồng thời của cụm tham chiếu. Các truy vấn được đẩy vào hàng đợi truy vấn ngay lập tức được máy khách chọn và gửi đến cụm. Nếu cụm không có khả năng xử lý các truy vấn nhanh như cụm tham chiếu, thì số lượng truy vấn đang chạy đồng thời sẽ tăng lên khi so sánh với cụm tham chiếu. Chúng tôi cũng quyết định vô hiệu hóa quy mô đồng thời trong quá trình thử nghiệm này vì chúng tôi muốn tập trung vào các loại nút thay vì các tính năng của cụm.

Bảng sau đây hiển thị các truy vấn đồng thời chạy trên DC2 và RA3 (cả 18 nút) với hai bộ kiểm tra truy vấn khác nhau (3:00 sáng và 1:00 chiều). Chúng được chọn để chúng tôi có thể kiểm tra cả khối lượng công việc trong ngày và qua đêm. 3:00 sáng là lúc chúng tôi có nhiều công việc ETL tự động đang chạy nhất và 1:00 chiều là khi chúng tôi có hoạt động người dùng cao.

Trung bình của việc chạy các truy vấn đồng thời trên cụm RA3 cao hơn nhiều so với cụm DC2. Điều này khiến chúng tôi kết luận rằng một cụm gồm 18 RA3.4xlarge có thể không đủ để xử lý khối lượng công việc này một cách đáng tin cậy.

RA3.16xlarge

Ban đầu, chúng tôi đã chọn loại nút RA3.4xlarge để kiểm soát chi tiết hơn trong việc tinh chỉnh số lượng nút. Tuy nhiên, chúng tôi đã bỏ qua một chi tiết quan trọng: cùng một loại phiên bản được sử dụng cho các nút worker và leader. Một nút dẫn đầu cần quản lý tất cả quá trình xử lý song song diễn ra trong cụm và một RA3.4xlarge duy nhất là không đủ để làm như vậy.

Với suy nghĩ này, chúng tôi đã thử nghiệm thêm hai cấu hình cụm: 6 x RA3.16xlarge và 8 x RA3.16xlarge, đồng thời đo tính đồng thời một lần nữa. Lần này kết quả tốt hơn nhiều; RA3.16xlarge có thể theo kịp đồng thời tham chiếu và điểm hấp dẫn dường như nằm trong khoảng từ 6–8 nút.

Mọi thứ có vẻ tốt hơn và cấu hình mục tiêu của chúng tôi hiện là cụm 7 x RA3.16xlarge. Bây giờ chúng tôi đã đủ tự tin để tiến hành di chuyển.

Cuộc di cư

Bất kể chúng tôi hào hứng tiến hành như thế nào, chúng tôi vẫn muốn thực hiện một quá trình di chuyển có tính toán. Cách tốt nhất là có một cẩm nang dành cho quá trình di chuyển—hướng dẫn từng bước về những việc cần thực hiện và cả kế hoạch dự phòng bao gồm kế hoạch khôi phục. Vì lý do đơn giản, chúng tôi chỉ liệt kê ở đây các bước có liên quan trong trường hợp bạn đang tìm kiếm nguồn cảm hứng.

Kế hoạch di chuyển

Kế hoạch di chuyển bao gồm các bước chính sau:

1. Xóa DNS khỏi cụm hiện tại, trong trường hợp của chúng tôi là Amazon Route 53. Không người dùng nào có thể truy vấn sau này.
2. Kiểm tra xem có bất kỳ phiên nào vẫn đang chạy truy vấn hay không và quyết định đợi hoặc dừng truy vấn đó. Điều này cho thấy rõ ràng rằng những người dùng này đang sử dụng URL cụm trực tiếp để kết nối.
   1. Để kiểm tra các phiên đang chạy, hãy sử dụng SELECT * FROM STV_SESSIONS.
   2. Để kiểm tra các phiên đã dừng, hãy sử dụng SELECT PG_TERMINATE_BACKEND(xxxxx);.
3. Tạo ảnh chụp nhanh cụm DC2.
4. Tạm dừng cụm DC2.
5. Tạo một cụm RA3 từ ảnh chụp nhanh với cấu hình sau:
   1. Loại nút – RA3.16xlarge
   2. Số lượng nút - 7
   3. Tên cơ sở dữ liệu – Tương tự DC2
   4. Các vai trò IAM được liên kết – Tương tự DC2
   5. VPC – Tương tự DC2
   6. Nhóm bảo mật VPC – Tương tự DC2
   7. Nhóm thông số – Tương tự DC2
6. Chờ SELECT COUNT(1) FROM STV_UNDERREPPED_BLOCKS để trả về 0. Điều này có liên quan đến quá trình hydrat hóa của cụm.
7. Trỏ DNS đến cụm RA3.
8. Người dùng hiện có thể truy vấn lại cụm.

Kế hoạch dự phòng

Trong trường hợp hiệu suất của ETL hàng giờ và hàng ngày không được chấp nhận, kế hoạch dự phòng sẽ được kích hoạt:

1. Thêm một nút nữa để giải quyết khối lượng công việc không mong muốn.
2. Tăng giới hạn số giờ mở rộng quy mô đồng thời.
3. Đánh giá lại nhóm tham số.

Theo kế hoạch này, chúng tôi đã di chuyển từ các nút DC2 sang RA3 trong khoảng 3.5 giờ, từ khi dừng cụm cũ đến khởi động cụm mới và để các quy trình của chúng tôi đồng bộ hóa hoàn toàn. Sau đó, chúng tôi tiến hành theo dõi hiệu suất trong vài giờ. Dung lượng lưu trữ trông tuyệt vời và mọi thứ đều hoạt động trơn tru, nhưng chúng tôi tò mò muốn xem các quy trình qua đêm sẽ hoạt động như thế nào.

Sáng hôm sau, chúng tôi thức dậy với thứ mà chúng tôi sợ hãi: một cụm chậm chạp. Chúng tôi đã kích hoạt kế hoạch dự phòng của mình và trong vài ngày sau đó, chúng tôi đã hoàn thành việc thực hiện cả ba hành động mà chúng tôi có trong kế hoạch dự phòng.

Bản thân việc thêm một nút bổ sung không mang lại nhiều trợ giúp, tuy nhiên, người dùng đã trải nghiệm hiệu suất tốt trong những giờ mở rộng quy mô đồng thời. Các tính năng mở rộng đồng thời cho phép Amazon Redshift tạm thời tăng dung lượng cụm bất cứ khi nào khối lượng công việc yêu cầu. Chúng tôi đã định cấu hình nó để cho phép sử dụng tối đa 4 giờ mỗi ngày—1 giờ miễn phí và 3 giờ trả phí. Chúng tôi đã chọn giá trị cụ thể này vì xét về giá cả, nó tương đương với việc thêm một nút nữa (đưa chúng tôi đến chín nút) với lợi thế bổ sung là chỉ sử dụng và thanh toán cho nó khi khối lượng công việc yêu cầu.

Hành động cuối cùng chúng tôi thực hiện có liên quan đến nhóm tham số, cụ thể là WLM. Như đã nêu ban đầu, chúng tôi đã có một WLM được tinh chỉnh thủ công, nhưng nó tỏ ra không hiệu quả đối với cụm RA3 mới này. Vì vậy, chúng tôi quyết định thử WLM tự động với cấu hình sau.

WLM thủ công yêu cầu bạn phân bổ thủ công phần trăm tài nguyên và xác định số lượng vị trí trên mỗi hàng đợi. Mặc dù điều này mang lại cho bạn sự tách biệt tài nguyên, nhưng điều đó cũng có nghĩa là tài nguyên được phân bổ liên tục và có thể bị lãng phí nếu chúng không được sử dụng. Auto WLM tự động đặt các biến này tùy thuộc vào mức độ ưu tiên và khối lượng công việc của từng hàng đợi. Điều này có nghĩa là một truy vấn trong hàng đợi có mức độ ưu tiên cao nhất sẽ nhận được tất cả các tài nguyên được phân bổ cho nó, trong khi các hàng đợi có mức độ ưu tiên thấp hơn sẽ cần đợi các tài nguyên có sẵn. Với suy nghĩ này, chúng tôi chia ETL của mình tùy thuộc vào mức độ ưu tiên của nó: ETL hàng ngày thành cao nhất, ETL hàng giờ thành bình thường (để tạo cơ hội công bằng cho các truy vấn của người dùng cạnh tranh tài nguyên) và chất lượng giám sát và dữ liệu ở mức thấp.

Sau khi áp dụng quy mô đồng thời và WLM tự động, chúng tôi đã đạt được hiệu suất ổn định trong cả tuần và coi việc di chuyển là thành công.

Hiện trạng sau khi di chuyển

Gần một năm đã trôi qua kể từ khi chúng tôi chuyển sang các nút RA3 và chúng tôi vô cùng hài lòng. Nhờ vào Lưu trữ được quản lý Redshift (RMS), các vấn đề về dung lượng ổ đĩa của chúng tôi đã là dĩ vãng và hiệu suất nói chung là tuyệt vời so với cụm DC2 trước đây của chúng tôi. Chúng tôi hiện có 300 người dùng hoạt động hàng tháng. Chi phí cụm đã tăng lên do loại nút mới và quy mô đồng thời, nhưng giờ đây chúng tôi cảm thấy đã sẵn sàng cho tương lai và không mong đợi bất kỳ thay đổi kích thước cụm nào sớm.

Nhìn lại, chúng tôi muốn có một quá trình di chuyển được chuẩn bị và lên kế hoạch cẩn thận, đồng thời chúng tôi có thể tìm hiểu thêm về RA3 với môi trường thử nghiệm của mình. Tuy nhiên, kinh nghiệm của chúng tôi cũng cho thấy rằng môi trường thử nghiệm không phải lúc nào cũng an toàn và một số chi tiết có thể bị bỏ qua. Cuối cùng, đây là những điểm chính của chúng tôi từ quá trình di chuyển sang các nút RA3:

• Chọn loại nút phù hợp theo khối lượng công việc của bạn. Một cụm RA3.16xlarge cung cấp các nút công nhân và thủ lĩnh mạnh mẽ hơn.
• Sử dụng quy mô đồng thời để cung cấp thêm tài nguyên khi khối lượng công việc yêu cầu. Thêm một nút mới không phải lúc nào cũng là giải pháp tiết kiệm chi phí nhất.
• WLM thủ công yêu cầu rất nhiều điều chỉnh; sử dụng WLM tự động cho phép phân phối tài nguyên cụm tốt hơn và công bằng hơn.

Kết luận

Trong bài đăng này, chúng tôi đã đề cập đến cách OLX Group hiện đại hóa kho dữ liệu Amazon Redshift của chúng tôi bằng cách di chuyển sang các nút RA3. Chúng tôi trình bày chi tiết cách chúng tôi kiểm tra trước khi di chuyển, bản thân quá trình di chuyển và kết quả. Bây giờ chúng tôi đang bắt đầu khám phá các khả năng được cung cấp bởi các nút RA3. Đặc biệt, khả năng chia sẻ dữ liệu cùng với Dịch chuyển đỏ không có máy chủ mở ra cánh cửa cho các thiết lập kiến ​​trúc thú vị mà chúng tôi đang mong chờ.

Nếu bạn đang gặp phải các sự cố lưu trữ giống như chúng tôi đã từng gặp phải với cụm Amazon Redshift của mình, chúng tôi thực sự khuyên bạn nên di chuyển sang các nút RA3. Tính năng RMS của nó tách rời khả năng mở rộng của sức mạnh tính toán và lưu trữ, cung cấp một giải pháp tiết kiệm chi phí hơn.

Cảm ơn đã đọc bài đăng này và hy vọng bạn thấy nó hữu ích. Nếu bạn đang trải qua tình huống tương tự và có bất kỳ câu hỏi nào, vui lòng liên hệ.

Giới thiệu về tác giả

Miguel Chin là Giám đốc Kỹ thuật Dữ liệu tại OLX Group, một trong những mạng nền tảng giao dịch phát triển nhanh nhất thế giới. Ông chịu trách nhiệm quản lý một nhóm kỹ sư dữ liệu theo định hướng miền giúp định hình hệ sinh thái dữ liệu của công ty bằng cách phổ biến các khái niệm dữ liệu tiên tiến như lưới dữ liệu.

David Greenshtein là Kiến trúc sư giải pháp chuyên gia cho Analytics tại AWS với niềm đam mê ETL và tự động hóa. Anh ấy làm việc với các khách hàng của AWS để thiết kế và xây dựng các giải pháp phân tích cho phép doanh nghiệp đưa ra các quyết định dựa trên dữ liệu. Khi rảnh rỗi, anh thích chạy bộ và đạp xe cùng con trai.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• Platoblockchain. Web3 Metaverse Intelligence. Khuếch đại kiến ​​thức. Truy cập Tại đây.
• nguồn: https://aws.amazon.com/blogs/big-data/how-olx-group-migrated-to-amazon-redshift-ra3-for-simpler-faster-and-more-cost-effective-analytics/