[hotfix] Refresh Slack invite link
[flink-web.git] / roadmap.md
index 7fdd3cdb508ea17b40c1b6fb16197a2f4ddbdd2f..d48eded4fb11bd62eafc9f90a76eac68ab985c2d 100644 (file)
@@ -22,154 +22,188 @@ under the License.
 
 <hr />
 
-{% toc %}
+{% toc %} 
 
-**Preamble:** This is not an authoritative roadmap in the sense of a strict plan with a specific
-timeline. Rather, we, the community, share our vision for the future and give an overview of the bigger
-initiatives that are going on and are receiving attention. This roadmap shall give users and
-contributors an understanding where the project is going and what they can expect to come.
+**Preamble:** This roadmap means to provide user and contributors with a high-level summary of ongoing efforts,
+grouped by the major threads to which the efforts belong. With so much that is happening in Flink, we
+hope that this helps with understanding the direction of the project.
+The roadmap contains both efforts in early stages as well as nearly completed
+efforts, so that users may get a better impression of the overall status and direction of those developments.
+
+More details and various smaller changes can be found in the
+[FLIPs](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals)
 
 The roadmap is continuously updated. New features and efforts should be added to the roadmap once
 there is consensus that they will happen and what they will roughly look like for the user.
 
-# Analytics, Applications, an the roles of DataStream, DataSet, and Table API
+**Last Update:** 2022-04-19
+
+<hr />
+
+# Feature Radar
+
+The feature radar is meant to give users guidance regarding feature maturity, as well as which features
+are approaching end-of-life. For questions, please contact the developer mailing list:
+[dev@flink.apache.org](mailto:dev@flink.apache.org)
+
+<div class="row front-graphic">
+  <img src="{{ site.baseurl }}/img/flink_feature_radar_3.svg" width="700px" />
+</div>
 
-Flink views stream processing as a [unifying paradigm for data processing]({{ site.baseurl }}/flink-architecture.html)
-(batch and real-time) and event-driven applications. The APIs are evolving to reflect that view:
+## Feature Stages
 
-  - The **Table API / SQL** is becoming the primary API for analytical use cases, in a unified way
-    across batch and streaming. To support analytical use cases in a more streamlined fashion,
-    the API is extended with additional functions ([FLIP-29](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97552739)).
+  - **MVP:** Have a look, consider whether this can help you in the future.
+  - **Beta:** You can benefit from this, but you should carefully evaluate the feature.
+  - **Ready and Evolving:** Ready to use in production, but be aware you may need to make some adjustments to your application and setup in the future, when you upgrade Flink.
+  - **Stable:** Unrestricted use in production
+  - **Reaching End-of-Life:** Stable, still feel free to use, but think about alternatives. Not a good match for new long-lived projects.
+  - **Deprecated:** Start looking for alternatives now
 
-    Like SQL, the Table API is *declarative*, operates on a *logical schema*, and applies *automatic optimization*.
-    Because of these properties, that API does not give direct access to time and state.
+<hr />
+
+# Unified Analytics: Where Batch and Streaming come Together; SQL and beyond.
+
+Flink is a streaming data system in its core, that executes "batch as a special case of streaming".
+Efficient execution of batch jobs is powerful in its own right; but even more so, batch processing
+capabilities (efficient processing of bounded streams) open the way for a seamless unification of
+batch and streaming applications.
 
-  - The **DataStream API** is the primary API for data-driven applications and data pipelines.
-    It uses *physical data types* (Java/Scala classes) and there is no automatic rewriting.
-    The applications have explicit control over *time* and *state* (state, triggers, proc. fun.).
+Unified streaming/batch up-levels the streaming data paradigm: It gives users consistent semantics across
+their real-time and lag-time applications. Furthermore, streaming applications often need to be complemented
+by batch (bounded stream) processing, for example when reprocessing data after bugs or data quality issues,
+or when bootstrapping new applications. A unified API and system make this much easier.
 
-    In the long run, the DataStream API should fully subsume the DataSet API through *bounded streams*.
-    
-# Batch and Streaming Unification
+## A unified SQL Platform
 
-Flink's approach is to cover batch and streaming by the same APIs, on a streaming runtime.
-[This blog post]({{ site.baseurl }}/news/2019/02/13/unified-batch-streaming-blink.html)
-gives an introduction to the unification effort. 
+The community has been building Flink to a powerful basis for a unified (batch and streaming) SQL analytics
+platform, and is continuing to do so.
 
-The biggest user-facing parts currently ongoing are:
+SQL has very strong cross-batch-streaming semantics, allowing users to use the same queries for ad-hoc analytics
+and as continuous queries. Flink already contains an efficient unified query engine, and a wide set of
+integrations. With user feedback, those are continuously improved.
 
-  - Table API restructuring [FLIP-32](https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions)
-    that decouples the Table API from batch/streaming specific environments and dependencies.
+**Going Beyond a SQL Stream/Batch Processing Engine**
 
-  - The new source interfaces [FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface)
-    generalize across batch and streaming, making every connector usable as a batch and
-    streaming data source.
+  - To extend the capability of a pure stream processor and make Flink ready for future use cases, 
+    [FLIP-188](https://cwiki.apache.org/confluence/display/FLINK/FLIP-188%3A+Introduce+Built-in+Dynamic+Table+Storage)
+    has been announced adding built in dynamic table storage.
+  - The experience of updating Flink SQL based jobs has been rather cumbersome as it could have
+    lead to new job graphs making restoring from savepoints/checkpoints impossible. 
+    [FLIP-190](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191336489&src=contextnavpagetreemode)
+    that already has been shipped as MVP is targeting this.
 
-  - The introduction of *upsert-* or *changelog-* sources [FLINK-8545](https://issues.apache.org/jira/browse/FLINK-8545)
-    will support more powerful streaming inputs to the Table API.
 
-On the runtime level, the streaming operators are extended to also support the data consumption
-patterns required for some batch operations ([discussion thread](https://lists.apache.org/thread.html/cb1633d10d17b0c639c3d59b2283e9e01ecda3e54ba860073c124878@%3Cdev.flink.apache.org%3E)).
-This is also groundwork for features like efficient [side inputs](https://cwiki.apache.org/confluence/display/FLINK/FLIP-17+Side+Inputs+for+DataStream+API).
+**Platform Infrastructure**
 
-# Fast Batch (Bounded Streams)
+  - After [FLIP-163](https://cwiki.apache.org/confluence/display/FLINK/FLIP-163%3A+SQL+Client+Improvements) 
+    the community is working again on a set of SQL Client usability improvements
+    ([FLIP-189](https://cwiki.apache.org/confluence/display/FLINK/FLIP-189%3A+SQL+Client+Usability+Improvements))
+    which is aiming at improving the user experience, when using the SQL client.
 
-The community's goal is to make Flink's performance on bounded streams (batch use cases) competitive with that
-of dedicated batch processors. While Flink has been shown to handle some batch processing use cases faster than
-widely-used batch processors, there are some ongoing efforts to make sure this the case for broader use cases:
+**Support for Common Languages, Formats, Catalogs**
 
-  - Faster and more complete SQL/Table API: The community is merging the Blink query processor which improves on
-    the current query processor by adding a much richer set of runtime operators, optimizer rules, and code generation.
-    The new query processor will have full TPC-DS support and up to 10x performance improvement over the current
-    query processor ([FLINK-11439](https://issues.apache.org/jira/browse/FLINK-11439)).
+  - With [FLIP-216](https://cwiki.apache.org/confluence/display/FLINK/FLIP-216%3A++Introduce+pluggable+dialect+and++decouple+Hive+connector)
+    there's now the initiative to introduce pluggable dialects on the example of the Hive connector.
+    Including so many dependencies to make dialects work has lead to an overhead for contributors 
+    and users.
 
-  - Exploiting bounded streams to reduce the scope of fault tolerance: When input data is bounded, it is
-    possible to completely buffer data during shuffles (memory or disk) and replay that data after a
-    failure. This makes recovery more fine grained and thus much more efficient
-    ([FLINK-10288](https://issues.apache.org/jira/browse/FLINK-10288)).
+Flink has a broad SQL coverage for batch (full TPC-DS support) and a state-of-the-art set of supported
+operations in streaming. There is continuous effort to add more functions and cover more SQL operations.
 
-  - An application on bounded data can schedule operations after another, depending on how the operators
-    consume data (e.g., first build hash table, then probe hash table).
-    We are separating the scheduling strategy from the ExecutionGraph to support different strategies
-    on bounded data ([FLINK-10429](https://issues.apache.org/jira/browse/FLINK-10429)).
+## Deep Batch / Streaming Unification for the DataStream API
 
-  - Caching of intermediate results on bounded data, to support use cases like interactive data exploration.
-    The caching generally helps with applications where the client submits a series of jobs that build on
-    top of one another and reuse each others' results.
-    [FLINK-11199](https://issues.apache.org/jira/browse/FLINK-11199)
+The *DataStream API* is Flink's *physical* API, for use cases where users need very explicit control over data
+types, streams, state, and time. This API is evolving to support efficient batch execution on bounded data.
 
-  - External Shuffle Services (mainly bounded streams) to support decoupling from computation and
-    intermediate results for better resource efficiency on systems like Yarn.
-    [FLIP-31](https://cwiki.apache.org/confluence/display/FLINK/FLIP-31%3A+Pluggable+Shuffle+Manager).
+DataStream API executes the same dataflow shape in batch as in streaming, keeping the same operators.
+That way users keep the same level of control over the dataflow, and our goal is to mix and switch between
+batch/streaming execution in the future to make it a seamless experience.
 
-Various of these enhancements can be taken from the contributed code from the
-[Blink fork](https://github.com/apache/flink/tree/blink).
+**Unified Sources and Sinks**
 
-To exploit the above optimizations for bounded streams in the DataStream API, we need
-break parts of the API and explicitly model bounded streams.
+  - The first APIs and implementations of sources were specific to either streaming programs in the DataStream API
+    ([SourceFunction](https://github.com/apache/flink/blob/master/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/functions/source/SourceFunction.java)),
+    or to batch programs in the DataSet API ([InputFormat](https://github.com/apache/flink/blob/master/flink-core/src/main/java/org/apache/flink/api/common/io/InputFormat.java)).
 
-# Stream Processing Use Cases
+    In this effort, we are creating sources that work across batch and streaming execution. The aim is to give
+    users a consistent experience across both modes, and to allow them to easily switch between streaming and batch
+    execution for their unbounded and bounded streaming applications.
+    The interface for this New Source API is done and available, and we are working on migrating more source connectors
+    to this new model, see [FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface).
 
-Flink will get the new modes to stop a running application while ensuring that output and
-side-effects are consistent and committed prior to shutdown. *SUSPEND* commit output/side-effects,
-but keep state, while *TERMINATE* drains state and commits the outputs and side effects.
-[FLIP-34](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103090212) has the details.
-  
-The *new source interface* effort ([FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface))
-aims to give simpler out-of-the box support for event time and watermark generation for sources.
-Sources will have the option to align their consumption speed in event time, to reduce the
-size of in-flight state when re-processing large data volumes in streaming
-([FLINK-10887](https://issues.apache.org/jira/browse/FLINK-10886)).
+  - Similar to the sources, the original sink APIs are also specific to streaming
+    ([SinkFunction](https://github.com/apache/flink/blob/master/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/functions/sink/SinkFunction.java))
+    and batch ([OutputFormat](https://github.com/apache/flink/blob/master/flink-core/src/main/java/org/apache/flink/api/common/io/OutputFormat.java))
+    APIs and execution.
 
-To make evolution of streaming state simpler, we plan to add first class support for
-[Protocol Buffers](https://developers.google.com/protocol-buffers/), similar to the way
-Flink deeply supports Avro state evolution ([FLINK-11333](https://issues.apache.org/jira/browse/FLINK-11333)).
+    We have introduced a new API for sinks that consistently handles result writing and committing (*Transactions*)
+    across batch and streaming. The first iteration of the API exists, and we are porting sinks and refining the
+    API in the process. See [FLIP-143](https://cwiki.apache.org/confluence/display/FLINK/FLIP-143%3A+Unified+Sink+API).
 
-# Deployment, Scaling, Security
+<hr />
+
+# Applications vs. Clusters; "Flink as a Library"
 
-There is a big effort to design a new way for Flink to interact with dynamic resource
-pools and automatically adjust to resource availability and load.
-Part of this is  becoming a *reactive* way of adjusting to changing resources (like
-containers/pods being started or removed) [FLINK-10407](https://issues.apache.org/jira/browse/FLINK-10407),
-while other parts are resulting in *active* scaling policies where Flink decides to add
-or remove TaskManagers, based on internal metrics.
+The goal of these efforts is to make it feel natural to deploy (long running streaming) Flink applications.
+Instead of starting a cluster and submitting a job to that cluster, these efforts support deploying a streaming
+job as a self contained application.
 
-To support the active resource management also in Kubernetes, we are adding a Kubernetes Resource Manager
-[FLINK-9953](https://issues.apache.org/jira/browse/FLINK-9953).
+For example as a simple Kubernetes deployment; deployed and scaled like a regular application without extra workflows.
 
-The Flink Web UI is being ported to a newer framework and getting additional features for
-better introspection of running jobs [FLINK-10705](https://issues.apache.org/jira/browse/FLINK-10705).
+  - There is currently a Kubernetes Operator being developed by the community. See
+    [FLIP-212](https://cwiki.apache.org/confluence/display/FLINK/FLIP-212%3A+Introduce+Flink+Kubernetes+Operator).
 
-The community is working on extending the interoperability with authentication and authorization services.
-Under discussion are general extensions to the [security module abstraction](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Flink-security-improvements-td21068.html)
-as well as specific [enhancements to the Kerberos support](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Flink-Kerberos-Improvement-td25983.html).
+<hr />
 
-# Ecosystem
+# Performance
 
-The community is working on extending the support for catalogs, schema registries, and
-metadata stores, including support in the APIs and the SQL client ([FLINK-11275](https://issues.apache.org/jira/browse/FLINK-11275)).
-We are adding DDL (Data Definition Language) support to make it easy to add tables and streams to
-the catalogs ([FLINK-10232](https://issues.apache.org/jira/browse/FLINK-10232)).
+Continuous work to keep improving performance and recovery speed.
 
-There is a broad effort to integrate Flink with the Hive Ecosystem, including
-metastore and Hive UDF support [FLINK-10556](https://issues.apache.org/jira/browse/FLINK-10556).
+## Faster Checkpoints and Recovery
 
-# Connectors & Formats
+The community is continuously working on improving checkpointing and recovery speed.
+Checkpoints and recovery are stable and have been a reliable workhorse for years. We are still
+trying to make it faster, more predictable, and to remove some confusions and inflexibility in some areas.
 
-Support for additional connectors and formats is a continuous process.
+  - [FLIP-183](https://cwiki.apache.org/confluence/display/FLINK/FLIP-183%3A+Dynamic+buffer+size+adjustment)
+    is targeting size of checkpoints by debloating the buffers. A first beta is already available.
+  - With [FLIP-151](https://cwiki.apache.org/confluence/display/FLINK/FLIP-151%3A+Incremental+snapshots+for+heap-based+state+backend) 
+    there is an ongoing effort to implement a heap based state backend.
 
-# Miscellaneous
+<hr />
+
+# Apache Flink as part of an ever evolving data ecosystem
+
+There is almost no use case in which Apache Flink is used on its own. It has established itself
+as part of many data related reference architectures. In fact you'll find the squirrel logo covering
+several aspects. The community has added a lot of connectors and formats. With the already mentionend
+[FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface) and
+[FLIP-143](https://cwiki.apache.org/confluence/display/FLINK/FLIP-143%3A+Unified+Sink+API)
+a new default for connectors has been established.
+
+  - There are efforts to revise the formats API with
+    [FLIP-219](https://cwiki.apache.org/confluence/display/FLINK/FLIP-219%3A+Revised+Format+API)
+  - There is ongoing work on new connectors 
+    (e.g. [Pinot](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=177045634))
+  - Connectors will be hosted in an external repository going forward. See the 
+    [ML thread](https://lists.apache.org/thread/8k1xonqt7hn0xldbky1cxfx3fzh6sj7h)
+
+<hr />
+
+# Documentation
+
+There are various dedicated efforts to simplify the maintenance and structure (more intuitive navigation/reading)
+of the documentation.
+
+  - Docs Tech Stack: [FLIP-157](https://cwiki.apache.org/confluence/display/FLINK/FLIP-157+Migrate+Flink+Documentation+from+Jekyll+to+Hugo)
+  - General Docs Structure: [FLIP-42](https://cwiki.apache.org/confluence/display/FLINK/FLIP-42%3A+Rework+Flink+Documentation)
+  - SQL Docs: [FLIP-60](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=127405685)
+
+<hr />
 
-  - We are changing the build setup to not bundle Hadoop by default, but rather offer pre-packaged Hadoop
-    libraries for the use with Yarn, HDFS, etc. as convenience downloads
-    [FLINK-11266](https://issues.apache.org/jira/browse/FLINK-11266).
+# Stateful Functions
 
-  - The Flink code base is being updates to support Java 9, 10, and 11
-    [FLINK-8033](https://issues.apache.org/jira/browse/FLINK-8033),
-    [FLINK-10725](https://issues.apache.org/jira/browse/FLINK-10725).
-    
-  - To reduce compatibility issues with different Scala versions, we are working using Scala
-    only in the Scala APIs, but not in the runtime. That removes any Scala dependency for all
-    Java-only users, and makes it easier for Flink to support different Scala versions
-    [FLINK-11063](https://issues.apache.org/jira/browse/FLINK-11063).
+The Stateful Functions subproject has its own roadmap published under [statefun.io](https://statefun.io/).
 
+# Flink Kubernetes Operator
+The Flink Kubernetes Operator subproject has its own roadmap under the [documentation](https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/development/roadmap/).