TableEnvironment
The recommended way to create a TableEnvironment
is to create from an EnvironmentSettings
object:
Alternatively, users can create a StreamTableEnvironment
from an existing StreamExecutionEnvironment
to interoperate with the DataStream API.
These APIs are used to create/remove Table API/SQL Tables and write queries:
APIs | Description | Docs |
---|---|---|
from_table_source(table_source) | Creates a table from a table source. | link |
scan(*table_path) | Scans a registered table from catalog and returns the resulting Table. It can be replaced by from_path. | |
register_table(name, table) | Registers a Table object under a unique name in the TableEnvironment’s catalog. Registered tables can be referenced in SQL queries. It can be replaced by create_temporary_view. | link |
register_table_source(name, table_source) | Registers an external TableSource in the TableEnvironment’s catalog. | |
register_table_sink(name, table_sink) | Registers an external TableSink in the TableEnvironment’s catalog. | link |
insert_into(target_path, table) | Instructs to write the content of a Table object into a sink table. Note that this interface would not trigger the execution of jobs. You need to call the “execute” method to execute your job. | |
sql_update(stmt) | Evaluates a SQL statement such as INSERT, UPDATE or DELETE or a DDL statement. It can be replaced by execute_sql. | link |
Execute/Explain Jobs
These APIs are used to explain/execute jobs. Note that the API execute_sql
can also be used to execute jobs.
APIs | Description | Docs |
---|---|---|
explain_sql(stmt, *extra_details) | Returns the AST and the execution plan of the specified statement. | link |
create_statement_set() | Creates a StatementSet instance which accepts DML statements or Tables. It can be used to execute a multi-sink job. |
Deprecated APIs
These APIs are used to register UDFs or remove the registered UDFs. Note that the API can also be used to register/remove UDFs. For more details about the different kinds of UDFs, please refer to User Defined Functions.
APIs | Description | Docs |
---|---|---|
create_temporary_function(path, function) | Registers a Python user defined function class as a temporary catalog function. | |
create_temporary_system_function(name, function) | Registers a Python user defined function class as a temporary system function. If the name of a temporary system function is the same as a temporary catalog function, the temporary system function takes precedence. | link |
create_java_function(path, function_class_name, ignore_if_exists=None) | Registers a Java user defined function class as a catalog function under the given path. If the catalog is persistent, the registered catalog function can be used across multiple Flink sessions and clusters. | |
create_java_temporary_function(path, function_class_name) | Registers a Java user defined function class as a temporary catalog function. | link |
create_java_temporary_system_function(name, function_class_name) | Registers a Java user defined function class as a temporary system function. | |
drop_function(path) | Drops a catalog function registered under the given path. | link |
drop_temporary_function(path) | Drops a temporary system function registered under the given name. | |
drop_temporary_system_function(name) | Drops a temporary system function registered under the given name. | link |
APIs | Description | Docs |
---|---|---|
register_function(name, function) | Registers a Python user-defined function under a unique name. Replaces already existing user-defined function under this name. It can be replaced by create_temporary_system_function. | |
register_java_function(name, function_class_name) | Registers a Java user defined function under a unique name. Replaces already existing user-defined functions under this name. It can be replaced by create_java_temporary_system_function. | link |
Dependency Management
These APIs are used to manage the Python dependencies which are required by the Python UDFs. Please refer to the Dependency Management documentation for more details.
APIs | Description | Docs |
---|---|---|
get_config() | Returns the table config to define the runtime behavior of the Table API. You can find all the available configuration options in and Python Configuration. The following code is an example showing how to set the configuration options through this API: # set the parallelism to 8 table_env.get_config().set(“parallelism.default”, “8”) # set the job name table_env.get_config().set(“pipeline.name”, “my_first_job”) |
Catalog APIs
These APIs are used to access catalogs and modules. You can find more detailed introduction in and Catalogs documentation.
APIs | Description | Docs |
---|---|---|
register_catalog(catalog_name, catalog) | Registers a Catalog under a unique name. | |
get_catalog(catalog_name) | Gets a registered Catalog by name. | link |
use_catalog(catalog_name) | Sets the current catalog to the given value. It also sets the default database to the catalog’s default one. | |
get_current_catalog() | Gets the current default catalog name of the current session. | link |
get_current_database() | Gets the current default database name of the running session. | |
use_database(database_name) | Sets the current default database. It has to exist in the current catalog. That path will be used as the default one when looking for unqualified object names. | link |
load_module(module_name, module) | Loads a Module under a unique name. Modules will be kept in the loaded order. | |
unload_module(module_name) | Unloads a Module with given name. | link |
use_modules(*module_names) | Enables and changes the resolution order of loaded modules. | |
list_catalogs() | Gets the names of all catalogs registered in this environment. | link |
list_modules() | Gets the names of all enabled modules registered in this environment. | |
list_full_modules() | Gets the names of all loaded modules (including disabled modules) registered in this environment. | link |
list_databases() | Gets the names of all databases in the current catalog. | |
list_tables() | Gets the names of all tables and views in the current database of the current catalog. It returns both temporary and permanent tables and views. | link |
list_views() | Gets the names of all views in the current database of the current catalog. It returns both temporary and permanent views. | |
list_user_defined_functions() | Gets the names of all user defined functions registered in this environment. | link |
list_functions() | Gets the names of all functions in this environment. | |
list_temporary_tables() | Gets the names of all temporary tables and views available in the current namespace (the current database of the current catalog). | link |
list_temporary_views() | Gets the names of all temporary views available in the current namespace (the current database of the current catalog). |
Before Flink 1.10 you can configure the statebackend, checkpointing and restart strategy via the StreamExecutionEnvironment
. And now you can configure them by setting key-value options in TableConfig
, see Fault Tolerance, and Checkpointing for more details.