데이터 저장 형식 TextInputFormat/ Parquet 관련해서 정리

문제

📌 Hue 에서 컬럼수정시 >> 테이블 스키마 구조가 바뀌면 backfill 해줘야 하는 현상 아니면 Mismatch 오류가 뜸

원인

• 테이블 빌드시 parquet 가 아닌 경우 (TextInputFormat) 에는 컬럼 순서를 지켜줘야 함
  • 영향을 받는 형식
    • 'org.apache.hadoop.mapred.**TextInputFormat**'
• 그렇다면 ? >>
  • 빌드할때 PARQUET 형식으로 빌드해야함
    • external table 인데 spark.sql.sources.schema 달리면 안됨
      • spark.sql.... property 를 모두 제거하거나
      • spark.sql.sources.schema json 에 새로 추가하는 컬럼을 추가

ROW FORMAT SERDE

• ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
  • Parquet 형식을 사용하려면, 올바른 SerDe를 사용해야 합니다. 예를 들어, **org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe**를 사용할 수 있습니다.
  • 빌드할때 코드 (확인해보니 굳이 안해줘도 STORED AS PARQUET 요것만 넣어도 무방함)
    • **ParquetHiveSerDe**는 이 두 시스템 간의 호환성을 제공하여, Hive가 Parquet 파일 형식으로 저장된 데이터를 읽고 쓸 수 있도록 합니다.
  • CREATE TABLE my_table ( ... ) STORED AS PARQUET WITH SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe';

TextInputFormat

• **TextInputFormat**은 일반적으로 CSV나 TSV 같은 텍스트 파일을 처리할 때 사용

TextInputFormat과 Parquet을 비교

<aside> 📌 요약

• TextInputFormat은 호환성이 높고 이해하기 쉬우며, 초기 데이터 로딩이나 소규모 데이터셋에 적합합니다. 다만, 압축 및 I/O 효율성이 낮고 스키마를 지원하지 않습니다.
• Parquet은 대규모 데이터 분석에 최적화되어 있으며, 높은 압축율과 컬럼 단위 처리로 쿼리 성능이 우수합니다. 스키마를 내장하여 데이터 무결성을 유지할 수 있지만, 이진 형식으로 사람이 읽기 어렵고 데이터 준비가 복잡합니다. </aside>

특징 TextInputFormat Parquet

데이터 형식	텍스트 (CSV, TSV 등)	컬럼형
호환성	높은 호환성 (많은 데이터 소스가 텍스트 형식)	주로 빅데이터 및 분석 도구 (Hadoop, Spark 등)
이해 및 수정 용이성	사람 읽기 및 수정 용이	이진 형식, 사람이 읽기 어려움
압축 및 저장 효율성	일반적으로 낮음	높은 압축율 및 저장 효율성
스키마 지원	없음 (외부에서 정의 필요)	강력한 스키마 내장
쿼리 성능	전체 행 스캔 필요	특정 컬럼만 읽기 가능, 높은 쿼리 성능
I/O 성능	낮음	높음 (컬럼 단위 처리)
데이터 준비 용이성	쉬움 (간단한 스크립트나 편집기로 생성 가능)	데이터 준비 복잡, 전용 도구 필요
실시간 처리 적합성	적합 (실시간 스트리밍 데이터에 용이)	적합하지 않음
사용 사례	초기 데이터 로딩, 소규모 데이터셋	대규모 데이터 분석, 데이터 웨어하우스, BI 도구
파일 크기	비교적 큼	비교적 작음 (압축 적용)

TextInputFormat 사용 이유:

1. 호환성 및 단순성:
   • 텍스트 파일 호환성: 많은 데이터 소스가 CSV, TSV 같은 텍스트 형식으로 데이터를 제공하기 때문에 호환성이 좋습니다.
   • 단순성: 텍스트 형식은 이해하기 쉽고, 사람이 읽고 쓸 수 있습니다. 데이터 확인 및 디버깅이 용이합니다.
2. 데이터 준비 및 로딩:
   • 데이터 준비가 쉽다: 텍스트 형식의 데이터를 생성하거나 수정하는 것은 상대적으로 쉽습니다. 간단한 스크립트나 표준 텍스트 편집기만으로도 가능합니다.
   • 초기 데이터 로딩: 데이터를 처음 로딩하거나 작은 데이터셋을 다룰 때는 텍스트 형식이 더 적합할 수 있습니다.
3. 데이터 스트리밍:
   • 스트리밍 데이터 처리: 실시간 또는 스트리밍 데이터 처리의 경우, 텍스트 형식은 빠르게 처리하고 소비할 수 있는 장점이 있습니다.

Parquet 사용 이유:

1. 효율성 및 성능:
   • 컬럼형 저장: Parquet은 컬럼형 저장 형식을 사용하여, 특정 열만 읽거나 쓸 때 더 효율적입니다. 대규모 데이터 집합에서 특정 열에 대해 쿼리를 실행할 때 성능이 크게 향상됩니다.
   • 압축 및 인코딩: Parquet은 고도로 압축된 형식으로 데이터를 저장하여 저장 공간을 절약하고 I/O 성능을 향상시킵니다.
2. 스키마 지원:
   • 강력한 스키마 지원: Parquet 파일에는 스키마 정보가 포함되어 있어 데이터 타입과 구조를 명확히 정의할 수 있습니다. 이는 데이터 무결성을 유지하고, 분석 작업을 더 쉽게 만듭니다.
3. 분산 처리 최적화:
   • 분산 데이터 처리: Parquet은 Hadoop, Spark, Presto, Athena 같은 분산 데이터 처리 시스템과 잘 통합되어 대규모 데이터 분석 작업에 최적화되어 있습니다.

선택 기준:

• 데이터 크기: 소규모 데이터셋이나 초기 데이터 로딩의 경우, TextInputFormat이 더 간편할 수 있습니다. 반면, 대규모 데이터셋에서는 Parquet이 더 효율적입니다.
• 성능 요구 사항: 분석 성능이 중요한 경우, Parquet이 더 적합합니다. 특히, 특정 열에 대한 빈번한 쿼리가 있는 경우 Parquet의 컬럼형 저장 방식이 큰 이점을 제공합니다.
• 데이터 무결성: 데이터 타입과 구조를 명확히 유지해야 하는 경우 Parquet이 더 적합합니다. Parquet은 스키마를 내장하여 데이터 무결성을 유지합니다.
• 데이터 형태: 실시간 스트리밍 데이터나 로그 데이터의 경우, 텍스트 형식이 더 적합할 수 있습니다.

테스트를 해보자

1. 테이블 빌드 1

CREATE EXTERNAL TABLE temp.test_format_table_v2 (
    user_id         bigint ,
    contents_id     bigint,
    contents_type   string,
    keycol_cnt      bigint
       )
PARTITIONED BY (
  base_dt string
       )
stored as parquet
location
  's3://bucketplace-emr-ba/hive-ba/output/temp/test_format_table'
;

1. 하루치 insert

INSERT INTO  temp.test_format_table_v2
select *
,'2024-04-10' as base_Dt
from ( SELECT
           user_id,
            project_name,
           contents_id,
           contents_type,
           count(DISTINCT concat(cast(contents_type AS VARCHAR), cast(contents_id AS VARCHAR))) AS keycol_cnt
       --     , base_dt
-- select *
       FROM contents.contents_meta_daily cmd
       WHERE 1 = 1
         AND base_dt = '2024-04-10'
       GROUP BY 1, 2, 3,4
       limit 100)
where 1=1

1. 휴에서 컬럼변경

-- -- content_stat_monthly_test_v2 테이블 교체
 alter table temp.test_format_table_v2
 add columns (project_name string)
-- ;

alter table temp.test_format_table_v2
change column project_name project_name string AFTER user_id

1. 조회

select * from temp.test_format_table_v2

1. 변경된 컬럼 insert

INSERT INTO  temp.test_format_table_v2
select *
,'2024-04-11' as base_Dt
from ( SELECT
           user_id,
            project_name,
           contents_id,
           contents_type,
           count(DISTINCT concat(cast(contents_type AS VARCHAR), cast(contents_id AS VARCHAR))) AS keycol_cnt
       --     , base_dt
-- select *
       FROM contents.contents_meta_daily cmd
       WHERE 1 = 1
         AND base_dt = '2024-04-11'
       GROUP BY 1, 2, 3,4
       limit 100
       )
where 1=1

;

1. 조회

select * from temp.test_format_table_v2 where base_dt = '2024-04-11'

• 잘 된다 !

실습

• content_stat_monthly >> 변경완료 

기존에 Textinputformat으로 만든 테이블은 어떡하나 ?문제

📌 Hue 에서 컬럼수정시 >> 테이블 스키마 구조가 바뀌면 backfill 해줘야 하는 현상 아니면 Mismatch 오류가 뜹니다 ㅠ

원인

• 테이블 빌드시 parquet 가 아닌 경우 (TextInputFormat) 에는 컬럼 순서를 지켜줘야 함
  • 영향을 받는 형식
    • 'org.apache.hadoop.mapred.**TextInputFormat**'
• 그렇다면 ? >>
  • 빌드할때 PARQUET 형식으로 빌드해야함
    • external table 인데 spark.sql.sources.schema 달리면 안됨
      • spark.sql.... property 를 모두 제거하거나
      • spark.sql.sources.schema json 에 새로 추가하는 컬럼을 추가

ROW FORMAT SERDE

• ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
  • Parquet 형식을 사용하려면, 올바른 SerDe를 사용해야 합니다. 예를 들어, **org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe**를 사용할 수 있습니다.
  • 빌드할때 코드 (확인해보니 굳이 안해줘도 STORED AS PARQUET 요것만 넣어도 무방함)
    • **ParquetHiveSerDe**는 이 두 시스템 간의 호환성을 제공하여, Hive가 Parquet 파일 형식으로 저장된 데이터를 읽고 쓸 수 있도록 합니다.
  • CREATE TABLE my_table ( ... ) STORED AS PARQUET WITH SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe';

TextInputFormat

• **TextInputFormat**은 일반적으로 CSV나 TSV 같은 텍스트 파일을 처리할 때 사용

TextInputFormat과 Parquet을 비교

 📌 요약

• TextInputFormat은 호환성이 높고 이해하기 쉬우며, 초기 데이터 로딩이나 소규모 데이터셋에 적합합니다. 다만, 압축 및 I/O 효율성이 낮고 스키마를 지원하지 않습니다.
• Parquet은 대규모 데이터 분석에 최적화되어 있으며, 높은 압축율과 컬럼 단위 처리로 쿼리 성능이 우수합니다. 스키마를 내장하여 데이터 무결성을 유지할 수 있지만, 이진 형식으로 사람이 읽기 어렵고 데이터 준비가 복잡합니다. </aside>

특징 TextInputFormat Parquet

데이터 형식	텍스트 (CSV, TSV 등)	컬럼형
호환성	높은 호환성 (많은 데이터 소스가 텍스트 형식)	주로 빅데이터 및 분석 도구 (Hadoop, Spark 등)
이해 및 수정 용이성	사람 읽기 및 수정 용이	이진 형식, 사람이 읽기 어려움
압축 및 저장 효율성	일반적으로 낮음	높은 압축율 및 저장 효율성
스키마 지원	없음 (외부에서 정의 필요)	강력한 스키마 내장
쿼리 성능	전체 행 스캔 필요	특정 컬럼만 읽기 가능, 높은 쿼리 성능
I/O 성능	낮음	높음 (컬럼 단위 처리)
데이터 준비 용이성	쉬움 (간단한 스크립트나 편집기로 생성 가능)	데이터 준비 복잡, 전용 도구 필요
실시간 처리 적합성	적합 (실시간 스트리밍 데이터에 용이)	적합하지 않음
사용 사례	초기 데이터 로딩, 소규모 데이터셋	대규모 데이터 분석, 데이터 웨어하우스, BI 도구
파일 크기	비교적 큼	비교적 작음 (압축 적용)

TextInputFormat 사용 이유:

1. 호환성 및 단순성:
   • 텍스트 파일 호환성: 많은 데이터 소스가 CSV, TSV 같은 텍스트 형식으로 데이터를 제공하기 때문에 호환성이 좋습니다.
   • 단순성: 텍스트 형식은 이해하기 쉽고, 사람이 읽고 쓸 수 있습니다. 데이터 확인 및 디버깅이 용이합니다.
2. 데이터 준비 및 로딩:
   • 데이터 준비가 쉽다: 텍스트 형식의 데이터를 생성하거나 수정하는 것은 상대적으로 쉽습니다. 간단한 스크립트나 표준 텍스트 편집기만으로도 가능합니다.
   • 초기 데이터 로딩: 데이터를 처음 로딩하거나 작은 데이터셋을 다룰 때는 텍스트 형식이 더 적합할 수 있습니다.
3. 데이터 스트리밍:
   • 스트리밍 데이터 처리: 실시간 또는 스트리밍 데이터 처리의 경우, 텍스트 형식은 빠르게 처리하고 소비할 수 있는 장점이 있습니다.

Parquet 사용 이유:

1. 효율성 및 성능:
   • 컬럼형 저장: Parquet은 컬럼형 저장 형식을 사용하여, 특정 열만 읽거나 쓸 때 더 효율적입니다. 대규모 데이터 집합에서 특정 열에 대해 쿼리를 실행할 때 성능이 크게 향상됩니다.
   • 압축 및 인코딩: Parquet은 고도로 압축된 형식으로 데이터를 저장하여 저장 공간을 절약하고 I/O 성능을 향상시킵니다.
2. 스키마 지원:
   • 강력한 스키마 지원: Parquet 파일에는 스키마 정보가 포함되어 있어 데이터 타입과 구조를 명확히 정의할 수 있습니다. 이는 데이터 무결성을 유지하고, 분석 작업을 더 쉽게 만듭니다.
3. 분산 처리 최적화:
   • 분산 데이터 처리: Parquet은 Hadoop, Spark, Presto, Athena 같은 분산 데이터 처리 시스템과 잘 통합되어 대규모 데이터 분석 작업에 최적화되어 있습니다.

선택 기준:

• 데이터 크기: 소규모 데이터셋이나 초기 데이터 로딩의 경우, TextInputFormat이 더 간편할 수 있습니다. 반면, 대규모 데이터셋에서는 Parquet이 더 효율적입니다.
• 성능 요구 사항: 분석 성능이 중요한 경우, Parquet이 더 적합합니다. 특히, 특정 열에 대한 빈번한 쿼리가 있는 경우 Parquet의 컬럼형 저장 방식이 큰 이점을 제공합니다.
• 데이터 무결성: 데이터 타입과 구조를 명확히 유지해야 하는 경우 Parquet이 더 적합합니다. Parquet은 스키마를 내장하여 데이터 무결성을 유지합니다.
• 데이터 형태: 실시간 스트리밍 데이터나 로그 데이터의 경우, 텍스트 형식이 더 적합할 수 있습니다.

테스트를 해보자

• 테이블 빌드 1

CREATE EXTERNAL TABLE temp.test_format_table_v2 (
    user_id         bigint ,
    contents_id     bigint,
    contents_type   string,
    keycol_cnt      bigint
       )
PARTITIONED BY (
  base_dt string
       )
stored as parquet
location
  's3://bucketplace-emr-ba/hive-ba/output/temp/test_format_table'
;

• 하루치 insert

INSERT INTO  temp.test_format_table_v2
select *
,'2024-04-10' as base_Dt
from ( SELECT
           user_id,
            project_name,
           contents_id,
           contents_type,
           count(DISTINCT concat(cast(contents_type AS VARCHAR), cast(contents_id AS VARCHAR))) AS keycol_cnt
       --     , base_dt
-- select *
       FROM contents.contents_meta_daily cmd
       WHERE 1 = 1
         AND base_dt = '2024-04-10'
       GROUP BY 1, 2, 3,4
       limit 100)
where 1=1

• 휴에서 컬럼변경

-- -- content_stat_monthly_test_v2 테이블 교체
 alter table temp.test_format_table_v2
 add columns (project_name string)
-- ;

alter table temp.test_format_table_v2
change column project_name project_name string AFTER user_id

• 조회

select * from temp.test_format_table_v2

• 변경된 컬럼 insert

INSERT INTO  temp.test_format_table_v2
select *
,'2024-04-11' as base_Dt
from ( SELECT
           user_id,
            project_name,
           contents_id,
           contents_type,
           count(DISTINCT concat(cast(contents_type AS VARCHAR), cast(contents_id AS VARCHAR))) AS keycol_cnt
       --     , base_dt
-- select *
       FROM contents.contents_meta_daily cmd
       WHERE 1 = 1
         AND base_dt = '2024-04-11'
       GROUP BY 1, 2, 3,4
       limit 100
       )
where 1=1

;

• 조회

select * from temp.test_format_table_v2 where base_dt = '2024-04-11'

• 잘 된다 !

실습

• content_stat_monthly >> 변경완료 

기존에 Textinputformat으로 만든 테이블은 어떡하나 ?