Migrowanie obciążeń usługi Azure HDInsight 3.6 Hive do usługi HDInsight 4.0

  • Artykuł

Usługa HDInsight 4.0 ma kilka zalet w usłudze HDInsight 3.6. Oto omówienie nowości w usłudze HDInsight 4.0.

W tym artykule opisano kroki migracji obciążeń hive z usługi HDInsight 3.6 do 4.0, w tym

  • Uaktualnianie kopii i schematu magazynu metadanych Hive
  • Sejf migracji pod kątem zgodności ACID
  • Zachowywanie zasad zabezpieczeń programu Hive

Nowe i stare klastry usługi HDInsight muszą mieć dostęp do tych samych kont magazynu.

Migracja tabel programu Hive do nowego konta magazynu wymaga wykonania oddzielnego kroku. Zobacz Migracja programu Hive między kontami magazynu.

Zmiany w programie Hive 3 i co nowego:

Zmiany klienta Hive

Hive 3 obsługuje tylko klienta elastycznego, beeline do uruchamiania zapytań i poleceń administracyjnych programu Hive z wiersza polecenia. Usługa Beeline używa połączenia JDBC z serwerem HiveServer do wykonywania wszystkich poleceń. Analizowanie, kompilowanie i wykonywanie operacji odbywa się w programie HiveServer.

Wprowadzono obsługiwane polecenia interfejsu wiersza polecenia programu Hive przez wywołanie metody Beeline przy użyciu słowa kluczowego Hive jako użytkownika programu Hive lub wywołanie linii beeline przy użyciu polecenia beeline -u <JDBC URL>. Adres URL JDBC można uzyskać ze strony Ambari Hive.

Screenshot showing JDBC URL output.

Użycie rozwiązania Beeline (zamiast grubego interfejsu wiersza polecenia hive klienta, który nie jest już obsługiwany) ma kilka zalet, w tym:

  • Zamiast obsługiwać całą bazę kodu Hive, można obsługiwać tylko klienta JDBC.
  • Obciążenie uruchamiania jest niższe przy użyciu rozwiązania Beeline, ponieważ cała baza kodu Hive nie jest zaangażowana.

Można również wykonać skrypt hive, który znajduje się w katalogu "/usr/bin", który wywołuje połączenie beeline przy użyciu adresu URL JDBC.

Screenshot showing beeline connection output.

Architektura klienta elastycznego ułatwia zabezpieczanie danych w programie

  • Stan sesji, wewnętrzne struktury danych, hasła itd. znajdują się na kliencie zamiast na serwerze.
  • Niewielka liczba demonów wymaganych do wykonywania zapytań upraszcza monitorowanie i debugowanie.

Serwer HiveServer wymusza ustawienia listy dozwolonych i listy zablokowanych, które można zmienić za pomocą SET poleceń. Korzystając z list zablokowanych, można ograniczyć konfigurację pamięci, aby zapobiec niestabilności serwera Hive. Można skonfigurować wiele wystąpień serwera HiveServer z różnymi listami dozwolonymi i zablokowanymi w celu ustalenia różnych poziomów stabilności.

Zmiany magazynu metadanych Hive

Hive obsługuje teraz tylko zdalny magazyn metadanych zamiast osadzonego magazynu metadanych (w ramach maszyny wirtualnej HS2 JVM). Magazyn metadanych Hive znajduje się w węźle w klastrze zarządzanym przez system Ambari w ramach stosu usługi HDInsight. Autonomiczny serwer poza klastrem nie jest obsługiwany. Polecenia key=value nie są już ustawiane w wierszu polecenia w celu skonfigurowania magazynu metadanych Hive. Na podstawie wartości skonfigurowanej w poleceniu "hive.metastore.uris=" " używana usługa HMS i nawiązano połączenie.

Zmiana aparatu wykonywania

Apache Tez zastępuje mapReduce jako domyślny aparat wykonywania programu Hive. Usługa MapReduce jest przestarzała, począwszy od programu Hive 2.0 Refer HIVE-12300. W przypadku wyrażeń skierowanych grafów acyklicznych (DAG) i elementów pierwotnych transferu danych wykonywanie zapytań Hive w usłudze Tez zwiększa wydajność. Zapytania SQL przesyłane do programu Hive są wykonywane w następujący sposób

  1. Program Hive kompiluje zapytanie.
  2. Tez wykonuje zapytanie.
  3. Usługa YARN przydziela zasoby dla aplikacji w klastrze i umożliwia autoryzację zadań Hive w kolejkach usługi YARN.
  4. Hive aktualizuje dane w systemie ABFS lub WASB.
  5. Funkcja Hive zwraca wyniki zapytania za pośrednictwem połączenia JDBC.

Jeśli starszy skrypt lub aplikacja określa mapReduce do wykonania, wyjątek występuje w następujący sposób

Screenshot showing map reducer exception output.

Uwaga

Większość funkcji zdefiniowanych przez użytkownika (UDF, user-defined functions) nie wymaga zmiany w celu wykonania w usłudze Tez zamiast mapReduce.

Zmiany dotyczące transakcji ACID i CBO:

  • Tabele ACID są domyślnym typem tabeli w usłudze HDInsight 4.x bez przeciążenia wydajności ani działania.

  • Uproszczone tworzenie aplikacji, operacje z silniejszymi gwarancjami transakcyjnymi i prostszą semantyka poleceń SQL

  • Wewnętrzna usługa Hive zajmuje się zasobnikami tabel ACID w usłudze HDInsight 4.1, co eliminuje obciążenie konserwacyjne.

  • Optymalizacje zaawansowane — uaktualnianie w modelu CBO

  • Automatyczna pamięć podręczna zapytań. Właściwość używana do włączania buforowania zapytań to hive.query.results.cache.enabled. Należy ustawić tę właściwość na true. Program Hive domyślnie przechowuje pamięć podręczną wyników zapytania w /tmp/hive/__resultcache__/. usłudze Hive przydziela 2 GB dla pamięci podręcznej wyników zapytania. To ustawienie można zmienić, konfigurując następujący parametr w bajtach hive.query.results.cache.max.size.

    Aby uzyskać więcej informacji, korzyści z migracji do usługi Azure HDInsight 4.0.

Zmaterializowane ponowne zapisywanie widoków

Aby uzyskać więcej informacji, na temat Programu Hive — zmaterializowane widoki

Zmiany po uaktualnieniu do programu Apache Hive 3

Aby zlokalizować tabele apache Hive 3 i korzystać z nich po uaktualnieniu, należy zrozumieć zmiany występujące podczas procesu uaktualniania. Zmiany dotyczące zarządzania tabelami i ich lokalizacji, uprawnień do katalogów tabel, typów tabel i kwestii dotyczących zgodności ACID.

Zarządzanie tabelami programu Hive

Program Hive 3 przejmuje większą kontrolę nad tabelami niż Hive 2 i wymaga, aby tabele zarządzane przestrzegały ścisłej definicji. Poziom kontroli programu Hive przejmuje tabele jest jednorodny dla tradycyjnych baz danych. Hive zdaje sobie sprawę ze zmian różnicowych w danych; ta struktura kontroli zwiększa wydajność.

Jeśli na przykład usługa Hive wie, że rozpoznawanie zapytania nie wymaga skanowania tabel dla nowych danych, program Hive zwraca wyniki z pamięci podręcznej wyników zapytania hive. Gdy dane bazowe w zmaterializowanym widoku zmienią się, program Hive musi ponownie skompilować zmaterializowany widok. Właściwości ACID ujawniają dokładnie, które wiersze uległy zmianie i należy je przetworzyć i dodać do zmaterializowanego widoku.

Zmiany programu Hive we właściwościach ACID

W programach Hive 2.x i 3.x tabele transakcyjne (zarządzane) i nietransakcyjne (zewnętrzne). Tabele transakcyjne mają właściwości niepodzielne, spójne, izolacyjne i trwałe (ACID). W programie Hive 2.x początkowa wersja przetwarzania transakcji ACID to ACID v1. W programie Hive 3.x domyślne tabele będą miały wartość ACID w wersji 2.

Natywne i nienatywne formaty magazynu

Formaty magazynu są czynnikiem zmiany uaktualniania typów tabel. Programy Hive 2.x i 3.x obsługują następujące natywne i nienatywne formaty magazynu hadoop

Natywne: tabele z wbudowaną obsługą technologii Hive w następujących formatach plików

  • Tekst
  • Plik sekwencji
  • Plik RC
  • Plik AVRO
  • Plik ORC
  • Plik Parquet

Nienatywne: tabele korzystające z programu obsługi magazynu, takie jak DruidStorageHandler lub HBaseStorageHandler

Zmiany uaktualniania do typów tabel w usłudze HDInsight 4.x

W poniższej tabeli porównaliśmy typy tabel Hive i operacje ACID przed uaktualnieniem z usługi HDInsight 3.x i po uaktualnieniu do usługi HDInsight 4.x. Własność pliku tabeli Hive jest czynnikiem określania typów tabel i operacji ACID po uaktualnieniu

Porównanie typów tabel w usługach HDInsight 3.x i HDInsight 4.x

HDInsight 3.x - - - HDInsight 4.x -
Typ tabeli ACID v1 Format Właściciel (użytkownik) pliku tabeli Hive Typ tabeli ACID v2
Zewnętrzne Nie. Natywny lub inny niż natywny Hive lub non-Hive Zewnętrzne Nie.
Zarządzany Tak ORC Hive lub non-Hive Zarządzane, możliwe do zaktualizowania Tak
Zarządzany Nie. ORC Hive Zarządzane, możliwe do zaktualizowania Tak
Zarządzany Nie. ORC inne niż Hive Zewnętrzne z usuwaniem danych NIE
Zarządzany Nie. Natywny (ale inny niż ORC) Hive Zarządzane, wstaw tylko Tak
Zarządzany Nie. Natywny (ale inny niż ORC) inne niż Hive Zewnętrzne z usuwaniem danych Nie.
Zarządzany Nie. Inne niż natywne Hive lub non-Hive Zewnętrzne z usuwaniem danych Nie.

Personifikacja hive

Personifikacja hive została domyślnie włączona w programie Hive 2 (doAs=true) i domyślnie wyłączona w programie Hive 3. Personifikacja hive uruchamia program Hive jako użytkownik końcowy, a nie.

Inne zmiany uaktualniania usługi HDInsight 4.x

  1. Zarządzane tabele ACID, które nie należą do użytkownika programu Hive, pozostają tabelami zarządzanymi po uaktualnieniu, ale hive staje się właścicielem.
  2. Po uaktualnieniu format tabeli Programu Hive jest taki sam jak przed uaktualnieniem. Na przykład tabele natywne lub nienatywne pozostają odpowiednio natywne lub nienatywne.

Zmiany lokalizacji

Po uaktualnieniu lokalizacja zarządzanych tabel lub partycji nie zmienia się w żadnym z następujących warunków:

  • Stara tabela lub katalog partycji nie był w domyślnej lokalizacji /apps/hive/warehouse przed uaktualnieniem.
  • Stara tabela lub partycja znajduje się w innym systemie plików niż nowy katalog magazynu.
  • Stary katalog tabeli lub partycji znajduje się w innej strefie szyfrowania niż nowy katalog magazynu.

W przeciwnym razie lokalizacja zarządzanych tabel lub partycji ulegnie zmianie. Proces uaktualniania przenosi pliki zarządzane do programu /hive/warehouse/managed. Domyślnie program Hive umieszcza wszystkie nowe tabele zewnętrzne tworzone w usłudze HDInsight 4.x w programie /hive/warehouse/external

Obiekt /apps/hive directory, który jest dawną lokalizacją magazynu Hive 2.x, może lub nie istnieje w usłudze HDInsight 4.x

Następujące scenariusze są obecne w przypadku zmian lokalizacji

Scenariusz 1

Jeśli tabela jest tabelą zarządzaną w usłudze HDInsight-3.x i jeśli znajduje się w lokalizacji /apps/hive/warehouse i przekonwertowana jako tabela zewnętrzna w usłudze HDInsight-4.x, lokalizacja jest taka sama /apps/hive/warehouse w usłudze HDInsight 4.x. Nie zmienia żadnej lokalizacji. Po wykonaniu tego kroku polecenie alter table konwertuje je jako tabelę zarządzaną (kwas) w tej samej lokalizacji /apps/hive/warehouse.

Scenariusz 2

Jeśli tabela jest tabelą zarządzaną w usłudze HDInsight-3.x i jeśli znajduje się w lokalizacji /apps/hive/warehouse i przekonwertowana na tabelę zarządzaną (ACID) w usłudze HDInsight 4.x, lokalizacja to /hive/warehouse/managed.

Scenariusz 3 Jeśli tworzysz tabelę zewnętrzną, w usłudze HDInsight-4.x bez określania żadnej lokalizacji będzie ona obecna w lokalizacji /hive/warehouse/external.

Konwersja tabeli

Po uaktualnieniu w celu przekonwertowania tabeli nietransakcyjnej na tabelę transakcyjną ACID w wersji 2 należy użyć ALTER TABLE polecenia i ustawić właściwości tabeli na

transaction'='true' and 'EXTERNAL'='false
  • Zarządzana tabela, format inny niż ACID, ORC i należący do użytkownika innego niż Hive w usłudze HDInsight-3.x zostaną przekonwertowane na tabelę zewnętrzną, inną niż ACID w usłudze HDInsight-4.x.
  • Jeśli użytkownik chce zmienić tabelę zewnętrzną (nieKWAS) na ACID, powinien również zmienić tabelę zewnętrzną na zarządzaną i ACID. Ponieważ w usłudze HDInsight-4.x wszystkie zarządzane tabele są domyślnie ściśle ACID. Nie można przekonwertować tabel zewnętrznych (innych niż ACID) na tabelę ACID.

Uwaga

Tabela musi być tabelą ORC.

Aby przekonwertować tabelę zewnętrzną (inną niż ACID) na tabelę Managed (ACID),

  1. Przekonwertuj tabelę zewnętrzną na zarządzaną i kwas równą true, używając następującego polecenia: 
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
  2. Jeśli spróbujesz wykonać następujące polecenie dla tabeli zewnętrznej, zostanie wyświetlony poniższy błąd.

Scenariusz 1

Rozważmy, że tabela rt jest tabelą zewnętrzną (non-ACID). Jeśli tabela nie jest tabelą ORC,

alter table rt set TBLPROPERTIES ('transactional'='true');
ERROR : FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. The table must be stored using an ACID compliant format (such as ORC): work.rt
The table must be ORC format

Scenariusz 2

>>>> alter table rt set TBLPROPERTIES ('transactional'='true'); If the table is ORC table.
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. work.rt can't be declared transactional because it's an external table (state=08S01,code=1)

Ten błąd występuje, ponieważ tabela rt jest tabelą zewnętrzną i nie można przekonwertować tabeli zewnętrznej na ACID.

Scenariusz 3

>>>> alter table rt set TBLPROPERTIES ('EXTERNAL'='false');
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. Table work.rt failed strict managed table checks due to the following reason: Table is marked as a managed table but isn't transactional. (state=08S01,code=1)

W tym miejscu próbujemy najpierw zmienić tabelę zewnętrzną na zarządzaną tabelę. W usłudze HDInsight 4.x powinna ona być tabelą ściśle zarządzaną (co oznacza, że powinna to być tabela ACID). Więc tutaj dostajesz impas. Jedynym sposobem przekonwertowania tabeli zewnętrznej (NON_ACID) na zarządzaną (ACID) należy wykonać następujące polecenie:

alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Składnia i semantyka

  • Tworzenie tabeli Aby zwiększyć użyteczność i funkcjonalność, zmieniono tworzenie tabeli programu Hive 3. Program Hive zmienił tworzenie tabeli w następujący sposób

    • Tworzy tabelę zgodną ze standardem ACID, która jest domyślną wartością w usłudze HDP
    • Obsługuje proste operacje zapisu i wstawiania
    • Zapisy w wielu partycjach
    • Wstawia wiele aktualizacji danych w jednej instrukcji SELECT
    • Eliminuje potrzebę zasobnika.

    Jeśli masz potok ETL, który tworzy tabele w programie Hive, tabele są tworzone jako ACID. Hive ściśle kontroluje dostęp i okresowo wykonuje kompaktowanie w tabelach

    Przed uaktualnieniem w usłudze HDInsight 3.x domyślnie create TABLE utworzono tabelę inną niż ACID.

    Po uaktualnieniu Domyślnie create TABLE tworzy pełną tabelę transakcyjną ACID w formacie ORC.

    Akcja Wymagana do uzyskania dostępu do tabel Hive ACID z platformy Spark, należy nawiązać połączenie z programem Hive przy użyciu Połączenie or magazynu Hive (HWC). Aby napisać tabele ACID w technologii Hive z platformy Spark, należy użyć interfejsu API HWC i HWC

  • Ucieczka db.table odwołań

    Należy zmienić zapytania używające odwołań db.table, aby uniemożliwić usłudze Hive interpretowanie całego ciągu db.table jako nazwy tabeli. Program Hive 3.x odrzuca db.table zapytania SQL. Kropka (.) nie jest dozwolona w nazwach tabel. Nazwa bazy danych i nazwa tabeli są ujęte w backticks. Znajdź tabelę zawierającą problematyczne odwołanie do tabeli. math.students wyświetlane w instrukcji CREATE TABLE. Należy ująć nazwę bazy danych i nazwę tabeli w backticks.

    TABLE `math`.`students` (name VARCHAR(64), age INT, gpa DECIMAL(3,2));

  • RZUTOWANIE TIMESTAMPS Wyniki aplikacji, które rzutują cyfry na znaczniki czasu, różnią się od Hive 2 do Hive 3. Usługa Apache Hive zmieniła zachowanie funkcji CAST tak, aby było zgodne ze standardem SQL, który nie kojarzy strefy czasowej z typem ZNACZNIKA CZASU.

    Przed uaktualnieniem Rzutowanie wartości typu liczbowego do znacznika czasu może służyć do wygenerowania wyniku, który odzwierciedla strefę czasową klastra. Na przykład 1597217764557 to 2020-08-12 00:36:04 PDT. Uruchomienie następującego zapytania rzutuje wartość liczbową na znacznik czasu w pliku PDT: SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    Po uaktualnieniu Rzutowanie wartości typu liczbowego do znacznika czasu generuje wynik, który odzwierciedla utc zamiast strefy czasowej klastra. Uruchomienie zapytania rzutuje wartość liczbową na znacznik czasu w formacie UTC. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    Wymagana akcja Aplikacji zmiany. Nie rzutuj z liczb, aby uzyskać lokalną strefę czasową. Wbudowane funkcje from_utc_timestamp i to_utc_timestamp mogą służyć do naśladowania zachowania przed uaktualnieniem.

  • SPRAWDZANIE ZGODNOŚCI ZMIAN KOLUMNY Domyślna zmiana konfiguracji może spowodować niepowodzenie aplikacji, które zmieniają typy kolumn.

    Przed uaktualnieniem w usłudze HDInsight 3.x Hive.metastore.disallow.incompatible.col.type.changes jest domyślnie fałsz, aby zezwolić na zmiany niezgodnych typów kolumn. Na przykład można zmienić kolumnę STRING na kolumnę niezgodnego typu, na przykład MAP<STRING, STRING>. Nie występuje błąd.

    Po uaktualnieniu pliku hive.metastore.disallow.incompatible.col.type.changes jest domyślnie prawdziwe. Program Hive uniemożliwia zmianę niezgodnych typów kolumn. Zgodne zmiany typu kolumny, takie jak INT, STRING, BIGINT, nie są blokowane.

    Akcja Wymagana zmiana aplikacji w celu uniemożliwienia niezgodnych zmian typu kolumny, aby zapobiec ewentualnemu uszkodzeniu danych.

  • UPUSZCZANIE PARTYCJI

    Słowa kluczowe OFFLINE i NO_DROP w klauzuli CASCADE dotyczące usuwania partycji powodują problemy z wydajnością i nie są już obsługiwane.

    Przed uaktualnieniem możesz użyć słów kluczowych OFFLINE i NO_DROP w klauzuli CASCADE, aby zapobiec odczytywaniu lub usuwaniu partycji.

    Po uaktualnieniu trybu OFFLINE i NO_DROP nie są obsługiwane w klauzuli CASCADE.

    Akcja Wymagana zmiana aplikacji w celu usunięcia trybu OFFLINE i NO_DROP z klauzuli CASCADE. Użyj schematu autoryzacji, takiego jak Ranger, aby zapobiec usuwaniu lub odczytywaniu partycji.

  • Zmiana nazwy tabeli po uaktualnieniu Zmiana nazwy tabeli zarządzanej przenosi jej lokalizację tylko wtedy, gdy tabela jest tworzona bez LOCATION klauzuli i znajduje się w katalogu bazy danych.

Ograniczenia dotyczące CBO

  • Widzimy, że dane wyjściowe select dają końcowe zero w kilku kolumnach. Jeśli na przykład mamy kolumnę tabeli z wartością datatype jako dziesiętną (38,4), a jeśli wstawimy dane jako 38, doda ona końcowe zero i zapewni wynik 38,0000 Jako na https://issues.apache.org/jira/browse/HIVE-12063 i https://issues.apache.org/jira/browse/HIVE-24389, idea zostanie zachowana skala i precyzja zamiast uruchamiać otokę w kolumnach dziesiętnych. Jest to domyślne zachowanie programu Hive 2. Aby rozwiązać ten problem, możesz skorzystać z poniższej opcji.

    1. Zmodyfikuj typ danych na poziomie źródła, aby dostosować dokładność kolumny col1(decimal(38,0)). Ta wartość daje wynik 38 bez końcowego zera. Jeśli jednak wstawisz dane jako 35.0005, będzie to .0005 i zostanie wyświetlona tylko wartość 38 1.Usuń końcowe zera dla kolumn z problemem, a następnie rzutuj na ciąg,
      1. Użyj opcji TRIM(cast(<column_name> AS STRING))+0 FROM <table_name>;
      2. Użyj wyrażenia regularnego.

  1. Zapytanie Hive kończy się niepowodzeniem z komunikatem "Nieobsługiwane wyrażenie subquery", gdy używamy system UNIX_TIMESTAMP w zapytaniu. Jeśli na przykład uruchomimy zapytanie, zgłasza błąd "Nieobsługiwane wyrażenie podzapytania"

    select * from
(SELECT col_1 from table1 where col_2 >= unix_timestamp('2020-03-07','yyyy-MM-dd'));

    Głównym przypadkiem tego problemu jest to, że bieżąca baza kodu Hive zgłasza wyjątek, który analizuje system UNIX_TIMESTAMP, ponieważ nie ma precyzyjnego mapowania HiveTypeSystemImpl.java code dla precyzji, z UNIX_TIMESTAMP której obliczanie jest rozpoznawane jako BIGINT. Ale poniższe zapytanie działa prawidłowo select * from (SELECT col_1 from table1 where col_2 >= 1);

    To polecenie jest wykonywane pomyślnie, ponieważ col_2 jest liczbą całkowitą. Powyższy problem został rozwiązany w systemach hdi-3.1.2-4.1.12(4.1 stack) i hdi-3.1.2-5.0.8(5.0)

Kroki uaktualniania

1. Przygotowanie danych

2. Kopiowanie bazy danych SQL

  • Jeśli klaster używa domyślnego magazynu metadanych Hive, postępuj zgodnie z tym przewodnikiem , aby wyeksportować metadane do zewnętrznego magazynu metadanych. Następnie utwórz kopię zewnętrznego magazynu metadanych na potrzeby uaktualnienia.

  • Jeśli klaster używa zewnętrznego magazynu metadanych Hive, utwórz jego kopię. Opcje obejmują eksportowanie/importowanie i przywracanie do punktu w czasie.

3. Uaktualnianie schematu magazynu metadanych

W tym kroku użyto Hive Schema Tool elementu z usługi HDInsight 4.0 do uaktualnienia schematu magazynu metadanych.

Ostrzeżenie

Ten krok nie jest odwracalny. Uruchom to tylko na kopii magazynu metadanych.

  1. Utwórz tymczasowy klaster usługi HDInsight 4.0, aby uzyskać dostęp do programu Hive schematoolw wersji 4.0. W tym kroku można użyć domyślnego magazynu metadanych Hive.

  2. W klastrze usługi HDInsight 4.0 wykonaj polecenie schematool , aby uaktualnić docelowy magazyn metadanych usługi HDInsight 3.6. Edytuj następujący skrypt powłoki, aby dodać nazwę serwera SQL, nazwę bazy danych, nazwę użytkownika i hasło. Otwórz sesję SSH w węźle głównym i uruchom ją.

    SERVER='servername.database.windows.net'  # replace with your SQL Server
DATABASE='database'  # replace with your 3.6 metastore SQL Database
USERNAME='username'  # replace with your 3.6 metastore username
PASSWORD='password'  # replace with your 3.6 metastore password
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/schematool -upgradeSchema -url "jdbc:sqlserver://$SERVER;databaseName=$DATABASE;trustServerCertificate=false;encrypt=true;hostNameInCertificate=*.database.windows.net;" -userName "$USERNAME" -passWord "$PASSWORD" -dbType "mssql" --verbose

    Uwaga

    To narzędzie używa klienta beeline do wykonywania skryptów SQL w programie /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql.

    Składnia SQL w tych skryptach nie musi być zgodna z innymi narzędziami klienckimi. Na przykład program SSMS i Edytor Power Query w witrynie Azure Portal wymagają słowa kluczowego GO po każdym poleceniu.

    Jeśli jakikolwiek skrypt zakończy się niepowodzeniem z powodu przekroczenia limitu czasu zasobów lub transakcji, przeprowadź skalowanie w górę bazy danych SQL Database.

  3. Sprawdź ostateczną wersję przy użyciu zapytania select schema_version from dbo.version.

    Dane wyjściowe powinny być zgodne z następującym poleceniem powłoki bash z klastra usługi HDInsight 4.0.

    grep . /usr/hdp/$(hdp-select --version)/hive/scripts/metastore/upgrade/mssql/upgrade.order.mssql | tail -n1 | rev | cut -d'-' -f1 | rev

  4. Usuń tymczasowy klaster usługi HDInsight 4.0.

4. Wdrażanie nowego klastra usługi HDInsight 4.0

Utwórz nowy klaster usługi HDInsight 4.0, wybierając uaktualniony magazyn metadanych Hive i te same konta magazynu.

  • Nowy klaster nie wymaga tego samego domyślnego systemu plików.

  • Jeśli magazyn metadanych zawiera tabele znajdujące się w wielu kontach magazynu, należy dodać te konta magazynu do nowego klastra, aby uzyskać dostęp do tych tabel. Zobacz Dodawanie dodatkowych kont magazynu do usługi HDInsight.

  • Jeśli zadania hive kończą się niepowodzeniem z powodu niedostępności magazynu, sprawdź, czy lokalizacja tabeli znajduje się na koncie magazynu dodanym do klastra.

    Użyj następującego polecenia programu Hive, aby zidentyfikować lokalizację tabeli:

    SHOW CREATE TABLE ([db_name.]table_name|view_name);

5. Konwertowanie tabel pod kątem zgodności ACID

Tabele zarządzane muszą być zgodne ze standardem ACID w usłudze HDInsight 4.0. Uruchom polecenie strictmanagedmigration w usłudze HDInsight 4.0, aby przekonwertować wszystkie tabele niezarządzane na tabele zewnętrzne z właściwością 'external.table.purge'='true'. Wykonaj z węzła głównego:

sudo su - hive
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/hive --config /etc/hive/conf --service strictmanagedmigration --hiveconf hive.strict.managed.tables=true -m automatic --modifyManagedTables

6. Nie znaleziono błędu klasy z MultiDelimitSerDe

Problem

W niektórych sytuacjach podczas uruchamiania zapytania Hive może zostać wyświetlony java.lang.ClassNotFoundException komunikat o org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe tym, że klasa nie zostanie znaleziona. Ten błąd występuje, gdy klient przeprowadza migrację z usługi HDInsight 3.6 do usługi HDInsight 4.0. Klasa org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDeSerDe , która jest częścią hive-contrib-1.2.1000.2.6.5.3033-1.jar usługi HDInsight 3.6, jest usuwana i używamy org.apache.hadoop.hive.serde2.MultiDelimitSerDe klasy , która jest częścią hive-exec jar hdI-4.0. hive-exec jar domyślnie zostanie załadowany do modułu HS2 po uruchomieniu usługi.

KROKI ROZWIĄZYWANIA PROBLEMÓW

  1. Sprawdź, czy jakikolwiek plik JAR w folderze (prawdopodobnie powinien znajdować się w folderze bibliotek Hive, który znajduje /usr/hdp/current/hive/lib się w usłudze HDInsight), zawiera tę klasę lub nie.
  2. Sprawdź klasę org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe i org.apache.hadoop.hive.serde2.MultiDelimitSerDe jak wspomniano w rozwiązaniu.

Rozwiązanie

  1. Mimo że plik JAR jest plikiem binarnym, nadal można użyć grep polecenia z -Hrni przełącznikami, tak jak poniżej, aby wyszukać określoną nazwę klasy

    grep -Hrni "org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe" /usr/hdp/current/hive/lib

  2. Jeśli nie można odnaleźć klasy, nie zwróci żadnych danych wyjściowych. Jeśli znajdzie klasę w pliku JAR, zwróci dane wyjściowe

  3. Poniżej przedstawiono przykład z klastra usługi HDInsight 4.x

    sshuser@hn0-alters:~$ grep -Hrni "org.apache.hadoop.hive.serde2.MultiDelimitSerDe" /usr/hdp/4.1.9.7/hive/lib/
Binary file /usr/hdp/4.1.9.7/hive/lib/hive-exec-3.1.0.4.1-SNAPSHOT.jar matches

  4. Z powyższych danych wyjściowych możemy potwierdzić, że żaden plik jar nie zawiera klasy org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe i plik jar hive-exec zawiera org.apache.hadoop.hive.serde2.MultiDelimitSerDe.

  5. Spróbuj utworzyć tabelę z formatem DerDe w formacie wiersza ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe

  6. To polecenie rozwiąże problem. Jeśli tabela została już utworzona, możesz zmienić jej nazwę przy użyciu poniższych poleceń

    Hive => ALTER TABLE TABLE_NAME SET SERDE 'org.apache.hadoop.hive.serde2.MultiDelimitSerDe'
Backend DB => UPDATE SERDES SET SLIB='org.apache.hadoop.hive.serde2.MultiDelimitSerDe' where SLIB='org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe';

Polecenie aktualizacji polega na ręcznej aktualizacji szczegółów w bazie danych zaplecza, a polecenie alter służy do zmiany tabeli przy użyciu nowej klasy SerDe z beeline lub Hive.

Skrypt porównania schematu bazy danych zaplecza programu Hive

Poniższy skrypt można uruchomić po zakończeniu migracji.

Istnieje prawdopodobieństwo, że w bazie danych zaplecza brakuje kilku kolumn, co powoduje błędy zapytań. Jeśli uaktualnienie schematu nie zostało prawidłowo wykonane, istnieje prawdopodobieństwo, że możemy napotkać nieprawidłowy problem z nazwą kolumny. Poniższy skrypt pobiera nazwę kolumny i typ danych z bazy danych zaplecza klienta i udostępnia dane wyjściowe, jeśli brakuje kolumny lub nieprawidłowego typu danych.

Poniższa ścieżka zawiera plik schemacompare_final.py i test.csv. Skrypt znajduje się w pliku "schemacompare_final.py", a plik "test.csv" zawiera całą nazwę kolumny i typ danych dla wszystkich tabel, które powinny znajdować się w bazie danych zaplecza hive.

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/schemacompare_final.py

https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/test.csv

Pobierz te dwa pliki z linku. Skopiuj te pliki do jednego z węzłów głównych, w których działa usługa Hive.

Kroki wykonywania skryptu:

Utwórz katalog o nazwie "schemacompare" w katalogu "/tmp".

Umieść folder "schemacompare_final.py" i "test.csv" w folderze "/tmp/schemacompare". Wykonaj polecenie "ls -ltrh /tmp/schemacompare/" i sprawdź, czy pliki są obecne.

Aby wykonać skrypt języka Python, użyj polecenia "python schemacompare_final.py". Ten skrypt rozpoczyna wykonywanie skryptu i ukończenie go trwa krócej niż pięć minut. Powyższy skrypt automatycznie łączy się z bazą danych zaplecza i pobiera szczegóły z każdej tabeli, której program Hive używa i aktualizuje szczegóły w nowym pliku CSV o nazwie "return.csv". Po utworzeniu pliku return.csv porównuje dane z plikiem "test.csv" i wyświetla nazwę kolumny lub typ danych, jeśli brakuje niczego w nazwie tabeli.

Po wykonaniu skryptu zobaczysz następujące wiersze, które wskazują, że szczegóły są pobierane dla tabel, a skrypt jest w toku

KEY_CONSTRAINTS
Details Fetched
DELEGATION_TOKENS
Details Fetched
WRITE_SET
Details Fetched
SERDES
Details Fetched

Szczegóły różnicy można zobaczyć w wierszu "DIFFERENCE DETAILS:". Jeśli istnieje jakakolwiek różnica, drukuje

PART_COL_STATS;
('difference', ['BIT_VECTOR', 'varbinary'])
The line with semicolon PART_COL_STATS; is the table name. And under the table name you can find the differences as ('difference', ['BIT_VECTOR', 'varbinary']) if there are any difference in column or datatype.

Jeśli w tabeli nie ma żadnych różnic, dane wyjściowe są następujące:

BUCKETING_COLS;
('difference', [])
PARTITIONS;
('difference', [])

Z tych danych wyjściowych można znaleźć nazwy kolumn, których brakuje lub które są niepoprawne. Możesz uruchomić następujące zapytanie w bazie danych zaplecza, aby sprawdzić, czy brakuje kolumny, czy nie.

SELECT * FROM INFORMATION_SCHEMA.columns WHERE TABLE_NAME = 'PART_COL_STATS';

Jeśli na przykład w tabeli pominięto dowolną kolumnę, na przykład jeśli uruchomimy zapytania, takie jak wstawianie lub wstawianie zastąpić, statystyki zostaną obliczone automatycznie i spróbują zaktualizować tabelę statystyk, na przykład PART_COL_STATS i TAB_COL_STATS. Jeśli w tabelach brakuje kolumny takiej jak "BIT_VECTOR", błąd "Nieprawidłowa nazwa kolumny" zakończy się niepowodzeniem. Możesz dodać kolumnę, jak wspomniano w poniższych poleceniach. Aby obejść ten problem, możesz wyłączyć statystyki, ustawiając następujące właściwości, które nie mogą zaktualizować statystyk w bazie danych zaplecza.

hive.stats.autogather=false;
hive.stats.column.autogather=false;
To Fix this issue, run the following two queries on backend SQL server (Hive metastore DB):

ALTER TABLE PART_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);
ALTER TABLE TAB_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);

Ten krok pozwala uniknąć niepowodzeń zapytań, które kończą się niepowodzeniem z komunikatem "Nieprawidłowa nazwa kolumny" raz po migracji.

Zabezpieczanie programu Hive w wersjach usługi HDInsight

Usługa HDInsight opcjonalnie integruje się z usługą Microsoft Entra ID przy użyciu pakietu HDInsight Enterprise Security Package (ESP). Usługa ESP używa protokołu Kerberos i platformy Apache Ranger do zarządzania uprawnieniami określonych zasobów w klastrze. Zasady platformy Ranger wdrożone w usłudze Hive w usłudze HDInsight 3.6 można migrować do usługi HDInsight 4.0, wykonując następujące czynności:

  1. Przejdź do panelu programu Ranger Service Manager w klastrze usługi HDInsight 3.6.
  2. Przejdź do zasad o nazwie HIVE i wyeksportuj zasady do pliku json.
  3. Upewnij się, że wszyscy użytkownicy, do których odwołuje się wyeksportowany kod json zasad, istnieją w nowym klastrze. Jeśli użytkownik jest określany w formacie json zasad, ale nie istnieje w nowym klastrze, dodaj użytkownika do nowego klastra lub usuń odwołanie z zasad.
  4. Przejdź do panelu programu Ranger Service Manager w klastrze usługi HDInsight 4.0.
  5. Przejdź do zasad o nazwie HIVE i zaimportuj kod json zasad ranger z kroku 2.

Zmiany hive w usłudze HDInsight 4.0, które mogą wymagać zmian aplikacji

  • Aby udostępnić magazyn metadanych między tabelami Spark i Hive, zobacz Dodatkowa konfiguracja przy użyciu usługi Hive Warehouse Połączenie or.

  • Usługa HDInsight 4.0 używa autoryzacji opartej na magazynie. Jeśli zmodyfikujesz uprawnienia do plików lub utworzysz foldery jako inny użytkownik niż hive, prawdopodobnie wystąpią błędy programu Hive na podstawie uprawnień magazynu. Aby rozwiązać ten problem, przyznaj rw- użytkownikowi dostęp. Zobacz Przewodnik po uprawnieniach systemu plików HDFS.

  • HiveCLI element jest zastępowany ciągiem Beeline.

Zapoznaj się z anonsem usługi HDInsight 4.0, aby zapoznać się z innymi zmianami.

Publikowanie migracji

Pamiętaj, aby wykonać te kroki po zakończeniu migracji.

Rozsądek tabeli

  1. Utwórz ponownie tabele w programie Hive 3.1 przy użyciu funkcji CTAS lub IOW, aby zmienić typ tabeli zamiast zmieniać właściwości tabeli.
  2. Zachowaj wartość doAs jako false.
  3. Upewnij się, że zarządzana tabela/własność danych jest własnością użytkownika "hive".
  4. Użyj zarządzanych tabel ACID, jeśli format tabeli to ORC i zarządzany inny niż ACID dla typów innych niż ORC.
  5. Wygeneruj ponownie statystyki dotyczące ponownie utworzonych tabel, ponieważ migracja spowodowałaby nieprawidłowe statystyki.

Kondycja klastra

Jeśli wiele klastrów współużytkuje ten sam magazyn i bazę danych HMS, należy włączyć automatyczne kompaktowanie/kompaktowanie wątków tylko w jednym klastrze i wyłączyć wszędzie indziej.

Dostrajanie magazynu metadanych w celu zmniejszenia użycia procesora CPU.

  1. Wyłącz odbiorniki zdarzeń transakcyjnych.

    Uwaga

    Wykonaj poniższe kroki tylko wtedy, gdy funkcja replikacji hive nie jest używana.

    1. Z interfejsu użytkownika systemu Ambari usuń wartość hive.metastore.transactional.event.listeners.
    2. Wartość domyślna: org.apache.hive.hcatalog.listener.DbNotificationListener
    3. Nowa wartość: <Empty>

  2. Wyłączanie programu Hive PrivilegeSynchronizer

    1. W interfejsie użytkownika systemu Ambari ustaw właściwość hive.privilege.syncr = false.
    2. Wartość domyślna: true
    3. Nowa wartość: false

  3. Optymalizowanie funkcji naprawy partycji

  4. Wyłącz naprawę partycji — ta funkcja służy do synchronizowania partycji tabel programu Hive w lokalizacji magazynu z magazynem metadanych Hive. Tę funkcję można wyłączyć, jeśli po pozyskaniu danych zostanie użyta opcja "naprawa msck".

  5. Aby wyłączyć funkcję , dodaj polecenie "discover.partitions=false" w obszarze właściwości tabeli przy użyciu funkcji ALTER TABLE. OR (jeśli nie można wyłączyć funkcji)

  6. Zwiększ częstotliwość naprawy partycji.

  7. W interfejsie użytkownika systemu Ambari zwiększ wartość "metastore.partition.management.task.frequency" (w sekundach).

    Uwaga

    Ta zmiana może opóźnić widoczność niektórych partycji pozyskanych do magazynu.

    1. Wartość domyślna: 60
    2. Proponowana wartość: 3600

  8. Optymalizacje zaawansowane Następujące opcje należy przetestować w środowisku niższym (nieprodowym) przed zastosowaniem do środowiska produkcyjnego.

    1. Usuń odbiornik powiązany z materializowanym widokiem, jeśli nie jest używany widok zmaterializowany.
    2. W interfejsie użytkownika systemu Ambari dodaj właściwość niestandardową (w niestandardowym pliku hive-site.xml) i usuń niechciane wątki magazynu metadanych w tle.
    3. Nazwa właściwości: metastore.task.threads.remote
    4. Wartość domyślna: N/A (it uses few class names internally)
    5. Nowa wartość: org.apache.hadoop.hive.metastore.txn.AcidHouseKeeperService,org.apache.hadoop.hive.metastore.txn.AcidOpenTxnsCounterService,org.apache.hadoop.hive.metastore.txn.AcidCompactionHistoryService,org.apache.hadoop.hive.metastore.txn.AcidWriteSetService,org.apache.hadoop.hive.metastore.PartitionManagementTask

  9. Wyłącz wątki w tle, jeśli replikacja jest wyłączona.

    1. W interfejsie użytkownika systemu Ambari dodaj właściwość niestandardową (w niestandardowym pliku hive-site.xml) i usuń niechciane wątki.
    2. Nazwa właściwości: metastore.task.threads.always
    3. Wartość domyślna: N/A (it uses few class names internally)
    4. Nowa wartość: org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

Dostrajanie zapytań

  1. Zachowaj domyślne konfiguracje programu Hive, aby uruchamiać zapytania w miarę ich dostosowywania dla obciążeń TPC-DS. Wymaga dostrajania na poziomie zapytania tylko wtedy, gdy zakończy się niepowodzeniem lub działa wolno.
  2. Upewnij się, że statystyki są aktualne, aby uniknąć złego planu lub nieprawidłowych wyników.
  3. Unikaj mieszania zewnętrznych i zarządzanych tabel ACID w typie sprzężenia zapytań. W takim przypadku spróbuj przekonwertować tabelę zewnętrzną na zarządzaną tabelę inną niż ACID za pomocą rekreacji.
  4. W programie Hive-3 wiele pracy miało miejsce w przypadku wektoryzacji, CBO, sygnatury czasowej ze strefą itp., które mogą zawierać błędy produktu. Jeśli więc jakiekolwiek zapytanie daje nieprawidłowe wyniki, spróbuj wyłączyć wektoryzacja, CBO, map-join itp., aby sprawdzić, czy to pomoże.

Inne kroki, które należy wykonać, aby naprawić nieprawidłowe wyniki i niską wydajność po migracji

  1. Problem z zapytaniem Hive daje niepoprawny wynik. Nawet zapytanie select count(*) daje niepoprawny wynik.

    Przyczyna, że właściwość "hive.compute.query.using.stats" jest domyślnie ustawiona na true. Jeśli ustawimy ją na true, używa ona statystyk przechowywanych w magazynie metadanych do wykonania zapytania. Jeśli statystyki nie są aktualne, wyniki są niepoprawne.

    Rozwiązanie zbiera statystyki dla zarządzanych tabel przy użyciu alter table <table_name> compute statics; polecenia na poziomie tabeli i na poziomie kolumny. Link referencyjny — https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. Wykonywanie zapytań hive trwa długo.

    Przyczyna Jeśli zapytanie ma warunek sprzężenia, gałąź tworzy plan, czy używać sprzężenia mapy, czy scalania na podstawie rozmiaru tabeli i warunku sprzężenia. Jeśli jedna z tabel zawiera mały rozmiar, ładuje tę tabelę w pamięci i wykonuje operację sprzężenia. Dzięki temu wykonywanie zapytania jest szybsze w porównaniu z sprzężeniami scalania.

    Rozwiązanie Upewnij się, że właściwość "hive.auto.convert.join=true" jest wartością domyślną. Ustawienie wartości false powoduje użycie sprzężenia scalania i może spowodować niską wydajność. Hive decyduje, czy używać sprzężenia mapy, czy nie na podstawie następujących właściwości, które są ustawione w klastrze

    set hive.auto.convert.join=true;
set hive.auto.convert.join.noconditionaltask=true;
set hive.auto.convert.join.noconditionaltask.size=<value>;
set hive.mapjoin.smalltable.filesize = <value>;

    Wspólne sprzężenie może być automatycznie konwertowane na sprzężenie mapy, jeśli hive.auto.convert.join.noconditionaltask=trueszacowany rozmiar małych tabel jest mniejszy niż gałąź.auto.convert.join.noconditionaltask.size (wartość domyślna to 10000000 MB).

    Jeśli wystąpi jakikolwiek problem związany z funkcją OOM przez ustawienie właściwości hive.auto.convert.join true, zaleca się ustawienie jej na wartość false tylko dla tego konkretnego zapytania na poziomie sesji, a nie na poziomie klastra. Ten problem może wystąpić, jeśli statystyki są nieprawidłowe, a usługa Hive decyduje się na użycie sprzężenia mapy na podstawie statystyk.

  • Problem z zapytaniem Hive daje niepoprawny wynik, jeśli zapytanie ma warunek sprzężenia, a zaangażowane tabele mają wartości null lub puste.

    Przyczyna Czasami może wystąpić problem związany z wartościami null, jeśli tabele biorące udział w zapytaniu mają wiele wartości null. Usługa Hive nieprawidłowo przeprowadza optymalizację zapytań z zaangażowanymi wartościami null, co powoduje nieprawidłowe wyniki.

    Rozwiązanie Zalecamy wypróbowanie ustawienia właściwości set hive.cbo.returnpath.hiveop=true na poziomie sesji, jeśli otrzymasz nieprawidłowe wyniki. Ta konfiguracja wprowadza filtrowanie bez wartości null dla kluczy sprzężenia. Jeśli tabele miały wiele wartości null, aby zoptymalizować operację sprzężenia między wieloma tabelami, możemy włączyć tę konfigurację tak, aby uwzględniała tylko wartości nie null.

  • Problem z zapytaniem Hive daje niepoprawny wynik, jeśli zapytanie ma wiele warunków sprzężenia.

    Przyczyna : Czasami tez generuje złe plany środowiska uruchomieniowego, gdy istnieją te same sprzężenia wiele czasu z sprzężeniami mapowania.

    Rozwiązanie Istnieje prawdopodobieństwo uzyskania nieprawidłowych wyników po ustawieniu hive.merge.nway.joins wartości false. Spróbuj ustawić wartość true tylko dla zapytania, którego dotyczy problem. Ułatwia to wykonywanie zapytań o wiele sprzężeń w tym samym warunku, scalanie łączy się ze sobą w jeden operator sprzężenia. Ta metoda jest przydatna, jeśli duże sprzężenia mieszania pozwalają uniknąć fazy przetasowania.

  • Problem: istnieje wzrost czasu wykonywania zapytania o dzień w porównaniu z wcześniejszymi przebiegami.

    Przyczyna tego problemu może wystąpić, jeśli występuje wzrost większej liczby małych plików. Dlatego gałąź zajmuje trochę czasu podczas odczytywania wszystkich plików w celu przetworzenia danych, co powoduje zwiększenie czasu wykonywania.

    Rozwiązanie Upewnij się, że kompaktacja jest często uruchamiana dla tabel zarządzanych. Ten krok pozwala uniknąć małych plików i zwiększyć wydajność.

    Link referencyjny: Transakcje Hive — Apache Hive — Apache Software Foundation.

  • Problem z zapytaniem Hive daje niepoprawny wynik, gdy klient korzysta z warunku sprzężenia w tabeli zarządzanego kwasu i zarządzanej tabeli innej niż ACID.

    Przyczyna z programu HIVE 3 do wewnątrz jest ściśle żądana, aby wszystkie zarządzane tabele były zachowywane jako tabela kwasów. A jeśli chcemy zachować ją jako tabelę kwasów, format tabeli musi być orc i jest to główne kryteria. Jeśli jednak wyłączymy ścisłą właściwość tabeli zarządzanej "hive.strict.managed.tables" na wartość false, możemy utworzyć zarządzaną tabelę inną niż ACID. Niektórzy klienci tworzą zewnętrzną tabelę ORC lub po migracji tabeli przekonwertowanej na tabelę zewnętrzną i wyłączają ścisłą właściwość tabeli zarządzanej i konwertują ją na zarządzaną tabelę. W tym momencie tabela została przekonwertowana na format orc niezarządzany przez acid.

    Optymalizacja rozwiązania Hive pójdzie nie tak, jeśli połączysz tabelę z tabelą ORC niezarządzaną przez kwas z tabelą orc zarządzaną kwasem.

    Jeśli konwertujesz tabelę zewnętrzną na zarządzaną tabelę,

    1. Nie należy ustawiać właściwości "hive.strict.managed.tables" na wartość false. W przypadku ustawienia można utworzyć tabelę zarządzaną przez inny niż ACID, ale nie jest ona żądana w programie HIVE-3
    2. Przekonwertuj tabelę zewnętrzną na tabelę zarządzaną przy użyciu następującego polecenia alter zamiast alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');

Przewodnik po rozwiązywaniu problemów

Przewodnik rozwiązywania problemów z obciążeniami hive w usłudze HDInsight 3.6 do 4.0 zawiera odpowiedzi na typowe problemy występujące podczas migrowania obciążeń hive z usługi HDInsight 3.6 do usługi HDInsight 4.0.

Dalsze informacje