OLAP do LLM hỗ trợ: Trải nghiệm Tencent với Apache Doris

Sáu tháng trước, tôi đã viết về lý do tại sao chúng tôi thay thế ClickHouse bằng Apache Doris làm công cụ OLAP cho hệ thống quản lý dữ liệu của chúng tôi. Hồi đó, chúng tôi đang gặp khó khăn với việc tự động tạo các câu lệnh SQL. Nhiều ngày trôi qua, chúng tôi đã đạt được những tiến bộ đủ lớn để làm tài liệu tham khảo cho bạn, vì vậy tôi lại ở đây.

Chúng tôi đã áp dụng Mô hình ngôn ngữ lớn (LLM) để hỗ trợ các dịch vụ OLAP dựa trên Doris của chúng tôi.

LLM + OLAP

Động lực của chúng tôi là giúp nhân viên nội bộ của chúng tôi thoát khỏi quá trình học tập khó khăn khi viết SQL. Vì vậy, chúng tôi đã sử dụng LLM làm trung gian. Nó chuyển đổi các câu hỏi ngôn ngữ tự nhiên thành các câu lệnh SQL và gửi SQL đến công cụ OLAP để thực thi.

Giống như mọi trải nghiệm liên quan đến AI, chúng tôi đã gặp phải một số xích mích:

1. LLM không hiểu các thuật ngữ dữ liệu, như "trường", "hàng", "cột" và "bảng". Thay vào đó, họ có thể dịch một cách hoàn hảo các thuật ngữ kinh doanh như "thu nhập doanh nghiệp" và "DAU", về cơ bản là nội dung của các trường/hàng/cột. Điều đó có nghĩa là nó chỉ có thể hoạt động tốt nếu các nhà phân tích sử dụng từ chính xác để chỉ số liệu họ cần khi nhập câu hỏi.

   
   

2. LLM chúng tôi đang sử dụng có tốc độ suy luận chậm. Phải mất hơn 10 giây để trả lời. Vì nó tính phí bằng token nên hiệu quả chi phí trở thành một vấn đề.

   
   

3. Mặc dù LLM được đào tạo trên một bộ sưu tập lớn các bộ dữ liệu công cộng nhưng nó lại thiếu thông tin về kiến thức thích hợp. Trong trường hợp của chúng tôi, LLM cực kỳ xa lạ với các bài hát indie, vì vậy ngay cả khi các bài hát đó được đưa vào cơ sở dữ liệu của chúng tôi, LLM sẽ không thể xác định chúng một cách chính xác.

   
   

4. Đôi khi các câu hỏi đầu vào của chúng tôi yêu cầu thông tin pháp lý, chính trị, tài chính và quy định đầy đủ và mới nhất, khó có thể đưa vào tập dữ liệu đào tạo hoặc cơ sở kiến thức. Chúng ta cần kết nối LLM với cơ sở thông tin rộng hơn để thực hiện các nhiệm vụ đa dạng hơn.

   
   

Chúng tôi giải quyết từng vấn đề một.

1. Lớp ngữ nghĩa

Đối với vấn đề số 1, chúng tôi giới thiệu một lớp ngữ nghĩa giữa LLM và công cụ OLAP. Lớp này dịch các thuật ngữ kinh doanh sang các trường dữ liệu tương ứng. Nó có thể xác định các điều kiện lọc dữ liệu từ các từ ngữ ngôn ngữ tự nhiên khác nhau, liên hệ chúng với các số liệu liên quan và sau đó tạo các câu lệnh SQL.

Ngoài ra, lớp ngữ nghĩa còn có thể tối ưu hóa logic tính toán. Khi các nhà phân tích nhập một câu hỏi liên quan đến một truy vấn phức tạp, chẳng hạn như nối nhiều bảng, lớp ngữ nghĩa có thể chia câu hỏi đó thành nhiều truy vấn một bảng để giảm sự biến dạng ngữ nghĩa.

2. Quy tắc phân tích cú pháp LLM

Để tăng hiệu quả chi phí khi sử dụng LLM, chúng tôi đánh giá độ phức tạp tính toán của tất cả các kịch bản, chẳng hạn như tính toán số liệu, truy xuất bản ghi chi tiết và phân đoạn người dùng. Sau đó, chúng tôi tạo các quy tắc và dành riêng bước phân tích cú pháp LLM cho các tác vụ phức tạp. Điều đó có nghĩa là đối với các tác vụ tính toán đơn giản, nó sẽ bỏ qua việc phân tích cú pháp.

Ví dụ: khi nhà phân tích nhập "cho tôi biết thu nhập của các nền tảng âm nhạc chính", LLM xác định rằng câu hỏi này chỉ đòi hỏi một số số liệu hoặc thứ nguyên, do đó, nó sẽ không phân tích cú pháp thêm mà gửi thẳng để tạo và thực thi SQL. Điều này phần lớn có thể rút ngắn thời gian phản hồi truy vấn và giảm chi phí API.

3. Schema Mapper và cơ sở kiến thức bên ngoài

Để trao quyền cho LLM với kiến thức thích hợp, chúng tôi đã thêm Trình ánh xạ lược đồ ngược dòng từ LLM. Schema Mapper ánh xạ câu hỏi đầu vào tới cơ sở kiến thức bên ngoài và sau đó LLM sẽ thực hiện phân tích cú pháp.

Chúng tôi liên tục thử nghiệm và tối ưu hóa Schema Mapper. Chúng tôi phân loại và xếp hạng nội dung trong cơ sở kiến thức bên ngoài, đồng thời thực hiện nhiều cấp độ ánh xạ khác nhau (ánh xạ toàn văn bản và ánh xạ mờ) để cho phép phân tích cú pháp ngữ nghĩa tốt hơn.

4. Plugin

Chúng tôi đã sử dụng các plugin để kết nối LLM với nhiều trường thông tin hơn và chúng tôi có các phương pháp tích hợp khác nhau cho các loại plugin khác nhau:

• Nhúng các tệp cục bộ : Điều này đặc biệt hữu ích khi chúng ta cần "dạy" LLM những chính sách quy định mới nhất, thường là các tệp văn bản. Đầu tiên, hệ thống vector hóa tệp văn bản cục bộ, thực hiện tìm kiếm ngữ nghĩa để tìm các thuật ngữ trùng khớp hoặc tương tự trong tệp cục bộ, trích xuất nội dung liên quan và đưa chúng vào cửa sổ phân tích cú pháp LLM để tạo đầu ra.

  
  

• Plugin của bên thứ ba : Thị trường có đầy đủ các plugin của bên thứ ba được thiết kế cho mọi loại lĩnh vực. Với họ, LLM có thể giải quyết các chủ đề trên phạm vi rộng. Mỗi plugin có chức năng nhắc nhở và gọi điện riêng. Sau khi câu hỏi đầu vào xuất hiện lời nhắc, plugin có liên quan sẽ được gọi.

Sau khi chúng tôi hoàn thành bốn tối ưu hóa trên, hệ thống SuperSonic sẽ ra đời.

Khung SuperSonic

Bây giờ hãy để tôi hướng dẫn bạn qua khuôn khổ này:

• Một nhà phân tích nhập một câu hỏi.

  
  

• Schema Mapper ánh xạ câu hỏi tới cơ sở kiến thức bên ngoài.

  
  

• Nếu có các trường trùng khớp trong cơ sở kiến thức bên ngoài, câu hỏi sẽ không được LLM phân tích cú pháp. Thay vào đó, công thức tính toán số liệu sẽ kích hoạt công cụ OLAP bắt đầu truy vấn. Nếu không có trường phù hợp, câu hỏi sẽ nhập LLM.

  
  

• Dựa trên các quy tắc được xác định trước, LLM đánh giá mức độ phức tạp của câu hỏi. Nếu đó là một truy vấn đơn giản, nó sẽ chuyển trực tiếp đến công cụ OLAP; nếu đó là một truy vấn phức tạp, nó sẽ được phân tích cú pháp ngữ nghĩa và chuyển đổi thành câu lệnh DSL.

  
  

• Ở Lớp ngữ nghĩa, câu lệnh DSL sẽ được phân chia dựa trên kịch bản truy vấn của nó. Ví dụ: nếu đó là truy vấn nối nhiều bảng, lớp này sẽ tạo ra nhiều câu lệnh SQL truy vấn một bảng.

• Nếu câu hỏi liên quan đến kiến thức bên ngoài, LLM sẽ gọi plugin của bên thứ ba.

Ví dụ:

Để trả lời liệu một bài hát nhất định có thể được biểu diễn trên các chương trình tạp kỹ hay không, hệ thống sẽ truy xuất kho dữ liệu OLAP để biết thông tin chi tiết về bài hát đó và hiển thị kết quả từ plugin Truy vấn sử dụng thương mại của bên thứ ba.

Kiến trúc OLAP

Đối với phần OLAP của khung này, sau nhiều vòng phát triển kiến trúc, quy trình OLAP hiện tại của chúng tôi trông như thế này.

Dữ liệu thô được sắp xếp thành các thẻ và số liệu do các nhà phân tích xác định tùy chỉnh. Các thẻ và số liệu được quản lý thống nhất để tránh các định nghĩa không nhất quán. Sau đó, chúng được kết hợp thành các bộ thẻ và bộ số liệu khác nhau cho các truy vấn khác nhau.

Chúng tôi đã rút ra hai bài học chính cho bạn từ trải nghiệm tối ưu hóa kiến trúc của chúng tôi.

1. Hợp lý hóa các liên kết

Trước khi sử dụng Apache Doris, chúng tôi đã từng sử dụng ClickHouse để tăng tốc tính toán thẻ và số liệu cũng như Elaticsearch để xử lý dữ liệu thứ nguyên. Đó là hai công cụ phân tích và yêu cầu chúng tôi điều chỉnh các câu lệnh truy vấn cho phù hợp với cả hai công cụ đó. Đó là mức độ bảo trì cao.

Do đó, chúng tôi đã thay thế ClickHouse bằng Apache Doris và sử dụng chức năng Danh mục Elaticsearch để kết nối dữ liệu Elaticsearch với Doris. Bằng cách này, chúng tôi biến Doris thành cổng truy vấn thống nhất của mình.

2. Chia bàn phẳng

Trong các phiên bản đầu tiên của kiến trúc OLAP, chúng tôi thường đưa dữ liệu vào các bảng phẳng, điều này khiến mọi việc trở nên phức tạp. Có một điều, các bảng phẳng đã hấp thụ tất cả độ trễ ghi từ các luồng ngược dòng và điều đó làm tăng thêm sự mất mát đáng kể về tính kịp thời của dữ liệu. Mặt khác, 50% dữ liệu trong bảng phẳng là dữ liệu thứ nguyên, hiếm khi được cập nhật. Mỗi chiếc bàn phẳng mới đều có một số dữ liệu chiều cồng kềnh tiêu tốn nhiều không gian lưu trữ.

Do đó, chúng tôi chia các bảng phẳng thành bảng số liệu và bảng thứ nguyên. Vì chúng được cập nhật theo các bước khác nhau nên chúng tôi đưa chúng vào các mô hình dữ liệu khác nhau.

• Bảng số liệu : Chúng tôi sắp xếp dữ liệu số liệu trong mô hình Khóa tổng hợp của Apache Doris, có nghĩa là dữ liệu mới sẽ được hợp nhất với dữ liệu cũ bằng SUM, MAX, MIN, v.v.

  
  

• Bảng thứ nguyên : Các bảng này nằm trong mô hình Unique Key của Apache Doris, nghĩa là bản ghi dữ liệu mới sẽ thay thế bản ghi cũ. Điều này có thể tăng hiệu suất đáng kể trong các kịch bản truy vấn của chúng tôi.

  
  

Bạn có thể hỏi, điều này có gây rắc rối trong truy vấn không, vì hầu hết các truy vấn đều yêu cầu dữ liệu từ cả hai loại bảng? Đừng lo lắng, chúng tôi giải quyết vấn đề đó bằng tính năng Rollup của Doris. Trên cơ sở các bảng cơ sở, chúng ta có thể chọn các thứ nguyên mà chúng ta cần để tạo các chế độ xem Tổng hợp, chế độ xem này sẽ tự động thực thi GROUP BY . Điều này giúp chúng tôi giảm bớt nhu cầu xác định thẻ cho từng chế độ xem Tổng hợp và tăng tốc độ truy vấn phần lớn.

Thủ thuật khác

Theo kinh nghiệm của chúng tôi với Apache Doris, chúng tôi cũng nhận thấy một số chức năng khác rất hữu ích, vì vậy tôi cũng liệt kê chúng ở đây cho bạn:

1. Chế độ xem cụ thể hóa

Chế độ xem cụ thể hóa là một tập dữ liệu được tính toán trước. Đó là một cách để tăng tốc truy vấn khi bạn thường xuyên cần truy cập dữ liệu ở một số kích thước nhất định. Trong những trường hợp này, chúng tôi xác định các thẻ và chỉ số phái sinh dựa trên các thẻ gốc. Ví dụ: chúng tôi tạo chỉ số dẫn xuất bằng cách kết hợp Chỉ số 1, Chỉ số 2 và Chỉ số 3: sum(m1+m2+m3) . Sau đó, chúng ta có thể tạo Chế độ xem cụ thể hóa cho nó. Theo lịch phát hành Doris, phiên bản 2.1 sẽ hỗ trợ Chế độ xem vật chất hóa nhiều bảng và chúng tôi rất mong chờ điều đó.

2. Đầu nối Flink-Doris

Điều này nhằm đảm bảo Chính xác một lần trong quá trình nhập dữ liệu. Flink-Doris-Connector triển khai cơ chế điểm kiểm tra và cam kết hai giai đoạn, đồng thời cho phép đồng bộ hóa dữ liệu tự động từ cơ sở dữ liệu quan hệ sang Doris.

3. Nén chặt

Khi số lượng tác vụ tổng hợp hoặc khối lượng dữ liệu trở nên quá tải đối với Flink, quá trình nén dữ liệu có thể có độ trễ rất lớn. Chúng tôi giải quyết vấn đề đó bằng Nén dọc và Nén phân đoạn. Nén dọc chỉ hỗ trợ tải một phần của cột nên có thể giảm mức tiêu thụ lưu trữ khi nén các bàn phẳng. Nén phân đoạn có thể tránh tạo ra quá nhiều phân đoạn trong quá trình ghi dữ liệu và cho phép nén trong khi ghi đồng thời.

Cái gì tiếp theo

Với mục đích giảm chi phí và tăng tính khả dụng của dịch vụ, chúng tôi dự định thử nghiệm tính năng Phân tách tính toán lưu trữ và Sao chép chéo cụm của Doris mới được phát hành, đồng thời chúng tôi tiếp thu mọi ý tưởng và thông tin đầu vào về khung SuperSonic và dự án Apache Doris.