다음을 통해 공유


Azure HDInsight 3.6 Hive 워크로드를 HDInsight 4.0으로 마이그레이션

HDInsight 4.0은 HDInsight 3.6에 비해 몇 가지 이점이 있습니다. 다음은 HDInsight 4.0의 새로운 기능에 대한 개요입니다.

이 문서에서는 다음을 포함하여 HDInsight 3.6의 Hive 워크로드를 4.0으로 마이그레이션하는 단계를 설명합니다.

  • Hive 메타스토어 복사 및 스키마 업그레이드
  • ACID 호환성을 위한 안전한 마이그레이션
  • Hive 보안 정책 유지

새 HDInsight 클러스터와 이전 HDInsight 클러스터에는 동일한 스토리지 계정에 대한 액세스 권한이 있어야 합니다.

Hive 테이블을 새 스토리지 계정으로 마이그레이션하는 작업은 별도의 단계로 수행해야 합니다. 스토리지 계정 간 Hive 마이그레이션을 참조하세요.

Hive 3 변경 내용 및 새로운 기능

Hive 클라이언트 변경 내용

Hive 3은 명령줄에서 씬 클라이언트, 쿼리 실행용 Beeline 및 Hive 관리 명령만 지원합니다. Beeline은 HiveServer에 대한 JDBC 연결을 사용하여 모든 명령을 실행합니다. 구문 분석, 컴파일 및 실행 작업은 HiveServer에서 수행됩니다.

Hive 사용자로서 Hive 키워드를 사용하여 Beeline을 호출하거나 beeline -u <JDBC URL>을 통해 Beeline을 호출하여 지원되는 Hive CLI 명령을 입력합니다. JDBC URL은 Ambari Hive 페이지에서 가져올 수 있습니다.

Screenshot showing JDBC URL output.

더 이상 지원되지 않는 씩 클라이언트 Hive CLI 대신 Beeline을 사용하면 다음과 같은 몇 가지 장점이 있습니다.

  • 전체 Hive 코드베이스를 유지 관리하는 대신 JDBC 클라이언트만 유지 관리할 수 있습니다.
  • 전체 Hive 코드베이스가 포함되지 않으므로 Beeline을 사용하면 시작 오버헤드가 줄어듭니다.

JDBC URL을 사용하여 Beeline 연결을 호출하는 "/usr/bin" 디렉터리 아래에 있는 Hive 스크립트를 실행할 수도 있습니다.

Screenshot showing beeline connection output.

씬 클라이언트 아키텍처는 다음과 같은 상황에서 데이터를 쉽게 보호합니다.

  • 세션 상태, 내부 데이터 구조, 암호 등은 서버 대신 클라이언트에 있습니다.
  • 쿼리를 실행하는 데 필요한 디먼 수가 적어 모니터링 및 디버깅이 간소화됩니다.

HiveServer는 SET 명령을 사용하여 변경할 수 있는 허용 목록 및 차단 목록 설정을 적용합니다. 차단 목록을 사용하면 메모리 구성을 제한하여 Hive Server 불안정을 방지할 수 있습니다. 다양한 허용 목록과 차단 목록을 사용하여 여러 HiveServer 인스턴스를 구성하여 다양한 수준의 안정성을 설정할 수 있습니다.

Hive 메타스토어 변경 내용

Hive는 이제 포함된 메타스토어(HS2 JVM 내) 대신 원격 메타스토어만 지원합니다. Hive 메타스토어는 HDInsight 스택의 일부로 Ambari에서 관리하는 클러스터의 노드에 있습니다. 클러스터 외부의 독립 실행형 서버는 지원되지 않습니다. 명령줄에서 더 이상 key=value 명령을 설정하여 Hive 메타스토어를 구성하지 않습니다. "hive.metastore.uris=' ' "에 구성된 값에 따라 HMS 서비스가 사용되며 연결이 설정됩니다.

실행 엔진 변경

Apache Tez는 기본 Hive 실행 엔진으로 MapReduce를 대체합니다. MapReduce는 Hive 2.0부터 더 이상 사용되지 않습니다. HIVE-12300을 참조하세요. DAG(방향성 비순환 그래프) 및 데이터 전송 기본 형식을 사용하여 Tez에서 Hive 쿼리를 실행하면 성능이 향상됩니다. Hive에 제출하는 SQL 쿼리는 다음과 같이 실행됩니다.

  1. Hive에서 쿼리를 컴파일합니다.
  2. Tez에서 쿼리를 실행합니다.
  3. YARN에서 클러스터 전체의 애플리케이션에 대한 리소스를 할당하고, YARN 큐의 Hive 작업에 대한 권한 부여를 사용하도록 설정합니다.
  4. Hive에서 ABFS 또는 WASB의 데이터를 업데이트합니다.
  5. Hive에서 JDBC 연결을 통해 쿼리 결과를 반환합니다.

레거시 스크립트 또는 애플리케이션에서 실행에 대해 MapReduce를 지정하는 경우 다음과 같은 예외가 발생합니다.

Screenshot showing map reducer exception output.

참고 항목

대부분의 UDF(사용자 정의 함수)는 MapReduce 대신 Tez에서 실행되도록 변경할 필요가 없습니다.

ACID 트랜잭션 및 CBO와 관련된 변경 내용:

  • ACID 테이블은 성능 또는 운영 오버로드가 없는 HDInsight 4.x의 기본 테이블 형식입니다.

  • 간소화된 애플리케이션 개발, 더 강력한 트랜잭션 보장을 사용하는 작업, SQL 명령에 대한 더 간단한 의미 체계

  • Hive 내부에서 HDInsight 4.1의 ACID 테이블에 대한 버킷팅을 처리하므로 유지 관리 오버헤드가 제거됩니다.

  • 고급 최적화 – CBO에서 업그레이드

  • 자동 쿼리 캐시. 쿼리 캐싱을 사용하도록 설정하는 데 사용되는 속성은 hive.query.results.cache.enabled입니다. 이 속성을 true로 설정해야 합니다. Hive는 쿼리 결과 캐시를 /tmp/hive/__resultcache__/.에 저장합니다. 기본적으로 Hive는 쿼리 결과 캐시에 대해 2GB를 할당합니다. 이 설정은 다음 매개 변수를 hive.query.results.cache.max.size 바이트 단위로 구성하여 변경할 수 있습니다.

    자세한 내용은 Azure HDInsight 4.0으로 마이그레이션할 때의 이점을 참조하세요.

구체화된 뷰 재작성

자세한 내용은 Hive - 구체화된 뷰를 참조하세요.

Apache Hive 3으로 업그레이드 후의 변경 내용

업그레이드 후 Apache Hive 3 테이블을 찾아서 사용하려면 업그레이드 프로세스 중에 발생하는 변경 내용을 이해해야 합니다. 테이블의 관리 및 위치, 테이블 디렉터리에 대한 권한, 테이블 형식 및 ACID 준수 문제가 변경되었습니다.

테이블에 대한 Hive 관리

Hive 3은 Hive 2보다 테이블을 더 많이 제어하며 관리형 테이블은 엄격한 정의를 준수해야 합니다. Hive에서 테이블을 인수하는 제어 수준은 기존 데이터베이스와 동일한 유형입니다. Hive는 데이터의 델타 변경 내용을 자체적으로 인식합니다. 이 제어 프레임워크는 성능을 향상시킵니다.

예를 들어 Hive에서 쿼리를 확인해도 테이블에서 새 데이터를 검사할 필요가 없다는 것을 인식하고 경우 Hive는 Hive 쿼리 결과 캐시의 결과를 반환합니다. 구체화된 뷰의 기본 데이터가 변경되면 Hive에서구체화된 뷰를 다시 빌드해야 합니다. ACID 속성은 변경되고 구체화된 뷰에 처리하고 추가해야 하는 행을 정확하게 표시합니다.

ACID 속성에 대한 Hive 변경 내용

Hive 2.x 및 3.x에는 트랜잭션(관리형) 테이블과 비 트랜잭션(외부) 테이블이 모두 있습니다. 트랜잭션 테이블에는 ACID(원자성, 일관성, 격리성 및 내구성) 속성이 있습니다. Hive 2.x에서 ACID 트랜잭션 처리의 초기 버전은 ACID v1입니다. Hive 3.x에서 기본 테이블은 ACID v2를 사용합니다.

네이티브 및 비 네이티브 스토리지 형식

스토리지 형식은 테이블 형식에 대한 업그레이드 변경의 요소입니다. Hive 2.x 및 3.x에서 지원하는 Hadoop 네이티브 및 비 네이티브 스토리지 형식은 다음과 같습니다.

네이티브: Hive에서 기본적으로 다음 파일 형식으로 지원하는 테이블

  • Text
  • 시퀀스 파일
  • RC 파일
  • AVRO 파일
  • ORC 파일
  • Parquet 파일

비 네이티브: DruidStorageHandler 또는 HBaseStorageHandler와 같은 스토리지 처리기를 사용하는 테이블

테이블 형식에 대한 HDInsight 4.x 업그레이드 변경 내용

다음 표에서는 HDInsight 3.x에서 업그레이드하기 전과 HDInsight 4.x로 업그레이드한 후의 Hive 테이블 형식과 ACID 작업을 비교합니다. Hive 테이블 파일의 소유권은 업그레이드 후의 테이블 형식과 ACID 작업을 결정하는 요소입니다.

HDInsight 3.x 및 HDInsight 4.x 테이블 형식 비교

HDInsight 3.x - - - HDInsight 4.x -
테이블 형식 ACID v1 형식 Hive 테이블 파일 소유자(사용자) 테이블 형식 ACID v2
외부 아니요 네이티브 또는 비 네이티브 Hive 또는 비 Hive 외부 아니요
관리 ORC Hive 또는 비 Hive 관리형, 업데이트 가능
관리형 아니요 ORC Hive 관리형, 업데이트 가능
관리형 아니요 ORC 비 Hive 외부, 데이터 삭제 사용 아니요
관리 아니요 네이티브(ORC가 아닌 경우) Hive 관리됨, 삽입만
관리형 아니요 네이티브(ORC가 아닌 경우) 비 Hive 외부, 데이터 삭제 사용 아니요
관리 아니요 비 네이티브 Hive 또는 비 Hive 외부, 데이터 삭제 사용 아니요

Hive 가장

Hive 가장은 기본적으로 Hive 2(doAs=true)에서 사용하도록 설정되었으며, Hive 3에서는 기본적으로 사용하지 않도록 설정되었습니다. Hive 가장은 최종 사용자인지 여부에 관계없이 실행합니다.

기타 HDInsight 4.x 업그레이드 변경 내용

  1. Hive 사용자가 소유하지 않은 관리형 ACID 테이블은 업그레이드 후에도 관리형 테이블로 유지되지만 Hive가 소유자가 됩니다.
  2. 업그레이드 후 Hive 테이블의 형식은 업그레이드 전과 동일합니다. 예를 들어 네이티브 또는 비 네이티브 테이블은 각각 네이티브 또는 비 네이티브 테이블로 유지됩니다.

위치 변경

업그레이드 후 관리형 테이블 또는 파티션의 위치는 다음 조건 중 하나에서 변경되지 않습니다.

  • 이전 테이블 또는 파티션 디렉터리가 업그레이드 전에는 /apps/hive/warehouse 기본 위치에 없었습니다.
  • 이전 테이블 또는 파티션은 새 웨어하우스 디렉터리와 다른 파일 시스템에 있습니다.
  • 이전 테이블 또는 파티션 디렉터리는 새 웨어하우스 디렉터리와 다른 암호화 영역에 있습니다.

그렇지 않으면 관리형 테이블 또는 파티션의 위치가 변경됩니다. 업그레이드 프로세스는 관리형 파일을 /hive/warehouse/managed로 이동합니다. 기본적으로 Hive는 HDInsight 4.x에서 만드는 새 외부 테이블을 /hive/warehouse/external에 배치합니다.

Hive 2.x 웨어하우스의 이전 위치인 /apps/hive directory는 HDInsight 4.x에 있거나 있지 않을 수도 있습니다.

위치 변경에 대한 시나리오는 다음과 같습니다.

시나리오 1

테이블이 HDInsight-3.x의 관리형 테이블이고 /apps/hive/warehouse 위치에 있고 HDInsight-4.x에서 외부 테이블로 변환된 경우 위치는 HDInsight 4.x에서도 동일한 /apps/hive/warehouse입니다. 위치는 변경되지 않습니다. 이 단계 후에는 alter table 명령을 수행하여 해당 테이블을 동일한/apps/hive/warehouse 위치에 있는 관리형(ACID) 테이블로 변환합니다.

시나리오 2

테이블이 HDInsight-3.x의 관리형 테이블이고 /apps/hive/warehouse 위치에 있고 HDInsight 4.x의 관리형(ACID) 테이블로 변환된 경우 위치는 /hive/warehouse/managed입니다.

시나리오 3 HDInsight-4.x에서 위치를 지정하지 않고 외부 테이블을 만드는 경우 해당 테이블은 /hive/warehouse/external 위치에 있습니다.

테이블 변환

업그레이드 후 비 트랜잭션 테이블을 ACID v2 트랜잭션 테이블로 변환하려면 ALTER TABLE 명령을 사용하고 테이블 속성을 다음과 같이 설정합니다.

transaction'='true' and 'EXTERNAL'='false
  • HDInsight-3.x에서 비 Hive 사용자가 소유하고는 비 ACID, ORC 형식의 관리형 테이블은 HDInsight-4.x에서 외부 비 ACID 테이블로 변환됩니다.
  • 사용자가 외부 테이블(비 ACID)을 ACID로 변경하려는 경우 외부 테이블도 관리형 및 ACID로 변경해야 합니다. HDInsight-4.x에서는 모든 관리 테이블이 기본적으로 엄격하게 ACID이기 때문입니다. 외부 테이블(비 ACID)은 ACID 테이블로 변환할 수 없습니다.

참고 항목

테이블은 ORC 테이블이어야 합니다.

외부 테이블(비 ACID)을 관리형(ACID) 테이블로 변환하려면 다음을 수행합니다.

  1. 다음 명령을 사용하여 외부 테이블을 관리형으로 변환하고 ACID를 true로 변환합니다.
    alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
    
  2. 외부 테이블에 대해 다음 명령을 실행하려고 하면 아래 오류가 발생합니다.

시나리오 1

rt 테이블이 외부 테이블(비 ACID)이라고 가정합니다. 테이블이 비 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

시나리오 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)

이 오류는 rt 테이블이 외부 테이블이고 외부 테이블을 ACID로 변환할 수 없기 때문에 발생합니다.

시나리오 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)

여기서는 먼저 외부 테이블을 관리형 테이블로 변경하려고 합니다. HDInsight 4.x에서는 엄격한 관리형 테이블이어야 합니다(즉, ACID여야 함). 따라서 여기서는 교착 상태가 발생합니다. 외부 테이블(NON_ACID)을 관리형(ACID) 테이블로 변환하는 유일한 방법은 다음 명령을 수행해야 하는 것입니다.

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

구문 및 의미 체계

  • 테이블 만들기 - 사용 가능성과 기능성을 향상시키기 위해 Hive 3에서 테이블 만들기가 변경되었습니다. Hive에서 테이블 만들기는 다음과 같은 방법으로 변경되었습니다.

    • HDP의 기본값인 ACID 준수 테이블 만들기
    • 간단한 쓰기 및 삽입 지원
    • 여러 파티션에 쓰기
    • 단일 SELECT 문에 여러 데이터 업데이트 삽입
    • 버킷팅이 필요하지 않음

    Hive에서 테이블을 만드는 ETL 파이프라인이 있는 경우 테이블을 ACID로 만듭니다. 이제 Hive는 액세스를 엄격하게 제어하고 테이블에서 압축을 주기적으로 수행합니다.

    업그레이드 전 HDInsight 3.x에서는 기본적으로 CREATE TABLE에서 비 ACID 테이블을 만들었습니다.

    업그레이드 후 CREATE TABLE에서 기본적으로 전체 ACID 트랜잭션 테이블을 ORC 형식으로 만듭니다.

    필요한 작업 Spark에서 Hive ACID 테이블에 액세스하려면 HWC(Hive Warehouse Connector)를 사용하여 Hive에 연결합니다. ACID 테이블을 Spark에서 Hive로 쓰려면 HWC 및 HWC API를 사용합니다.

  • db.table 참조 이스케이프

    Hive에서 전체 db.table 문자열을 테이블 이름으로 해석하지 못하도록 db.table 참조를 사용하는 쿼리를 변경해야 합니다. Hive 3.x는 SQL 쿼리에서 db.table을 거부합니다. 테이블 이름에는 점(.)이 허용되지 않습니다. 데이터베이스 이름과 테이블 이름을 백틱으로 묶습니다. 문제가 있는 테이블 참조가 있는 테이블을 찾습니다. 이 경우 CREATE TABLE 문에 나타나는 math.students입니다. 데이터베이스 이름과 테이블 이름을 백틱으로 묶으세요.

    TABLE `math`.`students` (name VARCHAR(64), age INT, gpa DECIMAL(3,2));
    
  • 타임스탬프 캐스팅 - 숫자를 타임스탬프로 캐스팅하는 애플리케이션의 결과는 Hive 2와 Hive 3마다 각각 다릅니다. Apache Hive는 표준 시간대를 TIMESTAMP 형식과 연결하지 않는 SQL Standard를 준수하도록 CAST 동작을 변경했습니다.

    업그레이드 전 숫자 형식 값을 타임스탬프로 캐스팅하여 클러스터의 표준 시간대를 반영하는 결과를 생성할 수 있습니다. 예를 들어 1597217764557은 2020-08-12 00:36:04 PDT입니다. 다음 쿼리를 실행하면 숫자가 PDT의 타임스탬프로 캐스팅됩니다. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 00:36:04 |

    업그레이드 후 숫자 형식 값을 타임스탬프로 캐스팅하면 클러스터의 표준 시간대 대신 UTC를 반영하는 결과가 생성됩니다. 다음 쿼리를 실행하면 숫자가 UTC의 타임스탬프로 캐스팅됩니다. SELECT CAST(1597217764557 AS TIMESTAMP); | 2020-08-12 07:36:04.557 |

    필요한 작업 애플리케이션을 변경합니다. 현지 표준 시간대를 얻기 위해 숫자에서 캐스팅하지 마세요. from_utc_timestamp 및 to_utc_timestamp 기본 제공 함수를 사용하여 업그레이드 전 동작을 모방할 수 있습니다.

  • 열 변경의 호환성 확인 - 기본 구성 변경으로 인해 열 형식을 변경하는 애플리케이션이 실패할 수 있습니다.

    업그레이드 전 HDInsight 3.x에서 Hive.metastore.disallow.incompatible.col.type.changes는 호환되지 않는 열 형식에 대한 변경을 허용하기 위해 기본적으로 false입니다. 예를 들어 STRING 열을 MAP<STRING, STRING>과 같은 호환되지 않는 형식의 열로 변경할 수 있습니다. 오류가 발생하지 않습니다.

    업그레이드 후 hive.metastore.disallow.in Compatible.col.type.changes는 기본적으로 true입니다. Hive는 호환되지 않는 열 형식의 변경을 방지합니다. INT, STRING, BIGINT 등 호환되는 열 형식 변경은 차단되지 않습니다.

    필요한 작업 가능한 데이터 손상을 방지하기 위해 호환되지 않는 열 형식 변경을 허용하지 않도록 애플리케이션을 변경합니다.

  • 파티션 삭제

    성능 문제가 발생하므로 파티션 삭제에 대한 CASCADE 절의 OFFLINE 및 NO_DROP 키워드는 더 이상 지원되지 않습니다.

    업그레이드 전 CASCADE 절에서 OFFLINE 및 NO_DROP 키워드를 사용하여 파티션이 읽히거나 삭제되지 않도록 방지할 수 있습니다.

    업그레이드 후 CASCADE 절에서 OFFLINE 및 NO_DROP이 지원되지 않습니다.

    필요한 작업 CASCADE 절에서 OFFLINE 및 NO_DROP을 제거하도록 애플리케이션을 변경합니다. Ranger와 같은 권한 부여 체계를 사용하여 파티션이 삭제되거나 읽히지 않도록 방지합니다.

  • 테이블 이름 바꾸기 - 업그레이드 후 관리형 테이블의 이름을 바꾸면 테이블이 LOCATION 절 없이 만들어지고 데이터베이스 디렉터리에 있는 경우에만 해당 위치가 이동됩니다.

CBO와 관련된 제한 사항

  • 선택 출력의 몇 개의 열에서 후행 0을 제공하는 것을 볼 수 있습니다. 예를 들어 데이터 형식이 10진수(38,4)인 테이블 열이 있고 데이터를 38로 삽입하면 후행 0이 추가되고 결과가 38.0000으로 제공됩니다. https://issues.apache.org/jira/browse/HIVE-12063https://issues.apache.org/jira/browse/HIVE-24389에 따라 10진수 열에서 래퍼를 실행하는 대신 소수 자릿수와 정밀도를 유지합니다. 이는 Hive 2의 기본 동작입니다. 이 문제를 해결하기 위해 아래 옵션을 따를 수 있습니다.

    1. 정밀도를 col1(decimal(38,0))으로 조정하도록 원본 수준에서 데이터 형식을 수정합니다. 이 값은 뒤에 후행 0이 없는 38이라는 결과를 제공합니다. 그러나 데이터를 35.0005로 삽입하면 이 데이터는 .0005이고 값만 38 1로 제공됩니다. 문제가 있는 열에 대해 후행 0을 제거한 문자열로 캐스팅합니다.
      1. select TRIM(cast(<column_name> AS STRING))+0 FROM <table_name>;을 사용합니다.
      2. 정규식을 사용합니다.
  1. Hive 쿼리에서 UNIX_TIMESTAMP를 사용하면 "지원되지 않는 하위 쿼리 식"으로 인해 이 쿼리가 실패합니다. 예를 들어 쿼리를 실행하면 "지원되지 않는 하위 쿼리 식" 오류가 throw됩니다.

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

    이 문제의 근본 원인은 Calcite에서 BIGINT로 인식하는 UNIX_TIMESTAMP의 정밀도에 대한 정밀도 매핑이 HiveTypeSystemImpl.java code에 없기 때문에 현재 Hive 코드베이스에서 UNIX_TIMESTAMP를 구문 분석하는 예외를 throw한다는 것입니다. 그러나 아래 쿼리는 정상적으로 작동합니다. select * from (SELECT col_1 from table1 where col_2 >= 1);

    col_2가 정수이므로 이 명령은 성공적으로 실행됩니다. 위의 문제는 hdi-3.1.2-4.1.12(4.1 스택) 및 hdi-3.1.2-5.0.8(5.0 스택)에서 해결되었습니다.

업그레이드 단계

1. 데이터 준비

  • HDInsight 3.6은 기본적으로 ACID 테이블을 지원하지 않습니다. 그러나 ACID 테이블이 있는 경우 'MAJOR' 압축을 실행합니다. 압축에 대한 자세한 내용은 Hive 언어 설명서를 참조하세요.

  • Azure Data Lake Storage Gen1을 사용하는 경우 Hive 테이블 위치는 클러스터의 HDFS 구성에 따라 달라질 수 있습니다. 다음 스크립트 작업을 실행하여 이러한 위치를 다른 클러스터로 이식할 수 있도록 합니다. 실행 중인 클러스터에 대한 동작 스크립팅을 참조하세요.

    속성
    Bash 스크립트 URI https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
    노드 유형 Head
    매개 변수

2. SQL 데이터베이스 복사

  • 클러스터가 기본 Hive 메타스토어를 사용하는 경우 이 가이드에 따라 메타데이터를 외부 메타스토어로 내보냅니다. 그런 다음 업그레이드할 외부 메타스토어 복사본을 만듭니다.

  • 클러스터가 외부 Hive 메타스토어를 사용하는 경우 해당 복사본을 만듭니다. 옵션에는 내보내기/가져오기특정 시점 복원이 있습니다.

3. 메타스토어 스키마 업그레이드

이 단계에서는 HDInsight 4.0의 Hive Schema Tool을 사용하여 메타스토어 스키마를 업그레이드합니다.

Warning

이 단계는 되돌릴 수 없습니다. 메타스토어의 복사본에서만 이 단계를 실행합니다.

  1. 임시 HDInsight 4.0 클러스터를 만들어 4.0 Hive schematool에 액세스합니다. 이 단계에서는 기본 Hive 메타스토어를 사용할 수 있습니다.

  2. HDInsight 4.0 클러스터에서 schematool을 실행하여 대상 HDInsight 3.6 메타스토어를 업그레이드합니다. 다음 셸 스크립트를 편집하여 SQL 서버 이름, 데이터베이스 이름, 사용자 이름 및 암호를 추가합니다. 헤드 노드에서 SSH 세션을 열고 실행합니다.

    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
    

    참고 항목

    이 유틸리티는 beeline 클라이언트를 사용하여 /usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql에서 SQL 스크립트를 실행합니다.

    이러한 스크립트의 SQL 구문이 다른 클라이언트 도구와 반드시 호환되는 것은 아닙니다. 예를 들어, SSMSAzure Portal 쿼리 편집기에는 각 명령 뒤에 GO 키워드가 필요합니다.

    리소스 용량 또는 트랜잭션 시간 제한으로 인해 스크립트가 실패하는 경우 SQL Database를 스케일 업합니다.

  3. select schema_version from dbo.version 쿼리를 사용하여 최종 버전을 확인합니다.

    출력은 HDInsight 4.0 클러스터의 다음 bash 명령 중 하나와 일치해야 합니다.

    grep . /usr/hdp/$(hdp-select --version)/hive/scripts/metastore/upgrade/mssql/upgrade.order.mssql | tail -n1 | rev | cut -d'-' -f1 | rev
    
  4. 임시 HDInsight 4.0 클러스터를 삭제합니다.

4. 새 HDInsight 4.0 클러스터 배포

업그레이드된 Hive 메타스토어 및 동일한 스토리지 계정을 선택하여 새 HDInsight 4.0 클러스터를 만듭니다.

  • 새 클러스터에는 동일한 기본 파일 시스템이 필요하지 않습니다.

  • 메타스토어가 여러 스토리지 계정에 있는 테이블을 포함하는 경우, 이러한 테이블에 액세스하려면 해당 스토리지 계정을 새 클러스터에 추가해야 합니다. HDInsight에 추가 스토리지 계정 추가를 참조하세요.

  • 스토리지에 액세스하지 못해 Hive 작업이 실패하는 경우 테이블 위치가 클러스터에 추가된 스토리지 계정에 있는지 확인합니다.

    다음 Hive 명령을 사용하여 테이블 위치를 식별합니다.

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

5. ACID를 준수하기 위한 테이블 변환

관리되는 테이블은 HDInsight 4.0에서 ACID를 준수해야 합니다. HDInsight 4.0에서 strictmanagedmigration을(를) 실행하여 ACID로 관리되지 않는 모든 테이블을 외부 테이블('external.table.purge'='true' 속성 사용)로 변환합니다. 헤드 노드에서 다음을 실행합니다.

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. MultiDelimitSerDe 클래스를 찾을 수 없음 오류 발생

문제

Hive 쿼리를 실행할 때 특정 상황에서 org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe 클래스를 찾을 수 없다는 java.lang.ClassNotFoundException가 표시될 수 있습니다. 이 오류는 고객이 HDInsight 3.6에서 HDInsight 4.0으로 마이그레이션할 때 발생합니다. HDInsight 3.6의 일부인 SerDe 클래스 org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe가 제거되고 hive-contrib-1.2.1000.2.6.5.3033-1.jar가 HDI-4.0에서 hive-exec jar의 일부인 org.apache.hadoop.hive.serde2.MultiDelimitSerDe 클래스를 사용하고 있습니다. hive-exec jar는 이 서비스를 시작할 때 기본적으로 HS2에 로드됩니다.

문제 해결 단계

  1. 폴더 아래의 JAR(HDInsight의 /usr/hdp/current/hive/lib에 해당하는 Hive 라이브러리 폴더 아래에 있을 수 있음)에 이 클래스가 포함되어 있는지 여부를 확인합니다.
  2. 솔루션에 설명된 대로 클래스 org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDeorg.apache.hadoop.hive.serde2.MultiDelimitSerDe를 확인합니다.

솔루션

  1. JAR 파일은 이진 파일이지만 아래와 같이 -Hrni 스위치와 함께 grep 명령을 사용하여 특정 클래스 이름을 검색할 수 있습니다.

    grep -Hrni "org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe" /usr/hdp/current/hive/lib
    
  2. 클래스를 찾을 수 없으면 출력이 반환되지 않습니다. JAR 파일에서 클래스를 찾으면 출력이 반환됩니다.

  3. 다음은 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. 위의 출력에서 jar에 클래스 org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe가 포함되어 있지 않고 hive-exec jar에 org.apache.hadoop.hive.serde2.MultiDelimitSerDe가 포함되어 있는지 확인할 수 있습니다.

  5. 행 형식 DerDe를 ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe로 사용하여 테이블을 만듭니다.

  6. 이 명령은 문제를 해결합니다. 테이블을 이미 만든 경우 아래 명령을 사용하여 이름을 바꿀 수 있습니다.

    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';
    

update 명령은 백 엔드 DB에서 세부 정보를 수동으로 업데이트하며 alter 명령은 beeline 또는 Hive에서 새 SerDe 클래스로 테이블을 변경하는 데 사용됩니다.

Hive 백 엔드 DB 스키마 비교 스크립트

마이그레이션이 완료되면 다음 스크립트를 실행할 수 있습니다.

백 엔드 DB에서 몇 개의 열이 누락되어 쿼리 오류가 발생할 수 있습니다. 스키마 업그레이드가 제대로 수행되지 않은 경우 잘못된 열 이름 문제가 발생할 수 있습니다. 아래 스크립트는 고객 백 엔드 DB에서 열 이름과 데이터 형식을 가져오고, 누락된 열이 있거나 잘못된 데이터 형식이 있는 경우 출력을 제공합니다.

다음 경로에는 schemacompare_final.py 및 test.csv 파일이 포함되어 있습니다. 스크립트는 "schemacompare_final.py" 파일에 있고, "test.csv" 파일에는 Hive 백 엔드 DB에 있어야 하는 모든 테이블에 대한 모든 열 이름과 데이터 형식이 포함되어 있습니다.

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

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

링크에서 이러한 두 파일을 다운로드합니다. 그리고 이러한 파일을 Hive 서비스가 실행되는 헤드 노드 중 하나에 복사합니다.

스크립트 실행 단계:

"schemacompare"라는 디렉터리를 "/tmp" 디렉터리 아래에 만듭니다.

"schemacompare_final.py" 및 "test.csv"를 "/tmp/schemacompare" 폴더에 넣습니다. "ls -ltrh /tmp/schemacompare/"를 수행하고 파일이 있는지 확인합니다.

Python 스크립트를 실행하려면 "python Schemacompare_final.py" 명령을 사용합니다. 이 스크립트는 스크립트 실행을 시작하며 완료하는 데 5분 미만이 걸립니다. 위의 스크립트는 자동으로 백 엔드 DB에 연결하고, Hive에서 사용하는 각 테이블의 세부 정보를 가져오고 "return.csv"라는 새 csv 파일의 세부 정보를 업데이트합니다. return.csv 파일이 만들어지면 데이터를 "test.csv" 파일과 비교하고 테이블 이름 아래에 누락된 항목이 있으면 열 이름 또는 데이터 형식을 출력합니다.

스크립트가 실행되면 다음 줄을 볼 수 있습니다. 이는 테이블에 대한 세부 정보를 가져오고 스크립트가 진행 중임을 나타냅니다.

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

그리고 "DIFFERENCE DETAILS:" 줄 아래에서 차이 세부 정보를 볼 수 있습니다. 차이가 있으면 출력됩니다.

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.

테이블에 차이가 없는 경우 출력은 다음과 같습니다.

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

이 출력에서 누락되었거나 잘못된 열 이름을 확인할 수 있습니다. 백 엔드 DB에서 다음 쿼리를 실행하여 열이 누락되었는지 여부를 한 번 확인할 수 있습니다.

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

예를 들어 테이블에서 열이 누락된 경우 insert 또는 insert overwrite와 같은 쿼리를 실행하면 통계가 자동으로 계산되고 PART_COL_STATS 및 TAB_COL_STATS와 같은 통계 테이블을 업데이트하려고 시도합니다. 그리고 테이블에서"BIT_VECTOR"와 같은 열이 누락되면 "잘못된 열 이름" 오류로 인해 실패합니다. 다음 명령에서 설명한 대로 열을 추가할 수 있습니다. 해결 방법으로 백 엔드 데이터베이스의 통계를 업데이트할 수 없는 다음 속성을 설정하여 통계를 사용하지 않도록 설정할 수 있습니다.

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);

이 단계는 마이그레이션 후 "잘못된 열 이름"으로 인해 실패하는 쿼리 오류를 한 번 방지합니다.

HDInsight 버전 간 Hive 보안

HDInsight는 필요에 따라 HDInsight ESP(Enterprise Security Package)를 사용하여 Microsoft Entra ID와 통합됩니다. ESP는 Kerberos 및 Apache Ranger를 사용하여 클러스터 내 특정 리소스에 대한 사용 권한을 관리합니다. HDInsight 3.6의 Hive에 대해 배포된 Ranger 정책은 다음 단계를 통해 HDInsight 4.0으로 마이그레이션할 수 있습니다.

  1. HDInsight 3.6 클러스터의 Ranger Service Manager 패널로 이동합니다.
  2. HIVE라는 정책으로 이동하여 json 파일로 정책을 내보냅니다.
  3. 내보낸 정책 json에서 참조되는 모든 사용자가 새 클러스터에 있는지 확인합니다. 사용자가 정책 json에서 참조되지만 새 클러스터에 없는 경우 새 클러스터에 사용자를 추가하거나 정책에서 참조를 제거합니다.
  4. HDInsight 4.0 클러스터의 Ranger Service Manager 패널로 이동합니다.
  5. HIVE라는 정책으로 이동하여 2단계에서 Ranger 정책 json을 가져옵니다.

애플리케이션을 변경해야 할 수도 있는 HDInsight 4.0의 Hive 변경 내용

기타 변경 내용은 HDInsight 4.0 발표를 참조하세요.

마이그레이션 게시

마이그레이션이 완료되면 다음 단계를 수행해야 합니다.

테이블 온전성

  1. 테이블 속성을 변경하는 대신 CTAS 또는 IOW를 사용하여 Hive 3.1에서 테이블을 다시 만들어 테이블 형식을 변경합니다.
  2. doAs를 false로 유지합니다.
  3. 관리형 테이블/데이터 소유권이 "hive" 사용자에게 있는지 확인합니다.
  4. ORC 테이블 형식인 경우 관리형 ACID 테이블을 사용하고, 비 ORC 형식인 경우 관리형 비 ACID를 사용합니다.
  5. 마이그레이션으로 인해 잘못된 통계가 발생했으므로 다시 만든 테이블의 통계를 다시 생성합니다.

클러스터 상태

여러 클러스터에서 동일한 스토리지와 HMS DB를 공유하는 경우 한 클러스터에서만 자동 압축/압축 스레드를 사용하도록 설정하고 다른 클러스터에서는 사용하지 않도록 설정해야 합니다.

CPU 사용량을 줄이도록 메타스토어를 튜닝합니다.

  1. 트랜잭션 이벤트 수신기를 사용하지 않도록 설정합니다.

    참고 항목

    Hive 복제 기능을 사용하지 않는 경우에만 다음 단계를 수행하세요.

    1. Ambari UI에서 hive.metastore.transactional.event.listeners 값을 제거합니다.
    2. 기본값: org.apache.hive.hcatalog.listener.DbNotificationListener
    3. 새 값: <Empty>
  2. Hive PrivilegeSynchronizer를 사용하지 않도록 설정합니다.

    1. Ambari UI에서 hive.privilege.synchronizer = false를 설정합니다.
    2. 기본값: true
    3. 새 값: false
  3. 파티션 복구 기능을 최적화합니다.

  4. 파티션 복구 사용 안 함 - 이 기능은 스토리지 위치에 있는 Hive 테이블의 파티션을 Hive 메타스토어와 동기화하는 데 사용됩니다. 데이터 수집 후 "msck repair"를 사용하는 경우 이 기능을 사용하지 않도록 설정할 수 있습니다.

  5. 이 기능을 사용하지 않도록 설정하려면 ALTER TABLE을 사용하여 테이블 속성 아래에 "discover.partitions=false"를 추가합니다. OR(기능을 사용하지 않도록 설정할 수 없는 경우)

  6. 파티션 복구 빈도를 늘립니다.

  7. Ambari UI에서 "metastore.partition.management.task.frequency" 값을 초 단위로 늘립니다.

    참고 항목

    이 변경으로 인해 스토리지에 수집된 일부 파티션의 표시가 지연될 수 있습니다.

    1. 기본값: 60
    2. 제안된 값: 3600
  8. 고급 최적화 - 다음 옵션은 프로덕션에 적용하기 전에 하위(비 프로덕션) 환경에서 테스트해야 합니다.

    1. 구체화된 뷰가 사용되지 않는 경우 구체화된 뷰 관련 수신기를 제거합니다.
    2. Ambari UI에서 사용자 지정 속성을 사용자 지정 hive-site.xml에 추가하고 원하지 않는 백그라운드 메타스토어 스레드를 제거합니다.
    3. 속성 이름: metastore.task.threads.remote
    4. 기본값: N/A (it uses few class names internally)
    5. 새 값: 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. 복제가 사용하지 않도록 설정된 경우 백그라운드 스레드를 사용하지 않도록 설정합니다.

    1. Ambari UI에서 사용자 지정 속성을 사용자 지정 hive-site.xml에 추가하고 원하지 않는 스레드를 제거합니다.
    2. 속성 이름: metastore.task.threads.always
    3. 기본값: N/A (it uses few class names internally)
    4. 새 값: org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask

쿼리 튜닝

  1. TPC-DS 워크로드에 맞게 튜닝된 쿼리를 실행하려면 Hive의 기본 구성을 유지합니다. 실패하거나 느리게 실행되는 경우에만 쿼리 수준 튜닝이 필요합니다.
  2. 잘못된 계획 또는 결과를 방지하려면 통계가 최신 상태인지 확인합니다.
  3. 조인 유형의 쿼리에서 외부 및 관리형 ACID 테이블을 혼합하지 않도록 방지합니다. 이러한 경우 다시 만들기를 통해 외부에서 관리형 비 ACID 테이블로 변환합니다.
  4. Hive-3에서는 제품 버그가 있을 수 있는 벡터화, CBO, 영역이 포함된 타임스탬프 등에 대한 많은 작업이 수행되었습니다. 따라서 쿼리에서 잘못된 결과를 제공하는 경우 벡터화, CBO, 맵 조인 등을 사용하지 않도록 설정하여 도움이 되는지 확인합니다.

마이그레이션 후 잘못된 결과와 성능 저하를 해결하기 위해 따라야 할 기타 단계

  1. 문제 Hive 쿼리에서 잘못된 결과를 제공합니다. select count(*) 쿼리에서도 잘못된 결과를 제공합니다.

    원인 'hive.compute.query.using.stats' 속성은 기본적으로 true로 설정됩니다. true로 설정되면 메타스토어에 저장된 통계를 사용하여 쿼리를 실행합니다. 최신 통계가 아닌 경우 잘못된 결과가 발생합니다.

    해결 방법 테이블 수준 및 열 수준에서 alter table <table_name> compute statics; 명령을 사용하여 관리형 테이블에 대한 통계를 수집합니다. 참조 링크 - https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatistics

  2. 문제 Hive 쿼리를 실행하는 데 시간이 오래 걸립니다.

    원인 쿼리에 조인 조건이 있는 경우 Hive는 테이블 크기 및 조인 조건에 따라 맵 조인을 사용할지 아니면 병합 조인을 사용할지에 대한 계획을 만듭니다. 테이블 중 하나에 작은 크기가 포함되어 있으면 해당 테이블을 메모리에 로드하고 조인 작업을 수행합니다. 이렇게 하면 쿼리 실행이 병합 조인에 비해 더 빠릅니다.

    해결 방법 기본값인 "hive.auto.convert.join=true" 속성을 설정해야 합니다. false로 설정하면 병합 조인이 사용되므로 성능이 저하될 수 있습니다. Hive는 클러스터에 설정된 다음 속성에 따라 맵 조인을 사용할지 여부를 결정합니다.

    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>;
    

    hive.auto.convert.join.noconditionaltask=true인 경우 작은 테이블의 예상 크기가hive.auto.convert.join.noconditionaltask.size(기본값: 10000000MB)보다 작으면 일반적인 조인이 맵 조인으로 자동으로 변환될 수 있습니다.

    hive.auto.convert.join 속성을 true로 설정하여 OOM과 관련된 문제가 발생하는 경우 클러스터 수준이 아닌 세션 수준의 특정 쿼리에 대해서만 false로 설정하는 것이 좋습니다. 통계가 잘못되었고 Hive에서 통계에 따라 맵 조인을 사용하도록 결정한 경우 이 문제가 발생할 수 있습니다.

  • 문제 쿼리에 조인 조건이 있고 포함된 테이블에 null 또는 빈 값이 있는 경우 Hive 쿼리에서 잘못된 결과를 제공합니다.

    원인 쿼리에 포함된 테이블에 null 값이 많이 있는 경우 null 값과 관련된 문제가 발생할 수 있습니다. Hive에서 포함된 null 값을 사용하여 쿼리 최적화를 잘못 수행함으로써 잘못된 결과를 발생합니다.

    해결 방법 잘못된 결과가 발생하면 세션 수준에서 set hive.cbo.returnpath.hiveop=true 속성을 설정하는 것이 좋습니다. 이 구성은 null 아님 필터링을 조인 키에 도입합니다. 테이블에 null 값이 많은 경우 여러 테이블 간의 조인 작업을 최적화하기 위해 이 구성을 사용하도록 설정하여 null이 아닌 값만 고려할 수 있습니다.

  • 문제 쿼리에 여러 조인 조건이 있는 경우 Hive 쿼리에서 잘못된 결과를 제공합니다.

    원인 때로는 맵 조인을 사용하는 동일한 조인이 여러 번 있을 때마다 Tez에서 잘못된 런타임 계획을 생성합니다.

    해결 방법 hive.merge.nway.joins를 false로 설정하면 잘못된 결과가 발생할 수 있습니다. 영향을 받은 쿼리에 대해서만 true로 설정해 봅니다. 이렇게 하면 동일한 조건에서 여러 조인을 사용하여 쿼리하고 모든 조인을 단일 조인 연산자에 병합할 수 있습니다. 이 방법은 다시 순서 섞기 단계를 방지하기 위해 큰 순서 섞기 조인을 수행하는 경우에 유용합니다.

  • 문제' 쿼리 실행 시간이 이전 실행에 비해 날마다 증가합니다.

    원인 작은 파일이 더 많이 증가하는 경우 이 문제가 발생할 수 있습니다. 따라서 Hive에서 데이터를 처리하기 위해 모든 파일을 읽는 데 시간이 걸리므로 실행 시간이 증가합니다.

    해결 방법 관리형 테이블에 대해 압축을 자주 실행해야 합니다. 이 단계에서는 작은 파일을 방지하고 성능을 향상시킵니다.

    참조 링크: Hive Transactions - Apache Hive - Apache Software Foundation.

  • 문제 고객이 관리형 ACID ORC 테이블 및 관리형 비 ACID ORC 테이블에서 조인 조건을 사용하는 경우 Hive 쿼리에서 잘못된 결과를 제공합니다.

    원인 HIVE 3부터 모든 관리형 테이블을 ACID 테이블로 유지하도록 엄격하게 요청됩니다. 그리고 이를 ACID 테이블로 유지하려면 주요 조건으로 테이블 형식이 ORC여야 합니다. 그러나 "hive.strict.managed.tables" strict 관리형 테이블 속성을 false로 사용하지 않도록 설정하면 관리형 비 ACID 테이블을 만들 수 있습니다. 경우에 따라 고객이 외부 ORC 테이블을 만들거나 마이그레이션 후 테이블을 외부 테이블로 변환하고 strict 관리형 테이블 속성을 사용하지 않도록 설정하고 관리형 테이블로 변환합니다. 이 시점에서 테이블은 비 ACID 관리형 ORC 형식으로 변환되었습니다.

    해결 방법 비 ACID 관리형 ORC 테이블과 ACID 관리형 ORC 테이블을 조인하면 Hive 최적화가 잘못됩니다.

    외부 테이블을 관리형 테이블로 변환하는 경우

    1. "hive.strict.managed.tables" 속성을 false로 설정하지 않습니다. 설정하면 비 ACID 관리형 테이블을 만들 수 있지만 HIVE-3에서는 요청되지 않습니다.
    2. alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false'); 대신 다음과 같은 alter 명령을 사용하여 외부 테이블을 관리형 테이블로 변환합니다.
    alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
    

문제 해결 가이드

Hive 워크로드에 대한 HDInsight 3.6~4.0 문제 해결 가이드는 Hive 워크로드를 HDInsight 3.6에서 HDInsight 4.0으로 마이그레이션할 때 발생하는 일반적인 문제에 대한 답변을 제공합니다.

추가 참고 자료