Bối cảnh áp dụng Flink SQL
- Trong số các ứng dụng dựa trên Flink do Azar Matching Dev Team quản lý, có một ứng dụng legacy nặng sử dụng 96 CPU
- Ứng dụng này triển khai nhiều chức năng theo kiến trúc nguyên khối nên rất khó bảo trì
- Khi thay đổi node chạy do công việc hạ tầng, đã phát sinh vấn đề khiến ứng dụng không hoạt động bình thường
- Cần quyết định giữa việc tiếp tục bảo trì với mức độ mệt mỏi vận hành cao, hay thay thế bằng cách khác
Những lựa chọn có thể cân nhắc
- Các chức năng quan trọng của ứng dụng hiện có đã được triển khai trong ứng dụng Flink mới
- Nhóm đã cân nhắc cách thay thế phần phát hành sự kiện có điều kiện và thực thi logic
- Triển khai bằng một Flink App
- Ưu điểm: vận hành đơn giản
- Nhược điểm: ứng dụng dễ phình to, và nếu một phần lỗi thì các chức năng khác cũng dễ bị ảnh hưởng
- Triển khai bằng nhiều Flink App
- Ưu điểm: có thể quản lý độc lập
- Nhược điểm: số lượng ứng dụng tăng lên sẽ làm tăng gánh nặng
- Sử dụng Flink SQL
- Ưu điểm: có thể định nghĩa logic bằng truy vấn, chỉ cần quản lý một cụm
- Nhược điểm: khó biểu đạt logic phức tạp, và sẽ khó nếu chưa quen quản lý cụm
Lý do chọn Flink SQL và so sánh với các công nghệ thay thế
- Trước khi áp dụng Flink SQL, nhóm đã xem xét ksqlDB và Spark Structured Streaming
- Lý do chọn Flink SQL:
- High Availability
- Có thể lưu và khôi phục trạng thái ứng dụng một cách ổn định thông qua Checkpoint và Savepoint
- JobManager có thể được cấu hình ở chế độ HA
- Hỗ trợ các tính năng streaming nâng cao
- Hỗ trợ nhiều tính năng xử lý streaming bằng cú pháp SQL
- Hỗ trợ window, join, xử lý event time, watermark, v.v.
- Khả năng mở rộng thông qua UDF và Custom Connector
- Có thể kết nối hàm do người dùng định nghĩa với nhiều nguồn dữ liệu và sink khác nhau
vs ksqlDB
- Dù được bao gồm trong nền tảng Confluent, nhưng hoạt động HA trong xử lý streaming có trạng thái vẫn kém hiệu quả
vs Spark Structured Streaming
- Được triển khai dựa trên Spark SQL engine, có thể viết UDF và Custom Sink
- Do hoạt động theo đơn vị micro-batch nên có thể bất lợi cho xử lý thời gian thực
Xây dựng môi trường cụm và cách triển khai truy vấn
Kiểm thử đơn giản trên môi trường local
- Giới thiệu cách khởi chạy Flink Cluster trên local và gửi truy vấn SQL
Kiến trúc cụm trong môi trường vận hành
- Cấu hình Flink SQL Cluster trên Kubernetes
- So sánh Application mode và Session mode
Triển khai truy vấn bằng phương pháp GitOps
- Sử dụng GitHub Actions để triển khai truy vấn và dừng Job
Một số trường hợp vận hành chính và kinh nghiệm xử lý sự cố
Khi JobManager hoặc TaskManager bị fail
- JobManager có thể tiếp tục công việc ngay cả khi fail nhờ cấu hình HA
- Với TaskManager, công việc sẽ được phân phối lại và tiếp tục chạy khi có fail
Khi truy vấn bị fail
- Có thể xảy ra khi dữ liệu bất thường được đưa vào hoặc khi thiếu tài nguyên tính toán
- Có thể cấu hình bỏ qua lỗi định dạng JSON và đặt giá trị mặc định
Khi một số Job bị fail lúc khởi động lại cụm
- Cần điều chỉnh các thiết lập timeout và retry
Khi muốn sửa một điều kiện trong truy vấn rồi triển khai lại
- Chỉ trong các thay đổi đơn giản mới có thể khôi phục state bằng savepoint
Các điểm giám sát chính
- Kiểm tra các chỉ số như
numRunningJobs, taskmanager.cpu.load, taskmanager.memory.used
Kết luận
- Việc áp dụng Flink SQL đã cải thiện năng suất và hiệu quả vận hành
- Tính ổn định rất cao, và nhóm có kế hoạch triển khai mô hình GitOps Controller
1 bình luận
Các hệ thống phân tán như Flink cần duy trì HA bằng cách giữ 2~3 rack, và có vẻ như ở đây họ đã đảm bảo HA bằng cách tích hợp với Kubernetes. Nhưng rồi cuối cùng vẫn phải tính đến tài nguyên của các node worker của Kubernetes, nên tôi cũng tự hỏi liệu họ có cấu hình các node chỉ để chạy Flink hay không (có vẻ sẽ có vấn đề node worker bị sập khi tải Flink tăng cao).
Vậy từ góc nhìn đó, dùng Kubernetes có lợi thế gì không?
Ngoài ra, khi dùng window function trong Flink thì dữ liệu trong khoảng đó sẽ được giữ trong bộ nhớ để câu lệnh SQL join hoạt động, nên xét ở góc độ trade-off thì tôi cũng băn khoăn liệu Flink có phải là lựa chọn tốt hay không. Nếu theo thời gian, SQL ngày càng phình to mà job bị chết thì hậu quả sẽ rất lớn..
Bản thân tôi cũng đang suy nghĩ rằng khi cần join ở data source tầng trên cùng thì thay vì dùng Flink, có thể hạ xuống mức application level để xử lý theo cách nào.