Tại sao SIGQ lại chuyển từ BigQuery sang ClickHouse?

Công ty Cổ phần SIGQ cung cấp “Incident Lake” – một trợ lý AI chuyên về quản lý sự cố. Ban đầu, công ty này sử dụng BigQuery làm nền tảng dữ liệu, nhưng khoảng nửa năm trước, họ đã chuyển sang ClickHouse và hiện đang vận hành chính thức khối lượng công việc của nhiều khách hàng trên nền tảng ClickHouse.

Vào cuối tháng 4, tại một địa điểm nào đó ở Tokyo, đã diễn ra cuộc đối thoại giữa ông Alexey Milovidov (sau đây gọi là Alexey), đồng sáng lập kiêm Giám đốc Công nghệ (CTO) của ClickHouse, và ông Takaaki Kanetsuki (sau đây gọi là Kanetsuki), Giám đốc Điều hành Công ty Cổ phần SIGQ. Bài viết này sẽ tìm hiểu cách ClickHouse đã giải quyết những thách thức mà SIGQ đang phải đối mặt, cũng như bối cảnh của quá trình chuyển đổi này.

Bài viết này là phần đầu của loạt bài phỏng vấn. Để đọc phần tiếp theo, vui lòng xem bài “Khám phá vai trò của SRE trong kỷ nguyên AI thông qua dữ liệu và quản lý sự cố ”.

Quá trình các kỹ sư C++ tạo ra cơ sở dữ liệu phân tích lưu lượng truy cập thuộc hàng lớn nhất thế giới

Câu hỏi: Anh Alexey đã tiếp tục phát triển ClickHouse từ năm 2009, nhưng ban đầu, điều gì đã khiến anh bắt đầu tham gia vào lĩnh vực cơ sở dữ liệu? Xin anh chia sẻ về điều này, bao gồm cả những thách thức mà anh đã phải đối mặt ban đầu.

Alexey: Ban đầu, tôi không phải là nhà phát triển cơ sở dữ liệu, mà là kỹ sư C++ tại một công ty lớn. Công việc của tôi là phụ trách một dịch vụ cung cấp báo cáo phân tích người truy cập cho các nhà điều hành trang web. Tại đây, tôi đã phải đối mặt với một thách thức lớn. Trên một nền tảng có quy mô với hàng nghìn tỷ sự kiện xảy ra mỗi ngày, chúng tôi phải cho phép tùy chỉnh báo cáo gần như không giới hạn và cung cấp chức năng giúp người dùng có thể thu thập bất kỳ số liệu tổng hợp nào họ mong muốn. Hơn nữa, hệ thống còn phải đảm bảo tính thời gian thực đến mức kết quả phải hiển thị ngay lập tức ngay khi người dùng định nghĩa báo cáo.

Tất nhiên, MySQL không thể đáp ứng được trường hợp sử dụng này, nên tôi bắt đầu thử nghiệm nhiều loại cơ sở dữ liệu khác nhau. Trong quá trình đó, tôi biết đến sự tồn tại của cơ sở dữ liệu định hướng cột và nền tảng dữ liệu lớn, đồng thời so sánh các sản phẩm hiện có từ góc độ hiệu năng, tỷ lệ nén và chi phí. Kết quả là, tôi bắt đầu nghĩ rằng mình có thể tự phát triển một hệ thống lưu trữ định hướng cột chuyên biệt cho các tác vụ tổng hợp, sắp xếp và lọc dữ liệu. Sản phẩm được phát triển từ ý tưởng này là nguyên mẫu có tên “OLAPServer”, và tôi nhận thấy nó hoạt động hiệu quả hơn so với các hệ thống hiện có.

※OLAP (OnLine Analytical Processing): Công nghệ phân tích đa chiều tức thì lượng dữ liệu khổng lồ được lưu trữ trong kho dữ liệu (data warehouse) và các hệ thống tương tự. Ví dụ, công nghệ này được sử dụng để phân tích dữ liệu doanh thu theo nhiều trục khác nhau như khu vực hay thời gian.

Q. Vậy là điều đó đã dẫn đến sự ra đời của ClickHouse ngày nay phải không?

Alexey: Vào thời điểm đó, tôi chưa có một tầm nhìn rõ ràng nào về ClickHouse, nhưng trong đầu tôi đã có ý tưởng mơ hồ là muốn xây dựng một hệ thống đa năng, có thể xử lý nhiều loại truy vấn khác nhau. Ban đầu, tôi dành thời gian rảnh rỗi để phát triển dự án, sau đó dần dần dành cả thời gian làm việc cho nó, và phiên bản đầu tiên của ClickHouse đã được phát hành vào năm 2012. Hệ thống này không chỉ được đội ngũ của tôi sử dụng mà còn được các bộ phận khác trong công ty, như thương mại điện tử và phân tích kinh doanh, áp dụng.Sau đó, khi tham gia các hội nghị công nghệ, tôi nhận ra rằng nhu cầu đối với loại cơ sở dữ liệu này là cực kỳ lớn. Rất nhiều kỹ sư tại các công ty khác cũng đang tự phát triển các nguyên mẫu tương tự như của tôi. Tôi tin chắc rằng dự án này cần được phát hành dưới dạng mã nguồn mở, nên đã thuyết phục công ty và chính thức công bố vào năm 2016. Tháng 6 năm nay sẽ đánh dấu đúng 10 năm kể từ khi ClickHouse được phát hành dưới dạng mã nguồn mở.

Những hạn chế của BigQuery mà Incident Lake phải đối mặt

Câu hỏi: Gần đây, SIGQ đã chuyển nền tảng dữ liệu của Incident Lake từ BigQuery sang ClickHouse Cloud. Việc chuyển đổi này nhằm giải quyết những thách thức nào?

Kanetsuki: Trước tiên, tôi sẽ giới thiệu ngắn gọn về các đặc điểm của Incident Lake. Incident Lake là một nền tảng quản lý sự cố tích hợp trí tuệ nhân tạo (AI). Trong khi nhiều công cụ hiện có được thiết kế dành cho các nhà phát triển, công cụ của chúng tôi lại tập trung vào đội ngũ quản lý chịu trách nhiệm điều phối việc xử lý sự cố.

Tại hiện trường xử lý sự cố, các yêu cầu xử lý sự cố và lập báo cáo liên tục được gửi đến, nhưng đây là những công việc gây áp lực rất lớn. Do đó, tác nhân AI của Incident Lake sẽ hỗ trợ các công việc như tạo dòng thời gian và lập báo cáo. Vì vậy, khi sự cố xảy ra, Incident Lake không chỉ thu thập nhật ký lỗi mà còn thu thập cả nhật ký giao tiếp từ các nền tảng như Slack và Teams.

Alexey: Ý anh là sẽ sử dụng dữ liệu thu thập được để tự động tạo bản tóm tắt, phải không?

Kanetsuki: Đúng vậy. Và yếu tố quan trọng nhất để hiện thực hóa cơ chế này chính là độ mới của dữ liệu. Nếu không thể xác định được liệu dữ liệu hiện tại có chính xác hay không, hay thông tin nào là mới nhất, thì sự hỗ trợ từ các tác nhân AI sẽ trở nên không đáng tin cậy ngay từ đầu.

Chúng tôi lưu trữ hai loại dữ liệu. Đó là dữ liệu thô, chẳng hạn như tin nhắn của người dùng, và dữ liệu đã được vectơ hóa. Tất cả dữ liệu và báo cáo được tạo ra đều được vectơ hóa để đạt được khả năng tìm kiếm gần giống với tìm kiếm ngữ nghĩa.

Để theo dõi tình hình ứng phó với sự cố đang thay đổi từng giây từng phút, tính cập nhật của dữ liệu là vô cùng quan trọng. Do đó, cần phải cập nhật dữ liệu đã thu thập theo dòng thời gian mới nhất.

Tuy nhiên, BigQuery vào thời điểm đó có một hạn chế là không thể cập nhật dữ liệu ngay sau khi chèn, điều này đã trở thành một thách thức trong việc duy trì tính mới mẻ của dữ liệu. Do đó, chúng tôi đã quyết định nhân cơ hội này để chuyển sang ClickHouse Cloud.

Alexey: Trong số người dùng ClickHouse, có rất nhiều doanh nghiệp đã sử dụng BigQuery trong nhiều năm. Cũng giống như SIGQ, nhiều doanh nghiệp chuyển sang ClickHouse vì lý do độ trễ. Ngoài ra, do ClickHouse có khả năng làm được nhiều việc hơn, nên cũng có nhiều doanh nghiệp chuyển sang vì tính năng phong phú hơn. Bên cạnh đó, vấn đề chi phí cũng rất quan trọng. BigQuery áp dụng mô hình tính phí theo lượng sử dụng, trong đó phí được tính cho từng truy vấn và theo khối lượng dữ liệu được xử lý.Điều này phù hợp khi người dùng thỉnh thoảng thực hiện truy vấn, nhưng không phù hợp lắm với những người dùng thực hiện số lượng lớn truy vấn, đặc biệt là các tác nhân AI. Các tác nhân AI thường thực hiện 10 đến 20 truy vấn chỉ trong một yêu cầu, dẫn đến chi phí trên BigQuery tăng vọt.

Câu hỏi: Quý vị đang tận dụng các tính năng của ClickHouse như thế nào tại Incident Lake? Đặc biệt, xin vui lòng cho biết nếu có tính năng nào mà ông Kanetsuki cảm thấy thực sự hữu ích.

Kanetsuki: Ví dụ như tính năng tìm kiếm vectơ xấp xỉ của ClickHouse. Tại Incident Lake, chúng tôi đang tận dụng tính năng này để thu thập các sự cố tương tự.

Trong quá trình xử lý sự cố, việc xác định xem đã từng có trường hợp tương tự nào xảy ra trong quá khứ hay chưa là rất quan trọng. Tuy nhiên, trên thực tế, việc tìm kiếm các sự cố tương tự chỉ bằng phương pháp tìm kiếm vectơ đơn thuần là rất khó khăn. Do đó, tại Incident Lake, chúng tôi tận dụng tính năng tìm kiếm vectơ xấp xỉ của ClickHouse để thể hiện mức độ tương đồng dưới dạng số liệu. Tính năng hiển thị mức độ tương đồng và tìm kiếm sự cố tương tự này đã nhận được phản hồi rất tích cực từ phía khách hàng.

Trước khi chuyển sang ClickHouse, chúng tôi đã tự triển khai tính toán độ tương đồng, nhưng đây là một tác vụ rất nặng. Bằng cách tận dụng tính năng tìm kiếm vectơ xấp xỉ của ClickHouse, chúng tôi cảm thấy đã nâng cao được giá trị của Incident Lake đồng thời giảm đáng kể tải hệ thống.

Câu hỏi: Tôi được biết SIGQ là công ty đầu tiên tại Nhật Bản áp dụng tính năng tìm kiếm vectơ xấp xỉ của ClickHouse.

Kanetsuki: Vâng. Chúng tôi đã bắt đầu sử dụng tính năng mới này ngay từ ngày nó được triển khai trên ClickHouse Cloud. Thực ra, đây là tính năng mà chúng tôi đã chờ đợi từ lâu, đến mức chúng tôi còn liên hệ với các thành viên của ClickHouse để hỏi: “Khi nào thì có thể sử dụng được?”

Alexey: Sự hiện diện của những khách hàng như vậy thực sự là niềm vui lớn đối với chúng tôi. Chúng tôi luôn tìm kiếm các đối tác kỹ thuật sẵn sàng kiểm chứng các tính năng mới trên khối lượng công việc thực tế trong môi trường kinh doanh. Có lẽ chính sự nhiệt tình của anh Kanetsuki đã trở thành động lực giúp chúng tôi ra mắt tính năng này trên ClickHouse Cloud.

Tại sao các công ty AI hàng đầu thế giới lại chọn ClickHouse?

Câu hỏi: ClickHouse được biết đến là một cơ sở dữ liệu phân tích tốc độ cao, có khả năng trả về kết quả truy vấn đối với dữ liệu quy mô petabyte hay các dữ liệu đo lường phức tạp chỉ trong thời gian dưới một giây. Tại sao ClickHouse lại có thể đáp ứng được cả quy mô dữ liệu lớn như vậy lẫn tính thời gian thực?

Alexey: Trước hết, cần lưu ý rằng trong ClickHouse, không cần thiết phải tách biệt dữ liệu giao dịch (OLTP) và dữ liệu phân tích (OLAP). Một trong những hiểu lầm phổ biến về dữ liệu lớn là quan điểm cho rằng cần phải quản lý riêng biệt dữ liệu giao dịch và dữ liệu mới nhất dùng cho phân tích.

※OLTP (Online Transaction Processing): Công nghệ nhằm mục đích đọc và ghi chính xác một lượng nhỏ dữ liệu (giao dịch), chẳng hạn như chuyển khoản ngân hàng hay đặt hàng trên các trang thương mại điện tử

Ví dụ, quan niệm cho rằng “nên lưu trữ toàn bộ dữ liệu lịch sử trên S3 hoặc RDBMS, và chỉ đưa một lượng nhỏ dữ liệu mới nhất cần thiết cho phân tích thời gian thực vào cơ sở dữ liệu phân tích” là một hiểu lầm khá phổ biến. Tuy nhiên, trên thực tế, bằng cách kết hợp nhiều công nghệ khác nhau, chúng ta có thể đạt được cả việc chèn dữ liệu gần như theo thời gian thực lẫn thời gian phản hồi dưới một phần giây cho các truy vấn phân tích. Cụ thể, đó là các công nghệ như lưu trữ định hướng cột (column-oriented storage) giúp xử lý truy vấn với tốc độ cao, hay cấu trúc dữ liệu MergeTree cho phép chèn dữ liệu với tốc độ cao.

Hơn nữa, ClickHouse lưu trữ toàn bộ dữ liệu trên bộ lưu trữ chung và kết hợp với cơ chế bộ nhớ đệm phân cấp. Bằng cách đặt bộ nhớ đệm trên SSD và bộ nhớ của máy cục bộ, hệ thống có thể mang lại hiệu suất tương đương bộ nhớ trong cho dữ liệu được truy cập thường xuyên, hiệu suất của SSD NVMe cho phần lớn dữ liệu, đồng thời tận dụng hiệu quả chi phí của bộ lưu trữ đối tượng trên toàn hệ thống.

Điểm mạnh của ClickHouse chính là khả năng cung cấp tất cả những tính năng này dưới dạng một hệ thống tích hợp duy nhất.

Câu hỏi: Nhiều công ty AI hàng đầu thế giới như OpenAI và Anthropic đang triển khai khả năng quan sát trên nền tảng ClickHouse. Lý do nào khiến họ lựa chọn ClickHouse?

Alexey: Câu trả lời rất đơn giản. Đó là vì khối lượng dữ liệu khổng lồ mà các công ty AI cần không thể được xử lý bằng bất kỳ công nghệ nào khác. Trên thực tế, họ đã thử nghiệm rất nhiều công nghệ khác nhau, nhưng tất cả đều không hoạt động được. Tuy nhiên, ClickHouse lại hoạt động hiệu quả đến mức đáng kinh ngạc, nên cuối cùng họ vẫn tiếp tục sử dụng nó.

Điểm mạnh của ClickHouse nằm ở khả năng mở rộng. Các công ty AI phải xử lý lượng dữ liệu khổng lồ lên tới hàng chục petabyte đổ về mỗi ngày. Với ClickHouse, người dùng có thể xây dựng cụm máy chủ gồm hàng nghìn máy và thực thi các truy vấn phân tán trên đó. Hệ thống này cũng cho phép tạo chỉ mục văn bản một cách hiệu quả cho lượng dữ liệu nhật ký khổng lồ. So với các hệ thống hiện có, ClickHouse xử lý những tác vụ này tốt hơn rất nhiều.

Ngoài ra, tỷ lệ nén dữ liệu cao cũng là một đặc điểm nổi bật. Các doanh nghiệp như Comcast và eBay đã đạt được tỷ lệ nén lên tới 20 lần, 30 lần. Do các hệ thống khác không có hiệu suất lưu trữ cao đến mức này, nên trong môi trường lưu trữ dữ liệu quy mô hàng chục petabyte, ClickHouse trở thành lựa chọn hàng đầu. Hơn nữa, khi kết hợp với hệ thống lưu trữ đối tượng, nó sẽ trở thành một giải pháp gần như hoàn hảo.

Trên thực tế, các công ty AI hàng đầu như OpenAI, Anthropic, Tesla và xAI đang sử dụng ClickHouse trên quy mô lớn để đảm bảo khả năng quan sát, đồng thời phân tích dữ liệu mới nhất ngay trên quy mô hiện có.

Kanetsuki: Những gì anh vừa giải thích thực sự rất thuyết phục. Cách các nút mở rộng quy mô và dữ liệu được phân tán như thế nào. Khi hiểu được cơ chế đó, chúng ta có thể trực quan nhận ra lý do tại sao ClickHouse có thể tiếp tục xử lý dữ liệu ở mức petabyte. 

Tương lai của cơ sở dữ liệu là sự tích hợp giữa OLTP và OLAP

Câu hỏi: Vừa rồi, anh Alexey đã đề cập rằng “trong ClickHouse, không cần phải tách biệt dữ liệu giao dịch và dữ liệu phân tích”. Vậy trong bối cảnh nền tảng dữ liệu quy mô lớn của thời đại trí tuệ nhân tạo, liệu hai loại dữ liệu này có được tích hợp với nhau trong tương lai hay không? Xin hai anh chia sẻ quan điểm của mình về triển vọng của cơ sở dữ liệu thế hệ mới.

Kanetsuki: Thực ra, bên cạnh công việc kinh doanh, tôi còn tham gia nghiên cứu trong lĩnh vực cơ sở dữ liệu và đang tìm hiểu về phương pháp HTAP. Tại công ty cũ, tôi từng tham gia vận hành hệ thống phân tích dữ liệu quy mô lớn, nhưng luôn gặp khó khăn trong việc quản lý độ trễ khi truyền dữ liệu từ OLTP sang OLAP. Chính vì vậy, tôi đã rất quan tâm đến phương pháp HTAP – vốn loại bỏ hoàn toàn công đoạn tích hợp dữ liệu – và bắt đầu nghiên cứu về nó.Vào tháng 3 năm nay, tôi cũng đã trình bày bài báo tại hội nghị DOLAP, được tổ chức song song với EDBT/ICDT (một trong những hội nghị cơ sở dữ liệu nổi tiếng nhất ở châu Âu).

※HTAP: Công nghệ cho phép thực hiện cả xử lý giao dịch (OLTP) và xử lý phân tích (OLAP) trên cùng một nền tảng

Thách thức hiện tại của HTAP là đồng bộ hóa dữ liệu. Về mặt nội bộ, hệ thống đang thực hiện quá trình chuyển dữ liệu đã được ghi vào OLTP sang OLAP, nhưng đây là một quá trình tốn kém và gặp khó khăn trong việc duy trì luồng dữ liệu. Mặc dù muốn phân tích ngay dữ liệu vừa được ghi, nhưng nếu độ trễ của truy vấn lên đến 1 giờ thì cuối cùng cũng không thể nắm bắt được tình hình mới nhất.

Alexey: Một thách thức khi xây dựng cơ sở dữ liệu HTAP là cấu trúc dữ liệu nội bộ cần thiết cho từng loại khối lượng công việc lại khác nhau một cách cơ bản. Cơ sở dữ liệu OLAP cần có cơ chế lưu trữ theo cột để đảm bảo tốc độ xử lý cao, cùng với chỉ mục thưa trên các khối nén. Tuy nhiên, với cấu trúc dữ liệu này, việc đọc hoặc cập nhật một bản ghi riêng lẻ một cách hiệu quả lại rất khó khăn. Ngược lại, cơ sở dữ liệu OLTP cần có chỉ mục chi tiết cho từng bản ghi và cấu trúc dữ liệu cho phép thay thế bản ghi một cách nhanh chóng.

Do đó, có hai cách tiếp cận. Cách thứ nhất là tìm điểm cân bằng trong một cấu trúc dữ liệu duy nhất. Cơ sở dữ liệu trong bộ nhớ là một ví dụ điển hình, nhưng trên thực tế, phương pháp này chưa thực sự thành công. Lý do là khi xử lý dữ liệu quy mô lớn, cấu trúc dữ liệu tích hợp không phù hợp lắm với quá trình phân tích, và hệ thống sẽ bị sập ngay khi dữ liệu không còn chứa vừa trong bộ nhớ nữa.

Một phương pháp khác là cách đồng bộ hóa nhanh chóng hai cấu trúc dữ liệu khác nhau. Hiện nay, phương pháp này được sử dụng phổ biến hơn. ClickHouse Cloud cũng áp dụng cách tiếp cận này. Cụ thể, ClickHouse và ClickHouse Postgres được triển khai trên bộ nhớ NVMe tốc độ cao và được đồng bộ hóa với nhau. Nhờ đó, dữ liệu trên Postgres có thể được xử lý từ ClickHouse với độ trễ ở mức chấp nhận được.

Kanetsuki: Tại Incident Lake, chúng tôi cũng đang sử dụng song song Postgres và ClickHouse. Hiện tại, hai hệ thống này chưa được đồng bộ hóa, nhưng chúng tôi mong muốn tích hợp càng nhiều dữ liệu vào ClickHouse càng tốt. Các vấn đề như chỉ mục duy nhất cho ID và khả năng tương thích SQL đang là những trở ngại; vậy liệu có kế hoạch phát triển nào trong tương lai không?

Alexey: Câu trả lời là có, và chúng tôi đang trong quá trình phát triển. Ngoài ra, về khả năng tương thích với SQL, khi kiểm tra bằng SQL Logic Test, chúng tôi đã đạt được mức tương thích trên 97%, chứng tỏ hệ thống hỗ trợ đầy đủ các tính năng của SQL tiêu chuẩn.

Những yếu tố cần thiết cho nền tảng dữ liệu trong kỷ nguyên AI

Qua cuộc đối thoại cho đến nay, có thể thấy rằng lý do SIGQ chuyển sang sử dụng ClickHouse không chỉ đơn thuần là để cắt giảm chi phí. Động cơ cốt lõi hơn nằm ở việc đáp ứng các yêu cầu về nền tảng dữ liệu cần thiết cho công tác quản lý sự cố trong kỷ nguyên AI, và những yêu cầu đó hoàn toàn phù hợp với lịch sử cũng như các đặc tính kỹ thuật của ClickHouse.

Trong phần 2, chúng tôi sẽ đi sâu tìm hiểu xem cách thức quản lý sự cố và vai trò của SRE trong kỷ nguyên AI sẽ thay đổi như thế nào trên nền tảng dữ liệu này.