apache phoenix Tham gia hiệu suất truy vấn

Question

Tôi bắt đầu sử dụng phoenix vài tháng trở lại. Dưới đây là chi tiết về môi trường và phiên bản.

Hadoop - Cloudera CDH 5.4.7-1. Phoenix - 4.3 - Phoenix có tên là bưu kiện trên CDH5.4.7-1. Phiên bản HBase - HBase 1.0.0 JDK - 1.7.0_67 1 Máy chủ chính và 3 khu vực.

Chúng tôi bắt đầu thực hiện POC để đánh giá Apache Phoenix. Chúng tôi có dữ liệu trong 12 bảng khác nhau trên Oracle DB. Chúng tôi lấy dữ liệu vào hệ thống Hadoop bằng cổng vàng Oracle.

Có 12 bảng Phoenix khác nhau, mỗi bảng có 40-100 cột với vài trăm hàng. Chúng tôi làm một quá trình chuyển đổi và sau đó tải vào một bảng cuối cùng. Đây là ETL cơ bản mà chúng tôi đang làm. Quá trình chuyển đổi trải qua một vài giai đoạn trung gian, nơi chúng ta cư trú các bảng trung gian. Do đó có "tham gia" giữa các bảng.

Mọi thứ hoạt động tốt và chúng tôi có thể triển khai toàn bộ quy trình ETL. Tôi rất hài lòng với sự dễ sử dụng và thực hiện.

Sự cố bắt đầu khi chúng tôi bắt đầu với Thử nghiệm hiệu suất với hàng triệu hàng. Dưới đây là những vấn đề.

1. Quy trình chuyển đổi trung gian làm hỏng máy chủ khu vực: Tham gia hai bảng, mỗi bảng có 20 Triệu hàng. Chỉ mục phụ được tạo trên cột tôi đang tham gia. Hai bảng được muối với 9 xô. Điều này được thực hiện tốt nếu số lượng hàng được tạo ra từ kết nối nhỏ hơn ~ 200k. Các hàng 200k mất hơn 10 phút để thực thi. Nếu số hàng kết quả là nhiều hơn thì máy chủ vùng bắt đầu bị lỗi. Mã thử nghiệm giải thích số lượng chọn (available_bal) từ muối.b_acct2 ba tham gia bên trong (chọn c_item_id từ salted.m_item2 mi trong đó s_info_id = 12345) là mi trên ba.c_item_id = mi.c_item_id;

   + ------------------------------------------ + | PLAN | + ------------------------------------------ + | KHÁCH HÀNG 9-CHUNK PARALLEL 9-WAY FULL SCAN OVER SALTED.S2_BA_CI_IDX | | SERVER AGGREGATE INTO SINGLE ROW | | PARALLEL INNER-JOIN BẢNG 0 (SKIP MERGE) | | KHÁCH HÀNG 9-CHUNK PARALLEL 9-WAY RANGE QUÉT TRÊN SALTED.S_MI_SI_IDX [0,19,266] | | CLIENT MERGE SORT | | DYNAMIC SERVER FILTER BY TO_BIGINT ("C_ITEM_ID") IN (MI.C_ITEM_ID) | + ------------------------------------------ +

2. Tham gia 6 bảng cho phép chuyển đổi cuối cùng bị treo: Tham gia 6 bảng trên các cột được lập chỉ mục trả về dữ liệu cho các hàng nhỏ hơn 1M. Điều này mất 10-12 phút. Nhưng nếu kết quả tham gia là khoảng hơn 1 triệu, kết quả sẽ bị treo và kết quả không trở lại. Ban đầu tôi nhận được InsufficientMemoryException, mà tôi đã giải quyết bằng cách thay đổi cấu hình và tăng bộ nhớ có sẵn. Tôi không nhận được lại InsufficientMemoryException, nhưng truy vấn không thực thi trong hơn 20 phút. Chúng tôi hy vọng sẽ thực hiện trong vòng vài giây.

Dưới đây là các thông số:

jvm.bootoptions= -Xms512m –Xmx9999M. 
hbase.regionserver.wal.codec : org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec 
hbase.rpc.timeout 600000 
phoenix.query.timeoutMs 360000000 
phoenix.query.maxServerCacheBytes 10737418240 
phoenix.coprocessor.maxServerCacheTimeToLiveMs 900000 
hbase.client.scanner.timeout.period 600000 
phoenix.query.maxGlobalMemoryWaitMs 100000 
phoenix.query.maxGlobalMemoryPercentage 50 
hbase.regionserver.handler.count 50 

Tóm tắt: Những vấn đề cốt lõi là thực hiện chậm của tham gia truy vấn và cuối cùng đâm máy chủ khu vực khi dữ liệu vượt quá 1 triệu hàng. Có giới hạn về việc thực thi không? Hãy giúp tôi giải quyết những vấn đề này khi chúng tôi đang trải qua quá trình đánh giá và tôi không muốn buông bỏ Phoenix! Nếu tôi có thể thực hiện các truy vấn trên trong thời gian nhanh, thì tôi sẽ không ngần ngại sử dụng Phoenix.

Kính trọng, Shivamohan

Answer 1

Theo mặc định, Phoenix sử dụng hash-tham gia, đòi hỏi phải có các dữ liệu để phù hợp trong bộ nhớ. Nếu bạn gặp sự cố (với các bảng rất lớn), bạn có thể tăng lượng bộ nhớ được cấp cho Phoenix (thiết lập cấu hình) hoặc đặt truy vấn "gợi ý" (ví dụ: SELECT /*+ USE_SORT_MERGE_JOIN*/ FROM ...) để sử dụng các phép nối sắp xếp hợp nhất không có yêu cầu. Họ dự định tự động phát hiện thuật toán kết hợp lý tưởng trong tương lai. Ngoài ra, Phoenix hiện chỉ hỗ trợ một tập hợp con các hoạt động tham gia.

Answer 2

Bạn đã thử khái niệm RHS & RHS đã được mô tả trong tài liệu phượng hoàng như là một tính năng tối ưu hóa hiệu năng (http://phoenix.apache.org/joins.html)? Trường hợp tham gia LHS tham gia sẽ được xây dựng dưới dạng bảng băm trong bộ đệm máy chủ vì vậy hãy đảm bảo rằng bảng nhỏ hơn của bạn tạo thành LHS của phần nối bên trong. Các cột bạn đã chọn trong truy vấn có phải là một phần của chỉ mục phụ mà bạn đã tạo không? Nếu bạn đã thử ở trên và vẫn nhận được độ trễ trong vài phút thì u cần phải kiểm tra bộ nhớ của các máy chủ vùng Hbase và liệu chúng có đủ để phục vụ truy vấn của bạn hay không.