Bài viết này được đồng viết bởi tôi và đồng nghiệp của tôi Kai Dai. Cả hai chúng tôi đều là kỹ sư nền tảng dữ liệu tại Tencent Music (NYSE: TME), nhà cung cấp dịch vụ phát nhạc trực tuyến với con số khổng lồ 800 triệu người dùng hoạt động hàng tháng. Bỏ con số ở đây không phải để khoe khoang mà để gợi ý về biển dữ liệu mà tôi và những người đồng nghiệp tội nghiệp của tôi phải đối phó hàng ngày. Chúng tôi sử dụng ClickHouse để làm gì Thư viện nhạc của Tencent Music chứa dữ liệu thuộc mọi dạng và loại: nhạc đã ghi, nhạc sống, âm thanh, video, v.v. Là kỹ sư nền tảng dữ liệu, công việc của chúng tôi là chắt lọc thông tin từ dữ liệu, dựa vào đó đồng đội của chúng tôi có thể đưa ra quyết định tốt hơn để hỗ trợ người dùng và đối tác âm nhạc của chúng tôi. Cụ thể, chúng tôi thực hiện phân tích toàn diện về bài hát, lời bài hát, giai điệu, album và nghệ sĩ, biến tất cả thông tin này thành nội dung dữ liệu và chuyển chúng cho người dùng dữ liệu nội bộ của chúng tôi để đếm khoảng không quảng cáo, lập hồ sơ người dùng, phân tích số liệu và nhắm mục tiêu theo nhóm . Chúng tôi đã lưu trữ và xử lý hầu hết dữ liệu của mình trong Kho dữ liệu Tencent (TDW), một nền tảng dữ liệu ngoại tuyến nơi chúng tôi đưa dữ liệu vào các hệ thống thẻ và số liệu khác nhau, sau đó tạo các bảng phẳng tập trung vào từng đối tượng (bài hát, nghệ sĩ, v.v.). Sau đó, chúng tôi đã nhập các bảng phẳng vào ClickHouse để phân tích và Elaticsearch để tìm kiếm dữ liệu và nhắm mục tiêu theo nhóm. Sau đó, các nhà phân tích dữ liệu của chúng tôi đã sử dụng dữ liệu theo các thẻ và chỉ số mà họ cần để tạo bộ dữ liệu cho các tình huống sử dụng khác nhau, trong đó họ có thể tạo các thẻ và chỉ số của riêng mình. Đường ống xử lý dữ liệu trông như thế này: Các vấn đề với ClickHouse Khi làm việc với đường ống trên, chúng tôi gặp một số khó khăn: : Không hỗ trợ cập nhật một phần cột. Do đó, bất kỳ độ trễ nào từ bất kỳ nguồn dữ liệu nào cũng có thể làm chậm quá trình tạo bảng phẳng và do đó làm suy yếu tính kịp thời của dữ liệu. Cập nhật một phần : Dữ liệu dưới các thẻ và chỉ số khác nhau được cập nhật ở các tần suất khác nhau. Dù ClickHouse rất xuất sắc trong việc xử lý các bảng phẳng, nhưng việc đổ tất cả dữ liệu vào một bảng phẳng và phân vùng theo ngày là một sự lãng phí rất lớn về tài nguyên lưu trữ, chưa kể chi phí bảo trì đi kèm. Chi phí lưu trữ cao : Về mặt kiến trúc, ClickHouse được đặc trưng bởi sự kết hợp chặt chẽ giữa các nút lưu trữ và nút tính toán. Các thành phần của nó phụ thuộc lẫn nhau rất nhiều, làm tăng thêm rủi ro về sự mất ổn định của cụm. Ngoài ra, đối với các truy vấn được liên kết trên ClickHouse và Elaticsearch, chúng tôi phải xử lý rất nhiều sự cố kết nối. Điều đó thật tẻ nhạt. Chi phí bảo trì cao Chuyển sang Apache Doris , một cơ sở dữ liệu phân tích thời gian thực, tự hào có một số tính năng chính xác là những gì chúng tôi cần để giải quyết các vấn đề của mình: Apache Doris : Doris hỗ trợ nhiều mô hình dữ liệu khác nhau, trong đó Mô hình tổng hợp hỗ trợ cập nhật một phần cột theo thời gian thực. Dựa trên điều này, chúng tôi có thể nhập trực tiếp dữ liệu thô vào Doris và tạo các bảng phẳng ở đó. Quá trình nhập diễn ra như sau: Đầu tiên, chúng tôi sử dụng Spark để tải dữ liệu vào Kafka; sau đó, mọi dữ liệu gia tăng sẽ được cập nhật lên Doris và Elaticsearch thông qua Flink. Trong khi đó, Flink sẽ tổng hợp trước dữ liệu để giảm bớt gánh nặng cho Doris và Elaticsearch. Cập nhật một phần : Doris hỗ trợ truy vấn nối nhiều bảng và truy vấn được liên kết trên Hive, Iceberg, Hudi, MySQL và Elaticsearch. Điều này cho phép chúng tôi chia các bảng phẳng lớn thành các bảng nhỏ hơn và phân vùng chúng theo tần suất cập nhật. Lợi ích của việc này bao gồm giảm bớt gánh nặng lưu trữ và tăng thông lượng truy vấn. Chi phí lưu trữ : Doris có kiến trúc đơn giản và tương thích với giao thức MySQL. Việc triển khai Doris chỉ liên quan đến hai quy trình (FE và BE) mà không phụ thuộc vào các hệ thống khác, giúp dễ dàng vận hành và bảo trì. Ngoài ra, Doris hỗ trợ truy vấn các bảng dữ liệu ES bên ngoài. Nó có thể dễ dàng giao tiếp với siêu dữ liệu trong ES và tự động ánh xạ lược đồ bảng từ ES để chúng tôi có thể thực hiện các truy vấn trên dữ liệu Elaticsearch qua Doris mà không phải vật lộn với các kết nối phức tạp. Chi phí bảo trì Hơn nữa, Doris hỗ trợ nhiều phương thức nhập dữ liệu, bao gồm nhập hàng loạt từ bộ lưu trữ từ xa như HDFS và S3, đọc dữ liệu từ MySQL binlog và Kafka, đồng thời đồng bộ hóa dữ liệu theo thời gian thực hoặc nhập hàng loạt từ MySQL, Oracle và PostgreSQL. Nó đảm bảo tính khả dụng của dịch vụ và độ tin cậy của dữ liệu thông qua giao thức nhất quán và có khả năng tự động gỡ lỗi. Đây là tin tuyệt vời cho các nhà khai thác và bảo trì của chúng tôi. Nói theo thống kê, các tính năng này đã cắt giảm 42% chi phí lưu trữ và 40% chi phí phát triển của chúng tôi. Trong quá trình sử dụng Doris, chúng tôi đã nhận được rất nhiều sự hỗ trợ từ cộng đồng Apache Doris mã nguồn mở và sự giúp đỡ kịp thời từ nhóm SelectDB, hiện đang chạy phiên bản thương mại của Apache Doris. Cải thiện hơn nữa để phục vụ nhu cầu của chúng tôi Giới thiệu một lớp ngữ nghĩa Nói về bộ dữ liệu, về mặt sáng sủa, các nhà phân tích dữ liệu của chúng tôi được tự do xác định lại và kết hợp các thẻ và số liệu một cách thuận tiện. Nhưng mặt tối, tính không đồng nhất cao của thẻ và hệ thống số liệu dẫn đến khó khăn hơn trong việc sử dụng và quản lý chúng. Giải pháp của chúng tôi là giới thiệu một lớp ngữ nghĩa trong quy trình xử lý dữ liệu của chúng tôi. Lớp ngữ nghĩa là nơi tất cả các thuật ngữ kỹ thuật được dịch thành các khái niệm dễ hiểu hơn cho người dùng dữ liệu nội bộ của chúng tôi. Nói cách khác, chúng tôi đang biến các thẻ và chỉ số thành công dân hạng nhất để xác định và quản lý dữ liệu. Tại sao điều này sẽ giúp? Đối với các nhà phân tích dữ liệu, tất cả các thẻ và số liệu sẽ được tạo và chia sẻ ở lớp ngữ nghĩa nên sẽ ít nhầm lẫn hơn và hiệu quả cao hơn. Đối với người dùng dữ liệu, họ không còn cần tạo bộ dữ liệu của riêng mình hoặc tìm ra bộ dữ liệu nào phù hợp cho từng tình huống mà có thể chỉ cần thực hiện các truy vấn trên bộ thẻ và bộ số liệu được chỉ định của họ. Nâng cấp lớp ngữ nghĩa Việc xác định rõ ràng các thẻ và số liệu ở lớp ngữ nghĩa là không đủ. Để xây dựng một hệ thống xử lý dữ liệu được tiêu chuẩn hóa, mục tiêu tiếp theo của chúng tôi là đảm bảo định nghĩa nhất quán về thẻ và chỉ số trong toàn bộ quy trình xử lý dữ liệu. Vì lợi ích này, chúng tôi đã biến lớp ngữ nghĩa thành trung tâm của hệ thống quản lý dữ liệu của mình: Làm thế nào nó hoạt động? Tất cả logic tính toán trong TDW sẽ được xác định ở lớp ngữ nghĩa dưới dạng một thẻ hoặc chỉ số. Lớp ngữ nghĩa nhận các truy vấn logic từ phía ứng dụng, chọn một công cụ phù hợp và tạo SQL. Sau đó, nó sẽ gửi lệnh SQL tới TDW để thực hiện. Trong khi đó, nó cũng có thể gửi các tác vụ nhập dữ liệu và cấu hình tới Doris, đồng thời quyết định các chỉ số và thẻ nào sẽ được tăng tốc. Bằng cách này, chúng tôi đã làm cho các thẻ và chỉ số dễ quản lý hơn. Một điều khó hiểu là vì mỗi thẻ và chỉ số được xác định riêng lẻ nên chúng tôi đang gặp khó khăn với việc tự động hóa việc tạo câu lệnh SQL hợp lệ cho các truy vấn. Nếu bạn có bất kỳ ý tưởng nào về điều này, bạn rất được chào đón để nói chuyện với chúng tôi. Cung cấp toàn quyền cho Apache Doris Như bạn có thể thấy, Apache Doris đã đóng một vai trò quan trọng trong giải pháp của chúng tôi. Việc tối ưu hóa việc sử dụng Doris có thể cải thiện phần lớn hiệu quả xử lý dữ liệu tổng thể của chúng tôi. Vì vậy, trong phần này, chúng tôi sẽ chia sẻ với bạn những gì chúng tôi làm với Doris để tăng tốc độ truy vấn và nhập dữ liệu cũng như giảm chi phí. Những gì chúng ta muốn? Hiện tại, chúng tôi có hơn 800 thẻ và hơn 1300 chỉ số được lấy từ hơn 80 bảng nguồn trong TDW. Khi nhập dữ liệu từ TDW sang Doris, chúng tôi hy vọng đạt được: : Ngoài việc nhập dữ liệu ngoại tuyến T+1 truyền thống, chúng tôi yêu cầu gắn thẻ theo thời gian thực. Tính khả dụng trong thời gian thực : Mỗi bảng nguồn tạo dữ liệu thông qua tác vụ ETL của chính nó ở các tốc độ khác nhau và chỉ liên quan đến một phần của thẻ và số liệu, vì vậy chúng tôi yêu cầu hỗ trợ cập nhật một phần các cột. Cập nhật một phần : Chúng tôi cần thời gian phản hồi chỉ vài giây trong các tình huống nhắm mục tiêu, phân tích và báo cáo theo nhóm. Hiệu suất cao : Chúng tôi hy vọng giảm chi phí càng nhiều càng tốt. Chi phí thấp Chúng ta làm gì? Tạo các bảng phẳng trong Flink thay vì TDW Tạo bảng phẳng trong TDW có một vài nhược điểm: : TDW phải duy trì thêm một bảng phẳng ngoài hơn 80 bảng nguồn rời rạc. Đó là sự dư thừa rất lớn. Chi phí lưu trữ cao : Bất kỳ sự chậm trễ nào trong các bảng nguồn sẽ được tăng thêm và làm chậm toàn bộ liên kết dữ liệu. Tính kịp thời thực tế thấp : Để đạt được tính kịp thời thực tế sẽ cần thêm các nỗ lực và nguồn lực phát triển. Chi phí phát triển cao Ngược lại, tạo các bảng phẳng trong Doris dễ dàng hơn và ít tốn kém hơn. Quá trình này như sau: Sử dụng Spark để nhập dữ liệu mới vào Kafka theo cách ngoại tuyến. Sử dụng Flink để sử dụng dữ liệu Kafka. Tạo một bảng phẳng thông qua ID khóa chính. Nhập bàn phẳng vào Doris. Như được hiển thị bên dưới, Flink đã tổng hợp năm dòng dữ liệu, trong đó "ID"=1, thành một dòng trong Doris, giảm áp lực ghi dữ liệu lên Doris. Điều này có thể giảm phần lớn chi phí lưu trữ vì TDW không còn phải duy trì hai bản sao dữ liệu và KafKa chỉ cần lưu trữ dữ liệu mới đang chờ nhập. Ngoài ra, chúng tôi có thể thêm bất kỳ logic ETL nào chúng tôi muốn vào Flink và sử dụng lại nhiều logic phát triển để nhập dữ liệu ngoại tuyến và thời gian thực. Đặt tên cho các cột một cách thông minh Như chúng tôi đã đề cập, Mô hình tổng hợp của Doris cho phép cập nhật một phần các cột. Ở đây chúng tôi cung cấp phần giới thiệu đơn giản về các mô hình dữ liệu khác trong Doris để bạn tham khảo: : Điều này có thể áp dụng cho các tình huống yêu cầu tính duy nhất của khóa chính. Nó chỉ giữ dữ liệu mới nhất của cùng một ID khóa chính. (Theo những gì chúng tôi biết, cộng đồng Apache Doris cũng đang lên kế hoạch bao gồm cập nhật một phần các cột trong Mô hình duy nhất.) Mô hình duy nhất : Mô hình này lưu trữ tất cả dữ liệu gốc chính xác như hiện tại mà không có bất kỳ sự tổng hợp trước hoặc sao chép nào. Mô hình trùng lặp Sau khi xác định được mô hình dữ liệu, chúng tôi phải suy nghĩ về cách đặt tên cho các cột. Sử dụng các thẻ hoặc chỉ số làm tên cột không phải là lựa chọn vì: Ⅰ. Người dùng dữ liệu nội bộ của chúng tôi có thể cần đổi tên chỉ số hoặc thẻ, nhưng Doris 1.1.3 không hỗ trợ sửa đổi tên cột. Ⅱ. Thẻ có thể được sử dụng trực tuyến và ngoại tuyến thường xuyên. Nếu điều đó liên quan đến việc thêm và bớt các cột, nó sẽ không chỉ tốn thời gian mà còn gây bất lợi cho hiệu suất truy vấn. Thay vào đó, chúng tôi làm như sau: Để đổi tên thẻ và số liệu một cách linh hoạt, chúng tôi sử dụng bảng MySQL để lưu trữ siêu dữ liệu (tên, ID duy nhất trên toàn cầu, trạng thái, v.v.). Mọi thay đổi đối với tên sẽ chỉ xảy ra trong siêu dữ liệu nhưng sẽ không ảnh hưởng đến lược đồ bảng trong Doris. Ví dụ: nếu một được cung cấp ID là 4, nó sẽ được lưu trữ với tên cột là a4 trong Doris. Sau đó, nếu có liên quan đến một truy vấn, nó sẽ được chuyển đổi thành a4 trong SQL. song_name song_name Đối với các thẻ trực tuyến và ngoại tuyến, chúng tôi sắp xếp các thẻ dựa trên tần suất chúng được sử dụng. Những cái ít được sử dụng nhất sẽ được đánh dấu ngoại tuyến trong siêu dữ liệu của chúng. Sẽ không có dữ liệu mới nào được đặt trong các thẻ ngoại tuyến nhưng dữ liệu hiện có trong các thẻ đó sẽ vẫn khả dụng. Để tính khả dụng theo thời gian thực của các chỉ số và thẻ mới được thêm vào, chúng tôi tạo sẵn một số cột ID trong bảng Doris dựa trên ánh xạ ID tên. Các cột ID dành riêng này sẽ được phân bổ cho các thẻ và chỉ số mới được thêm vào. Vì vậy, chúng ta có thể tránh thay đổi lược đồ bảng và các chi phí phát sinh. Kinh nghiệm của chúng tôi cho thấy rằng chỉ 10 phút sau khi các thẻ và số liệu được thêm vào, dữ liệu bên dưới chúng có thể có sẵn. Đáng chú ý, Doris 1.2.0 được phát hành gần đây hỗ trợ Thay đổi lược đồ ánh sáng, có nghĩa là để thêm hoặc xóa các cột, bạn chỉ cần sửa đổi siêu dữ liệu trong FE. Ngoài ra, bạn có thể đổi tên các cột trong bảng dữ liệu miễn là bạn đã bật Thay đổi giản đồ nhẹ cho các bảng. Đây là một tiết kiệm rắc rối lớn cho chúng tôi. Tối ưu hóa ngày viết Dưới đây là một vài phương pháp đã giúp giảm 75% thời gian nhập dữ liệu ngoại tuyến hàng ngày của chúng tôi và điểm nén CUMU của chúng tôi từ 600+ xuống 100. Flink tổng hợp trước: như đã đề cập ở trên. Tự động định cỡ lô viết: Để giảm mức sử dụng tài nguyên Flink, chúng tôi cho phép ghi dữ liệu trong một Chủ đề Kafka vào các bảng Doris khác nhau và nhận ra sự thay đổi tự động kích thước lô dựa trên lượng dữ liệu. Tối ưu hóa ghi dữ liệu Doris: tinh chỉnh kích thước của máy tính bảng và thùng cũng như các tham số nén cho từng kịch bản: max_XXXX_compaction_thread max_cumulative_compaction_num_singleton_deltas Tối ưu hóa logic cam kết BE: tiến hành lưu trữ danh sách BE vào bộ nhớ đệm thường xuyên, cam kết chúng vào các nút BE theo lô và sử dụng mức độ chi tiết cân bằng tải tốt hơn. Sử dụng Dori-on-ES trong Truy vấn Khoảng 60% truy vấn dữ liệu của chúng tôi liên quan đến nhắm mục tiêu theo nhóm. Nhắm mục tiêu theo nhóm là tìm dữ liệu mục tiêu của chúng tôi bằng cách sử dụng một bộ thẻ làm bộ lọc. Nó đặt ra một số yêu cầu đối với kiến trúc xử lý dữ liệu của chúng tôi: Nhắm mục tiêu theo nhóm liên quan đến người dùng APP có thể liên quan đến logic rất phức tạp. Điều đó có nghĩa là hệ thống phải hỗ trợ đồng thời hàng trăm thẻ làm bộ lọc. Hầu hết các trường hợp nhắm mục tiêu theo nhóm chỉ yêu cầu dữ liệu thẻ mới nhất. Tuy nhiên, truy vấn số liệu cần hỗ trợ dữ liệu lịch sử. Người dùng dữ liệu có thể cần thực hiện thêm phân tích tổng hợp về dữ liệu số liệu sau khi nhắm mục tiêu theo nhóm. Người dùng dữ liệu cũng có thể cần thực hiện các truy vấn chi tiết về thẻ và chỉ số sau khi nhắm mục tiêu theo nhóm. Sau khi cân nhắc, chúng tôi quyết định áp dụng Doris-on-ES. Doris là nơi chúng tôi lưu trữ dữ liệu số liệu cho từng kịch bản dưới dạng bảng phân vùng, trong khi Elaticsearch lưu trữ tất cả dữ liệu thẻ. Giải pháp Doris-on-ES kết hợp khả năng lập kế hoạch truy vấn phân tán của Doris và khả năng tìm kiếm toàn văn của Elaticsearch. Mẫu truy vấn như sau: SELECT tag, agg(metric) FROM Doris WHERE id in (select id from Es where tagFilter) GROUP BY tag Như được hiển thị, dữ liệu ID nằm trong Elaticsearch sẽ được sử dụng trong truy vấn phụ trong Doris để phân tích số liệu. Trong thực tế, chúng tôi thấy rằng thời gian phản hồi truy vấn có liên quan đến quy mô của nhóm mục tiêu. Nếu nhóm mục tiêu chứa hơn một triệu đối tượng, truy vấn sẽ mất tối đa 60 giây. Nếu nó thậm chí còn lớn hơn, có thể xảy ra lỗi hết thời gian chờ. Sau khi điều tra, chúng tôi đã xác định được hai yếu tố gây lãng phí thời gian lớn nhất: I. Khi Doris BE lấy dữ liệu từ Elaticsearch (1024 dòng mỗi lần theo mặc định), đối với một nhóm mục tiêu gồm hơn một triệu đối tượng, chi phí I/O của mạng có thể rất lớn. II. Sau khi lấy dữ liệu, Doris BE cần tiến hành các hoạt động Tham gia với các bảng số liệu cục bộ thông qua SHUFFLE/BROADCAST, việc này có thể tốn rất nhiều chi phí. Vì vậy, chúng tôi thực hiện các tối ưu hóa sau: Thêm biến phiên truy vấn chỉ định có bật tối ưu hóa hay không. es_optimize Khi ghi dữ liệu vào ES, hãy thêm một cột BK để lưu số nhóm sau khi ID khóa chính được băm. Thuật toán giống như thuật toán xô trong Doris (CRC32). Sử dụng Doris BE để tạo kế hoạch thực hiện Bucket Join, gửi số bucket tới BE ScanNode và đẩy nó xuống ES. Sử dụng ES để nén dữ liệu được truy vấn; biến nhiều lần tìm nạp dữ liệu thành một và giảm chi phí I/O của mạng. Đảm bảo rằng Doris BE chỉ lấy dữ liệu của các nhóm liên quan đến bảng chỉ số cục bộ và tiến hành trực tiếp các hoạt động Tham gia cục bộ để tránh xáo trộn dữ liệu giữa các Doris BE. Do đó, chúng tôi giảm thời gian phản hồi truy vấn cho nhắm mục tiêu theo nhóm lớn từ 60 giây xuống còn 3,7 giây đáng ngạc nhiên. Thông tin cộng đồng cho thấy Doris sẽ hỗ trợ lập chỉ mục đảo ngược kể từ phiên bản 2.0.0 sắp được phát hành. Với phiên bản mới này, chúng tôi sẽ có thể tiến hành tìm kiếm toàn văn trên các loại văn bản, lọc tương đương hoặc phạm vi của văn bản, số và ngày giờ, đồng thời kết hợp thuận tiện logic AND, OR, NOT trong lọc vì lập chỉ mục đảo ngược hỗ trợ các loại mảng. Tính năng mới này của Doris dự kiến sẽ mang lại hiệu suất tốt hơn 3~5 lần so với Elaticsearch trên cùng một nhiệm vụ. Tinh chỉnh quản lý dữ liệu Khả năng phân tách dữ liệu nóng và lạnh của Doris cung cấp nền tảng cho các chiến lược giảm chi phí của chúng tôi trong quá trình xử lý dữ liệu. Dựa trên cơ chế TTL của Doris, chúng tôi chỉ lưu trữ dữ liệu của năm hiện tại trong Doris và đưa dữ liệu lịch sử trước đó vào TDW để giảm chi phí lưu trữ. Chúng tôi thay đổi số lượng bản sao cho các phân vùng dữ liệu khác nhau. Ví dụ: chúng tôi đặt ba bản sao cho dữ liệu của ba tháng gần đây, được sử dụng thường xuyên, một bản sao cho dữ liệu cũ hơn sáu tháng và hai bản sao cho dữ liệu ở giữa. Doris hỗ trợ biến dữ liệu nóng thành dữ liệu lạnh nên chúng tôi chỉ lưu trữ dữ liệu của bảy ngày qua trong SSD và chuyển dữ liệu cũ hơn sang HDD để lưu trữ ít tốn kém hơn. Phần kết luận Cảm ơn bạn đã cuộn xuống đây và hoàn thành bài đọc dài này. Chúng tôi đã chia sẻ những niềm vui và nước mắt, những bài học kinh nghiệm và một số phương pháp thực hành có thể có giá trị đối với bạn trong quá trình chuyển đổi từ ClickHouse sang Doris. Chúng tôi thực sự đánh giá cao sự trợ giúp từ cộng đồng Apache Doris và nhóm SelectDB, nhưng chúng tôi vẫn có thể theo đuổi họ trong một thời gian vì chúng tôi cố gắng nhận dạng tự động dữ liệu nóng và lạnh, tính toán trước các thẻ/số liệu thường dùng, đơn giản hóa logic mã bằng cách sử dụng Chế độ xem cụ thể hóa, v.v.
