Tương lai của kdb+?
(timestored.com)- Trong lĩnh vực tài chính, kdb+ từng là công cụ mạnh mẽ cho phân tích dữ liệu thị trường lịch sử và tính toán thời gian thực, nhưng hiện nay ở từng trường hợp sử dụng đã xuất hiện các công nghệ thay thế đủ trưởng thành
- Nhiều người dùng không cần đến tốc độ tối đa của kdb+, và các nền tảng nội bộ của ngân hàng cũng không khai thác hết hiệu năng đó, khiến lợi thế về tốc độ trở nên kém quyết định hơn
- Phân tích định lượng cục bộ trên thực tế do hệ sinh thái Python dẫn dắt, còn các công cụ cộng đồng miễn phí như DuckDB và Polars có lợi hơn về mặt học tập và chuyển việc
- Streaming thời gian thực và tính toán phân tán vẫn là thế mạnh của kdb+, nhưng độ khó khi triển khai cùng mức độ nhận biết ngày càng rộng của Kafka, Flink và RisingWave khiến việc mở rộng trở nên khó khăn
- Để kdb+ tồn tại lâu dài, cần có lộ trình sử dụng miễn phí, tập trung vào sản phẩm cốt lõi, giảm độ dốc của đường cong học tập và tính đại chúng để mở rộng ra ngoài lĩnh vực tài chính
Vai trò của kdb+ trong lĩnh vực tài chính
- kdb+ đã được sử dụng trong nhiều hệ thống và tác vụ phân tích của ngành tài chính
- Lưu trữ và phân tích dữ liệu thị trường lịch sử: các trường hợp như MS Horizon, Citi CloudKDB, UBS Krypton
- Phân tích định lượng cục bộ: phân tích thanh khoản, phân tích PnL, phân tích lợi nhuận theo từng khách hàng
- Engine tính toán streaming thời gian thực: Streaming VWAP, Streaming TCA
- Tính toán phân tán: các tác vụ như tính toán margin cho danh mục cổ phiếu, phân tích rủi ro, trong đó dữ liệu được chia nhỏ, tính toán rồi ghép lại
Dữ liệu thị trường lịch sử: có thể giữ khách hàng hiện tại, nhưng khó mở rộng khách hàng mới
- Nhiều người dùng muốn truy vấn dữ liệu dung lượng lớn để tạo minute bar, thực hiện asof join hoặc các phân tích chuỗi thời gian nâng cao hơn
- Các lựa chọn cạnh tranh đã mở rộng sang những cơ sở dữ liệu mới như ClickHouse, QuestDB, các nhà cung cấp cloud như BigQuery và Redshift, cũng như Market Data as a Service
- Có ba lý do khiến lợi thế tốc độ của kdb+ không còn mang tính quyết định như trước
- Phần lớn người dùng không cần đến “tốc độ” của kdb+
- Phần lớn nền tảng nội bộ của ngân hàng không khai thác hết tốc độ của kdb+
- Các sản phẩm cạnh tranh hiện đã đủ nhanh
- Benchmark ClickBench được nhắc đến như một benchmark được công khai minh bạch
- kdb+ có thể giữ được khách hàng hiện tại, nhưng các doanh nghiệp tier 2 muốn cloud-native hoặc các lựa chọn khác, nên việc giành khách hàng mới không dễ
- Các khách hàng lớn hiện tại đã phải đầu tư lớn để xây dựng nền tảng riêng, còn nền tảng kdb cloud vẫn còn những điểm cần hoàn thiện thêm
Phân tích định lượng cục bộ: Hệ sinh thái Python chiếm ưu thế
- Các lựa chọn thay thế cho phân tích định lượng cục bộ phần lớn xoay quanh Python
- Python + DuckDB
- Python + Polars
- Python + PyKX
- Python + dataframe, Modin, v.v.
- Trong mảng này, Python đã thắng; câu hỏi còn lại gần như là ai sẽ cung cấp các công cụ bổ trợ nhanh hơn
- Lý do DuckDB và Polars có triển vọng lớn là vì chúng miễn phí
- Người dùng bắt đầu từ đại học sẽ học bằng công cụ miễn phí và rất có khả năng sẽ không đổi về sau
- Các quant trong công ty cũng ưa thích công cụ miễn phí để có thể tiếp tục làm các phân tích tương tự ở công việc tiếp theo
- Nếu chỉ phụ thuộc vào kdb+, khi chuyển sang công ty không có kdb+, họ có thể mất đi một phần lớn bộ kỹ năng của mình
- kdb+ là một sản phẩm ngách chưa lan rộng đáng kể ra ngoài tài chính, có chi phí khởi đầu cao và cú pháp cũng xa lạ
Streaming thời gian thực và tính toán phân tán: Có thế mạnh, nhưng người thắng chưa rõ
- Streaming thời gian thực và tính toán phân tán luôn là các trường hợp sử dụng kém phổ biến hơn của kdb+, và cũng không phải lý do chính giúp giành được hợp đồng
- Khả năng kết hợp dữ liệu thời gian thực và dữ liệu lịch sử trong một mô hình được xem là thế mạnh lớn nhất của kdb+
- Trong triển khai thực tế, đôi khi cần người cực kỳ thành thạo, nếu không hệ thống có thể trở nên hỗn loạn
- Những trường hợp thất bại như vậy cũng ảnh hưởng tiêu cực đến việc các bộ phận khác trong công ty áp dụng kdb+ cho mục đích khác
- Người thắng cuối cùng trong mảng này vẫn chưa rõ, nhưng khả năng đó là kdb+ có vẻ thấp
- Kafka đã có các triển khai quy mô lớn và mindshare, trong khi các công nghệ như Flink và RisingWave cũng đang nổi lên
Mã nguồn mở và chuẩn hóa hấp thụ các ưu điểm của kdb+
- kdb+ là một công nghệ xuất sắc, nhưng trong khi nó vẫn xuất sắc ở mức tương tự 15 năm trước, hệ sinh thái xung quanh đã thay đổi nhanh chóng
- Các công ty mã nguồn mở tốt đã lấy những ý tưởng cốt lõi của kdb+
- Parquet/Iceberg tương tự định dạng đĩa của kdb+ dành cho lưu trữ theo cột được tối ưu hóa
- Định dạng in-memory của Apache Arrow tương tự định dạng cột in-memory của kdb+
- Khái niệm log/replay/ksql của Kafka, nhìn từ một góc độ nhất định, cũng có thể xem là tương tự tplog
- QuestDB, DuckDB, ClickHouse đều hỗ trợ asof join
- Các đối thủ không chỉ học các ưu điểm của kdb+, mà còn chuẩn hóa chúng
- Snowflake, Dremio, Confluent, Databricks đã hỗ trợ Apache Iceberg và Parquet
- QuestDB, DuckDB, Python đã hỗ trợ Parquet theo kiểu native
- Nếu dữ liệu ở dạng Parquet, nhiều công cụ có thể chạy trên cùng một tập dữ liệu
- Cục diện so sánh không còn là KX đối đầu với một đối thủ đơn lẻ, mà là KX đối đầu với toàn bộ nhiều đối thủ
Những điều KX cần thay đổi
- Có đánh giá cho rằng KX đang thay đổi, nhưng chưa đủ nhanh
- Những thay đổi cần thiết có thể tóm gọn thành bốn điểm
- Cần cung cấp một phiên bản miễn phí có thể dùng cho nhiều mục đích, đồng thời chuẩn bị giấy phép hợp lý để khách hàng có ngân sách nhỏ cũng dễ sử dụng
- Cần tập trung vào việc làm cho sản phẩm cốt lõi trở nên xuất sắc
- MongoDB và InfluxDB là các ví dụ đối chiếu cho thấy chỉ với một cơ sở dữ liệu tốt cũng có thể giành được các hợp đồng lớn
- Độ hoàn thiện của sản phẩm cốt lõi quan trọng hơn các sản phẩm ngoại vi như Delta, kdb.ai
- Cũng cần giảm đường cong học tập dốc của kdb+
- Nếu cần, điều này có thể bao gồm cả việc thay đổi chính ngôn ngữ và công nghệ
- Nếu không trở nên đại chúng hơn, kdb+ có thể đi vào quá trình suy giảm chậm
- Không chỉ sản phẩm công nghệ cốt lõi, mà cả các thay đổi rộng hơn ở cấp công ty cũng cần được cân nhắc, bao gồm những chi phí và sáng kiến lớn như AI và chi tiêu marketing quy mô lớn
1 bình luận
Ý kiến Hacker News
Tôi cũng muốn đưa TimescaleDB vào danh sách ứng viên. Vì nó là một phần mở rộng của PostgreSQL nên các yếu tố liên quan đến SQL như replication, authentication vẫn được giữ nguyên
Nó cũng hỗ trợ nén theo kiểu lưu trữ cột và rất nhanh. Tôi đã dùng nó trong vài ứng dụng tài chính, và một lượng dữ liệu tick khổng lồ đã đi vào ứng dụng với tốc độ gần như tối đa mà phần cứng cho phép
Hỗ trợ cũng tốt và phản hồi trên Slack rất nhanh. Tôi cũng đã dùng kdb, nhưng nhược điểm lớn là đắt, còn ngôn ngữ Q thì thỉnh thoảng vui để nghịch như code golf, nhưng rồi bạn sẽ nhận ra các ký tự đơn lẻ đó không biểu đạt tốt như tưởng tượng
Nếu mục tiêu là phân tích định lượng tức thời thì kdb có thể là lựa chọn phù hợp, kiểu ngồi cả ngày nhập các chuỗi ngắn vào REPL để tìm ra thứ kiếm ra tiền. Nhưng nhiều công việc thực ra giống cron job hơn, nên nếu chỉ là chạy các truy vấn cố định theo lịch thì tốt hơn hết là viết theo cách mà người đến sau có thể đọc hiểu và bảo trì
Những kịch bản như “hiển thị cảm biến trên bản đồ và vẽ biểu đồ giá trị của từng cảm biến” có thể được xử lý nhanh gọn bằng một truy vấn duy nhất
Chỉ là dữ liệu của tôi hơi bệnh hoạn vì phía nguồn có thể tùy ý thay đổi cấu trúc và tôi phải chấp nhận điều đó. Nếu giá InfluxDB không điên rồ đến vậy thì thành thật mà nói chắc tôi đã dùng InfluxDB ngay
Tôi từng nghỉ việc chỉ sau 2 tuần ở một công việc giao dịch định lượng dùng kdb+. Tôi dùng được nó, nhưng trải nghiệm quá tệ
Tôi có thể than phiền rằng thiết kế ngôn ngữ hay việc debug thật khủng khiếp, nhưng điều khiến tôi bực bội nhất là cách làm việc có hoặc không có quy ước lập trình, và tôi nghĩ ngôn ngữ lẫn cộng đồng đóng vai trò lớn trong chuyện đó. Văn hóa công ty cũng góp phần: khi tôi hỏi tại sao tài liệu lại tệ đến vậy, tôi nhận được câu trả lời là “rồi theo thời gian chúng tôi sẽ hiểu, và làm thế này thì đội khác không dùng được ý tưởng của chúng tôi”
Toàn bộ stack cũng đã cũ kỹ, và với công cụ như Q thì cũng khó làm được nhiều thứ thú vị. Ví dụ, họ sao chép dữ liệu từ qStudio sang Excel để vẽ biểu đồ
Điều duy nhất tôi thấy tốt là họ không chạy theo trào lưu Docker/Kubernetes mà triển khai trực tiếp lên máy chủ. Việc quant cần có khả năng sửa nhanh trong production là hợp lý, nhưng tôi cũng nghĩ các lập trình viên web app không nên phải chờ 10 phút chỉ để xem kết quả chỉnh sửa trên production
Tôi có một giả thuyết về lý do các quant thích kdb. kdb là một vũ khí tốt. Nó phù hợp với một số mục đích, nhưng vì quá tẻ nhạt để xây dựng nên khó gọi là một công cụ. Người ta thích nó vì nó chạy ngay lập tức. Nhưng việc có thể đóng đinh bằng dao không có nghĩa đó là mục đích của con dao
Theo tiếp giả thuyết đó thì LISP, đặc biệt là Racket, có thể là công cụ tốt nhất. Nó không phải ngôn ngữ mạnh nhất ngay từ đầu, nhưng có thể tạo ra nhiều lớp trừu tượng nhờ khả năng thay đổi chính ngôn ngữ. C++ và Python là những ngôn ngữ lập trình tuyệt vời để làm ra phần mềm tốt, còn Python cũng là một vũ khí khá ổn
Q có thể tạo ra ảo giác rằng nó là ngôn ngữ tốt nhất để khám phá dữ liệu quant, nhưng đó là vì giới quant không đầu tư đủ để xây dựng phần mềm tốt và dùng công cụ tốt. Nếu thành thạo một Python IDE đúng nghĩa, bạn có thể làm việc hiệu quả hơn bất kỳ lập trình viên Q nào
Tôi sẽ không bắt đầu nói về hiệu năng. Bài được liên kết có thể không hay, nhưng phần đó thì có đề cập
Trước đây tôi từng bị Kdb+ gây ấn tượng khá mạnh. Tôi còn đi các buổi gặp mặt ở Chicago, nơi những truy vấn lớn chạy gần như ngay lập tức và cú pháp kiểu APL trông như thần chú ma thuật chỉ dân toán mới hiểu. Nhân viên bán hàng nói rằng Kdb được tối ưu đến mức có thể nằm trong bộ nhớ đệm L1 của bộ xử lý thời đó
Sau 10 năm, giờ tôi đang làm cùng kiểu công việc với Python, DuckDB và Jupyter trên các tệp Parquet. DuckDB không chỉ song song hóa mà còn vector hóa. Tôi không biết nếu benchmark với kdb+ thì sẽ ra sao, nhưng độ phản hồi của DuckDB trên tập dữ liệu lớn ít nhất cũng cho cảm giác nhanh ngang kdb+. Dĩ nhiên kdb+ có lẽ được tối ưu hơn nhiều, nhưng khác biệt là DuckDB miễn phí
Có vẻ khả năng cao hơn là người đó không hiểu được code nên nản và nghỉ
Nếu là một lập trình viên quant lành nghề và đó là một vị trí tốt, thì theo điều kiện hợp đồng kiểu này, nghỉ sau 2 tuần hẳn sẽ là thảm họa cho việc quản lý bước chuyển việc tiếp theo
Ví dụ, chỉ cần mở Jupyter Notebook và làm như sau
import pykx as kxdf = kx.q(“select from foo where bar”)plt.plot(df[“x”], df[“y”])Đây thực sự là một tích hợp mượt mà và mạnh mẽ. Bạn có thể tận dụng ưu điểm của cả hai thế giới, và trong 10 năm tới đây nó có thể là tính năng giúp cứu sống sản phẩm này
Một điểm hấp dẫn của kdb+/Q chưa được nêu rõ ở đây là tích hợp theo chiều dọc. Thay vì phải chọn và ghép nhiều công nghệ có sẵn, nó có thể xử lý các trường hợp sử dụng của cả một stack chỉ bằng một công nghệ duy nhất
Nhờ ngôn ngữ Q, khả năng tuần tự hóa dữ liệu tích hợp sẵn và tính năng giao tiếp liên tiến trình, một lập trình viên giỏi có thể tùy biến chính xác hệ thống cần thiết chỉ với một ngôn ngữ, và codebase thường chỉ gói gọn trong vài trang tài liệu thay vì hàng trăm hay hàng nghìn trang
Nếu tổ chức đã quyết định xử lý một phần vai trò này bằng phần mềm, giao thức hoặc định dạng khác, thì lợi thế của tích hợp theo chiều dọc về luồng phát triển và hiệu năng tổng thể sẽ giảm đi. Bản thân kdb+ lại còn độc quyền và đắt đỏ, nên việc biện minh cho triển khai toàn diện trong dự án mới là điều khó hiểu được. Công nghệ này thật sự là một viên ngọc, nên rất đáng tiếc
Sản phẩm dashboard thì khó dùng, và có lỗi nghiêm trọng là trình biên tập thường xuyên bị crash ngay cả với dashboard có độ phức tạp vừa phải. Q rất giàu tính năng nên sẽ cực kỳ thú vị nếu dùng để viết ứng dụng web, nhưng để cung cấp thứ gì đó cho người dùng thì lại buộc phải dùng trình biên tập kéo-thả
Nếu Shakti bao gồm thư viện xử lý các trường hợp doanh nghiệp phổ biến như cân bằng tải, quyền người dùng, SSO, thì tôi nghĩ nó có thể trở thành đối thủ thực sự của Kx. Một lập trình viên K thành thạo có lẽ làm được trong 1–2 tuần, nhưng nhiều tập đoàn lớn chỉ cho phép đưa sản phẩm vào sử dụng khi những tính năng đó đã được triển khai sẵn
Tôi đang thử nghiệm ý tưởng xây một lớp tích hợp như vậy bằng SQL trên các công nghệ mã nguồn mở như Kafka, Flink, Postgres, Iceberg, rồi thêm cú pháp đường tắt để việc xử lý chuỗi thời gian trong SQL thuận tiện hơn
https://github.com/DataSQRL/sqrl/
Mục tiêu là biến đổi SQL, tạo DAG tính toán, rồi dùng bộ tối ưu hóa dựa trên chi phí để cắt DAG và triển khai lên các công nghệ dữ liệu nền tảng, qua đó mang sức mạnh của kdb+ tới dưới dạng một gói tích hợp giữa công nghệ mã nguồn mở và SQL
Lẽ ra họ nên phát hành một phiên bản miễn phí có thể dùng cho nhiều mục đích
Theo tôi đây là trở ngại lớn nhất khiến kdb+ được công nhận là một công nghệ và sản phẩm xuất sắc, đồng thời phát triển trong cộng đồng lập trình viên
Tôi đã dùng kdb+ rất nhiều năm trong ngành tài chính và trở thành fan của nó. Trong thiết kế và sự đơn giản của nó có một vẻ thanh lịch như bắt rễ từ triết lý Unix. Ngay cả sau khi rời ngành tài chính và không còn làm ở công ty dùng kdb+, tôi vẫn thường có thôi thúc muốn dùng kdb+ cho những dự án nhỏ ở đây đó
Điều khiến tôi bức bối là giờ không thể dùng nữa, cũng không thể giới thiệu công cụ niche ít người biết này cho đồng nghiệp và geek out về việc nó đơn giản, hiệu quả đến mức nào trong một số tác vụ và phép tính cụ thể
Trước đây tôi từng phải viết mã C++ gửi dữ liệu vào kdb và một bộ giải mã wire protocol của họ, và chắc chắn khi đó có binary kdb để test cả hai
Tôi chỉ cần để kiểm thử thôi. Hình như Kx từng cấp giấy phép phát triển, nhưng chuyện này cũng lâu rồi
Tôi nhìn chung đồng ý với bài viết. Nếu làm mới từ đầu, tôi sẽ lưu dữ liệu trong Parquet và truy cập bằng Polars hoặc DuckDB
Tôi ghét q/kdb+ đến mức tự viết hẳn một ngôn ngữ cho phân tích chuỗi thời gian, nhưng thực ra Python đã là người chiến thắng từ nhiều năm nay rồi
Tôi từng xây một startup khá thành công với kdb+. Đó là công nghệ tôi biết, và nó giúp tạo ra sản phẩm vững chắc rất nhanh. Nhưng khi quy mô tăng lên, chúng tôi phải viết lại bằng phần mềm mã nguồn mở để có thể mở rộng đội ngũ
Tôi nhìn chung đồng ý với các khuyến nghị, nhưng tôi cho rằng Kx nên mở mã nguồn nền tảng của họ. Như vậy họ có thể thu hút kiểu lập trình viên muốn đóng góp cải tiến và công cụ cho hệ sinh thái
Kdb+ trông thực sự rất ngầu, và tôi từng học thử một chút cho vui cùng với APL. Có vẻ nó cũng khá phù hợp với nhiều mục đích trong ngành của tôi, nhưng giá thì vô lý
Tôi không thể trả kiểu 100.000 USD mỗi CPU như các ngân hàng tài chính vẫn trả. Thành ra họ gần như đang phớt lờ một tệp khách hàng tiềm năng khổng lồ
Những người khác có thể học kỹ thuật của họ rồi làm điều tương tự trong các lĩnh vực và ngôn ngữ khác
Bài viết này cần chỉnh lại vài điểm
clickhouse-localvàchdbTuy vậy, đến giờ vẫn chưa nơi nào thực sự thực hiện việc chuyển đổi. Có lẽ đó là một quyết định lớn nếu xét đến nhiều tích hợp đã mọc ra từ KDB. Dù vậy, rõ ràng nó mang cảm giác như một người kế thừa về mặt tinh thần
Tôi vẫn tự hỏi liệu bây giờ học phát triển kdb+ từ đầu có còn kiếm được rất nhiều tiền hay không. Tôi nhớ vài năm trước từng thấy tin tuyển dụng trả cỡ 1 triệu USD mỗi năm, và đã rất ngạc nhiên
Thật tiếc là kdb+ có điều khoản DeWitt, nên không ai có thể benchmark nó với các cơ sở dữ liệu khác được nhắc trong bài
Tôi cũng tò mò không biết có benchmark công khai nào do bên thứ ba thực hiện hay không