чем отличается external table и managed table

Русские Блоги

Базовая таблица управления Hive и внешняя таблица

В грамматике Hive есть ключевое слово для создания таблицы EXTERNAL, это ключевое слово указывает тип таблицы, в Hive есть два типа таблиц: таблица управления и управляемая таблица (внешняя таблица). Если ключевое слово EXTERNAL не добавлено, все созданные таблицы являются таблицами управления.

1. Информация таблицы управления

Как проверить, является ли таблица управляемой или управляемой? Вы можете использовать команду desc:

2. Внешний стол

Затем мы создаем внешнюю таблицу.Чтобы создать внешнюю таблицу, просто добавьте ключевое слово EXTERNAL в исходный оператор создания таблицы.

Вы видите, что внешняя таблица emp_ext была успешно создана, давайте посмотрим на подробное описание таблицы:

3. Разница между таблицами управления и внешними таблицами.

Так в чем же самое большое различие между внешними таблицами и таблицами управления? Для журналов веб-сайтов крупных компаний обычно существует специальный отдел для обработки журналов. После обработки журналы будут сохранены в hdfs. Например, путь сохранения следующий:
/hdfs/sitelog
​ 20190212.txt
​ 20190213.txt
​ 20190214.txt
Теперь есть два бизнес-отдела: интеллектуальный анализ данных и машинное обучение. Им обоим необходимо анализировать этот журнал. Если они хранятся в кусте в виде таблицы управления, то путь к файлу на hdfs будет следующим образом:
/user/dept1/hive
​ 20190212.txt
​ 20190213.txt
​ 20190214.txt
/user/dept2/hive
​ 20190212.txt
​ 20190213.txt
​ 20190214.txt
Таким образом, в hdfs хранится по три копии каждого файла. Если используется таблица управления, каждый файл будет сохранен по 9 копий, что приведет к большой трате дискового пространства. В это время вам необходимо использовать характеристики внешней таблицы. При создании таблицы внешняя таблица может указывать путь к файлу данных, например / hdfs / sitelog. Если вам не нужно использовать таблицу позже, вы можете удалить таблицу, но данные не будут удалены. Таблица управления удалит данные вместе при удалении таблицы.

Различия между таблицами управления и внешними таблицами заключаются в следующем:

4. Создайте внешнюю таблицу.

Мы создаем внешнюю таблицу, указав путь hdfs, а затем загружаем данные без загрузки.

Не имеет значения, если каталог, указанный в расположении, не существует, но родительский каталог должен иметь права доступа, иначе будет сообщено об ошибке. Создайте каталог и поместите данные в каталог ниже:

Затем мы запрашиваем таблицу:

Вы можете видеть, что данные были загружены, но мы не загрузили данные, поэтому, пока файл данных находится в соответствующем каталоге для внешней таблицы, к внешней таблице можно получить доступ в обычном режиме, что также является обычной практикой на предприятиях.

Чтобы узнать больше о больших данных, подпишитесь на публичный аккаунт WeChat: большие данные и искусственный интеллект для начинающих.

Отсканируйте QR-код ниже, чтобы следовать:

Источник

Managed vs. External Tables

Hive fundamentally knows two different types of tables:

Introduction

This document lists some of the differences between the two but the fundamental difference is that Hive assumes that it owns the data for managed tables. That means that the data, its properties and data layout will and can only be changed via Hive command. The data still lives in a normal file system and nothing is stopping you from changing it without telling Hive about it. If you do though it violates invariants and expectations of Hive and you might see undefined behavior.

Another consequence is that data is attached to the Hive entities. So, whenever you change an entity (e.g. drop a table) the data is also changed (in this case the data is deleted). This is very much like with traditional RDBMS where you would also not manage the data files on your own but use a SQL-based access to do so.

For external tables Hive assumes that it does not manage the data.

Managed or external tables can be identified using the DESCRIBE FORMATTED table_name command, which will display either MANAGED_TABLE or EXTERNAL_TABLE depending on table type.

Statistics can be managed on internal and external tables and partitions for query optimization.

Feature comparison

This means that there are lots of features which are only available for one of the two table types but not the other. This is an incomplete list of things:

Managed tables

Use managed tables when Hive should manage the lifecycle of the table, or when generating temporary tables.

External tables

An external table describes the metadata / schema on external files. External table files can be accessed and managed by processes outside of Hive. External tables can access data stored in sources such as Azure Storage Volumes (ASV) or remote HDFS locations. If the structure or partitioning of an external table is changed, an MSCK REPAIR TABLE table_name statement can be used to refresh metadata information.

Use external tables when files are already present or in remote locations, and the files should remain even if the table is dropped.

Источник

Big Data от A до Я. Часть 5.1: Hive — SQL-движок над MapReduce

Привет, Хабр! Мы продолжаем наш цикл статьей, посвященный инструментам и методам анализа данных. Следующие 2 статьи нашего цикла будут посвящены Hive — инструменту для любителей SQL. В предыдущих статьях мы рассматривали парадигму MapReduce, и приемы и стратегии работы с ней. Возможно многим читателям некоторые решения задач при помощи MapReduce показались несколько громоздкими. Действительно, спустя почти 50 лет после изобретения SQL, кажется довольно странным писать больше одной строчки кода для решения задач вроде «посчитай мне сумму транзакций в разбивке по регионам».

С другой стороны, классические СУБД, такие как Postgres, MySQL или Oracle не имеют такой гибкости в масштабировании при обработке больших массивов данных и при достижении объема большего дальнейшая поддержка становится большой головоной болью.

Собственно, Apache Hive был придуман для того чтобы объединить два этих достоинства:

Общее описание

Hive появился в недрах компании Facebook в 2007 году, а через год исходники hive были открыты и переданы под управление apache software foundation. Изначально hive представлял собой набор скриптов поверх hadoop streaming (см 2-ю статью нашего цикла), позже развился в полноценный фреймворк для выполнения запросов к данным поверх MapReduce.

Актуальная версия apache hive(2.0) представляет собой продвинутый фреймворк, который может работать не только поверх фреймворка Map/Reduce, но и поверх Spark(про спарк у нас будут отдельные статьи в цикле), а также Apache Tez.

Apache hive используют в production такие компании как Facebook, Grooveshark, Last.Fm и многие другие. Мы в Data-Centric alliance используем HIve в качестве основного хранилища логов нашей рекламной платформы.

Архитектура

Hive представляет из себя движок, который превращает SQL-запросы в цепочки map-reduce задач. Движок включает в себя такие компоненты, как Parser(разбирает входящие SQL-запрсоы), Optimimer(оптимизирует запрос для достижения большей эффективности), Planner (планирует задачи на выполнение) Executor(запускает задачи на фреймворке MapReduce.

Для работы hive также необходимо хранилище метаданных. Дело в том что SQL предполагает работу с такими объектами как база данных, таблица, колонки, строчки, ячейки и тд. Поскольку сами данные, которые использует hive хранятся просто в виде файлов на hdfs — необходимо где-то хранить соответствие между объектами hive и реальными файлами.

В качестве metastorage используется обычная реляционная СУБД, такая как MySQL, PostgreSQL или Oracle.

Command line interface

Для того чтобы попробовать работу с hive проще всего воспользоваться его командной строкой. Современная утилита для работы с hive называется beeline (привет нашим партнёрам из одноименного оператора 🙂 ) Для этого на любой машине в hadoop-кластере (см. наш туториал по hadoop) с установленным hive достаточно набрать команду.

Далее необходимо установить соединение с hive-сервером:

Data Units

При работе с hive можно выделить следующие объекты которыми оперирует hive:

База данных

База данных представляет аналог базы данных в реляционных СУБД. База данных представляет собой пространство имён, содержащее таблицы. Команда создания новой базы данных выглядит следующим образом:

Database и Schema в данном контексте это одно и тоже. Необязательная добавка IF NOT EXISTS как не сложно догадаться создает базу данных только в том случае если она еще не существует.

Пример создания базы данных:

Для переключения на соответствующую базу данных используем команду USE:

Таблица

Таблица в hive представляет из себя аналог таблицы в классической реляционной БД. Основное отличие — что данные hive’овских таблиц хранятся просто в виде обычных файлов на hdfs. Это могут быть обычные текстовые csv-файлы, бинарные sequence-файлы, более сложные колоночные parquet-файлы и другие форматы. Но в любом случае данные, над которыми настроена hive-таблица очень легко прочитать и не из hive.

Таблицы в hive бывают двух видов:

Классическая таблица, данные в которую добавляются при помощи hive. Вот пример создания такой таблицы (источник примера):

Загрузить данные мы сможем при помощи следующей команды:

После hive переместит данныe, хранящемся в нашем файле в хранилище hive. Убедиться в этом можно прочитав данные напрямую из файла в хранилище hive в hdfs:

Классические таблицы можно также создавать как результат select-запроса к другим таблицам:

Кстати говоря, SELECT для создания таблицы в данном случае уже запустит mapreduce-задачу.

Внешняя таблица, данные в которую загружаются внешними системами, без участия hive. Для работы с внешними таблицами при создании таблицы нужно указать ключевое слово EXTERNAL, а также указать путь до папки, по которому хранятся файлы:

После этого таблицей можно пользоваться точно так же как и обычными таблицами hive. Самое удобное в этом, что вы можете просто скопировать файл в нужную папочку в hdfs, а hive будет автоматом подхватывать новые файлы при запросах к соответствующей таблице. Это очень удобно при работе например с логами.

Партиция (partition)

Так как hive представляет из себя движок для трансляции SQL-запросов в mapreduce-задачи, то обычно даже простейшие запросы к таблице приводят к полному сканированию данных в этой таблицы. Для того чтобы избежать полного сканирования данных по некоторым из колонок таблицы можно произвести партиционирование этой таблицы. Это означает, что данные относящиеся к разным значениям будут физически храниться в разных папках на HDFS.

Для создания партиционированной таблицы необходимо указать по каким колонкам будет произведено партиционирование:

При заливке данных в такую таблицу необходимо явно указать, в какую партицию мы заливаем данные:

Посмотрим теперь как выглядит структура директорий:

Видно, что структура директорий выглядит таким образом, что каждой партиции соответствует отдельная папка на hdfs. Теперь, если мы будем запускать какие-либо запросы, у казав в условии WHERE ограничение на значения партиций — mapreduce возьмет входные данные только из соответствующих папок.

В случае External таблиц партиционирование работает аналогичным образом, но подобную структуру директорий придется создавать вручную.

Партиционирование очень удобно например для разделения логов по датам, так как правило любые запросы за статистикой содержат ограничение по датам. Это позволяет существенно сократить время запроса.

Бакет

Партиционирование помогает сократить время обработки, если обычно при запросах известны ограничения на значения какого-либо столбца. Однако оно не всегда применимо. Например — если количество значений в столбце очень велико. Напрмер — это может быть ID пользователя в системе, содержащей несколько миллионов пользователей.

В этом случае на помощь нам придет разделение таблицы на бакеты. В один бакет попадают строчки таблицы, для которых значение совпадает значение хэш-функции вычисленное по определенной колонке.

При любой работе с бакетированными таблицами необходимо не забывать включать поддержку бакетов в hive (иначе hive будет работать с ними как с обычными таблицами):

Для создания таблицы разбитой на бакеты используется конструкция CLUSTERED BY

Так как команда Load используется для простого перемещения данных в хранилище hive — в данном случае для загрузки она не подходит, так как данные необходимо предобработать, правильно разбив их на бакеты. Поэтому их нужно загрузить при помощи команды INSERT из другой таблицы(например из внешней таблицы):

После выполнения команды убедимся, что данные действительно разбились на 10 частей:

Теперь при запросах за данными, относящимися к определенному пользователю, нам не нужно будет сканировать всю таблицу, а только 1/10 часть этой таблицы.

Checklist по использованию hive

Теперь мы разобрали все объекты, которыми оперирует hive. После того как таблицы созданы — можно работать с ними, так как с таблицами обычных баз данных. Однако не стоит забывать о том что hive — это все же движок по запуску mapreduce задач над обычными файлами, и полноценной заменой классическим СУБД он не является. Необдуманное использование таких тяжелых команд, как JOIN может привести к очень долгим задачам. Поэтому прежде чем строить вашу архитектуру на основе hive — необходимо несколько раз подумать. Приведем небольшой checklist по использованию hive:

Заключение

В данной статье мы разобрали архитектуру hive, data unit-ы, которыми оперирует hive, привели примеры по созданию и заполнению таблиц hive. В следующей статье цикла мы рассмотрим продвинутые возможности hive, включающие в себя:

Источник

Разница между внутренними таблицами улья и внешними таблицами?

может ли кто-нибудь сказать мне разницу между внешней таблицей улья и внутренними таблицами. Я знаю, что разница возникает при падении таблицы. Я не понимаю, что вы подразумеваете под тем, что данные и метаданные удаляются во внутренних и только метаданные удаляются во внешних таблицах. Может кто-нибудь объяснить мне с точки зрения узлов, пожалуйста.

18 ответов:

если у вас есть секционированная таблица, разделы хранятся в базе данных(это позволяет hive использовать списки разделов, не заходя в файловую систему и не находя их и т. д.). Такие вещи являются «метаданными».

когда вы отбрасываете внутреннюю таблицу, она отбрасывает данные, а также отбрасывает метаданные.

когда вы отбрасываете внешнюю таблицу, она отбрасывает только метаданные. Это означает, что hive сейчас не знает об этих данных. Он не касается самих данных.

таблицы Hive могут быть созданы как внешние, так и внутренние. Это выбор, который влияет на то, как данные загружаются, управляются и управляются.

используйте внешние таблицы, когда:

используйте внутренние таблицы, когда:

вы хотите, чтобы Hive полностью управлял жизненным циклом таблицы и данных.

чтобы ответить на ваш вопрос:

для внешних таблиц Hive не перемещает данные в каталог хранилища. Если внешняя таблица удаляется, то метаданные таблицы удаляются, но не данные.

для внутренних таблиц Hive перемещает данные в каталог хранилища. Если таблица будет удалена, то метаданные таблицы и данные будут удалены.

Для справки:

разницу между внутренними & Внешние таблицы:

внешняя таблица хранит файлы на сервере HDFS, но таблицы не связаны с исходным файлом полностью.

при удалении внешней таблицы файл все еще остается на сервере HDFS.

в качестве примера, если вы создаете внешняя таблица под названием «table_test» в улье с помощью HIVE-QL и связать таблица в файл «файл»,тогда удаление » table_test «из HIVE не удалит» файл » из HDFS.

внешние табличные файлы доступны всем, кто имеет доступ к файловой структуре HDFS, и поэтому безопасность должна управляться в HDFS уровень файлов / папок.

метаданные хранятся на главном узле, и удаление внешней таблицы из HIVE только удаляет метаданные не файл данных.

Для Внутренних Таблиц-

Hive может иметь внутренние или внешние таблицы, это выбор, который влияет на то, как данные загружаются, управляются и управляются.

используйте внешние таблицы, когда:

используйте внутренние таблицы, когда:

внутренние таблицы полезны, если вы хотите, чтобы Hive управлял полным жизненным циклом ваших данных, включая удаление, тогда как внешние таблицы полезны, когда файлы используются за пределами Hive.

также имейте в виду, что Hive-это большое хранилище данных. Когда вы хотите удалить таблицу, вы не хотите потерять гигабайты или терабайты данных. Создание, перемещение и копирование данных в таком масштабе может занять много времени. Когда вы отбрасываете «управляемую» таблицу, улей также будет удалять свои данные. При удалении «внешней» таблицы удаляется только определение схемы из мета-хранилища hive. Данные по hdfs все еще остаются.

рассмотрим такой сценарий, который лучше всего подходит для внешней таблицы:

задание MapReduce (MR) фильтрует огромный файл журнала, чтобы выплюнуть n файлы sub log (например, каждый файл sub log содержит определенный тип сообщения log) и вывод i. e n файлы sub log хранятся в hdfs.

эти файлы журнала должны быть загружены в таблицы Hive для выполнения дальнейшего анализа, в этом сценарии я бы рекомендовал внешнюю таблицу(ы), потому что фактические файлы журнала генерируются и принадлежащий внешнему процессу, т. е. заданию MR, кроме того, вы можете избежать дополнительного шага загрузки каждого сгенерированного файла журнала в соответствующую таблицу Hive.

единственная разница в поведении (а не в предполагаемом использовании), основанная на моих ограниченных исследованиях и тестировании до сих пор (с использованием Hive 1.1.0-cdh5.12.0), похоже, заключается в том, что когда таблица отбрасывается

(Примечание: см. раздел «управляемые и внешние таблицы» в https://cwiki.apache.org/confluence/display/Hive/LanguageManual + DDL в котором перечислены некоторые другие различия, которые я не совсем понял)

Я считаю, что Hive выбирает место, где ему нужно создать таблицу на основе следующего приоритета сверху вниз

если параметр » Location «не используется во время» создания таблицы hive», используется указанное выше правило приоритета. Это применимо как для внутренних, так и внешних таблиц. Это означает, что внутренняя таблица не обязательно должна находиться в каталоге хранилища и может находиться в любом другом месте.

Примечание: я, возможно, пропустил некоторые сценарии, но на основе моего ограниченного исследования, поведение как внутренней, так и расширенной таблицы кажется одинаковым, за исключением одного различия (удаление данных), описанного выше. Я попробовал следующие сценарии для внутренних и внешних таблиц.

внешняя таблица-это таблица, для которой Hive не управляет хранилищем. При удалении внешней таблицы удаляется только определение в Hive. Данные остаются. Внутренняя таблица-это таблица, которой управляет улей. При удалении внутренней таблицы удаляются как определение в Hive, так и данные.

улей хранит только метаданные в метасторе и исходные данные в стороне от улья, когда мы используем внешнюю таблицу, мы можем дать местоположение » этими нашими исходными данными не будет эффекта, когда мы отбрасываем таблицу

когда данные уже есть в HDFS, можно создать внешнюю таблицу Hive для описания данных. Он называется внешним, поскольку данные во внешней таблице указываются в свойствах расположения, а не в каталоге хранилища по умолчанию.

при хранении данных во внутренних таблицах Hive полностью управляет жизненным циклом таблицы и данных. Это означает, что данные удаляются после внутренней таблицы. Если внешняя таблица удаляется, метаданные таблицы удаляются но данные сохраняются. В большинстве случаев внешняя таблица предпочтительнее, чтобы избежать удаления данных вместе с таблицами по ошибке.

для управляемых таблиц Hive управляет жизненным циклом их данных. Hive хранит данные для управляемых таблиц в подкаталоге под каталогом, определенным hive.метастор.склад.реж по умолчанию.

в это время определяется внешняя таблица, которая указывает на эти данные, но не является ее владельцем.

в Hive мы также можем создать внешнюю таблицу. Он сообщает Hive ссылаться на данные, которые находятся в существующем расположении за пределами каталога хранилища. Удаление внешних таблиц приведет к удалению метаданных, но не данных.

внутренние:таблица создана первый и Data загружается позже

внешний: Data и присутствует и таблица и создана сверху его.

простыми словами, есть две вещи:

улей может управлять вещами на складе, т. е. он не будет удалять данные из хранилища. Когда мы удаляем таблицу:

1) для внутренних таблиц данных осуществляется внутри склада. Поэтому будет удален.

2)для внешних таблиц данные управляются извечно из хранилища. Поэтому его нельзя удалить, и клиенты, кроме hive, также могут его использовать.

Источник

Hive Managed Table vs External Table : LOCATION directory

When you create an external (unmanaged) table, Hive keeps the data in the directory specified by the LOCATION keyword intact. But if you were to execute the same CREATE command and drop the EXTERNAL keyword, the table would be a managed table, and Hive would move the contents of the LOCATION directory into /user/hive/ warehouse/stocks, which may not be the behavior you expect.

4 Answers 4

In both cases(managed or external) Location is optional so whenever you specify LOCATION data will be stored on the same HDFC LOCATION PATH irrespective of which table you are creating(managed or external). And, if you don’t use LOCATION, default location path which is mentioned in hive-site.xml is considered.

When you create a table with the location keyword it will point the table to the location. The location specifies the path in hdfs to the data files.

When ever you specify a location you have to make sure that you place the data files there. In the above example we are explicitly telling hive where the data is in the external table. If we didn’t specify a table the default location would like below, and this is true for any table produced without location statement unless your sysadmin changes the default of course.

Managed and unmanaged tables Every Spark SQL table has metadata information that stores the schema and the data itself.

A managed table is a Spark SQL table for which Spark manages both the data and the metadata. In the case of managed table, Databricks stores the metadata and data in DBFS in your account. Since Spark SQL manages the tables, doing a DROP TABLE example_data deletes both the metadata and data.

Some common ways of creating a managed table are:

You can create an unmanaged table with your data in data sources such as Cassandra, JDBC table, and so on. See Data sources for more information about the data sources supported by Databricks. Some common ways of creating an unmanaged table are:

Источник