| <?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 rev="1.1" id="views"> |
| |
| <title>Overview of Impala Views</title> |
| <titlealts audience="PDF"><navtitle>Views</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="Tables"/> |
| <data name="Category" value="Schemas"/> |
| <data name="Category" value="Views"/> |
| </metadata> |
| </prolog> |
| |
| <conbody> |
| |
| <p> |
| Views are lightweight logical constructs that act as aliases for queries. You can specify a view name in a |
| query (a <codeph>SELECT</codeph> statement or the <codeph>SELECT</codeph> portion of an |
| <codeph>INSERT</codeph> statement) where you would usually specify a table name. |
| </p> |
| |
| <p> |
| A view lets you: |
| </p> |
| |
| <ul> |
| <li> |
| Issue complicated queries with compact and simple syntax: |
| <codeblock>-- Take a complicated reporting query, plug it into a CREATE VIEW statement... |
| create view v1 as select c1, c2, avg(c3) from t1 group by c3 order by c1 desc limit 10; |
| -- ... and now you can produce the report with 1 line of code. |
| select * from v1;</codeblock> |
| </li> |
| |
| <li> |
| Reduce maintenance, by avoiding the duplication of complicated queries across multiple applications in |
| multiple languages: |
| <codeblock>create view v2 as select t1.c1, t1.c2, t2.c3 from t1 join t2 on (t1.id = t2.id); |
| -- This simple query is safer to embed in reporting applications than the longer query above. |
| -- The view definition can remain stable even if the structure of the underlying tables changes. |
| select c1, c2, c3 from v2;</codeblock> |
| </li> |
| |
| <li> |
| Build a new, more refined query on top of the original query by adding new clauses, select-list |
| expressions, function calls, and so on: |
| <codeblock>create view average_price_by_category as select category, avg(price) as avg_price from products group by category; |
| create view expensive_categories as select category, avg_price from average_price_by_category order by avg_price desc limit 10000; |
| create view top_10_expensive_categories as select category, avg_price from expensive_categories limit 10;</codeblock> |
| This technique lets you build up several more or less granular variations of the same query, and switch |
| between them when appropriate. |
| <!-- My original assumption was confirmed correct by Alex: outer ORDER BY not actually needed. |
| In this case, we put an <codeph>ORDER BY</codeph> clause on the <q>top 10</q> view, even though there was already an <codeph>ORDER BY</codeph> |
| on the <q>top 10000</q> view, because when a query is executed in parallel and distributed among multiple nodes, the ordering is only |
| guaranteed if there is an <codeph>ORDER BY</codeph> clause at the outermost level. |
| --> |
| </li> |
| |
| <li> |
| Set up aliases with intuitive names for tables, columns, result sets from joins, and so on: |
| <codeblock>-- The original tables might have cryptic names inherited from a legacy system. |
| create view action_items as select rrptsk as assignee, treq as due_date, dmisc as notes from vxy_t1_br; |
| -- You can leave original names for compatibility, build new applications using more intuitive ones. |
| select assignee, due_date, notes from action_items;</codeblock> |
| </li> |
| |
| <li> |
| Swap tables with others that use different file formats, partitioning schemes, and so on without any |
| downtime for data copying or conversion: |
| <codeblock>create table slow (x int, s string) stored as textfile; |
| create view report as select s from slow where x between 20 and 30; |
| -- Query is kind of slow due to inefficient table definition, but it works. |
| select * from report; |
| |
| create table fast (s string) partitioned by (x int) stored as parquet; |
| -- ...Copy data from SLOW to FAST. Queries against REPORT view continue to work... |
| |
| -- After changing the view definition, queries will be faster due to partitioning, |
| -- binary format, and compression in the new table. |
| alter view report as select s from fast where x between 20 and 30; |
| select * from report;</codeblock> |
| </li> |
| |
| <li> |
| Avoid coding lengthy subqueries and repeating the same subquery text in many other queries. |
| </li> |
| |
| <li rev="2.3.0 collevelauth"> |
| Set up fine-grained security where a user can query some columns from a table but not other columns. |
| Because <keyword keyref="impala23_full"/> and higher support column-level authorization, this technique is no longer |
| required. If you formerly implemented column-level security through views, see |
| <xref keyref="sg_hive_sql"/> for details about the column-level authorization feature. |
| </li> |
| </ul> |
| |
| <p> |
| The SQL statements that configure views are <xref href="impala_create_view.xml#create_view"/>, |
| <xref href="impala_alter_view.xml#alter_view"/>, and <xref href="impala_drop_view.xml#drop_view"/>. You can |
| specify view names when querying data (<xref href="impala_select.xml#select"/>) and copying data from one |
| table to another (<xref href="impala_insert.xml#insert"/>). The <xref href="impala_with.xml#with">WITH</xref> |
| clause creates an inline view, that only exists for the duration of a single query. |
| </p> |
| |
| <codeblock>[localhost:21000] > create view trivial as select * from customer; |
| [localhost:21000] > create view some_columns as select c_first_name, c_last_name, c_login from customer; |
| [localhost:21000] > select * from some_columns limit 5; |
| Query finished, fetching results ... |
| +--------------+-------------+---------+ |
| | c_first_name | c_last_name | c_login | |
| +--------------+-------------+---------+ |
| | Javier | Lewis | | |
| | Amy | Moses | | |
| | Latisha | Hamilton | | |
| | Michael | White | | |
| | Robert | Moran | | |
| +--------------+-------------+---------+ |
| [localhost:21000] > create view ordered_results as select * from some_columns order by c_last_name desc, c_first_name desc limit 1000; |
| [localhost:21000] > select * from ordered_results limit 5; |
| Query: select * from ordered_results limit 5 |
| Query finished, fetching results ... |
| +--------------+-------------+---------+ |
| | c_first_name | c_last_name | c_login | |
| +--------------+-------------+---------+ |
| | Thomas | Zuniga | | |
| | Sarah | Zuniga | | |
| | Norma | Zuniga | | |
| | Lloyd | Zuniga | | |
| | Lisa | Zuniga | | |
| +--------------+-------------+---------+ |
| Returned 5 row(s) in 0.48s</codeblock> |
| |
| <p> |
| The previous example uses descending order for <codeph>ORDERED_RESULTS</codeph> because in the sample TPCD-H |
| data, there are some rows with empty strings for both <codeph>C_FIRST_NAME</codeph> and |
| <codeph>C_LAST_NAME</codeph>, making the lowest-ordered names unuseful in a sample query. |
| </p> |
| |
| <codeblock>create view visitors_by_day as select day, count(distinct visitors) as howmany from web_traffic group by day; |
| create view top_10_days as select day, howmany from visitors_by_day order by howmany limit 10; |
| select * from top_10_days;</codeblock> |
| |
| <p conref="../shared/impala_common.xml#common/usage_notes_blurb"/> |
| |
| <p conref="../shared/impala_common.xml#common/describe_formatted_view"/> |
| |
| <p conref="../shared/impala_common.xml#common/create_table_like_view"/> |
| |
| <p conref="../shared/impala_common.xml#common/complex_types_blurb"/> |
| |
| <p conref="../shared/impala_common.xml#common/complex_types_views"/> |
| |
| <p conref="../shared/impala_common.xml#common/straight_join_nested_queries"/> |
| |
| <p conref="../shared/impala_common.xml#common/restrictions_blurb"/> |
| |
| <ul> |
| <li> |
| <p> |
| You cannot insert into an Impala view. (In some database systems, this operation is allowed and inserts |
| rows into the base table.) You can use a view name on the right-hand side of an <codeph>INSERT</codeph> |
| statement, in the <codeph>SELECT</codeph> part. |
| </p> |
| </li> |
| |
| <li> |
| <!-- This same text is conref'ed in the #views and the #partition_pruning topics. --> |
| <p conref="../shared/impala_common.xml#common/partitions_and_views"/> |
| </li> |
| |
| <li rev="1.4.0"> |
| <p conref="../shared/impala_common.xml#common/order_by_view_restriction"/> |
| </li> |
| <li> |
| <p conref="../shared/impala_common.xml#common/tablesample_caveat"/> |
| </li> |
| </ul> |
| |
| <p> |
| <b>Related statements:</b> <xref href="impala_create_view.xml#create_view"/>, |
| <xref href="impala_alter_view.xml#alter_view"/>, <xref href="impala_drop_view.xml#drop_view"/> |
| </p> |
| </conbody> |
| </concept> |