Skip to content

Firehose + iceberg table 사용시 firehose에서는 data가 나중에 업데이트 되는 문제...

0

안녕하세요, us-east-1에서 iceberg table에 데이터 적제 테스트를 하다가 문제가 있어서 질문 남깁니다.

현재 사용중하는 서비스는 아래와 같습니다.

  • Lake Formation + Iceberg Table: table은 datetime, exchange, symbol, open, high, low, close, volume 이며, day 단위로 파티셔닝 적용
  • Data firehouse : Diret Input + Output: Iceberg Table
  • Athena: 데이터 확인용...

데이터의 종류는 여러 거래소의 코인 가격정보이며, 한번에 거래소와 코인들의 가격을 한번에 받아와서 Direct Input으로 Put record 넣는 중, 초기 수집 단계에서 history data는 datetime이 순차적으로 들어가는게 아니라 거래소별 심볼별 다양하게 들어가는 중 입니다.

fire hose fir hose 설정

초기에는 데이터가 들어 갈 때, athena에서 조회를 하면 약 1~2분 정도의 딜레이 후 조회가 가능했는데, 거래소가 엄청 늘어나고 한번에 넣는 데이터가 들어나니까 업데이트가 한참 걸리더군요.

그리고 하루 이상 아테나에서 조회가 안되서 문제를 파악하고 있습니다..

우선 이상한점은

  • 확인을 위해 Direct Input에 데이터를 넣는것을 한 두시간 멈추었지만, 테이블의 row count를 했을 때 지속적으로 늘어남..
  • 특정 거래소의 데이터가 '2014-01-10' 까지 조회가 되는 상태이지만, 실제 data를 넣는 프로그램에서는 '2015-12-30' 까지 넣은걸로 확인, 하지만 아테나 쿼리로는 조회가 계속 안됨.
  • 문제 확인을 위해 데이터 넣는걸 멈췄다가 확인이 필요한 거래소 심볼만 firehose로 넣었고, 2015-12-30 일 이후의 데이터를 firehose로 넣었는데, 아테나에서 '2014-01-13' 일까지 데이터가 들어간걸 확인... 이 부분이 가장 의문입니다.

그래서 실제 firehose -> {buffer} -> iceberg table로 데이터가 업데이트 되는데, 버퍼에 있는게 한참 뒤에 업데이트 되거나 일정 이상 데이터가 차지 않으면 데이터를 쓰지 않는거 같은데... 이걸 줄일 수 잇을까요?? buffer interval이 해당 설정을 하는게 아닌가요? firehose


추가로 궁금한점이, 데이터가 추가되면 data 하위에 해시 폴더 아래에 datetime 파티셔닝 폴더로 데이터가 들어가는데요. 이걸 하지 않게 하려고, emr spark에서 Table 을 만들 때, 아래 옵션을 range로 했는데 해당 옵션이 아닐까요..? 'write.distribution-mode'='range',

s3 directory 그리고 해시로 되어 있어서인지, spark에서 rewrite를 할 때, datetime을 지정하면 찾지 못하더군요 ㅠ

1개 답변
0

귀하의 질문에 대해 답변 드리겠습니다.

Firehose와 Iceberg 테이블을 사용할 때 데이터 업데이트 지연 문제는 여러 요인에 의해 발생할 수 있습니다.

  1. 버퍼링: Firehose는 기본적으로 데이터를 버퍼링합니다. 버퍼 간격 설정은 이 과정에 영향을 줍니다만, 데이터 양이 많아지면 설정된 간격보다 더 오래 걸릴 수 있습니다.

  2. 데이터 일관성: Iceberg 테이블은 원자성 커밋을 제공하지만, 대량의 데이터를 처리할 때는 일관성을 유지하기 위해 시간이 걸릴 수 있습니다.

  3. 파티셔닝: 날짜별 파티셔닝은 쿼리 성능을 향상시킬 수 있지만, 데이터 쓰기 과정에서 지연을 초래할 수 있습니다.

버퍼링 시간을 줄이기 위해서는 Firehose의 버퍼 간격과 크기 설정을 조정해볼 수 있습니다. 하지만 이는 데이터의 일관성과 트레이드오프 관계에 있으므로 신중히 결정해야 합니다.

S3 디렉토리 구조와 관련하여, Iceberg는 기본적으로 데이터 파일을 관리하기 위해 해시 기반의 디렉토리 구조를 사용합니다. 'write.distribution-mode'='range' 옵션은 데이터 분산 방식을 제어하지만, 파일 구조 자체를 변경하지는 않습니다.

Spark에서 rewrite 시 datetime을 찾지 못하는 문제는 Iceberg의 메타데이터 관리 방식 때문일 수 있습니다. Iceberg는 자체 메타데이터를 사용하여 데이터 파일을 추적하므로, 직접적인 파일 시스템 접근보다는 Iceberg API를 통해 데이터에 접근하는 것이 좋습니다.

이러한 문제들을 해결하기 위해서는 Firehose의 설정을 최적화하고, Iceberg 테이블의 파티셔닝 전략을 재검토하며, 데이터 쓰기 및 읽기 작업을 모니터링하여 병목 지점을 식별하는 것이 도움이 될 수 있습니다.
Sources
Use Apache Iceberg tables in Athena for Spark - Amazon Athena
firehose delivery stream destination error | AWS re:Post

답변함 3달 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.