Build Predictive Machine Learning with Flink | Workshop on Dec 18 | Register Now
We are pleased to announce the release of KSQL v0.5, aka the February 2018 release of KSQL. This release is focused on bug fixes and as well as performance and stability improvements.
Our focus for KSQL has been on improving its operational experience and on addressing issues and bugs reported by the KSQL user community or surfaced through KSQL’s rigorous testing strategies. With the general availability announcement today, we’re excited to see KSQL in production soon. Our efforts have centered around soak testing with eye towards supporting continuous workloads and operation, bounds testing, and performance testing, much of which runs on a daily basis through automated test suites. For example, our soak testing cluster has racked up over 1,000 hours and runs KSQL workloads 24×7. The performance tests we conduct allow us to understand performance characteristics of stateless and stateful KSQL queries. We currently run over 42 different tests that collect more than 700 metrics.
As they say, April showers bring May flowers. In this case, a relentless February focus on quality and stability will bring a trustworthy, production-ready product when KSQL sees its GA release next month—a future poised for a regular cadence of new features that help you take your KSQL-based systems in the direction you want to go.
If you have enjoyed this article, you might want to continue with the following resources to learn more about KSQL:
If you are interested in contributing to KSQL, we encourage you to get involved by sharing your feedback via the KSQL issue tracker, voting on existing issues by giving your +1 or opening pull requests. Use the #ksql channel in our public Confluent Slack community to ask questions, discuss use cases or help fellow KSQL users.
Tableflow can seamlessly make your Kafka operational data available to your AWS analytics ecosystem with minimal effort, leveraging the capabilities of Confluent Tableflow and Amazon SageMaker Lakehouse.
Building a headless data architecture requires us to identify the work we’re already doing deep inside our data analytics plane, and shift it to the left. Learn the specifics in this blog.