Data Engineering Blog

Riot Data Pipeline 구축하기 #7 - HDFS에 저장된 JSON 데이터로 Hive 테이블 생성하기

Taaewoo — Wed, 26 Apr 2023 04:18:55 +0900

Riot 데이터를 수집해서 최종적으로 HDFS에 저장하는 과정까지 성공했습니다( 비록 미흡한 점이 상당히 많지만.... ). 이제는 저장된 데이터를 기반으로 Hive 테이블을 생성하는 과정을 진행하겠습니다.

Docker Compose에 Hive 서비스 추가

Kafka에 있는 데이터를 HDFS에 저장하기 위해 Docker Compose에 Spark와 HDFS 서비스들을 추가했었습니다. 이번에는 동일한 Docker Compose에 Hive 서비스를 추가하겠습니다.

docker-compose.yml

version: '2'

services:

spark-master:

image: bde2020/spark-master:2.4.0-hadoop2.8

ports:

- "8080:8080"

- "7077:7077"

env_file:

- ./hadoop.env

environment:

- INIT_DAEMON_STEP=setup_spark

spark-worker-1:

image: bde2020/spark-worker:2.4.0-hadoop2.8

depends_on:

- spark-master

ports:

- "8081:8081"

env_file:

- ./hadoop.env

environment:

- "SPARK_MASTER=spark://spark-master:7077"

spark-notebook:

image: bde2020/spark-notebook:2.1.0-hadoop2.8-hive

container_name: spark-notebook

env_file:

- ./hadoop.env

ports:

- 9001:9001

namenode:

image: bde2020/hadoop-namenode:1.1.0-hadoop2.8-java8

container_name: namenode

volumes:

- ./data/namenode:/hadoop/dfs/name

environment:

- CLUSTER_NAME=test

env_file:

- ./hadoop.env

ports:

- 50070:50070

datanode:

image: bde2020/hadoop-datanode:1.1.0-hadoop2.8-java8

depends_on:

- namenode

volumes:

- ./data/datanode:/hadoop/dfs/data

env_file:

- ./hadoop.env

ports:

- 50075:50075

hive-server:

image: bde2020/hive:2.3.2-postgresql-metastore

volumes:

- ./hive_dir:/root

env_file:

- ./hadoop.env

environment:

HIVE_CORE_CONF_javax_jdo_option_ConnectionURL: "jdbc:postgresql://hive-metastore/metastore"

SERVICE_PRECONDITION: "hive-metastore:9083"

ports:

- "10000:10000"

- "8000:8000"

hive-metastore:

image: bde2020/hive:2.3.2-postgresql-metastore

env_file:

- ./hadoop.env

command: /opt/hive/bin/hive --service metastore

environment:

SERVICE_PRECONDITION: "namenode:50070 datanode:50075 hive-metastore-postgresql:5432"

ports:

- "9083:9083"

hive-metastore-postgresql:

image: bde2020/hive-metastore-postgresql:2.3.0

Match 데이터 경로 수정

이전 글에서 Match 데이터를 저장한 HDFS 경로는 "/riot/match_raw_data" 였습니다. 하지만 데이터가 계속해서 쌓이면서 성능의 이슈를 생각한다면 Hive 테이블의 partition이 필요할 것입니다. 그래서 닉네임을 기준으로 partition을 구분하겠습니다.

만약 닉네임이 "aaa"라면 경로는 "/riot/match_raw_data/name=aaa"가 될 것입니다. 해당 파티션으로 데이터를 옮긴 후 결과는 아래와 같습니다.

Match 데이터 Hive 테이블 생성

데이터는 모두 준비되었으니 이제 테이블을 생성하겠습니다. Hive 테이블 생성 시 Json 파일을 기반으로 한다면 JsonSerDe 형식으로 지정할 수 있습니다. 하지만 문제는 따로 있습니다. Riot Match 데이터의 경우 모든 키 값의 갯수가 약 300개 이상입니다. 테이블 생성 쿼리를 사용할 때 Json 구조에 맞는 column 명시가 필수적입니다. 300개 이상의 column 값들을 모두 적는 것은 상당히 어렵고 시간 낭비라고 생각합니다.

이러한 문제를 해결한 내용이 있으니 이 글을 참고하시기 바랍니다.

[Hive] Complex Json 데이터 테이블 생성하기 (Json SerDe)

Json 데이터를 사용하다보면 Json의 스키마 자체가 상당히 복잡하고 거대한 경우가 있습니다. 이번 글에서는 complex Json 데이터를 이용해 Hive 테이블을 생성하는 방법에 대해 소개하겠습니다. Json

taaewoo.tistory.com

위의 글을 참고해 Hive 테이블 생성 쿼리를 자동으로 추출하면 아래와 같습니다. Partition과 해당 파일의 Location 값을 추가로 적었습니다. Column은 실제로 3개밖에 없지만 아주 복잡한 Json 구조입니다.

create external table riot.match_raw(
  info struct<gamecreation:bigint, gameduration:int, gameendtimestamp:bigint, gameid:bigint, ...
  metadata struct<dataversion:string, matchid:string, participants:array<string>>,
  whosematch string)
PARTITIONED BY (name STRING)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 'hdfs://namenode:8020/riot/match_raw_data';

쿼리를 실행했을 때 정상적으로 수행된 것을 확인할 수 있습니다.

msck repair 명령어로 데이터 동기화 후 테이블을 조회해보면 아래와 같습니다. Json 구조가 워낙 복잡해 파악하기 어렵지만 확대하시면 더 자세하게 볼 수 있습니다.

다음 글에서는 이 데이터를 활용하는 과정에 대해 소개하도록 하겠습니다.

[HDFS] JMX Metrics 값 불러오기

Taaewoo — Sun, 2 Apr 2023 19:29:28 +0900

Hadoop의 HDFS를 사용하다보면 현재 HDFS의 사용량을 여러가지 방법들로 확인합니다. 예를 들어 NameNode의 Web UI를 접속해 확인하거나 Ambari와 같은 배포판 관리 시스템에서도 쉽게 확인할 수 있습니다. 그런데 만약 모니터링 시스템을 직접 개발해서 사용한다면 코드 상에서 어떻게 HDFS의 정보를 가져올 수 있을까요? 이 방법에 대해 소개해드리겠습니다.

NameNode Web UI

우리가 흔히 원하는 HDFS 정보들은 NameNode Web UI에서 모두 제공을 하고있습니다. 보통 NameNode의 50070 포트로 쉽게 접속할 수 있습니다. ( http://{NameNode}:50070 )

NameNode JMX

위의 NameNode Web UI는 HDFS 정보들을 어디서 가져오는 것일까요? 구글링을 여러가지 키워드로 검색해봤지만 원하는 답을 알 수 없었습니다. 그래서 결국 NameNode Web 소스 코드를 확인해봤습니다.

위의 GUI에서 제가 원하는 정보인 "DFS Used"를 Hadoop Github에서 검색해 html 파일을 찾았습니다.

https://github.com/apache/hadoop

dfshealth.html

{#nn}
<table class="table table-bordered table-striped">
  <tr><th> Configured Capacity:</th><td>{Total|fmt_bytes}</td></tr>
  <tr><th> Configured Remote Capacity:</th><td>{ProvidedCapacity|fmt_bytes}</td></tr>
  <tr><th> DFS Used:</th><td>{Used|fmt_bytes} ({PercentUsed|fmt_percentage})</td></tr>
  <tr><th> Non DFS Used:</th><td>{NonDfsUsedSpace|fmt_bytes}</td></tr>
  <tr><th> DFS Remaining:</th><td>{Free|fmt_bytes} ({PercentRemaining|fmt_percentage})</td></tr>
  <tr><th> Block Pool Used:</th><td>{BlockPoolUsedSpace|fmt_bytes} ({PercentBlockPoolUsed|fmt_percentage})</td></tr>
  <tr><th> DataNodes usages% (Min/Median/Max/stdDev): </th>
	<td>{#NodeUsage.nodeUsage}{min} / {median} / {max} / {stdDev}{/NodeUsage.nodeUsage}</td></tr>
{/nn}

dfshealth.html 파일에서 해당 값을 사용하는 것을 확인했습니다. 그리고 html 파일이 있는 경로에 비슷한 이름으로 dfshealth.js 파일을 발견했습니다. 그래서 dfshealth.js 파일을 확인한 결과 HDFS 정보를 가져오는 출처를 알 수 있어습니다.

dfshealth.js

 $.get(
      '/jmx?qry=Hadoop:service=NameNode,name=NameNodeInfo',
      guard_with_startup_progress(function (resp) {
        var data = workaround(resp.beans[0]);
        ....

dfshealth.js에서 JMX 호출을 통해 NameNode의 metric 값을 가져오는 것을 확인할 수 있었습니다. 그래서 해당 주소로 제가 사용하는 NameNode에 접근해봤습니다. 결과는 원하는 정보를 문제없이 불러올 수 있었습니다.

위의 Metric에서 현재 HDFS의 전체 용량, 사용량, 사용률, node별 사용 현황 등 여러가지 값들을 받을 수 있습니다.

NameNodeInfo라는 이름의 Metric 값을 불러왔는데 다른 Metric 값은 없을까하는 궁금증이 생겼습니다. 그래서 위의 주소 값에서 jmx만 남겨두고 확인을 해봤습니다.

그 결과 HDFS의 여러 Metric 값들을 모두 확인할 수 있었습니다. 만약 웹이나 여러 프로그래밍 코드에서 해당 HDFS 정보를 이용하고 싶다면 JMX Metric 값들을 호출해서 HTTP response로 활용할 수 있을 것 같습니다.

Riot Data Pipeline 구축하기 #6 - Spark Streaming으로 Kafka Consumer 구현 및 HDFS에 데이터 저장하기

Taaewoo — Mon, 13 Feb 2023 02:02:18 +0900

지난 글에서 Spring을 통해 Match 정보를 Kafka에 전송하는 과정까지 진행했습니다. 이번 글에서는 Kafka에 쌓인 데이터 확인과 Spark Streaming으로 Kafka Consumer를 구현하는 과정을 진행하겠습니다.

Kafka Topic 확인하기

Kafka Manager를 이용하면 Kafka 클러스터와 Topic 모니터링을 효율적으로 할 수 있습니다. Kafka 서비스를 위한 docker compose의 Kafka Manager 웹 GUI를 보면 아래와 같습니다. ( Kafka Cluster 등록 과정 필요 )

Topic 정보 또한 확인이 가능합니다. GUI가 없다면 직접 터미널에서 명령어를 통해 확인해야만 합니다. 하지만 Kafka Manager를 통해 쉽게 정보들을 확인할 수 있습니다. Spring에서 "summoner-match"라는 이름의 Topic 데이터가 Kafka Broker에 저장되어 있는 모습을 볼 수 있습니다.

Spark Streaming으로 Consumer 구현

Spark Streaming을 이용하여 Kafka Topic을 가져오는 것은 지난 글들에서 진행했습니다. ( [Spark] Spark structured streaming으로 Kafka topic 받기 #3 - pyspark로 HDFS에 topic data 저장하기) 이번에도 이와 비슷하게 진행했고, Json 데이터를 다룬다는 점에서 차이가 있었습니다.

Spark를 사용하기 위한 docker-compose.yml 파일은 아래처럼 명시해줍니다. HDFS 또는 Hive와 같은 서비스가 추가적인 서비스가 필요하다면 이어서 추가해주면 됩니다.

docker-compose.yml

version: '2'

services:

spark-master:

image: bde2020/spark-master:2.4.0-hadoop2.8

ports:

- "8080:8080"

- "7077:7077"

env_file:

- ./hadoop.env

environment:

- INIT_DAEMON_STEP=setup_spark

spark-worker-1:

image: bde2020/spark-worker:2.4.0-hadoop2.8

depends_on:

- spark-master

ports:

- "8081:8081"

env_file:

- ./hadoop.env

environment:

- "SPARK_MASTER=spark://spark-master:7077"

spark-notebook:

image: bde2020/spark-notebook:2.1.0-hadoop2.8-hive

container_name: spark-notebook

env_file:

- ./hadoop.env

ports:

- 9001:9001

namenode:

image: bde2020/hadoop-namenode:1.1.0-hadoop2.8-java8

container_name: namenode

volumes:

- ./data/namenode:/hadoop/dfs/name

environment:

- CLUSTER_NAME=test

env_file:

- ./hadoop.env

ports:

- 50070:50070

datanode:

image: bde2020/hadoop-datanode:1.1.0-hadoop2.8-java8

depends_on:

- namenode

volumes:

- ./data/datanode:/hadoop/dfs/data

env_file:

- ./hadoop.env

ports:

- 50075:50075

hive-server:

image: bde2020/hive:2.3.2-postgresql-metastore

volumes:

- ./hive_dir:/root

env_file:

- ./hadoop.env

environment:

HIVE_CORE_CONF_javax_jdo_option_ConnectionURL: "jdbc:postgresql://hive-metastore/metastore"

SERVICE_PRECONDITION: "hive-metastore:9083"

ports:

- "10000:10000"

- "8000:8000"

hive-metastore:

image: bde2020/hive:2.3.2-postgresql-metastore

env_file:

- ./hadoop.env

command: /opt/hive/bin/hive --service metastore

environment:

SERVICE_PRECONDITION: "namenode:50070 datanode:50075 hive-metastore-postgresql:5432"

ports:

- "9083:9083"

hive-metastore-postgresql:

image: bde2020/hive-metastore-postgresql:2.3.0

Spark에서 Match 데이터를 Kafka로부터 가져와 전처리 후 필요한 정보만 선별하여 HDFS에 저장하고 싶었습니다. 하지만 데이터를 사용하기 위한 방법으로, 원본 데이터를 데이터 플랫폼에 저장 후 파싱 후 새로운 테이블로 저장하는 데이터 마트 구축 방식을 이용하고 싶었습니다. 그래서 Kafka Topic을 json 데이터 형태로 HDFS에 저장하는 것을 목표로 정했습니다.

Spark Streaming으로 Consumer를 구현한 코드와 spark-submit 실행 코드는 아래와 같습니다.

from pyspark.sql import SparkSession
from pyspark.sql.functions import from_json, col

import json

spark = SparkSession.builder \
    .master("local") \
    .appName("Consume Riot Data") \
    .getOrCreate()

spark.sparkContext.setLogLevel('ERROR')

json_schema = spark.read.json("/riot/sample_one_data").schema


# Read stream
log = spark.readStream.format("kafka") \
.option("kafka.bootstrap.servers", "host.docker.internal:19096,host.docker.internal:29096,host.docker.internal:39096") \
.option("subscribe", "summoner-match") \
.option("startingOffsets", "earliest") \
.load()

print("**ReadStream Kafka topic schema")
log.printSchema()


parsed_df = log.select(from_json(col("value").cast("string"), json_schema) \
    .alias("parsed_value")).select(col("parsed_value.*"))


query = parsed_df \
.writeStream \
.format("json") \
.option("checkpointLocation", "/checkpoints/match_raw_data") \
.option("path", "/riot/match_raw_data") \
.option("maxRecordsPerFile", 1) \
.start()

query2 = parsed_df \
    .writeStream \
    .format("console") \
    .start()

query.awaitTermination()
query2.awaitTermination()

$ sh /spark/bin/spark-submit --packages org.apache.spark:spark-sql-kafka-0-10_2.11:2.4.0 consume_match_data_store.py

이때 spark.readStream에서 Kafka 주소에 "host.docker.internal:19096 ... 29096 ... 39096"을 넣어준 이유는 Kafka 클러스터와 Spark 서비스가 실행되는 클러스터는 서로 다른 docker compose이므로 서로의 hostname을 인식할 수 없기 때문입니다.

Kafka와 Spark의 docker-compose와 서로 통신하는 구조는 아래와 같습니다. Kafka를 docker로 사용할 때 host machine과 통신하는 구체적인 방법은 이전 글을 참고해주시기 바랍니다.

[Kafka] Docker로 Kafka 구성 시 Host machine과 통신하기 위한 listener 설정 방법

Match 데이터 HDFS에 저장된 결과

위의 Spark Streaming을 통한 Consumer 작업이 끝났다면, HDFS 명령어를 통해 데이터가 제대로 저장되었는지 확인합니다.

$ hdfs dfs -ls /riot/match_raw_data

이렇게 저장된 데이터를 Hive 테이블에 적재하는 과정은 다음 글에서 소개하도록 하겠습니다.

[Hive] Compile 상세 과정 #2 - Optimization 종류와 소스 코드 분석

Taaewoo — Tue, 27 Dec 2022 17:39:31 +0900

이전 글에 이어서 Hive의 Compile 상세 과정 중 Optimization의 여러 종류와 Compile 과정의 소스 코드를 분석하도록 하겠습니다.

Hive Optimization 종류

Hive는 쿼리를 최종적인 Task Tree로 만들기까지의 Compile 과정에서 여러 종류의 Optimization을 수행합니다. 3가지 종류의 Optimization에 대해서 소개하도록 하겠습니다.

CBO (Cost-Based Optimization)

Semantic Analyzer가 AST를 OP Tree로 만드는 과정에서의 Optimization.

- 참고 링크 : https://cwiki.apache.org/confluence/display/Hive/Cost-based+optimization+in+Hive

Cost-based optimization in Hive - Apache Hive - Apache Software Foundation

Abstract Apache Hadoop is a framework for the distributed processing of large data sets using clusters of computers typically composed of commodity hardware. Over last few years Apache Hadoop has become the de facto platform for distributed data processing

cwiki.apache.org

Apache Calcite를 이용하여 쿼리 구문을 Cost-Based Optimization하고 OP Tree를 생성합니다. 이때 Optimization은 뒤에서 나올 Logical Plan, Task Plan을 Optimization 하는 것과는 별개인 점을 참고 바랍니다.

Cost-Based Optimization 특징

- Join의 순서를 어떻게 정할지?

- 주어진 Join에 대해 어떤 알고리즘을 사용할지?

- Operator fail에 대하여 intermediate 결과를 계속 유지할지 또는 다시 계산할지?

- 병렬 작업의 정도

- Semi Join

Apache Calcite?
- SQL parsing, 쿼리 planning 등의 기능을 가지고 있는 오픈 소스 framework.
- 적용하려는 SQL의 데이터나 metadata를 자체적으로 따로 저장하지 않음.
- 그래서 외부 Metadata 또는 데이터를 plugin 방식으로 사용함.
( Hive에서 사용 시, Metastore가 이용됨. )
https://calcite.apache.org/

Logical Optimizaion

Logical Plan으로써 만들어진 OP Tree를 Optimization 수행 ( 실제 파일을 읽는 단계 X )

Logical Optimization 예시

- Predicate Pushdown : Table 전체 row를 scan 후 filter 하는 것이 아니라 filter 후 scan.

- Projection Pruning : Select 된 column에 대해서만 pruning.

- (Select - Select) 또는 (Filter-Filter) 구조를 하나의 Operator로 병합.

....

Physical Optimization

Physical Plan으로써 만들어진 Task Tree를 Optimization 수행 ( 실제 파일을 읽는 단계 )

Physical Optimization 예시

- Partition Pruning.

- Limit 절 사용 시, 일부 파일만 scan.

- Simple fetch 쿼리에 대해서는, MR 작업 없이 수행 ( hive.fetch.task.conversion )

....

Compile 과정 소스 코드 분석

Hive가 Compile을 하면서 쿼리가 변환되는 과정에 대해서 소스 코드와 함께 상세하게 알아보겠습니다.

( 아래 소스 코드들은 모두 Hive 2.3.2 버전입니다. )

0. Hive 쿼리

select * from test.tbl_1
where par=par_2
limit 7;

1. Hive 쿼리 -> AST

Driver.java

// compileInternal(String command, boolean deferClose) - Line:1317

ret = compile(command, true, deferClose);

...

// compile(String command, boolean resetTaskIds, boolean deferClose) - Line:468

ASTNode tree = ParseUtils.parse(command, ctx);

이전 글에서 언급한 것처럼 아키텍쳐 상으로는 Compiler라는 모듈이 존재하는 것처럼 보였지만, Line 1317 과 같이 실제 소스 코드에서는 Driver에서 compile() 메소드를 호출하는 것에 불과했습니다.

그리고 compile() 메소드에서 ParseUtils를 이용해 Hive 쿼리를 AST로 변환하는 것을 확인할 수 있고 결과물인 tree 변수는 아래처럼 쿼리가 각 토큰별로 트리 형태를 이루고 있습니다.

2. AST -> QB

SemanticAnalyzerFactory.java

// get(QueryState queryState, ASTNode tree) - Line:317

// hive.cbo.enabled 옵션 값에 따른 SemanticAnalyzer 객체 생성

// True : CalcitePlanner

// False : SemanticAnalyzer

SemanticAnalyzer semAnalyzer = HiveConf

.getBoolVar(queryState.getConf(), HiveConf.ConfVars.HIVE_CBO_ENABLED) ?

new CalcitePlanner(queryState) : new SemanticAnalyzer(queryState);

AST를 QB로 변환하기에 앞서 Driver에서 SemanticAnalyzer의 객체를 생성합니다. 그래서 SemanticAnalyzerFactory의 코드를 확인해보면 hive.cbo.enabled 옵션 값에 따라 CalcitePlanner 또는 SemanticAnalyzer로 할당하는 것을 확인할 수 있습니다. 즉, CalcitePlanner와 SemanticAnalyzer는 서로 상속 관계인 것을 확인할 수 있었습니다.

public class CalcitePlanner extends SemanticAnalyzer

이후 다시 Driver에서 SemanticAnalyzer의 메소드를 호출합니다.

Driver.java

// compile(String command, boolean resetTaskIds, boolean deferClose) - Line:506

// Semantic Analyzer 함수 사용

sem.analyze(tree, ctx);

SenticAnalyzer의 메소드를 따라서 내부로 들어가면 doPhase1() 이라는 메소드에서 AST의 각 토큰 값을 DFS 탐색으로 순회하면서 QB 객체에 정보를 저장합니다. ( CalcitePlanner에 의해 QB가 생성되는 과정은 생략하겠습니다. )

SemanticAnalyzer.java

// doPhase1(ASTNode ast, QB qb, Phase1Ctx ctx_1, PlannerContext plannerCtx) - Line:1428

// AST의 각 토큰 값 DFS 순회로 QB에 정보 저장

skipRecursion = true;

switch (ast.getToken().getType()) {

case HiveParser.TOK_SELECTDI:

qb.countSelDi();

// fall through

case HiveParser.TOK_SELECT:

qb.countSel();

qbp.setSelExprForClause(ctx_1.dest, ast);

...

if (!skipRecursion) {

// Iterate over the rest of the children

int child_count = ast.getChildCount();

for (int child_pos = 0; child_pos < child_count && phase1Result; ++child_pos) {

// Recurse

phase1Result = phase1Result && doPhase1(

(ASTNode)ast.getChild(child_pos), qb, ctx_1, plannerCtx);

}

...

작업이 다 수행되면 아래와 같이 QB에 QBParseInfo와 QBMetaData에 필요한 정보가 저장됩니다.

3. QB -> OP Tree (Optimized)

SemanticAnalyzer.java

// analyzeInternal(ASTNode ast, PlannerContext plannerCtx) - Line:11138

Operator sinkOp = genOPTree(ast, plannerCtx);

다시 SemanticAnalyzer에서 OP Tree를 생성하는 메소드를 호출합니다. 이때 CBO 옵션이 True라면 CalcitePlanner의 Override 된 genOPTree() 메소드가 호출되고, False라면 그대로 SemanticAnalyzer의 genOPTree() 메소드가 호출됩니다.

이후에는 SemanticAnalyzer에서 Optimizer 객체를 생성 후 OP Tree를 최적화합니다. 그 결과는 pCtx 변수에 저장되고 내부 변수들을 확인해보면 최적화된 OP Tree를 확인할 수 있습니다.

SemanticAnalyzer.java

// analyzeInternal(ASTNode ast, PlannerContext plannerCtx) - Line:11244

Optimizer optm = new Optimizer();

optm.setPctx(pCtx);

optm.initialize(conf);

pCtx = optm.optimize();

5. OP Tree (Optimized) -> Task Tree (Optimized)

TezCompilerFactory.java

// TaskCompiler getCompiler(HiveConf conf, ParseContext parseContext) - Line:39

// Execution Engine에 따른 Compiler 객체 생성

if (HiveConf.getVar(conf, HiveConf.ConfVars.HIVE_EXECUTION_ENGINE).equals("tez")) {

return new TezCompiler();

} else if (HiveConf.getVar(conf, HiveConf.ConfVars.HIVE_EXECUTION_ENGINE).equals("spark")) {

return new SparkCompiler();

} else {

return new MapReduceCompiler();

}

TaskCompiler는 Hive의 Execution Engine 종류에 따라 객체가 생성됩니다.

SemanticAnalyzer.java

// analyzeInternal(ASTNode ast, PlannerContext plannerCtx) - Line:11273

compiler.compile(pCtx, rootTasks, inputs, outputs);

SemanticAnalyzer에서 TaskCompiler를 이용하여 Task Tree를 생성합니다. 이때 TaskCompiler의 compile 메소드는 Task Tree 생성 및 최적화 과정을 모두 포함합니다.

TaskCompiler.java

// compile(final ParseContext pCtx, final List<Task<? extends Serializable>> rootTasks,

// final HashSet<ReadEntity> inputs, final HashSet<WriteEntity> outputs) - Line:279

generateTaskTree(rootTasks, pCtx, mvTask, inputs, outputs);

// compile(final ParseContext pCtx, final List<Task<? extends Serializable>> rootTasks,

// final HashSet<ReadEntity> inputs, final HashSet<WriteEntity> outputs) - Line:292

optimizeTaskPlan(rootTasks, pCtx, ctx);

최적화까지 모두 수행되면 아래와 같이 rootTasks와 fetchTask에 Task들이 부여됩니다.

위의 과정으로 Compile 과정은 모두 종료가 됩니다. 마지막으로 Driver는 Execution Engine에 Task들을 전달하면서 YARN을 통해 어플리케이션이 실행됩니다.

Hive 쿼리 실행 Log 내용 이해하기

이제는 위의 내용들을 기반으로 Hive 쿼리를 실행할 때 출력되는 Log를 이해할 수 있을 것입니다. ( Debug 모드 출력 )

Debug_Console.log

// Hive 쿼리
> select * from test.tbl_1 where par="par_2" limit 7;

// Parser : Hive 쿼리 -> AST

22/12/27 08:22:44 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG parse.ParseDriver: Parsing command: select * from test.tbl_1 where par="par_2" limit 7

22/12/27 08:22:44 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG parse.ParseDriver: Parse Completed

// Semantic Analyzer ( Calcite Planner )

22/12/27 08:22:45 [3852e623-31d5-427e-908a-5b621396c939 main]: INFO parse.CalcitePlanner: Starting Semantic Analysis

22/12/27 08:22:47 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG parse.CalcitePlanner: CBO Planning details:

22/12/27 08:22:47 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG parse.CalcitePlanner: Original Plan:

HiveSortLimit(offset=[0], fetch=[7])

HiveProject(col_1=[$0], col_2=[$1], col_3=[$2], par=[$3])

HiveFilter(condition=[=($3, _UTF-16LE'par_2')])

HiveTableScan(table=[[test.tbl_1]], table:alias=[tbl_1])

22/12/27 08:22:47 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG parse.CalcitePlanner: Plan After Join Reordering:

HiveSortLimit(fetch=[7]): rowcount = 1.0, cumulative cost = {0.0 rows, 0.0 cpu, 0.0 io}, id = 121

HiveProject(col_1=[$0], col_2=[$1], col_3=[$2], par=[CAST(_UTF-16LE'par_2'):VARCHAR(2147483647) CHARACTER SET "UTF-16LE" COLLATE "ISO-8859-1$en_US$primary"]): rowcount = 1.0, cumulative cost = {0.0 rows, 0.0 cpu, 0.0 io}, id = 119

HiveFilter(condition=[=($3, _UTF-16LE'par_2')]): rowcount = 1.0, cumulative cost = {0.0 rows, 0.0 cpu, 0.0 io}, id = 117

HiveTableScan(table=[[test.tbl_1]], table:alias=[tbl_1]): rowcount = 1.0, cumulative cost = {0}, id = 67

22/12/27 08:22:47 [3852e623-31d5-427e-908a-5b621396c939 main]: INFO parse.CalcitePlanner: CBO Succeeded; optimized logical plan.

// OP Tree
22/12/27 08:22:47 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG parse.CalcitePlanner: Before logical optimization

TS[0]-FIL[1]-SEL[2]-LIM[3]-FS[4]

// OP Tree (Optimized)

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG parse.CalcitePlanner: After logical optimization

TS[0]-SEL[2]-LIM[3]-LIST_SINK[6]

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: INFO ql.Driver: Semantic Analysis Completed

// Task Tree

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: INFO exec.TableScanOperator: Initializing operator TS[0]

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: INFO exec.SelectOperator: Initializing operator SEL[2]

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: INFO exec.LimitOperator: Initializing operator LIM[3]

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: INFO exec.ListSinkOperator: Initializing operator LIST_SINK[6]

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG exec.ListSinkOperator: Initialization Done 6 LIST_SINK done is reset.

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG exec.LimitOperator: Initialization Done 3 LIM done is reset.

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG exec.SelectOperator: Initialization Done 2 SEL done is reset.

22/12/27 08:22:48 [3852e623-31d5-427e-908a-5b621396c939 main]: DEBUG exec.TableScanOperator: Initialization Done 0 TS done is reset.

// Result

1 banana 5 par_2

2 apple 34 par_2

3 melon 156 par_2

4 lemon 23 par_2

5 tomato 11 par_2

6 banana 41 par_2

7 apple 52 par_2

Time taken: 3.81 seconds, Fetched: 7 row(s)

[Hive] Compile 상세 과정 #1 - 쿼리 변화 과정과 형태

Taaewoo — Sun, 25 Dec 2022 00:59:59 +0900

Hive를 이용하면서 Client로부터 제출된 쿼리가 어떻게 MR Job으로까지 변환이 될까라는 궁금증이 항상 있었습니다. 그래서 내부적인 Compile 과정에 대해서 공부를 하게 되었고, 소스 코드를 직접 분석해 봤습니다. 이전에 작성한 [Hive] Hive 아키텍처와 HiveServer2 & Hive Metastore 글을 먼저 읽으면 본 게시글을 이해하는데 도움이 될 겁니다.

Hive Architecture Review

- 주요 프로세스로 HiveServer2, Metastore 존재

- Driver가 중심에서 컴파일 과정, Task 전달 등 수행.

- Hive 쿼리의 변화 과정을 알기 위해선 위 그림의 Compiler 과정을 알아야함.

Hive 쿼리 처리 과정

- Hive 쿼리가 최종적으로 Map Reduce Job이 된다는 것은 잘 알고 있음.

- 하지만 대부분의 에러 발생은 중간 과정에서 발생.

- 위의 과정을 모른다면 에러의 원인을 파악하기 힘듦.

Architecture 그림에서 Compiler와 Driver를 모듈로써 따로 분리를 시키면 위와 같습니다. 하지만 제가 실제로 알아본 Hive 쿼리의 Compile 과정은 조금 달랐습니다. 아래의 그림을 통해 설명하겠습니다.

Hive Architecture에서 Compiler 모듈이 존재했던 것과 달리 실제 과정에서는 쿼리의 변화 과정에 필요한 각 모듈들이 모두 Driver에서 호출되어 사용되었습니다. 위 그림에서 확인할 수 있는 Hive 쿼리의 변화 과정은 다음과 같습니다.

Hive 쿼리 - AST - QB - OP Tree - Task Tree

Hive 쿼리의 변환 형태

Hive가 변환되면서 거치게 되는 각각의 형태에 대해서 알아보겠습니다.

AST

Abstract Syntax Tree, 일반적인 프로그래밍 Compile 과정에서 쓰이는 개념으로 추상화된 트리를 뜻합니다. 코드 또는 쿼리의 각 구문을 트리 형태로 분리시킨 형태입니다.

QB

Query Block, 쿼리 구조에 대한 정보를 담습니다. 보통 Sub 쿼리가 존재하는 쿼리에서 여러 구조의 QB 정보가 생깁니다.

Hive에서 사용하는 QB의 경우 두 가지 종류의 데이터가 담깁니다.

1) MetaData

-> 테이블에 대한 Metadata

2) ParseInfo

-> QB에 대한 parsing 정보

OP Tree

Operator Tree, Logical Plan으로써 Operator가 Tree 구조로 생성됨.

Operator 예시
- TS : Table Scan Operator
- GBY : Group By Operator
- RS : Reduce Sink Operator
- SEL : Select Operator
- FS : File Sink Operator
- FIL : Filter Operator

Logical Plan은 Hive를 debug 모드로 실행했을 때 Log에서 확인할 수 있습니다.

Task Tree

Task Tree, Logical Plan이 최종적으로 Execution engine에서 수행될 Physical Plan으로 변환된 상태.

Task 예시
- Fetch Task : [Stage-0 : FETCH]
- Root Task : [Stage-1 : MAPRED]

explain 문을 사용하여 쿼리의 plan을 확인할 때 Task Tree 구조를 볼 수 있습니다.

[Hive] Complex Json 데이터 테이블 생성하기 (Json SerDe)

Taaewoo — Thu, 15 Dec 2022 01:46:22 +0900

Json 데이터를 사용하다보면 Json의 스키마 자체가 상당히 복잡하고 거대한 경우가 있습니다. 이번 글에서는 complex Json 데이터를 이용해 Hive 테이블을 생성하는 방법에 대해 소개하겠습니다.

Json 데이터로 Hive 테이블 만들기

Json 데이터로 Hive 테이블을 만드는 방법은 여러가지가 있겠지만 이번 글에서는 Json SerDe를 이용한 방법을 소개할 예정입니다. 우선 Json SerDe를 위한 jar 파일부터 아래 링크에서 다운받도록 하겠습니다.

https://jar-download.com/maven-repository-class-search.php?search_box=org.openx.data.jsonserde.JsonSerDe

Download dependencies for java class org.openx.data.jsonserde.JsonSerDe

io.starburst.openx.data json-serde 1.3.9-e.10 compile group: 'io.starburst.openx.data', name: 'json-serde', version: '1.3.9-e.10' //Thanks for using https://jar-download.com libraryDependencies += "io.starburst.openx.data" % "json-serde" % "1.3.9-e.10" //T

jar-download.com

위의 링크에서 1.3.7.3 버전을 다운 받고 zip 파일을 풀어주면 "json-1.3.7.3.jar", "json-serde-cdh5-shim-1.3.7.3.jar", "json-serde-1.3.7.3.jar" 파일들이 나오게 됩니다. 이 파일들을 Hive의 lib 디렉토리에 넣어줍니다.

저의 경우 Docker를 이용해서 Hive를 사용했고 "$HIVE_HOME/lib" 경로에 넣어줬습니다. ( $HIVE_HOME : /opt/hive ) HIVE_HOME은 사용하는 플랫폼마다 다를 수 있으니 참고바랍니다.

간단한 예제를 보여드리겠습니다. 아래처럼 Json 파일 생성 후 HDFS 경로에 넣어줍니다. ( 게시글에서는 이렇게 줄바꿈을 넣었지만, 개행문자는 뒤에서 Hive 테이블을 select 하는 과정에서 에러가 납니다. 꼭 줄바꿈을 모두 없애고 저장해주세요. )

simple_schema.json

{
"key1" : {"sub_key1" : "sub_value1", "sub_key2" : "sub_value2"},
"key2" : 1357,
"key3" : ["list_value1", "list_value2", "list_value3"]
}

{"key1" : {"sub_key1" : "sub_value1", "sub_key2" : "sub_value2"},"key2" : 1357,"key3" : ["list_value1", "list_value2", "list_value3"]}

# HDFS에 테이블 폴더 만들기
$ hdfs dfs -mkdir /simple_schema_table_dir

# json 데이터 HDFS 경로에 넣기
$ hdfs dfs -put simple_schema.json /simple_schema_table_dir/

# 확인
$ hdfs dfs -ls /simple_schema_table_dir/
Found 1 items
-rw-r--r--   3 root supergroup  /simple_schema_table_dir/simple_schema.json

그럼 이제 이 테스트 데이터로 Hive 테이블을 만들어 보고 select 쿼리를 실행해보겠습니다.

# 테이블 생성
hive> create external table simple_schema_table(
    >  key1 struct<sub_key1:string, sub_key2:string>,
    >  key2 int,
    >  key3 array<string>
    > )
    > ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
    > LOCATION 'hdfs://namenode:8020/simple_schema_table_dir';
OK
Time taken: 1.164 seconds

# Metadata 업데이트
hive> msck repair table simple_schema_table;
OK
Time taken: 0.109 seconds

# select * 쿼리 실행  
hive> select * from simple_schema_table;
OK
{"sub_key1":"sub_value1","sub_key2":"sub_value2"}       1357    ["list_value1","list_value2","list_value3"]
Time taken: 2.216 seconds, Fetched: 1 row(s)

# Struct, Array select 쿼리 실행
hive> select key1.sub_key2, key3[1] from simple_schema_table;
OK
sub_value2      list_value2

Complex Json 데이터 create table 쿼리 자동 생성

하지만 아주 복잡하고 key 값만 총 100개 이상인 Json 데이터의 경우 어떻게 해야할까요? 위의 방법대로 하면 100 이상의 key 값들을 모두 명시하고 타입을 정의해줘야 합니다. 할수는 있지만 상당히 귀찮고, 시간이 많이 걸리기 때문에 할 엄두가 나지 않을 것입니다.

이러한 문제를 해결하기 위해 Json 스키마를 파악한 뒤 create table 쿼리까지 자동 생성해주는 오픈 소스가 있습니다. 아래 Github 링크에서 git clone을 통해 다운받아 주세요.

https://github.com/quux00/hive-json-schema

GitHub - quux00/hive-json-schema: Tool to generate a Hive schema from a JSON example doc

Tool to generate a Hive schema from a JSON example doc - GitHub - quux00/hive-json-schema: Tool to generate a Hive schema from a JSON example doc

github.com

사용법은 어렵지 않습니다. 해당 Github에 나와있는 것처럼 java 명령어를 이용해 바로 실행시켜줍니다.

$ java -cp target/json-hive-schema-1.0.jar net.thornydev.JsonHiveSchema simple_schema.json

위의 결과처럼 create table 쿼리문을 자동 생성하여 출력해줍니다. 위의 예시는 간단한 Json 스키마를 사용했지만, 제가 작업했던 게임 데이터를 저장한 Json 파일의 경우 상당히 complex 스키마임에도 불구하고 아래처럼 상당히 긴 쿼리를 만들어줍니다.

테이블 생성 쿼리문이 나왔다면 복사해서 Hive 쿼리로 실행해줍니다. Hive 쿼리가 정상적으로 실행되면, External 테이블의 경우 msck repair table 명령어로 Metadata 업데이트를 시켜주고 정상적으로 생성이 되었는지 위의 테스트 예시처럼 확인해줍니다.

[Hive] IntelliJ로 Runtime Debugging하기

Taaewoo — Sat, 12 Nov 2022 15:47:51 +0900

이번 글에서는 Hive를 Runtime 중에 소스 코드 레벨에서 Debugging하는 방법에 대해 소개하겠습니다.

Hive를 사용할 때 발생하는 에러는 보통 구글링을 해서 해결하곤 합니다. 하지만 구글링으로도 방법을 찾을 수 없을 때 근본적인 원인 파악을 위해 소스 코드 레벨에서 분석해야만 할 때가 있습니다. 아래의 방법으로 IntelliJ로 소스 코드 레벨에서 Debugging을 한다면 좀 더 쉽고 정확한 문제 해결을 할 수 있습니다.

사전 준비

Hive Debugging을 위해서 아래의 두가지를 준비합니다.

IntelliJ 설치
https://www.jetbrains.com/ko-kr/idea/download/#section=mac
Hive 소스 코드 다운로드 ( 사용하는 버전에 맞게 )
https://archive.apache.org/dist/hive/

다음으로는 IntelliJ에서 Hive 소스 코드로 프로젝트를 생성합니다. 아래와 같이 "Project from Existing Soureces"를 선택합니다.

나타나는 창에서 "Create project from existing sources" 선택하고 이어서 계속 Next를 눌러줍니다.

프로젝트가 생성되었다면 "Run" 메뉴에서 "Edit Configurations"를 눌러줍니다.

Configuration 창에서 아래와 같이 Host & Port와 "JDK 5 - 8"로 설정해줍니다. 이때 Host는 Hive를 실행하는 서버로 지정하고, Port의 경우 해당 서버가 이미 8000번을 사용한다면 다른 번호를 이용해줍니다.

Hive Runtime Debugging

사전 준비는 끝났다면 Hive를 실행할 서버에 접속해서 아래 명령어로 Hive CLI를 실행시켜줍니다.

$ HADOOP_CLIENT_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000" hive

저는 docker로 Hive 컨테이너를 실행시켰고 8000 port를 port forwarding 했습니다. 명령어를 실행하면 아래와 같이 Hive CLI가 계속 멈춰있는 상태인 것을 확인할 수 있습니다. ( docker 설정을 보려면 이 링크의 docker-compose.yml을 참고하세요. )

다음으로 IntelliJ에서 우측 상단의 Debugging 버튼(벌레 모양)을 눌러줍니다.

정상적으로 Debugging 모드에 들어갔다면 Connected 문구가 출력고 Hive CLI는 멈춰있던 상태에서 다시 실행됩니다.

이제 IntelliJ에서 Hive 소스 코드 중 원하는 곳에 Break point를 지정하고 Hive CLI에서 특정 쿼리를 실행합니다.

그러면 IntelliJ에서 우리가 원하던 Break point에서 멈추게 됩니다. Debugging 기능들을 이용하여 step을 옮길 수 있고 각 지점에서 사용되는 변수의 값들을 확인할 수 있습니다.

이러한 방식으로 Hive 수행 과정을 소스 코드 레벨에서 Debugging한다면 동작 과정을 상세하게 이해하거나 해결하기 어려운 이슈에 대해서 원인 파악 및 문제 해결하는데 도움이 될 것이라 생각합니다.

[Hive] limit 사용 시 leastNumRows 에러 발생 이슈

Taaewoo — Fri, 4 Nov 2022 23:24:15 +0900

이번 글에서는 Hive 쿼리를 limit 절과 함께 사용할 때 발생하는 leastNumRows 에러 발생 이슈와 해결 과정에 대해 공유하겠습니다.

문제 발견

Hive 테이블을 select 할 때 limit 절을 사용하면 에러가 발생하는 문제를 발견하게 되었습니다. Hive CLI에서 실행시킨 쿼리 예제와 발생하는 에러는 아래와 같았습니다.

select AA_COL from AA_TABLE
where partition_p=p1
limit 35;

java.io.IOException: org.apache.hadoop.hive.ql.metadata.HiveException: leastNumRows check failed

문제 상황

다양한 케이스들에 따라 위의 에러 발생 여부가 달랐습니다. 일단 사전에 설정되었던 Hive 옵션 중 하나는 "hive.fetch.task.conversion" 으로 Fetch Task 작동 없이 모두 MR 작업이 수행되도록 "none"으로 설정했다는 점, Hive 엔진은 Tez를 사용했다는 점 참고바랍니다.

쿼리 성공 케이스

hive.fetch.task.conversion 옵션을 more로 설정해 MR이 아닌 Fetch Task 작업이 수행되었을 때.
Tez 작업이 아닌 Spark를 이용한 Hive 쿼리를 실행시켰을 때.
limit 수를 2 이하로 했을 때.
limit 없이 테이블 전체를 select 할 때.

에러 발생 케이스

Tez 엔진으로 MR 작업이 수행될 때.
limit 수를 3 이상으로 했을 때

에러가 발생할 때 나타났던 주요 특징으로는, Hive 쿼리가 실행될 때가 아니라 쿼리 결과를 가져와 출력하는 Fetch 과정에서 에러가 발생했다는 점입니다. 여기서 추측할 수 있는 것은 Hive 쿼리 수행 자체는 크게 문제가 없다는 점이었습니다. 아래의 Hive CLI 출력과 Stack trace를 보면 Fetch 과정에서 문제가 발생한 것을 확인할 수 있습니다.

Hive CLI Console

----------------------------------------------------------------------------------------------------------------------------------
VERTICES MODE STATUS TOTAL COMPLETED RUNNING PENDING FAILED KILLED
----------------------------------------------------------------------------------------------------------------------------------
Map 1 .... SUCCESS 1 1 0 0 0 0
----------------------------------------------------------------------------------------------------------------------------------
VERTICES : 01/01. [=====================================>>] 100%
----------------------------------------------------------------------------------------------------------------------------------
Status : DAG finished successfully in 5.67 seconds

....

OK
java.io.IOException:org.apache.hadoop.hive.ql.metadata.HiveException: leastNumRows check failed

원인 분석

안타깝게도 "leastNumRows check failed" 관련 에러는 아무리 google에 검색해도 비슷한 게시물이 하나도 나오지 않았습니다.... 그래서 결국에는 Stack trace를 참고해 Hive 소스 코드 분석으로 에러의 원인을 파악해야만 했습니다. 에러에 대한 Stack trace와 소스 코드 분석 내용은 아래와 같습니다.

hiveserver2.log

java.io.IOException:org.apache.hadoop.hive.ql.metadata.HiveException: leastNumRows check failed
at org.apache.hadoop.hive.ql.exec.FetchTask.fetch(FetchTask.java)
at org.apache.hadoop.hive.ql.Driver.getResult(Driver.java)
at org.apache.hadoop.hive.ql.reexec.ReExecDriver.getResult(ReExecDriver.java)
at org.apache.hadoop.hive.cli.CliDriver.processLocalCmd(CliDriver.java)
....

Hive 3.1.0 Source code from Archive

FetchTask.java

public boolean fetch(List res) throws IOException {
    sink.reset(res);
    int rowsRet = work.getLeastNumRows();
    if (rowsRet <= 0) {
      rowsRet = work.getLimit() >= 0 ? Math.min(work.getLimit() - totalRows, maxRows) : maxRows;
    }
    try {
      if (rowsRet <= 0 || work.getLimit() == totalRows) {
        fetch.clearFetchContext();
        return false;
      }
      boolean fetched = false;
      while (sink.getNumRows() < rowsRet) {
        if (!fetch.pushRow()) {
          if (work.getLeastNumRows() > 0) {
            throw new HiveException("leastNumRows check failed");
          }

          // Closing the operator can sometimes yield more rows (HIVE-11892)
          fetch.closeOperator();

          return fetched;
        }
        fetched = true;
      }
  ....

fetch 과정에서 row 수 관련 조건으로 인해 "leastNumRows" 에러 발생

Stack trace에서 에러가 발생한 FetchTask.java 아래의 코드 내용은 Hive CLI에서 결과 값을 불러오는 내용이라 원인 분석에는 도움이 되지 않았습니다.

그래서 원인을 찾기 위해 Hive 쿼리의 limit 절과 관련된 옵션들을 찾아봤고, "hive.limit.~~" 으로 시작되는 옵션들을 아래와 같이 존재했습니다.

Hive Limit Option
hive.limit.optimize.enable	Whether to enable to optimization to trying a smaller subset of data for simple LIMIT first. - Default Value: false
hive.limit.row.max.size	When trying a smaller subset of data for simple LIMIT, how much size we need to guarantee each row to have at least. - Default Value: 100000
hive.limit.optimize.limit.file	When trying a smaller subset of data for simple LIMIT, maximum number of files we can sample. - Default Value: 10
hive.limit.optimize.fetch.max	Maximum number of rows allowed for a smaller subset of data for simple LIMIT, if it is a fetch query. Insert queries are not restricted by this limit. - Default Value: 50000

위의 옵션 중 "hive.limit.row.max.size"의 의미를 정확하게는 알 수 없었습니다. 하지만 "hive.limit.optimize.enable" 옵션에 대해 "false"로 설정 후 테스트를 진행했을 때 정상적으로 수행되었습니다.

쿼리 성공 케이스

....
(+) "hive.limit.optimize.enable" 옵션을 false로 설정 후 실행시켰을 때

이를 통해 Hive의 limit 절 쿼리를 수행할 때 optimization을 하는 과정에서 발생하는 문제라는 것을 알게 되었습니다.

Limit optimization의 동작 원리

위의 사실들을 알아냈고 문제 해결을 하기 위해 Hive가 limit 절 쿼리를 어떻게 optimization 하는지 원리를 알아야 했습니다. 그래서 관련 내용들을 Hive 소스 코드에서 확인하려고 했습니다.

Optimizer.java

...

if (HiveConf.getBoolVar(hiveConf, HiveConf.ConfVars.HIVELIMITOPTENABLE)) {
    transformations.add(new GlobalLimitOptimizer());
}

...

우선 "hive.limit.optimize.enable" 옵션을 true로 설정했을 때 Hive에서는 GlobalLimitOptimizer 객체를 추가합니다. 그래서 다시 GlobalLimitOptimizer에 대해 조사하던 중 아래 문구를 발견할 수 있었습니다.

위의 내용을 통해, Hive의 limit optimization은 테이블의 실제 파일을 몇 개만 읽어 sampling 하고 그 안에서 limit 수만큼만 결과로 보여준다는 것을 알게 되었습니다.

테스트 진행

1. 테이블에 (8개 Row가 있는 parquet) + (2개 Row가 있는 parquet) 저장

총 10개 Row
limit 1 ~ 8까지 에러 없이 정상 수행
limit 9 이상부터 동일한 에러 발생

2. 테이블에 (8개 Row가 있는 parquet) + (2개 Row가 있는 parquet x 5) 저장

총 18개 Row
limit 1 ~ 10까지 에러 없이 정상 수행
limit 11 이상부터 동일한 에러 발생

이 테스트들을 미루어 보았을 때, 특정 파일 몇 개를 sampling해서 limit 수를 만족하지 못할 때 에러가 발생한다는 것을 대충 알 수 있었지만, 어떤 파일을? 몇개를? sampling 하는지에 대한 상세한 과정을 알 수 없었습니다.

Hive CLI Debug Log 분석 및 문제 해결

Hive의 데이터 sampling 과정에 대해 조금이라도 힌트를 얻기 위해 Hive CLI를 Debug 모드로 실행해 Log를 확인했습니다. 명령어는 아래와 같습니다.

$ hive --hiveconf hive.root.logger=DEBUG,console

Hive의 쿼리 처리 과정을 상세하게 공부를 하고, Log를 한 줄씩 분석하기 시작했습니다. 확실하게 이론적인 부분에 먼저 접근한 뒤 실제 Log를 읽으니 더 많은 부분에 대해 이해할 수 있었고, 그 결과 sampling 관련 Log를 발견할 수 있었습니다.

Hive CLI Debug Log

INFO optimizer.GenMapRedUtils: Try to reduce input size for 'limit' sizeNeeded: 2000000 file limit : 10
INFO optimizer.SamplePruner: Path pattern = hdfs://nameservice1/data_path/AA_TABLE/partition_p=p1/*
INFO optimizer.SamplePruner: Got file: hdfs://nameservice1/data_path/AA_TABLE/partition_p=p1/file1.parquet
DEBUG optimizer.GenMapRedUtils: Adding hdfs://nameservice1/data_path/AA_TABLE/partition_p=p1/file1.parquet of table AA_TABLE
DEBUG optimizer.GenMapRedUtils: Information added for path hdfs://nameservice1/data_path/AA_TABLE/partition_p=p1/file1.parquet

Sampling 관련 작업들은 Hive의 optimization 과정에서 이루어진다는 것을 알 수 있었습니다.

( Hive optimization 관련 내용은 [Hive] Compile 상세 과정 #2 - Optimization 종류와 소스 코드 분석 글을 참고해주세요. )

그리고 가장 핵심적인 log로써 테이블 경로에 있는 파일들을 직접 접근하는 부분을 발견할 수 있었습니다. 위의 log 내용을 통해 첫 번째 테스트 과정에서 8개 Row를 가진 "file1.parquet" 파일 1개만 sampling에 사용되었다는 것을 알 수 있었습니다. 그래서 8보다 큰 숫자로 limit을 설정했을 때 에러가 발생한 것입니다. 그렇다면 왜 1개의 파일만 sampling에 사용되었는지 알기 위해 위의 log들이 기록되는 소스 코드를 분석했습니다.

GenMapRedUtils.java

INFO optimizer.GenMapRedUtils: Try to reduce input size for 'limit' sizeNeeded: 2000000 file limit : 10

if (parseCtx.getGlobalLimitCtx().isEnable()) {
      
      ...
      long sizePerRow = HiveConf.getLongVar(parseCtx.getConf(),
            HiveConf.ConfVars.HIVELIMITMAXROWSIZE);
        
      sizeNeeded = (parseCtx.getGlobalLimitCtx().getGlobalOffset()
            + parseCtx.getGlobalLimitCtx().getGlobalLimit()) * sizePerRow;
        
        
      ...
      LOG.info("Try to reduce input size for 'limit' " +
              "sizeNeeded: " + sizeNeeded +
              "  file limit : " + fileLimit);
      ...

GenMapRedUtils에서 log에서 발견된 sizeNeeded 변수의 계산 방법을 확인할 수 있었습니다. 계산 방법은 (limit 수) x (hive.limit.row.max.size) 입니다. limit 수를 Row 수라고 생각하여 최대 사이즈만큼 곱해준 값입니다. sizeNeeded 변수가 sampling에 필요한 값이라고 의심되지만, 아직 확인된 게 없으니 일단 넘어가겠습니다.

SamplePruner.java

INFO optimizer.SamplePruner: Path pattern = hdfs://nameservice1/data_path/AA_TABLE/partition_p=p1/*
INFO optimizer.SamplePruner: Got file: hdfs://nameservice1/data_path/AA_TABLE/partition_p=p1/file1.parquet

    ...
    LOG.info("Path pattern = " + pathPattern);
    FileStatus srcs[] = fs.globStatus(new Path(pathPattern));
    Arrays.sort(srcs);

    boolean hasFile = false, allFile = true;

    for (FileStatus src : srcs) {
      if (sizeLeft <= 0) {
        allFile = false;
        break;
      }
      
      ...
        LOG.info("Got file: " + src.getPath());
        hasFile = true;
        retPathList.add(src.getPath());
        sizeLeft -= src.getLen();
        if (retPathList.size() >= fileLimit && sizeLeft > 0) {
          return null;
        }
      ...

SamplePruner.java에서 그토록 원하던 sample 파일 선별 과정을 확인할 수 있었습니다. 파일 선별 과정을 요약하면 이렇습니다.

- 테이블 경로의 모든 파일을 srcs 배열에 저장

- srcs 배열을 파일명 순서로 정렬하고 반복문 실행

- 이때 sizeLeft 변수가 0 이하면 반복문 종료

- 파일을 List에 추가 후 파일 크기만큼 sizeLeft 감소

여기서 sizeLeft 변수는 GenMapRedUtils.java에서 사용된 sizeNeeded라는 것을 코드를 통해 확인할 수 있습니다. 즉 (limit 수) x (hive.limit.row.max.size)로 계산된 값이 sampling 할 총 파일 크기입니다.

결국 문제의 원인은 sizeNeeded 변수 값에 있었습니다. hive.limit.row.max.size 옵션의 default 값은 100,000으로 100KB입니다. 하지만 테이블의 데이터 파일을 확인한 결과 Row당 파일크기는 300KB까지 나가기도 했습니다. 결국 limit 20을 만족할만한 파일 sampling을 할 수 없었습니다.

그래서 hive.limit.row.max.size 옵션을 넉넉하게 3MB인 3,000,000으로 설정했습니다. 쿼리 실행 시 파일 sampling이 충분히 되어 limit 절을 이용하더라도 이전과 같은 에러가 발생하지 않았습니다.

결론

- limit 절을 포함한 쿼리 수행 시 에러 발생

- limit optimization 수행 시 에러 발생

- limit optimization의 파일 sampling 과정에서 용량 조건으로 인해 부족한 sampling 확인

- hive.limit.row.max.size 옵션 값 설정으로 문제 해결

References

https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties

[Algorithm][KMP] 28. Find the Index of the First Occurrence in a String

Taaewoo — Sun, 23 Oct 2022 23:35:57 +0900

KMP 알고리즘이란?

문자열을 한개씩 비교하는 것이 아니라 지금까지 비교한 문자열 중 접두사, 접미사가 같을 경우 중간 과정을 생략하고 비교하는 알고리즘

시간 복잡도

$ O(n + m) $

문제 링크

https://leetcode.com/problems/find-the-index-of-the-first-occurrence-in-a-string/

이번 문제는 주어진 문자열에서 sub 문자열이 몇번 째 index에 존재하는지를 답안으로 내야합니다. 단순하게 생각하면 단순 문자열 비교로 보일 수 있지만, 주어진 조건을 보면 문자열의 길이가 10000입니다. 그래서 단순 비교를 한다면 당연히 시간초과가 발생합니다.

단순 전체 비교 방법

우선 단순 비교로 문제를 푸는 방법을 소개하겠습니다. 전체 문자열의 시작 문자부터 Sub 문자열의 문자를 하나씩 비교합니다. 이렇게 Sub 문자열의 전체가 일치할 때까지 진행합니다. 단순 비교의 시간 복잡도는 전체 문자열의 크기 $ N $ 만큼 for 문을 사용하고 Sub 문자열의 크기 $ M $ 만큼 for문을 사용하기 때문에 $ O(NM) $ 가 됩니다. 이 때 $ M $ 의 크기가 $ N $이 된다면 $ O(N^2) $ 까지도 증가하게 됩니다. 아래 예시에서는 총 14번의 문자 비교가 필요합니다.

KMP 알고리즘 방법

우리는 위의 경우처럼 전체 문자열 N개를 하나하나 비교하고 싶지 않습니다. 효율적으로 비교가 필요 없는 부분은 아래처럼 생략하며 진행하고 싶습니다. 하지만 아래처럼 sub 문자열을 다시 처음부터 비교시키기엔 예외 상황이 있습니다. 바로 지금까지 비교해서 일치한 문자열 중 중복되는 문자열이 존재하는 경우입니다. 이러한 예외 상황을 고려해 효율적으로 중간 과정을 생략한 알고리즘이 바로 KMP 알고리즘입니다.

KMP 알고리즘의 핵심은 지금까지 연속으로 일치한 문자열에서 접두사와 접미사가 같은 경우가 있을 때 중간 과정을 생략하고 접미사를 접두사의 위치로 점프시키는 것입니다. 접두사와 접미사를 사용하는 이유는 위에서 말한 중복 상황을 고려하기 위함입니다. 글로는 이해가 어려울 수 있습니다. 아래 그림에서 단순 비교 방법과 비교하여 원리를 알면 더 이해하기 쉬울 것입니다.

KMP 알고리즘은 문자열 비교 중 일치하지 않는다면, 이전 문자열에서 접두사와 접미사 길이를 확인하고 접미사 다음 문자로 다시 비교합니다. 그림과 같이 접미사 부분인 "ab"를 제외하고 "c"부터 일치 여부를 다시 검사합니다.

그렇다면 만약 여기서 sub 문자열의 접미사 다음 문자가 일치하지 않는 문제가 발생하면 어떻게 될까요? 그러면 접미사를 다시 "Sub 문자열2" 로 생각하고 "Sub 문자열2" 에서 서로 일치하는 접미사와 접두사를 찾고 해당 접미사 다음 문자열부터 비교하면 됩니다. 만약 없다면 Sub 문자열 처음부터 다시 비교하면 됩니다.

접두사, 접미사가 일치하는 최대 길이 계산

위의 KMP 알고리즘을 적용하기 위해 Sub 문자열의 각 문자열 위치에서 접두사, 접미사가 일치하는 최대 길이를 사전에 계산합니다. 이 때 이 값을 "Longest Proper Prefix which is Suffix"라고 하여 LPS 배열이라고 부릅니다. 하지만 LPS 배열을 계산할 때 주의할 점은 Sub 문자열 또한 결국에는 문자열의 비교 과정이기 때문에 위에서 소개한 원리가 그대로 적용이 됩니다. LPS 배열의 이전 index 값들을 이용하여 LPS 배열의 새로운 index 값을 구합니다.

Python

그래서 KMP 알고리즘을 적용한 LeetCode 28번 문제의 풀이 코드는 아래와 같습니다.

class Solution:
    def strStr(self, haystack: str, needle: str) -> int:
        lps = [0] * len(needle)
        
        j = 0
        for i in range(1,len(needle)):
            while not( j == 0 or needle[i] == needle[j] ):
                j = lps[j-1]
                
            if needle[i] == needle[j]:
                j += 1
                lps[i] = j
                
        j = 0
        for i in range(0,len(haystack)):
            while not( j == 0 or haystack[i] == needle[j] ):
                j = lps[j-1]
                
            if haystack[i] == needle[j]:
                if j == len(needle)-1:
                    return i - j
                j += 1
        return -1

[NiFi] Json 데이터의 동적 크기 Array 전처리하기 (Base64 decoding)

Taaewoo — Wed, 21 Sep 2022 00:09:08 +0900

이번 글에서는 NiFi에서 Json 파일을 전처리하는 방법 중 하나에 대해 소개하겠습니다. NiFi에서 Json 데이터를 처리하기 위한 다양한 Procssor들이 존재합니다. 하지만 Json 데이터가 단순히 key / value 값들만 존재한다면 처리가 쉽겠지만, 경우에 따라서는 Json 데이터에 Array 타입이 존재할 수 있습니다. 그리고 Array의 크기가 고정이라면 다행이지만 데이터마다 동적인 크기를 가질 때는 상당히 골치 아파집니다. 아래 내용에서 이와 같은 동적인 크기의 Array 타입을 처리하는 방법을 제시하겠습니다.

Json 데이터 예시

이번 글에서 다룰 Json 데이터의 구조와 예시를 보여드리겠습니다.

Json의 가장 최상위에 A, B라는 key 값들이 존재합니다. A는 Array 타입으로써 index 당 AA, BB, CC라는 key값들로 String 타입의 Value들을 가집니다. 그리고 A는 동적인 크기를 가지기 때문에 위의 그림에서는 index가 3까지밖에 없지만, 데이터에 따라 10개, 100개도 존재할 수 있습니다. B는 단순히 String 타입의 Value를 가집니다. 아래는 위에서 제시한 구조의 Json 데이터 예시입니다.

{
  "A" :
    [
      {
        "AA" : "Array index 1 and property 1 value",
        "BB" : "Array index 1 and property 2 value",
        "CC" : "Array index 1 and property 3 value"
      },
      {
        "AA" : "Array index 2 and property 1 value",
        "BB" : "Array index 2 and property 2 value",
        "CC" : "Array index 2 and property 3 value"
      },
      {
        "AA" : "Array index 3 and property 1 value",
        "BB" : "Array index 3 and property 2 value",
        "CC" : "Array index 3 and property 3 value"
      }
    ],
  "B" : "String value"
}

그리고 NiFi에서는 BB를 key로 가지는 value들을 모두 base64 encoding한 데이터를 사용할 예정입니다. 아래 링크를 이용하면 쉽게 base64 encoding, decoding을 할 수 있습니다.

https://www.base64decode.org/

Base64 Decode and Encode - Online

Decode from Base64 format or encode into it with various advanced options. Our site has an easy to use online tool to convert your data.

www.base64decode.org

{
  "A" :
    [
      {
        "AA" : "Array index 1 and property 1 value",
        "BB" : "QXJyYXkgaW5kZXggMSBhbmQgcHJvcGVydHkgMiB2YWx1ZQ==",
        "CC" : "Array index 1 and property 3 value"
      },
      {
        "AA" : "Array index 2 and property 1 value",
        "BB" : "QXJyYXkgaW5kZXggMiBhbmQgcHJvcGVydHkgMiB2YWx1ZQ==",
        "CC" : "Array index 2 and property 3 value"
      },
      {
        "AA" : "Array index 3 and property 1 value",
        "BB" : "QXJyYXkgaW5kZXggMyBhbmQgcHJvcGVydHkgMiB2YWx1ZQ==",
        "CC" : "Array index 3 and property 3 value"
      }
    ],
  "B" : "String value"
}

FlowFile 생성

NiFi에서는 FlowFile을 생성하는 GenerateFlowFile Procssor가 존재하기 때문에 직접 Json 데이터를 생성 후 NiFi에서 불러 올 필요가 없습니다. 아래와 같이 Processor 생성 후 "Custom Text"에 우리가 원하는 Json 데이터를 넣어줍니다.

ExecuteGroovyScript Processor 사용

동적인 크기의 Array를 가진 Json 데이터를 처리하기위해 NiFi의 다양한 Procssor를 사용하며 시도해봤습니다. 하지만 대부분의 Procssor들이 동적인 크기의 Array를 처리할 수 없었고, 몇몇 존재하는 JoltTransformJson과 같은 Procssor들은 동적으로 처리를 할 수 있지만, 값들을 base64 decoding 하는데 어려움이 있었습니다. 그래서 결국 직접 코딩을 한 Script를 사용하여 Json 데이터를 처리하는 것이 가장 적합하다고 생각했습니다. 그리고 대량의 데이터를 처리하기 위해서는 속도가 중요한데 Python도 가능했지만 이는 Groovy 언어보다 속도에서 느리다는 정보가 있었고, NiFi에서 Groovy script를 많이 사용한다는 점을 고려하여 ExecuteGroovyScript를 사용하기로 결정했습니다.

( Script를 사용하지 않고 NiFi의 Procssor만을 사용하여 처리하는 방법에 대해서는 추후에 글을 게시하겠습니다. )

ExecuteGroovyScript의 데이터 결과를 확인하기 위한 사용하지 않을 UpdateAttribute Procssor 추가 후 연결해 Success, Failure Queue를 만들어줍니다. ExecuteGroovyScript의 설정 값은 딱히 건드릴 게 없습니다. "Script Body"에 Groovy script 내용을 넣어줍니다.

import groovy.json.JsonBuilder
import groovy.json.JsonSlurper
import groovy.json.JsonOutput
import org.apache.nifi.processor.io.StreamCallback
import java.nio.charset.StandardCharsets

def flowFile = session.get()
if( flowFile == null ){
    return;
}

def data
def beforeData

try{

    flowFile = session.write(flowFile, {inputStream, outputStream ->
    
        def content = inputStream.getText("UTF-8")
 
        beforeData = new JsonSlurper().parseText(content)
        data = new JsonSlurper().parseText(content)

        data.A.each{ obj ->
            if( !obj["BB"].isEmpty() ) {
                def decodedString = new String(obj["BB"].decodeBase64())
                obj["BB"] = decodedString 
            }
        }

        outputStream.write(JsonOutput.toJson(data).getBytes(StandardCharsets.UTF_8))
    } as StreamCallback)

} catch (Exception e){
    flowFile = session.putAttribute(flowFile, "errorMessage", e.getMessage().toString())
    session.transfer(flowFile, REL_FAILURE)
    return;
}

flowFile = session.putAttribute(flowFile, "afterData", data.toString())
flowFile = session.putAttribute(flowFile, "beforeData", beforeData.toString())
session.transfer(flowFile, REL_SUCCESS)

Groovy script 내용

우선 NiFi는 실시간 데이터 처리를 위한 소프트웨어이기 때문에 기본적으로 streaming 데이터 처리로 진행됩니다. 그래서 일반적으로 하는 코딩과는 느낌이 조금 다르지만 주어진 코드 내에서 원하는 내용만 작성해주면 됩니다.

import org.apache.nifi.processor.io.StreamCallback

def flowFile = session.get()
if( flowFile == null ){
    return;
}

try{

    flowFile = session.write(flowFile, {inputStream, outputStream ->
    
        // 데이터 처리 내용 작성
        def output
        

        outputStream.write(output)
    } as StreamCallback)

} catch (Exception e){
    session.transfer(flowFile, REL_FAILURE)
    return;
}

session.transfer(flowFile, REL_SUCCESS)

위와 같이 기본적인 템플릿 작성 후에 주석으로 표시된 부분에 데이터를 처리할 내용을 작성해줍니다. FlowFile마다 데이터 처리 내용이 적용이 되고 FlowFile의 content를 사용하기 위해서는 위의 코드 기준으로 "inputStream" 변수를 사용해줍니다. 그럼 이제 Json 데이터를 처리하는 내용을 설명하겠습니다. 아래 코드는 위 코드 주석에 해당되는 내용입니다.

try{

    flowFile = session.write(flowFile, {inputStream, outputStream ->

        // 데이터 처리 내용 작성
        def content = inputStream.getText("UTF-8")
 
        beforeData = new JsonSlurper().parseText(content)
        data = new JsonSlurper().parseText(content)

        data.A.each{ obj ->
            if( !obj["BB"].isEmpty() ) {
                def decodedString = new String(obj["BB"].decodeBase64())
                obj["BB"] = decodedString 
            }
        }

        outputStream.write(JsonOutput.toJson(data).getBytes(StandardCharsets.UTF_8))
    } as StreamCallback)

}

우선 Json 데이터 내용을 inputStream으로부터 불러와 content 변수에 넣어줍니다. String 형태로 받아온 Json 데이터를 파싱하기 위해 JsonSluper의 parseText 함수를 이용해 "data" 변수에 넣어줍니다. 이때 선언한 "beforeData"는 데이터 처리 전,후를 비교하기 위해 만든 변수입니다.

"data" 변수에 Json 데이터를 파싱한 결과를 넣어줬기 때문에, "."을 이용하여 nested Json 데이터에 접근할 수 있고 Array 타입은 each를 사용하여 loop 형태로 접근하여 각 loop 단계마다 "obj" 변수에 매핑됩니다. "."과 each문을 사용하여 원하는 하위 데이터까지 접근을 했다면 key / value 자료구조처럼 사용하면 우리가 원하는 데이터를 처리할 수 있습니다.

우리가 접근해서 처리하고 싶은 항목은 "BB"이기 때문에 "data.A"에 접근 후 each로 Array 타입 loop를 실행합니다. loop 문 안에서는 "obj"에 접근하여 "obj["BB"]"를 이용하여 "BB" key의 value에 접근합니다. Groovy에서는 "decodeBase64()" 함수를 이용하여 Base64 decoding을 할 수 있습니다. Decoding된 데이터를 String 형태로 변환하여 다시 "BB" key의 value에 넣어줍니다.

catch (Exception e){
    flowFile = session.putAttribute(flowFile, "errorMessage", e.getMessage().toString())
    session.transfer(flowFile, REL_FAILURE)
    return;
}

flowFile = session.putAttribute(flowFile, "afterData", data.toString())
flowFile = session.putAttribute(flowFile, "beforeData", beforeData.toString())
session.transfer(flowFile, REL_SUCCESS)

이어서 나머지 코드도 작성해줍니다. try / catch에 걸려 exception이 발생했다면 에러 메세지를 FlowFile의 attribute에 넣어준다면 원인 파악을 좀 더 쉽게 할 수 있습니다. 그리고 Processor 의 결과는 failure로 처리해줍니다. 데이터 처리가 정상적으로 되었다면 처리 전,후를 비교하기 위해 "data"와 "beforedata" 변수를 attribute에 넣어준다면 쉽게 확인할 수 있습니다. 마찬가지로 Processor의 결과는 success로 처리해줍니다.

Data Engineering Blog

Riot Data Pipeline 구축하기 #7 - HDFS에 저장된 JSON 데이터로 Hive 테이블 생성하기

Docker Compose에 Hive 서비스 추가

Match 데이터 경로 수정

Match 데이터 Hive 테이블 생성

[HDFS] JMX Metrics 값 불러오기

NameNode Web UI

NameNode JMX

dfshealth.html

dfshealth.js

Riot Data Pipeline 구축하기 #6 - Spark Streaming으로 Kafka Consumer 구현 및 HDFS에 데이터 저장하기

Kafka Topic 확인하기

Spark Streaming으로 Consumer 구현

Match 데이터 HDFS에 저장된 결과

[Hive] Compile 상세 과정 #2 - Optimization 종류와 소스 코드 분석

Hive Optimization 종류

CBO (Cost-Based Optimization)

Logical Optimizaion

Physical Optimization

Compile 과정 소스 코드 분석

0. Hive 쿼리

1. Hive 쿼리 -> AST

2. AST -> QB

3. QB -> OP Tree (Optimized)

5. OP Tree (Optimized) -> Task Tree (Optimized)

Hive 쿼리 실행 Log 내용 이해하기

[Hive] Compile 상세 과정 #1 - 쿼리 변화 과정과 형태

Hive Architecture Review

Hive 쿼리 처리 과정

Hive 쿼리의 변환 형태

AST

QB

OP Tree

Task Tree

[Hive] Complex Json 데이터 테이블 생성하기 (Json SerDe)

Json 데이터로 Hive 테이블 만들기

Complex Json 데이터 create table 쿼리 자동 생성

[Hive] IntelliJ로 Runtime Debugging하기

사전 준비

Hive Runtime Debugging

[Hive] limit 사용 시 leastNumRows 에러 발생 이슈

문제 발견

문제 상황

쿼리 성공 케이스

에러 발생 케이스

원인 분석

FetchTask.java

쿼리 성공 케이스

Limit optimization의 동작 원리

Optimizer.java

테스트 진행

Hive CLI Debug Log 분석 및 문제 해결

GenMapRedUtils.java

SamplePruner.java

결론

References

[Algorithm][KMP] 28. Find the Index of the First Occurrence in a String

KMP 알고리즘이란?

시간 복잡도

문제 링크

단순 전체 비교 방법

KMP 알고리즘 방법

접두사, 접미사가 일치하는 최대 길이 계산

Python

[NiFi] Json 데이터의 동적 크기 Array 전처리하기 (Base64 decoding)

Json 데이터 예시

FlowFile 생성

ExecuteGroovyScript Processor 사용

Groovy script 내용

결과 확인

GenerateFlowFile 실행

ExecuteGroovyScript 실행

FlowFile 결과