| commit | 4f5205a3d87821220a8dea9164a122788322884a | [log] [tgz] |
|---|---|---|
| author | Daniel Becker <daniel.becker@cloudera.com> | Fri Mar 15 17:52:26 2024 +0100 |
| committer | Impala Public Jenkins <impala-public-jenkins@cloudera.com> | Thu Mar 21 19:52:41 2024 +0000 |
| tree | 8121d8526784c303ec77d5b89786005e14f9b658 | |
| parent | 4d3676113f004fdc04f99ba4ba57887c5db3165b [diff] |
IMPALA-12926: Refactor BINARY type handling in the backend Currently the STRING and BINARY types are not distinguished in most of the backend. In contrast to the frontend, PrimitiveType::TYPE_BINARY is not used there at all, TYPE_STRING being used instead. This is to ensure that everything that works for STRING also works for BINARY. So far only file readers and writers have had to handle them differently, and they have access to ColumnDescriptors which contain AuxColumnType fields that differentiate these two types. However, only top-level columns have ColumnDescriptors. Adding support for BINARYs within complex types (see IMPALA-11491 and IMPALA-12651) necessitates adding type information about STRING vs BINARY to embedded fields as well. Using PrimitiveType::TYPE_BINARY would probably be the cleanest solution but it would affect huge parts of the code as TYPE_BINARY would have to be added to hundreds of switch statements and this would be error prone. Instead, this change introduces a new field in ColumnType: 'is_binary', which is true if the type is a BINARY and false otherwise. We keep using TYPE_STRING as the PrimitiveType of the ColumnType for BINARYs. This way full type information is present in ColumnType but code that does not differentiate between STRING and BINARY will continue to work for BINARY. With this change, AuxColumnType is no longer needed and is removed. See also IMPALA-5323 - https://gerrit.cloudera.org/#/c/18868/. This change is a very similar implementation of the same refactoring, except for the Kudu related parts. Testing: - added an extra test in binary-type.test Change-Id: Icedbad4e24a46e7731de11cc14218761d11fb86f Reviewed-on: http://gerrit.cloudera.org:8080/21157 Reviewed-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com> Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
Lightning-fast, distributed SQL queries for petabytes of data stored in open data and table formats.
Impala is a modern, massively-distributed, massively-parallel, C++ query engine that lets you analyze, transform and combine data from a variety of data sources:
The fastest way to try out Impala is a quickstart Docker container. You can try out running queries and processing data sets in Impala on a single machine without installing dependencies. It can automatically load test data sets into Apache Kudu and Apache Parquet formats and you can start playing around with Apache Impala SQL within minutes.
To learn more about Impala as a user or administrator, or to try Impala, please visit the Impala homepage. Detailed documentation for administrators and users is available at Apache Impala documentation.
If you are interested in contributing to Impala as a developer, or learning more about Impala's internals and architecture, visit the Impala wiki.
Impala only supports Linux at the moment. Impala supports x86_64 and has experimental support for arm64 (as of Impala 4.0). Impala Requirements contains more detailed information on the minimum CPU requirements.
Impala runs on Linux systems only. The supported distros are
Other systems, e.g. SLES12, may also be supported but are not tested by the community.
This distribution uses cryptographic software and may be subject to export controls. Please refer to EXPORT_CONTROL.md for more information.
See Impala's developer documentation to get started.
Detailed build notes has some detailed information on the project layout and build.