Data Lake 구축시 성능고려한 적절한 S3 오브젝트 키 패턴

0

S3에 Data Lake를 구축하려 합니다. 고려사항은 데이터 읽기 성능과 파티셔닝입니다.

  1. S3는 데이터 파티셔닝을 오브젝트의 키를 기준으로 lexicographically 하기때문에 읽기 성능을 최적화 하기위해선 오프젝트 키 맨 앞부분부터 (prefix가 되건, 파일네임이 되건간에 상관없이) 최대한 랜덤한 글자들이 들어가야 하는 걸로 알고있습니다.

  2. EMR, Athena, Redshift Spectrum 등을 이용해서 S3에 있는 데이터를 효과적으로 읽어들이기 위해서는 보통 기준이 time range가 됨으로 년도, 월, 일 등으로 prefix를 넣어서 분석대상 데이터의 양을 한정 할 수 있습니다.

위 2개의 방법이 충돌하더군요. 아무리 찾아봐도 시원한 설명이 없어서 여기에 문의드립니다. 결국 어쩔 수 없는건가요? 둘중에 하나를 골라야 한다면 당연히 파티셔닝을 안 할 수는 없기때문에 결국 1번은 포기해야되는 건지요? 만약, 그렇다면 구체적으로 어느정도의 성능 저하를 감수해야 하는건가요? 당연히, EMR, Athena, Redshift 의 클러스터 크기 구성에도 영향을 받겠지만, 일반적인 수치를 좀 알고 싶습니다. 예를들면, 다음와 같은 비교 구성입니다:

A. /버켓이름/sdkf1js6hdk2jfh.csv, /버켓이름/iuh3riu1gs9kjn.csv, /버켓이름/0ia5usdioasi.csv, ...
이런식으로 1GB CSV 파일이 5000개, 약 5TB를 모두 Redshift 스펙트럼에서 쿼리

B. /버켓이름/2000-01-01/sdkf1js6hdk2jfh.csv 이런식으로 해서 2010-12-31 까지 1GB CSV 파일이 약 50만개 있는데, 여기서 2008-01-01에서 2008-12-31까지만 지정(동일하게 파일 5000개 총 5TB)하여 Redshift 스펙트럼에서 쿼리

당연히 데이터 읽기 속도는 A가 빠를것입니다. A는 오브젝트 키의 맨앞 4글자가 모두 다르기 때문에 여러개의 파티션에 걸쳐 고르게 분포되어 저장되어 있기때문에, Redshift 클러스터가 일단 모든 오브젝트를 GET LIST 하여 여러개의 오브젝트를 동시에 끓어 당길때 성능은 최적화 되겠지요. 그러나, B의 경우는 모두 다 앞의 4글자가 "2008" 이기때문에 A보다는 덜 고르게, 최악의 경우에는 모두 같은 하나의 파티션에 저장되어 있을 수도 있겠습니다. A보단 속도가 떨어지겠죠?

B가 A보다 얼마큼 속도가 떨어지는지 분명한 설명이 아무데도 없습니다. 아니면, 아마도 속도 저하가 아예 없는지도 모르겠습니다. AWS 문서에만 그렇게 설명되어 있을뿐 실제로는 그렇지 않을 수도 있을것 같고, 또 리전마다 다를 수도 있겠습니다. 솔직히 S3 설계가 잘못된거 아닌가도 생각이 듭니다. 왜 오브젝트 키를 lexicographically 기준으로하여 파티셔닝 하는지 모르겠습니다. DynamoDB가 파티션키를 hashing 하여 파티셔닝 하는 구조와 동일하게 갔으면, 유저의 오브젝트 키 패턴이 어떻던지 간에 성능엔 문제가 없는데 말입니다. 좀 답답하네요. 아마도, 이건 AWS 클라우드 시스템 내부의 영역이고, 설계를 구조를 바꾸면 얼마든지 개선이 가능하기에 아직까지 정확한 설명이 없는 것으로 예상은 됩니다.

성능도 최대면서 테이블 파티셔닝도 가능하에 하려면 S3 객체들의 메타데이터 인덱스 디비를 DynamoDB에 두는 방법도 있기는 할것 같습니다. AWS 블로그 페이지 https://aws.amazon.com/blogs/big-data/building-and-maintaining-an-amazon-s3-metadata-index-without-servers/ 여기 글을 읽어 보았습니다.

하지만 지금 Athena 또는 EMR hive에서 S3 버킷을 대상으로 테이블 파티셔닝 지정하는 방법을 보면 모두 객체 키의 프리픽스에 "dt = 날짜" 이런식으로 넣고 사용하는데, DynamoDB에 있는 객체 인덱스를 쿼리해서 테이블 파니셔닝 하는 방법이 가능한가요? 불가한것 같긴 합니다.

아니면 미국본사에 개발자 직원구인 공고 보면 "S3 indexing" 이라는 팀이 있고, 그 팀에서 개발자 구하던데... 앞으로 어떤 새로운 인덱싱 및 인덱스 쿼리 기능이 나와서 EMR, Athena, Redshift Spectrum 에서 연동이 가능할까요?

질문 하나 더 드립니다. Athena는 서울리전에 언제 출시되나요?

Edited by: srvless0915 on May 12, 2017 1:08 AM

feita há 7 anos295 visualizações
1 Resposta
0

안녕하세요. AWS 서포트팀입니다.
문의 주셔서 감사합니다.

여러가지 의견을 주셨지만 문제는 S3에 데이터를 저장할 시 파티션 VS Prefix 중 어떤것으로 할지에 대한 고민인 것 같습니다.

이문제는 어떠한 쿼리 패턴이 더 많느냐에 따라 다를 것 같습니다.

  1. 매번 수십테라바이트의 데이터를 2000년부터 현재까지 읽는 업무가 많다면 말씀하신 대로 A번이 유리할 것 이고
  2. 특정한 기간에 대한 조건이 포함된 쿼리가 많다면 파티션된 데이터 구조를 이용하는 것이 성능이 좋으리라 생각합니다. 왜냐하면 대부분의 SQL on To of Hadoop(Hive, Presto(Athean) 등 ) 솔루션에서 파티션 기능을 사용할 경우 내부적으로 메타정보를 가지고 있고, 쿼리 시행시 메타정보를 참고하여 해당 데이터가 있는 위치만 읽는 기능을 제공하기 때문입니다.

매번 수십테라바이트의 데이터를 읽는 업무라 하더라도 B방법(파티션)을 권장드립니다. 왜냐하면 많은 양의 데이터를 한번에 작업하다보면 아무래도 메모리나 리소스 이슈가 있을 수 있고 소요되는 시간이 많이 걸리므로 많은 양의 데이터를 조금씩 나누어서 분석/작업하는 것이 더 효율적일 수 있기 때문입니다.

추가적으로 파일 이름을 random하게 주는 방식보다는 중간 경로에 "/버켓이름/2000-01-01/sdkf1js6hdk2jfh/filename.csv" 임의의 문자가 포함되는 것이 더 성능에 도움이 되고, 키 이름에 해시 문자열을 접두사로 추가하는 방법도 있습니다. (http://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/request-rate-perf-considerations.html )

Athena 는 저희 내부 문서를 참고했을 때 올해 말이나 그 이후에나 가능할 것으로 보입니다 .
감사합니다.

respondido há 7 anos

Você não está conectado. Fazer login para postar uma resposta.

Uma boa resposta responde claramente à pergunta, dá feedback construtivo e incentiva o crescimento profissional de quem perguntou.

Diretrizes para responder a perguntas