Phá vỡ các kho dữ liệu: Cách Apache Doris hợp lý hóa việc tích hợp dữ liệu khách hàng

Vấn đề về kho lưu trữ dữ liệu giống như bệnh viêm khớp đối với các doanh nghiệp trực tuyến vì hầu hết mọi người đều mắc phải nó khi về già. Doanh nghiệp tương tác với khách hàng thông qua trang web, ứng dụng di động, trang H5 và thiết bị cuối. Vì lý do này hay lý do khác, việc tích hợp dữ liệu từ tất cả các nguồn này là rất khó. Dữ liệu vẫn giữ nguyên vị trí và không thể liên kết với nhau để phân tích thêm. Đó là cách các silo dữ liệu hình thành. Doanh nghiệp của bạn càng phát triển, bạn càng có nhiều nguồn dữ liệu khách hàng đa dạng và bạn càng có nhiều khả năng bị mắc kẹt bởi các kho dữ liệu.

Đây chính xác là những gì xảy ra với công ty bảo hiểm mà tôi sắp nói đến trong bài viết này. Đến năm 2023, họ đã phục vụ hơn 500 triệu khách hàng và ký kết 57 tỷ hợp đồng bảo hiểm. Khi họ bắt đầu xây dựng nền tảng dữ liệu khách hàng (CDP) để đáp ứng kích thước dữ liệu như vậy, họ đã sử dụng nhiều thành phần.

Silo dữ liệu trong CDP

Giống như hầu hết các nền tảng dữ liệu, CDP 1.0 của họ có quy trình xử lý hàng loạt và quy trình phát trực tuyến theo thời gian thực. Dữ liệu ngoại tuyến được tải thông qua các công việc Spark tới Impala, nơi nó được gắn thẻ và chia thành các nhóm. Trong khi đó, Spark cũng gửi nó tới NebulaGraph để tính toán OneID (được trình bày chi tiết ở phần sau của bài đăng này). Mặt khác, dữ liệu thời gian thực được Flink gắn thẻ và sau đó được lưu trữ trong HBase, sẵn sàng để truy vấn.

Điều đó dẫn đến một lớp tính toán nặng về thành phần trong CDP: Impala, Spark, NebulaGraph và HBase.

Kết quả là các thẻ ngoại tuyến, thẻ thời gian thực và dữ liệu biểu đồ nằm rải rác trên nhiều thành phần. Việc tích hợp chúng cho các dịch vụ dữ liệu khác rất tốn kém do lưu trữ dư thừa và truyền dữ liệu cồng kềnh. Hơn nữa, do sự khác biệt về dung lượng lưu trữ, họ đã phải mở rộng kích thước của cụm CDH và cụm NebulaGraph, làm tăng thêm chi phí tài nguyên và bảo trì.

CDP dựa trên Apache Doris

Đối với CDP 2.0, họ quyết định giới thiệu một giải pháp thống nhất để dọn dẹp mớ hỗn độn. Ở lớp tính toán của CDP 2.0, Apache Doris đảm nhận cả tính toán và lưu trữ dữ liệu ngoại tuyến và thời gian thực.

Để nhập dữ liệu ngoại tuyến , họ sử dụng phương pháp Tải luồng . Thử nghiệm nhập 30 luồng của họ cho thấy rằng nó có thể thực hiện hơn 300.000 lượt nâng cấp mỗi giây. Để tải dữ liệu thời gian thực , họ sử dụng kết hợp Flink-Doris-Connector và Stream Load. Ngoài ra, trong báo cáo thời gian thực, nơi họ cần trích xuất dữ liệu từ nhiều nguồn dữ liệu bên ngoài, họ tận dụng tính năng Đa danh mục cho các truy vấn liên kết .

Quy trình phân tích khách hàng trên CDP này diễn ra như sau. Đầu tiên, họ phân loại thông tin khách hàng; sau đó họ gắn thẻ cho từng khách hàng. Dựa trên thẻ, họ chia khách hàng thành các nhóm để phân tích và vận hành có mục tiêu hơn.

Tiếp theo, tôi sẽ đi sâu vào các khối lượng công việc này và chỉ cho bạn cách Apache Doris tăng tốc chúng.

mộtID

Điều này đã từng xảy ra với bạn khi bạn có các hệ thống đăng ký người dùng khác nhau cho các sản phẩm và dịch vụ của mình chưa? Bạn có thể thu thập email của UserID A từ một trang web sản phẩm và sau đó là số an sinh xã hội của UserID B từ một trang web khác. Sau đó, bạn phát hiện ra rằng UserID A và UserID B thực sự thuộc về cùng một người vì họ có cùng số điện thoại.

Đó là lý do tại sao OneID nảy sinh như một ý tưởng. Đó là gộp thông tin đăng ký người dùng của tất cả các ngành nghề kinh doanh vào một bảng lớn trong Apache Doris, sắp xếp nó và đảm bảo rằng một người dùng có một OneID duy nhất.

Đây là cách họ tìm ra thông tin đăng ký nào thuộc về cùng một người dùng, tận dụng các chức năng trong Apache Doris.

Dịch vụ gắn thẻ

CDP này chứa thông tin của 500 triệu khách hàng , đến từ hơn 500 bảng nguồn và được gắn vào tổng cộng hơn 2000 thẻ .

Theo tính kịp thời, các thẻ có thể được chia thành thẻ thời gian thực và thẻ ngoại tuyến. Các thẻ thời gian thực được Apache Flink tính toán và ghi vào bảng phẳng trong Apache Doris, trong khi các thẻ ngoại tuyến được Apache Doris tính toán vì chúng được lấy từ bảng thuộc tính người dùng, bảng doanh nghiệp và bảng hành vi người dùng trong Doris. Đây là phương pháp hay nhất của công ty trong việc gắn thẻ dữ liệu:

1. Thẻ ngoại tuyến:

Trong thời gian ghi dữ liệu cao điểm, bản cập nhật đầy đủ có thể dễ dàng gây ra lỗi OOM do quy mô dữ liệu khổng lồ của chúng. Để tránh điều đó, họ sử dụng chức năng INSERT INTO SELECT của Apache Doris và kích hoạt cập nhật một phần cột . Điều này sẽ giảm đáng kể mức tiêu thụ bộ nhớ và duy trì sự ổn định của hệ thống trong quá trình tải dữ liệu.

 set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from .....

2. Thẻ thời gian thực:

Cập nhật một phần cột cũng có sẵn cho thẻ thời gian thực vì thẻ thời gian thực được cập nhật ở các tốc độ khác nhau. Tất cả những gì cần thiết là đặt partial_columns thành true .

 curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load

3. Truy vấn điểm đồng thời cao:

Với quy mô kinh doanh hiện tại, công ty đang nhận được yêu cầu truy vấn thẻ ở mức đồng thời trên 5000 QPS. Họ sử dụng kết hợp các chiến lược để đảm bảo hiệu suất cao. Đầu tiên, họ áp dụng Tuyên bố đã chuẩn bị sẵn để biên dịch trước và thực thi trước SQL. Thứ hai, họ tinh chỉnh các tham số cho Doris Backend và các bảng để tối ưu hóa việc lưu trữ và thực thi. Cuối cùng, chúng kích hoạt bộ đệm hàng như một phần bổ sung cho Apache Doris định hướng theo cột.

• Tinh chỉnh các tham số Doris Backend trong be.conf :

 disable_storage_row_cache = false storage_page_cache_limit=40%

• Tinh chỉnh các tham số bảng khi tạo bảng:

 enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true

4. Tính toán thẻ (join):

Trong thực tế, nhiều dịch vụ gắn thẻ được triển khai bằng cách nối nhiều bảng trong cơ sở dữ liệu. Điều đó thường liên quan đến hơn mười bảng. Để có hiệu suất tính toán tối ưu, họ áp dụng chiến lược nhóm colocation trong Doris.

Nhóm khách hàng

Quy trình phân nhóm khách hàng trong CDP 2.0 diễn ra như sau: Apache Doris nhận SQL từ dịch vụ khách hàng, thực hiện tính toán và gửi tập kết quả đến bộ lưu trữ đối tượng S3 thông qua SELECT INTO OUTFILE. Công ty đã chia khách hàng của mình thành 1 triệu nhóm. Nhiệm vụ nhóm khách hàng trước đây mất 50 giây để hoàn thành ở Impala giờ chỉ cần 10 giây ở Doris .

Ngoài việc phân nhóm khách hàng để phân tích chi tiết hơn, đôi khi họ còn phân tích theo hướng ngược lại. Tức là nhắm mục tiêu vào một khách hàng nhất định và tìm hiểu xem họ thuộc nhóm nào. Điều này giúp các nhà phân tích hiểu được đặc điểm của khách hàng cũng như sự chồng chéo của các nhóm khách hàng khác nhau như thế nào.

Trong Apache Doris, điều này được triển khai bởi các hàm BITMAP: BITMAP_CONTAINS là cách nhanh chóng để kiểm tra xem khách hàng có thuộc một nhóm nhất định hay không và BITMAP_OR , BITMAP_INTERSECT và BITMAP_XOR là các lựa chọn để phân tích chéo.

Phần kết luận

Từ CDP 1.0 đến CDP 2.0, công ty bảo hiểm áp dụng Apache Doris, kho dữ liệu hợp nhất, để thay thế Spark+Impala+HBase+NebulaGraph. Điều đó làm tăng hiệu quả xử lý dữ liệu của họ bằng cách phá vỡ các kho dữ liệu và hợp lý hóa các đường ống xử lý dữ liệu. Trong CDP 3.0 sắp tới, họ muốn nhóm khách hàng của mình bằng cách kết hợp thẻ thời gian thực và thẻ ngoại tuyến để phân tích đa dạng và linh hoạt hơn. Cộng đồng Apache Doris và nhóm VeloDB sẽ tiếp tục là đối tác hỗ trợ trong quá trình nâng cấp này.

Cũng được xuất bản ở đây .