Một vài năm trước, Kafka rất đơn giản và dễ hiểu: Chỉ gồm Producer và Consumer. Hiện tại chúng ta có thêm: Kafka Connect, Kafka Streams và KSQL vào hệ sinh thái Kafka. Những thành phần mới này thay thế cho Producer & Consumer hay hoàn thiện Kafka.
Hãy cùng làm rõ những vấn đề này:
Có 5 loại công việc trong Apache Kafka, và nó tương ứng với 5 API của Kafka.
- Kafka Producer API: Ứng dụng trực tiếp xuất bản data (VD: Clickstream, logs,IoT)
- Kafka Connect Source API: Bridging giữa Kafka và một datasource mà chúng ta không nắm quyền kiểm soát (CDC, Postgres, MongoDB, Twitter, REST API)
- Kafka Streams API/ KSQL: Ứng dụng muốn tổng hợp từ Kafka và đẩy ngược lại chính Kafka, còn được gọi là stream processing.
+ Sử dụng KSQL khi muốn xử lý công việc 1 cách real-time như SQL hoặc tính toán đơn giản. Sử dụng Kafka Stream API nếu bạn sử dụng logic phức tạp trong xử lý dữ liệu của bạn.
- Kafka Consumer API: Đọc 1 stream và ngay lập tức xử lý một hành động với nó (Ví dụ : Gửi Email,...)
- Kafka Connect Sink API: Đọc 1 stream và lưu trữ nó vào một target store (Kafka to S3, Kafka to HDFS, Kafka to PostgreSQL, Kafka to MongoDB, etc.)
Về cơ bản, Kafka Consumer và Kafka Sink API có thể dễ dàng thay thế cho nhau, nếu bạn sẵn sàng tự viết code cho những gì bạn cần.
=> Tổng hợp lại, những gạch đầu dòng kể trên sẽ giúp bạn thực hiện được những luồng một cách hiệu quả với ít lượng code nhất và giảm thiểu rủi ro thất bại nhất.
1. Kafka Producer API
- Lợi thế:
- Dễ sử dụng: Gửi data, là bất đồng bộ và sẽ nhận được 1 callback khi gửi xong. Vô cùng phù hợp với những ứng dụng mà trực tiếp điều hướng message như logs, clickstreams, IoT.
- Rất thường xuyên được sử dụng khi kết hợp với Proxy.
- Hạn chế:
- Kafka Producer API có thể mở rộng và xây dựng lên để làm rất nhiều thứ, tuy nhiên nó yêu cầu người phát triển phả viết thêm rất nhiều code. Vấn đề lớn nhất là khi mọi ngừoi cố gắng thực thi ETL giữa các databasse và Kafka khi sử dụng Producer API. Dứoi đấy là một số thứ mà không dễ để thực hiện:
- Làm sao để có thể theo dõi source Offset (i.e Làm sao để tiếp tục Producer xử lý tiếp luồng khi nó bị stop.)
- Làm thế nào để chia tải giữa các Producer?
2. Kafka Connect Source API:
- Lợi thế:
- Kafka Connect Source API là 1 framework xây dựng trên nền của Producer API. Nó được xây dựng để :
- Phân tán task cho các Producer xử lý song song
- Cơ chế dễ dàng để các Producer xử lý tiếp tại nơi mình đang bỏ dở.
- Cuối cùng là một loạt các trình kết nối có sẵn mà có thể tạn dụng ngay từ hôm nay để lấy dữ liệu từ hầu hết các nguồn dữ liệu mà k cần tốn dòng code nào.
- Hạn chế:
- Lợi thế cũng chính là nhược điểm, việc có các trình kết nối có sẵn có nghĩa là chúng ta phải tự viết các trình kết nối đến nguồn dữ liệu của chúng ta.
- Lợi thế:
- Kafka Consumer API thậm chí còn đơn giản hơn nữa, sử dụng Consumer Group từ đó Topic của bạn có thể được consumed song song. Tuy nhiên bạn cần cẩn thận với một số thứ, như là offset management và commits. Cũng như là sự cân bằng tải và hạn chế tạm thời. Rất dễ để viết. Nó phù hợp cho bất cứ loại nào công việc nào statelesss. Như là notification!
- Nhược điểm:
- Khi bạn thực hiện một số thao tác như ETL, Kafka Connect Sinks sẽ phù hợp hơn vì chúng sẽ giúp bạn tránh đc một số luồng logic phức tạp cũng như kết nối đến external data source.
- Lợi thế:
- Tương tự như Kafka Connect Source API, Kafka Connect Sink API cho phép bạn nâng tầm hệ sinh thái có sẵn của Kafka. Sử dụng Kafka Connector để thực hiện thao tác stream ETL mà k phải viết một dòng code nào. Kafka Connect cũng là API bậc cao của Consumer API nhưng nó dùng giống với Consumer.
- Nhược điểm:
- Giống Kafka Connect Source.
- Lợi thế:
- Nếu bạn muốn truy cập vào trong luồng xử lý, như là đọc dữ liệu từ Kafka 1 cách real-time và sau khi xử lý nó, viết lại vào Kafka. Bạn gần như không thể làm được với Kafka Consumer API và Kafka Producer API. (Vì 1 thằng chỉ chuyên đọc và 1 thằng chỉ chuyên viết). May mắn thay, Kafka Project giờ có Kafka Streams API, cho phép bạn viết với High Level DSL (resembling to a functional programming / Apache Spark type of program), hoặc Low Level API (resembling more to Apache Storm). Kafka Streams API yêu cầu bạn cần phải viết code, nhưng che giấu và bạn không phải quan tâm tới độ phức tạp của bảo trì producers và consumers. Để bạn có thể tập trung vào logic của luồng xử lý. Nó cũng đi kèm với join, aggregations và khả năng chính xác 1 lần.
- Nhược điểm:
- Bạn có thể viết thêm code vào làm rối rắm và phức tạp. Do việc debug và test là khá khó. Mặc dù hiện tại đã có test-utils library.
- Cuối cùng, mặc dù Kafka Streams nhìn đơn giản, nhưng nó thực ra rất khó để học và sẽ tạo thành 1 ra 1 chuỗi state, mà thường đc backup ở Kafka Topics. Điều này có nghĩa là tuỳ thuộc vào độ phức tạp của cấu trúc, Kafka Streams sẽ phải xử lý rất nhiều message, mặc dù đi vs nó bạn sẽ có stateless và chịu lỗi cao.
Không có nhận xét nào:
Đăng nhận xét