[hotfix] Refresh Slack invite link
[flink-web.git] / roadmap.md
index 46a09331cb8143ba76d1fc73d96d7403797c2163..d48eded4fb11bd62eafc9f90a76eac68ab985c2d 100644 (file)
@@ -24,139 +24,186 @@ under the License.
 
 {% 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.
 
-**Last Update:** 2019-09-04
+**Last Update:** 2022-04-19
 
-# Analytics, Applications, and the roles of DataStream, DataSet, and Table API
+<hr />
 
-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 Radar
 
-  - 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 being extended with more convenient multi-row/column operations ([FLIP-29](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97552739)).
+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)
 
-    - 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.
+<div class="row front-graphic">
+  <img src="{{ site.baseurl }}/img/flink_feature_radar_3.svg" width="700px" />
+</div>
 
-    - The Table API is also the foundation for the Machine Learning (ML) efforts inititated in ([FLIP-39](https://cwiki.apache.org/confluence/display/FLINK/FLIP-39+Flink+ML+pipeline+and+ML+libs)), that will allow users to easily build, persist and serve ([FLINK-13167](https://issues.apache.org/jira/browse/FLINK-13167)) ML pipelines/workflows through a set of abstract core interfaces.
+## Feature Stages
 
-  - 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.). 
-    In the long run, the DataStream API will fully subsume the DataSet API through *bounded streams*.
-    
-# Batch and Streaming Unification
+  - **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
 
-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.
+<hr />
 
-The biggest user-facing parts currently ongoing are:
+# Unified Analytics: Where Batch and Streaming come Together; SQL and beyond.
 
-  - 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. Some key parts of the FLIP are completed, such as the modular decoupling of expression parsing and the removal of Scala dependencies, and the next step is to unify the function stack ([FLINK-12710](https://issues.apache.org/jira/browse/FLINK-12710)).
+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 new source interfaces generalize across batch and streaming, making every connector usable as a batch and streaming data source ([FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface)).
+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.
 
-  - The introduction of *upsert-* or *changelog-* sources will support more powerful streaming inputs to the Table API ([FLINK-8545](https://issues.apache.org/jira/browse/FLINK-8545)).
+## A unified SQL Platform
 
-On the runtime level, the streaming operators were extended in Flink 1.9 to also support the data consumption patterns required for some batch operations — which is groundwork for upcoming features like efficient [side inputs](https://cwiki.apache.org/confluence/display/FLINK/FLIP-17+Side+Inputs+for+DataStream+API).
+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.
 
-Once these unification efforts are completed, we can move on to unifying the DataStream API.
+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.
 
-# Fast Batch (Bounded Streams)
+**Going Beyond a SQL Stream/Batch Processing Engine**
 
-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:
+  - 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.
 
-  - 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 Blink-based query processor has full TPC-H support (with TPC-DS planned for the next release) and up to 10x performance improvement over the pre-1.9 Flink query processor ([FLINK-11439](https://issues.apache.org/jira/browse/FLINK-11439)).
 
-  - 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)).
+**Platform Infrastructure**
 
-  - 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)).
+  - 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.
 
-Various of these enhancements can be integrated from the contributed code in the [Blink fork](https://github.com/apache/flink/tree/blink). To exploit these optimizations for bounded streams also in the DataStream API, we first need to break parts of the API and explicitly model bounded streams.
+**Support for Common Languages, Formats, Catalogs**
 
-# Stream Processing Use Cases
-  
-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)).
+  - 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.
 
-To overcome the current pitfalls of checkpoint performance under backpressure scenarios, the community is introducing the concept of [unaligned checkpoints](https://lists.apache.org/thread.html/fd5b6cceb4bffb635e26e7ec0787a8db454ddd64aadb40a0d08a90a8@%3Cdev.flink.apache.org%3E). This will allow checkpoint barriers to overtake the output/input buffer queue to speed up alignment and snapshot the inflight data as part of checkpoint state.
+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.
 
-We also plan to add first class support for
-[Protocol Buffers](https://developers.google.com/protocol-buffers/) to make evolution of streaming state simpler, similar to the way
-Flink deeply supports Avro state evolution ([FLINK-11333](https://issues.apache.org/jira/browse/FLINK-11333)).
+## Deep Batch / Streaming Unification for the DataStream API
 
-# Deployment, Scaling and Security
+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.
 
-To provide downstream projects with a consistent way to programatically control Flink deployment submissions, the Client API is being [refactored](https://lists.apache.org/thread.html/ce99cba4a10b9dc40eb729d39910f315ae41d80ec74f09a356c73938@%3Cdev.flink.apache.org%3E). The goal is to unify the implementation of cluster deployment and job submission in Flink and allow more flexible job and cluster management — independent of cluster setup or deployment mode. [FLIP-52](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=125308637) proposes the deprecation and removal of the legacy Program interface.
+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.
 
+**Unified Sources and Sinks**
 
-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).
+  - 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)).
 
-# Resource Management and Configuration
+    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).
 
-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.
+  - 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.
 
-  - The current TaskExecutor memory configuration in Flink has some shortcomings that make it hard to reason about or optimize resource utilization, such as: (1) different configuration models for memory footprint for Streaming and Batch; (2) complex and user-dependent configuration of off-heap state backends (typically RocksDB) in Streaming execution; (3) and sub-optimal memory utilization in Batch execution. [FLIP-49](https://cwiki.apache.org/confluence/display/FLINK/FLIP-49%3A+Unified+Memory+Configuration+for+TaskExecutors) proposes to unify managed memory configuration for TaskExecutors to make this process more generic and intuitive for the user.
+    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).
 
-  - In a similar way, we are introducing changes to Flink's resource management module with [FLIP-53](https://cwiki.apache.org/confluence/display/FLINK/FLIP-53%3A+Fine+Grained+Operator+Resource+Management) to enable fine-grained control over Operator resource utilization according to known (or unknown) resource profiles. Since the requirements of this FLIP conflict with the existing static slot allocation model, this model first needs to be refactored to provide dynamic slot allocation ([FLIP-56](https://cwiki.apache.org/confluence/display/FLINK/FLIP-56%3A+Dynamic+Slot+Allocation)).
+<hr />
 
-  - To support the active resource management also in Kubernetes, we are working on a Kubernetes Resource Manager
-([FLINK-9953](https://issues.apache.org/jira/browse/FLINK-9953)).
+# Applications vs. Clusters; "Flink as a Library"
 
-Spillable Heap State Backend ([FLIP-50](https://cwiki.apache.org/confluence/display/FLINK/FLIP-50%3A+Spill-able+Heap+Keyed+State+Backend)), a new state backend configuration, is being implemented to support spilling cold state data to disk before heap memory is exhausted and so reduce the chance of OOM errors in job execution. This is not meant as a replacement for RocksDB, but more of an enhancement to the existing Heap State Backend.
+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.
 
-# Ecosystem
+For example as a simple Kubernetes deployment; deployed and scaled like a regular application without extra workflows.
 
-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 have added DDL (Data Definition Language) support in Flink 1.9 to make it easy to add tables to catalogs ([FLINK-10232](https://issues.apache.org/jira/browse/FLINK-10232)), and will extend the support to streaming use cases in the next release.
+  - 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).
 
-There is also an ongoing effort to fully integrate Flink with the Hive ecosystem. The latest release made headway in bringing Hive data and metadata interoperability to Flink, along with initial support for Hive UDFs. Moving forward, the community will stabilize and expand on the existing implementation to support Hive DDL syntax and types, as well as other desirable features and capabilities described in [FLINK-10556](https://issues.apache.org/jira/browse/FLINK-10556).
+<hr />
 
-# Non-JVM Languages (Python)
+# Performance
 
-The work initiated in Flink 1.9 to bring full Python support to the Table API ([FLIP-38](https://cwiki.apache.org/confluence/display/FLINK/FLIP-38%3A+Python+Table+API)) will continue in the upcoming releases, also in close collaboration with the Apache Beam community. The next steps include:
+Continuous work to keep improving performance and recovery speed.
 
-  - Adding support for Python UDFs (Scalar Functions (UDF), Tabular Functions (UDTF) and Aggregate Functions (UDAF)). The details of this implementation are defined in [FLIP-58](https://cwiki.apache.org/confluence/display/FLINK/FLIP-58%3A+Flink+Python+User-Defined+Function+for+Table+API) and leverage the [Apache Beam portability framework](https://docs.google.com/document/d/1B9NmaBSKCnMJQp-ibkxvZ_U233Su67c1eYgBhrqWP24/edit#heading=h.khjybycus70) as a basis for UDF execution.
+## Faster Checkpoints and Recovery
+
+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.
+
+  - [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.
+
+<hr />
 
-  - Integrating Pandas as the final effort — that is, making functions in Pandas directly usable in the Python Table API.
+# Apache Flink as part of an ever evolving data ecosystem
 
-# Connectors and Formats
+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 />
 
-Support for additional connectors and formats is a continuous process.
+# Stateful Functions
 
-# Miscellaneous
+The Stateful Functions subproject has its own roadmap published under [statefun.io](https://statefun.io/).
 
-  - The Flink code base has been updated to support Java 9 ([FLINK-8033](https://issues.apache.org/jira/browse/FLINK-8033)) and Java 11 support is underway ([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)).
+# 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/).