10 năm ClickHouse mã nguồn mở
(clickhouse.com)- ClickHouse được công khai vào ngày 15 tháng 6 năm 2016 và trong 10 năm qua đã có hơn 2.000 người đóng góp, phát triển thành dự án tiêu biểu của cơ sở dữ liệu phân tích mã nguồn mở
- Dự án hướng tới mã nguồn mở Level 3, tức không chỉ công khai mã nguồn mà còn công khai cả hướng dẫn đóng góp, review code, roadmap, CI, phát hành và tài liệu
- Điểm khởi đầu là những giới hạn của hệ thống phân tích web dựa trên MySQL, và kinh nghiệm từ OLAPServer cùng Metrage đã dẫn tới xử lý hướng cột và thiết kế MergeTree
- ClickHouse không phải phần mở rộng trên một DBMS có sẵn mà là DBMS được xây dựng từ đầu, được phát triển từng bước từ năm 2009 với biểu diễn cột, hàm tổng hợp, table engine, nén, SQL parser, server·client và ReplicatedMergeTree
- Sau khi xử lý hàng trăm tỷ bản ghi mỗi ngày trong môi trường production nội bộ từ năm 2014, ClickHouse đã trải qua quá trình công bố bài viết và phê duyệt nội bộ năm 2015 trước khi được phát hành ra toàn cầu vào năm 2016
10 năm công bố mã nguồn mở
- ClickHouse được phát hành mã nguồn mở vào ngày 15 tháng 6 năm 2016
- Sau đó đã có hơn 2.000 người đóng góp và trở thành “cơ sở dữ liệu phân tích mã nguồn mở phổ biến nhất”
- Mục tiêu cốt lõi của dự án không chỉ là công khai mã nguồn mà còn là công khai tối đa quy trình phát triển và quy trình đóng góp
Mức độ mã nguồn mở mà ClickHouse hướng tới
- Mã nguồn mở có nhiều cấp độ
- Level 0: Công khai để có thể đọc mã, nhưng không hơn thế. Ví dụ là kiểu công bố để lưu trữ hoặc trưng bày như Doom, MS-DOS
- Level 1: Được cập nhật bằng commit trong kho mã công khai, nhưng không nhất thiết nhận đóng góp. Ví dụ là SQLite, Ladybird
- Level 2: Có nhận đóng góp nhưng quy trình phát triển không minh bạch và công khai hoàn toàn. Phần lớn các dự án mã nguồn mở hoạt động sôi nổi thuộc nhóm này
- Level 3: Có hướng dẫn đóng góp, theo dõi công việc, review code, roadmap phát triển, kiểm thử và CI, chu kỳ phát hành, hỗ trợ người dùng và tài liệu
- ClickHouse hướng tới mã nguồn mở Level 3
- Một mục tiêu khác là trở thành ví dụ về mã nguồn và thực hành phát triển để các lập trình viên muốn xây dựng cơ sở dữ liệu mới có thể tham khảo
- Mã nguồn hướng tới tính mô-đun, trực giao và có tài liệu
- Khi cần các khái niệm phức tạp, phần chú thích sẽ giải thích từ đầu để người đọc không cần tra thêm giáo trình, Wikipedia hay AI
Nơi phát triển C++ và thử nghiệm hiệu năng
- ClickHouse là một trong những kho mã nguồn mở C++ phổ biến, đồng thời hướng tới trở thành nơi có thể học cả các nền tảng như tính năng ngôn ngữ mới nhất như C++23, hệ thống build, tích hợp/kiểm thử liên tục và thực hành review code
- Thử nghiệm cấu trúc dữ liệu và tối ưu hiệu năng cũng là cách sử dụng quan trọng
- Ngay cả các Pull Request mang tính thử nghiệm không nhằm mục tiêu được merge cũng được kiểm thử ở mức tương đương bản phát hành production
- Có thể kiểm chứng trong ClickHouse các thử nghiệm như memory allocator mới, thư viện nén, hash table, định dạng dữ liệu, thuật toán sắp xếp
- Roadmap cũng bao gồm cả những hạng mục mang tính thử nghiệm, kỳ lạ, thậm chí buồn cười
- Mọi người đóng góp đều được ghi nhận trong CHANGELOG và bảng system.contributors bên trong cơ sở dữ liệu
- Có nhiều trường hợp một tính năng với triển khai ban đầu chưa hoàn chỉnh được hoàn thiện dần cùng nhau, và ngay cả khi phải viết lại toàn bộ mã thì ý định ban đầu và use case của tác giả đầu tiên vẫn được ghi nhận
Vấn đề trước ClickHouse và các prototype
- Commit đầu tiên của ClickHouse được tạo vào ngày 29 tháng 5 năm 2009, là một tối ưu hiệu năng nhằm giảm vấn đề các hàm libc như
localtime,mktime,gmtimequá chậm đến mức xuất hiện trong profiler - Điểm xuất phát là các thử nghiệm xử lý dữ liệu cho hệ thống phân tích web
- Hệ thống này nhận log pageview được gửi từ website, tương tự Google Analytics
- Nó sử dụng kết hợp MySQL, xử lý dữ liệu bằng C++, và các cấu trúc dữ liệu C++ tùy biến cho những phần MySQL không đáp ứng đủ
- Cơ sở dữ liệu MySQL lưu các báo cáo tiền tổng hợp cho khách hàng, còn các cấu trúc dữ liệu tùy biến được dùng để tính phiên người dùng và lịch sử người dùng
- Dữ liệu liên tục tăng, log mới đổ vào theo thời gian thực, và nếu không xử lý được log của mỗi 5 phút trong vòng 5 phút thì độ trễ sẽ tiếp tục chồng chất
- Nhiều cơ sở dữ liệu và thư viện khác cũng được thử nghiệm
- Đã xem xét TokuDB, LMDB, Judy Arrays, Hadoop, LZO, QuickLZ, HyperLogLog, tài liệu về nén dữ liệu và tài liệu về event loop server
- Yêu cầu cho phép người dùng tự tạo báo cáo tùy ý đã bộc lộ giới hạn của báo cáo tiền tổng hợp, dẫn tới việc xem xét cơ sở dữ liệu hướng cột
OLAPServer và Metrage
- Cách tiếp cận hướng cột là lưu log có cấu trúc nhưng chưa tổng hợp, sau đó tổng hợp tức thời trong lúc khách hàng chờ trang tải xong
- Đã thử Infobright, InfiniDB là phần mở rộng MySQL, cùng Vertica, MonetDB, LucidDB là các cơ sở dữ liệu phân tích độc lập, nhưng chúng không hoạt động được với điều kiện nạp 100 tỷ bản ghi mỗi ngày và 500 cột
- Prototype tùy biến đầu tiên là OLAPServer
- Được triển khai vào tháng 12 năm 2008 và phát hành vào tháng 1 năm 2009
- Lưu mọi cột trong một file nhị phân duy nhất theo từng ngày và từng website
- Dùng hash thay cho chuỗi và chỉ hỗ trợ kiểu số nguyên
- Dùng nén nhẹ và được cập nhật mỗi ngày một lần với độ trễ vài giờ
- Cung cấp API để chỉ định cột group, hàm tổng hợp, bộ lọc và sắp xếp, còn truy vấn được chỉ định bằng XML
- Việc “phi tổng hợp hóa” dữ liệu tổng hợp cũ từ MySQL để điền vào sao cho cho ra cùng kết quả được Evgenii Gatov giải quyết
- OLAPServer cũng hoạt động cho endpoint phân tích dữ liệu internet toàn công ty thay vì chỉ một website đơn lẻ, và phản hồi đủ nhanh để các nhà phân tích nội bộ dùng thay cho MapReduce nội bộ
- Prototype thứ hai là Metrage
- Khoảng 50TB dữ liệu được tích trong MySQL trên 50 shard, và nhiều cấu trúc dữ liệu tùy biến được lưu dưới dạng BLOB
- Khi tổng hợp, chương trình phải đọc BLOB, áp dụng mã tùy biến rồi chèn lại
- Dữ liệu MySQL không được nén, và thứ tự dữ liệu đến không khớp với thứ tự phạm vi truy vấn nên việc đọc cũng chậm
- Metrage là cấu trúc dữ liệu tùy biến cho tổng hợp tăng dần dùng background merge, mỗi bản ghi được định nghĩa bằng một struct C++ có các phương thức
add,update,merge,serializeText/Binary,deserializeText/Binary
- OLAPServer là cấu trúc hướng cột chưa tổng hợp, còn Metrage là cấu trúc hướng hàng thời gian thực với CRDT tùy ý
- ClickHouse bắt đầu bằng việc kết hợp tốc độ tổng hợp hướng cột với cập nhật thời gian thực và tính cục bộ dữ liệu dựa trên merge tree, rồi khái quát hóa để hỗ trợ ngôn ngữ truy vấn thực thụ và các kiểu dữ liệu
DBMS được xây dựng từ đầu
- ClickHouse là một ví dụ hiếm về DBMS được triển khai từ đầu, không dựa trên cơ sở dữ liệu có sẵn
- Các commit đầu tiên năm 2009 liên quan đến tối ưu hóa các cấu trúc dữ liệu khác trong cùng một monorepository, và còn được giữ lại vì trong quá trình công bố mã nguồn mở, lịch sử đã được bảo toàn khi tách kho mã
- Bước đầu tiên khi triển khai DBMS mới là hiện thực cột trong bộ nhớ, và các lớp
IColumncùngFieldquen thuộc đến nay đã xuất hiện từ đó- Có thể trông giống Apache Arrow, nhưng khi đó Apache Arrow chưa tồn tại
- Những định dạng hướng cột khác như RCFile, Trevni, ORC, Parquet cũng chưa tồn tại vào thời điểm đó
- Sau đó hàm tổng hợp được đưa vào, và đến nay vẫn là một trong những phần quan trọng nhất của ClickHouse
- Table engine cũng được đưa vào
- Ban đầu tên gọi “primary key” đã được dùng trong vài ngày
- Nó cho phép đọc và ghi cột trên đĩa
- Table engine đầu tiên tương tự TinyLog vẫn còn tồn tại đến ngày nay
- Ban đầu phần nén dùng QuickLZ, nhưng sau khi đọc blog của Yann Collet thì được thay bằng LZ4
Query pipeline và hiện thực SQL
- block streams là các thành phần pipeline xử lý dữ liệu tạo ra, tiêu thụ và biến đổi các chunk cột theo kiểu streaming
- Hiện nay đã được thay bằng Processors
- Chúng trở thành nền tảng cho việc định dạng kết quả và triển khai truy vấn bảng
- Trong cùng commit đó,
StorageSystemNumbersđược thêm vào cho mục đích kiểm thử và nay vẫn tồn tại dưới dạng bảngsystem.numbers - Query pipeline đầu tiên là in ra các số ở định dạng TSV, và phép toán quan hệ đầu tiên là
LIMIT - SQL parser ban đầu thử dùng boost::spirit nhưng thất bại, sau đó đã tự xây dựng recursive descent parser
- Cũng có những ý tưởng được đưa vào sớm rồi bị loại bỏ hoặc được đưa trở lại sau này
- Cột số mã hóa độ dài biến đổi bị loại vì chậm, và về sau rất lâu mới có custom compression codec độc lập với cột
- Kiểu cột
Variantchứa giá trị trường tùy ý cũng bị loại vì chậm, và Variant tốt hơn được thêm vào năm 2025 - Kiểu mảng kích thước cố định bị loại vì ít cần thiết, và hiện nay đang được xem xét thêm lại
- Điều này cho thấy nguyên tắc phát triển rằng loại bỏ mã không cần thiết còn quan trọng hơn việc thêm mã mới
Triển khai production và ReplicatedMergeTree
- Cấu trúc bảng thực tế đầu tiên được thử nghiệm trong ClickHouse là bảng
hits, hiện vẫn có thể thấy trong ClickBench - Trong quá trình đọc và ghi bảng này, người ta nhận ra C++ iostreams quá chậm, nên
WriteBuffervàReadBufferđã được đưa vào và vẫn còn dùng đến nay - Hàm đầu tiên của SQL là các toán tử số học, và từ đó trình thông dịch truy vấn
SELECTđầu tiên được triển khai - ClickHouse server được đưa vào ngày 9 tháng 3 năm 2012, còn
clickhouse-clientlà ngày 25 tháng 3 năm 2012 - Cùng với các table engine
Log,TinyLog,Merge,Distributed,Memory, việc triển khai production trở nên khả thi- Mục đích production đầu tiên là lưu các chunk log để xử lý bổ sung và chạy truy vấn toàn cục trên log thô
- Nó được dùng như một hàng đợi log bền vững có thể truy vấn bằng SQL
- Sau đó MergeTree được bổ sung
- Dù dữ liệu đi vào theo thứ tự thời gian, hệ thống vẫn thực hiện sắp xếp tăng dần ở background
- Điều này cho phép xử lý nhanh các truy vấn phạm vi cho một website đơn lẻ
- Từ đó có thể triển khai production thay thế OLAPServer và Metrage
- Năm 2012, Michael Kolupaev gia nhập với tư cách nhân viên thứ hai của nhóm và tham gia triển khai ReplicatedMergeTree
- Production được triển khai ở nhiều trung tâm dữ liệu theo khu vực, và đội hạ tầng thực hiện các “drills” tắt một trung tâm dữ liệu trong một giờ mỗi tháng
- Mọi dịch vụ production đều phải có replication đa trung tâm dữ liệu
- Ban đầu dùng cách double-write đơn giản và backfill sau khi hết downtime
- Để đạt 100% nhất quán và tự động khôi phục, cần đến distributed consensus
- ReplicatedMergeTree dùng ZooKeeper làm lớp metadata đã được triển khai
- ReplicatedMergeTree đã giúp ClickHouse có thể triển khai production cho các truy vấn hướng người dùng từ năm 2014
Quá trình đi đến công bố mã nguồn mở
- Năm 2014, ClickHouse trong production đã lưu trữ hàng trăm tỷ bản ghi mỗi ngày và phản hồi truy vấn thời gian thực của khách hàng
- Các nhà khoa học dữ liệu nội bộ trong công ty dùng ClickHouse để tính toán xu hướng internet, và cả tài liệu sử dụng đơn giản cũng được công bố
- Những bộ phận khác như quảng cáo, thương mại điện tử, hạ tầng và phân tích kinh doanh cũng thử dùng ClickHouse, đồng thời chuyển một số use case khỏi MapReduce nội bộ, MySQL và Postgres
- Cuối năm 2014, ClickHouse đã được dùng rộng rãi trong một công ty, và ngoại lệ đáng chú ý là CERN cũng triển khai thông qua hợp tác LHCb experiment
- Người ta cũng xác nhận rằng kỹ sư ở các công ty khác đang tự xây những thứ tương tự OLAPServer hay Metrage vì cơ sở dữ liệu hiện có không xử lý tốt use case của họ
- Năm 2015, bài viết về ClickHouse và bản dịch được công bố, qua đó càng xác nhận thêm sự quan tâm
- Trước khi công khai, nhóm đã chuẩn bị danh sách lợi ích tiềm năng và rủi ro để thuyết phục ban lãnh đạo công ty
- Sau khi được phê duyệt, kế hoạch phát hành, logo đầu tiên, website đầu tiên, bài blog và kho Debian đã được chuẩn bị, rồi ClickHouse được phát hành ra toàn thế giới vào ngày 15 tháng 6 năm 2016
- Hiện nay ClickHouse đã trở thành cơ sở dữ liệu phân tích phổ biến được các tập đoàn lớn trên toàn thế giới sử dụng
1 bình luận
Ý kiến trên Hacker News
Tôi phát hiện ClickHouse vào khoảng năm 2017~2018 và đã làm một bản proof of concept để thay thế Elasticsearch, kết quả chỉ sau vài tuần thì dung lượng lưu trữ và số truy vấn mỗi giây đã cải thiện gấp 5 lần
Nhưng phía quản lý từ chối vì nó không mấy nổi tiếng và trông giống như “một cơ sở dữ liệu nào đó do người Nga làm ra”
Cá nhân tôi vẫn khá tiếc vì đã thấy chuyến tàu đến sớm như vậy mà lại không kịp lên
Tỷ lệ nén cũng phi lý đến mức khó tin, còn benchmark chi phí lưu trữ thì hạ xuống gần mức chi phí S3
Một tầng lưu trữ tốn hàng triệu đô la mỗi tháng đã giảm xuống chỉ còn mức vài nghìn đô la mỗi tháng
ClickHouse không phải thuốc chữa bách bệnh, nhưng nếu hiểu cách dữ liệu được truy cập và có thể sắp xếp nó cho phù hợp, bạn sẽ đạt được hiệu quả cực lớn
Theo hiểu biết của tôi thì ClickHouse chỉ hữu ích cho kiểu tìm kiếm giống grep
Với tư cách là người đã dùng TimescaleDB trong thời gian dài, ClickHouse thực sự rất mới mẻ. psql thì quá tuyệt, và việc có thể phụ thuộc hoàn toàn vào một hệ cơ sở dữ liệu duy nhất cũng rất hay, nhưng ở khâu bảo trì migration và các bước triển khai thì khá đau đớn
TimescaleDB cũng có cảm giác là cấu trúc thay đổi theo từng phiên bản, và định hướng phát triển hơi chao đảo, nên đôi lúc nó giống một sản phẩm chất lượng alpha
Tôi vẫn đang cân nhắc liệu sẽ mở rộng bản mirror ClickHouse bằng PeerDB, hay triển khai riêng để không có thêm một tầng dễ hỏng nữa
Tôi muốn hỏi là bạn có xu hướng hoàn toàn không khuyến nghị TimescaleDB không. PostgreSQL hiện là phần vững chắc nhất trong stack của chúng tôi, nên tôi rất muốn tránh nỗi khổ của phần mềm chất lượng alpha
Phía DuckDB cũng có công việc về pg_duckdb, và còn có những nơi như Xata
Nhân tiện, tôi làm ở ParadeDB
Công cụ metrics và autoscaling của Cloud 66 đã trải qua 5 vòng lặp trước khi chốt với ClickHouse: Redis, Cassandra, tự xây bằng Ruby+RabbitMQ, tự xây bằng Go+RabbitMQ, rồi đến ClickHouse
Mỗi lần đều đụng phải một giới hạn nào đó hoặc gánh nặng tối ưu hóa không thể kham nổi, còn ClickHouse thì đã rất ổn định suốt 4 năm qua
Chỉ sau khi thay Loki bằng ClickHouse thì stack observability của tôi mới cuối cùng có cảm giác là “đúng”. Nó thực sự mạnh cho log và các truy vấn phân tích nói chung
Ngoài việc là một cơ sở dữ liệu OLAP rất tốt, các connector tích hợp sẵn để lấy dữ liệu từ nguồn từ xa đúng là yếu tố thay đổi cuộc chơi
Bạn có thể thiết lập tự động import định kỳ một thư mục S3 chứa các file Parquet/JSON, và cũng có thể kết nối trực tiếp tới Postgres
Ở kho dữ liệu của một tòa soạn cỡ trung, chúng tôi đã thay bộ Druid+Postgres+Trino bằng một node ClickHouse lớn duy nhất, và chưa từng muốn quay lại
Nó nhanh hơn nhiều, thực tế hơn nhiều, và cũng cần bảo trì ít hơn rất nhiều
Tôi thực sự thích ClickHouse, và hiệu năng của nó rất xuất sắc. Tôi có phải chỉnh vài truy vấn ở đây ở đó vì hiệu năng, nhưng nhìn chung nó vượt xa kỳ vọng
Ban đầu tôi dựng một pipeline thu thập thời gian thực để xử lý các đợt nạp dữ liệu tăng dần lớn, vì Redshift trước đây vừa đắt vừa tương đối chậm
Nhưng cho đến nay ClickHouse xử lý tốt cả lượng dữ liệu lớn lẫn các phép biến đổi lớn, đến mức tôi không cần pipeline đó nữa
Vấn đề duy nhất là trong cấu hình mặc định có bật một tính năng tracing khá nặng, và trên phần cứng tương đối nhỏ thì nó làm giảm hiệu năng đáng kể
Sau đó chúng tôi đã mở rộng quy mô và giờ nó trở thành lõi của data stack
Nếu ở quy mô thực sự rất lớn thì có thể tôi sẽ chọn thứ khác, nhưng miễn là vẫn ở mức vài node thì độ phức tạp vẫn kiểm soát được và dùng rất thích
Câu “ngay cả khi không nhắm tới việc được merge, bạn vẫn có thể mở pull request như một thử nghiệm và nó sẽ được kiểm tra ở mức tương đương release production. Bạn tìm ra một memory allocator, thư viện nén, hash table, định dạng dữ liệu hay thuật toán sắp xếp mới à? Hãy mang vào ClickHouse, nó sẽ phơi bày mọi thứ” thật ấn tượng
Nó phát hiện lỗi ở khắp nơi, bao gồm cả Linux kernel
Chúng tôi có một hệ thống fuzzing cực kỳ nghiêm ngặt, nhiều fuzzers chạy ở nhiều cấp độ khác nhau, và test được chạy với số lượng cấu hình kết hợp nhiều đến vô lý
Con số gần nhất tôi nghe được khoảng một năm trước là một lần chạy CI đầy đủ mất khoảng 400 giờ cho mỗi commit đơn lẻ
Nên theo nghĩa tích cực thì đúng là khá điên rồ
Thú vị là bài blog đưa SQLite và Ladybird lên cùng phổ, nhưng lại bỏ qua đối thủ mã nguồn mở cốt lõi là DuckDB
Tôi đồng ý rằng niềm tin nằm ở giai đoạn 3
Nhưng để bền vững trong kỷ nguyên cơ sở dữ liệu được vibe coding, sẽ cần phát minh ra một mô hình kinh doanh mới
Khi truy vấn các cột không được lập chỉ mục, ClickHouse có thể dễ dàng nhanh hơn DuckDB truy vấn Parquet tới 10 lần, còn khi đụng tới khóa chính thì gần như nhanh đến mức không thể so sánh
Có nhiều bài viết so sánh hai bên, nhưng thực tế ClickHouse và DuckDB nằm ở hai không gian hoàn toàn khác nhau
DuckDB là một engine phân tích mạnh, còn ClickHouse là một hệ quản trị cơ sở dữ liệu hoàn chỉnh với replication, engine MergeTree và nhiều thứ khác
Phần lớn mọi người không gặp vấn đề quy mô như vậy, nhưng khi gặp thì khác biệt rất lớn
Tôi thấy hơi tiếc vì trang đó ngại nói rằng “xử lý dữ liệu cho hệ thống phân tích web tương tự Google Analytics” thực ra đã được dùng ở Yandex
Có lẽ họ không muốn quảng bá công ty đó, nhưng tôi không rõ vì sao điều đó lại đáng buồn
ClickHouse từng là game changer ở một vài công ty tôi làm trước đây. Nó làm tôi nhớ đến tập podcast Rust in Production nói về việc áp dụng Rust
https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1