mirror of
https://github.com/apache/impala.git
synced 2025-12-30 12:02:10 -05:00
8377b9949c
For this change to land in master, the audience="hidden" code review needs to be completed first. Otherwise, the doc build would still work but the audience="hidden" content would be visible rather than hidden as desired. Some work happening in parallel might introduce additional instances of audience="Cloudera". I suggest addressing those in a followup CR so this global change can land quickly. Since the changes apply across so many different files, but are so narrow in scope, I suggest that the way to validate (check that no extraneous changes were introduced accidentally) is to diff just the changed lines: git diff -U0 HEAD^ HEAD In patch set 2, I updated other topics marked audience="Cloudera" by CRs that were pushed in the meantime. Change-Id: Ic93d89da77e1f51bbf548a522d98d0c4e2fb31c8 Reviewed-on: http://gerrit.cloudera.org:8080/5613 Reviewed-by: John Russell <jrussell@cloudera.com> Tested-by: Impala Public Jenkins
76 lines
3.7 KiB
XML
76 lines
3.7 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!--
|
|
Licensed to the Apache Software Foundation (ASF) under one
|
|
or more contributor license agreements. See the NOTICE file
|
|
distributed with this work for additional information
|
|
regarding copyright ownership. The ASF licenses this file
|
|
to you under the Apache License, Version 2.0 (the
|
|
"License"); you may not use this file except in compliance
|
|
with the License. You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing,
|
|
software distributed under the License is distributed on an
|
|
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
|
KIND, either express or implied. See the License for the
|
|
specific language governing permissions and limitations
|
|
under the License.
|
|
-->
|
|
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
|
|
<concept id="schema_objects">
|
|
|
|
<title>Impala Schema Objects and Object Names</title>
|
|
<titlealts audience="PDF"><navtitle>Schema Objects and Object Names</navtitle></titlealts>
|
|
<prolog>
|
|
<metadata>
|
|
<data name="Category" value="Impala"/>
|
|
<data name="Category" value="SQL"/>
|
|
<data name="Category" value="Data Analysts"/>
|
|
<data name="Category" value="Developers"/>
|
|
<data name="Category" value="Querying"/>
|
|
<data name="Category" value="Schemas"/>
|
|
</metadata>
|
|
</prolog>
|
|
|
|
<conbody>
|
|
|
|
<p>
|
|
<indexterm audience="hidden">schema objects</indexterm>
|
|
With Impala, you work with schema objects that are familiar to database users: primarily databases, tables, views,
|
|
and functions. The SQL syntax to work with these objects is explained in
|
|
<xref href="impala_langref_sql.xml#langref_sql"/>. This section explains the conceptual knowledge you need to
|
|
work with these objects and the various ways to specify their names.
|
|
</p>
|
|
|
|
<p>
|
|
Within a table, partitions can also be considered a kind of object. Partitioning is an important subject for
|
|
Impala, with its own documentation section covering use cases and performance considerations. See
|
|
<xref href="impala_partitioning.xml#partitioning"/> for details.
|
|
</p>
|
|
|
|
<p>
|
|
Impala does not have a counterpart of the <q>tablespace</q> notion from some database systems. By default,
|
|
all the data files for a database, table, or partition are located within nested folders within the HDFS file
|
|
system. You can also specify a particular HDFS location for a given Impala table or partition. The raw data
|
|
for these objects is represented as a collection of data files, providing the flexibility to load data by
|
|
simply moving files into the expected HDFS location.
|
|
</p>
|
|
|
|
<p>
|
|
Information about the schema objects is held in the
|
|
<xref href="impala_hadoop.xml#intro_metastore">metastore</xref> database. This database is shared between
|
|
Impala and Hive, allowing each to create, drop, and query each other's databases, tables, and so on. When
|
|
Impala makes a change to schema objects through a <codeph>CREATE</codeph>, <codeph>ALTER</codeph>,
|
|
<codeph>DROP</codeph>, <codeph>INSERT</codeph>, or <codeph>LOAD DATA</codeph> statement, it broadcasts those
|
|
changes to all nodes in the cluster through the <xref href="impala_components.xml#intro_catalogd">catalog
|
|
service</xref>. When you make such changes through Hive or directly through manipulating HDFS files, you use
|
|
the <xref href="impala_refresh.xml#refresh">REFRESH</xref> or
|
|
<xref href="impala_invalidate_metadata.xml#invalidate_metadata">INVALIDATE METADATA</xref> statements on the
|
|
Impala side to recognize the newly loaded data, new tables, and so on.
|
|
</p>
|
|
|
|
<p outputclass="toc"/>
|
|
</conbody>
|
|
</concept>
|