원천 DB 의 컬럼이 정확히 파악되지 않은 채 수집 테이블을 손으로 만들면, 뒷단 Spark 처리에서 컬럼 불일치로 계속 깨진다. DDL 을 사람이 쓰는 대신 원천의 information_schema 를 읽어 테이블별 CREATE EXTERNAL TABLE 을 만들어 내는 PG 를 하나 두면 이 문제가 사라진다.
GenerateFlowFile (트리거)
→ ExecuteSQLRecord (원천_컬럼메타_조회)
→ ExecuteScript (Hive_DDL_생성, Groovy)
→ PutHDFS (<테이블명>.hql)
SELECT table_name, column_name, data_type, column_type,
character_maximum_length, numeric_precision, numeric_scale,
ordinal_position, is_nullable, column_comment
FROM information_schema.columns
WHERE table_schema = '${src_schema}'
AND upper(table_name) IN (${src_table_in})
ORDER BY table_name, ordinal_position
upper(table_name) 을 쓰는 이유가 있다. MariaDB · MySQL 은 환경에 따라 테이블명 대소문자를 구분하므로 원천에 저장된 표기와 다르면 조용히 0행이 나온다.
큐 내용이 [] 로 비어 있다면 세 가지를 본다. src_schema 가 실제 DB 명과 정확히 같은지, 테이블명 대소문자가 맞는지, 그 계정에 information_schema 조회 권한이 있는지다.
진단할 때는 조건을 줄인 쿼리를 임시로 넣어 실제 값을 확인한다.
SELECT table_schema, table_name, count(*) AS col_cnt
FROM information_schema.columns
WHERE upper(table_name) IN ('EEM_TORG','EEM_TEM','EEM_TBT')
GROUP BY table_schema, table_name
여기 찍히는 table_schema 가 src_schema 에 넣어야 할 정확한 DB 명이고, table_name 표기가 src_table_in 에 넣을 대소문자다.
진단 쿼리를 그대로 둔 채 본 흐름을 돌리면 .hql 파일은 생기는데 컬럼이 `null` 하나만 나온다. 진단 쿼리에는 column_name · data_type 이 없기 때문이다. 확인이 끝나면 본 쿼리로 되돌린다.
원천 DB 풀이 여러 개면 소스 DB 별로 PG 를 따로 두고 같은 쿼리를 쓴다. 한 번에 세 개만 나온다면 그 PG 가 바라보는 풀의 src_table_in 목록이 세 개인 것이다.
| part_ymd | load_ts | |
|---|---|---|
| 성격 | 파티션 컬럼 | 일반 컬럼 |
| 데이터 파일 안 | 없다 | 있어야 한다 |
| 표현 | part_ymd=20260603 디렉터리 |
Parquet 컬럼 값 |
즉 Parquet 파일의 컬럼은 원천 컬럼 + load_ts 이고 part_ymd 는 빠진다. 둘을 같게 다루면 데이터가 안 보이거나 컬럼이 어긋난다.
CREATE EXTERNAL TABLE IF NOT EXISTS bronze.eem_torg (
...원천 컬럼...,
load_ts STRING
)
PARTITIONED BY (part_ymd STRING)
STORED AS PARQUET
LOCATION '/warehouse/tablespace/external/hive/bronze.db/eem_torg';
load_ts 는 Hive Parquet 의 timestamp 호환 문제를 피하려고 STRING(yyyy-MM-dd HH:mm:ss) 으로 두는 경우가 많다. part_ymd 는 STRING(yyyyMMdd) 이 무난하다.
적재 쪽은 ConvertRecord(JSON → Parquet) → UpdateRecord(/part_ymd, /load_ts 주입) → PutHDFS(${tmp.path}/${part_ymd}) → MoveHDFS 순으로 흐른다.
새 파라미터 컨텍스트를 만들기보다 기존 컨텍스트(nifi-config) 에 이미 있는 접속 · Kerberos · Hadoop 값을 참조하고, DDL 생성 전용 값(원천 스키마 · 출력 경로) 만 PG 변수로 두는 편이 배포가 간단하다.
fail_mail_to 같은 값은 파라미터가 아니라 각 PG 의 Variables 에 들어 있고 PutEmail 의 To 로 전달된다. 복수 수신자는 PG 우클릭 → Variables 에서 콤마로 구분해 넣는다.