<div id="readability-page-1" class="page"><div id="page" role="main">

		

		
			
<article id="post-3587">
	

	<div>
		
<figure></figure>



<p>인터넷에서의 위의 링크의 글을 읽게되었다. 데이터 엔지니어링에서 오래 업무를 본 사람들은 습관적으로 아래 이미지와 같은 형태로 데이터를 파티셔닝 하는 경우가 많다. 크게 버컷에 데이터 종류에 따라 나누고 s3://bucket/data 부분 그뒤에 데이터의 생성 날짜에 따라 year=YYYY/month=MM/day=DD 형태로 나누는 것이다.</p>



<figure><a href="https://charsyam.wordpress.com/wp-content/uploads/2025/10/s3.webp"><img data-attachment-id="3589" data-permalink="https://charsyam.wordpress.com/2025/10/08/data-s3%ec%97%90%ec%84%9c-%eb%8d%b0%ec%9d%b4%ed%84%b0-%ed%8c%8c%ed%8b%b0%ec%85%98-%ed%95%98%eb%8a%94-%eb%b2%95%ec%9d%98-%ec%a7%84%ec%8b%a4/s3/#main" data-orig-file="https://charsyam.wordpress.com/wp-content/uploads/2025/10/s3.webp" data-orig-size="1456,971" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="s3" data-image-description="" data-image-caption="" data-medium-file="https://charsyam.wordpress.com/wp-content/uploads/2025/10/s3.webp?w=300" data-large-file="https://charsyam.wordpress.com/wp-content/uploads/2025/10/s3.webp?w=776" width="1024" height="682" src="https://charsyam.wordpress.com/wp-content/uploads/2025/10/s3.webp?w=1024" alt="" sizes="(max-width: 1024px) 100vw, 1024px"></a></figure>



<p> 이렇게 나누면 뭐가 좋을까? 특정 데이터의 날짜로 읽거나 month로 읽거나 year 단위로 읽을 때 다른 데이터를 읽을 필요가 없다. 즉, 필요하지 않은 데이터를 자동으로 제거(pruning)이 가능해진다.  </p>



<pre><code>s3://bucket/data/year=2025/month=01/day=01/events.parquet</code></pre>



<p> 그런데 위의 방법이 나쁘니, 새로운 방식을 제안한다. 아래와 같이 그냥 하나에 쓰는 방식이다. </p>



<pre><code>s3://bucket/data/dt=2025-01-01/events.parquet</code></pre>



<p>여기서 장점으로 든 예제는 다음과 같은 것이다. 2024년 1월 1일 부터 2025년 2월 10일까지의 데이터가 필요하면 어떻게 표현해야 하는가? 먼저 후자의 방식은 단순히 아래와 같이 간단히 기술이 된다.</p>



<pre><code>WHERE dt &gt;= ‘2025-01-01’ AND dt &lt;= ‘2025-02-10’</code></pre>



<p>그런데 전자의 방식은 좀 더 복잡해진다. 개별 DAY, MONTH, YEAR 단위는 쉽지만, 개별적으로 쪼개기는 쉽지 않기 때문에 코드는 아래와 같이 복잡해진다.</p>



<pre><code></code></pre>



<pre><code>WHERE (year = ‘2024’ AND month = ‘01’ AND day = ‘01’)
   OR (year = ‘2024’ AND month = ‘01’ AND day = ‘02’)
   OR ...
   OR (year = ‘2025’ AND month = ‘02’ AND day = ‘10’)</code></pre>



<p>단순히 보면 누가봐도 후자가 전자보다 좋아보인다. 그리고 현재로는 후자가 더 좋은 방법이다. 그러면 여기에 핵심은 왜 전자의 방식이 유행했나이다. 당연히 좋은 방식을 두고 왜 안좋은 전자를 많이 선택했을까? 데이터 엔지니어들이 혹시나 멍청했던 것일까?</p>



<p> S3는 초기에 나왔던 버전과 현재의 버전의 기능과 성능이 많이 다르다. 실제로 Hive나 Spark 을 s3와 연결하는 것은 굉장한 도전이었던 시기도 있었다. 일단 이 문제의 특징을 몇 가지 살펴보면, 초기의 s3는 hot paritition 이슈가 있어서 prefix별로 shard 데이터를 저장하다 보니, 한 버킷이나 연결된 prefix안에 많은 파일이 있는 것이 좋지 않은 구조였습니다.</p>



<p> 이 경우에 전자의 방식도 좋은 방식은 아니지만, 후자는 더 성능 이슈를 일으킬 수 있습니다. 이 시기에 AWS의 권장 사항을 보면 아래와 같은 방법을 제시합니다.</p>



<p>비추천(비추천이지만 전자와 유사한…)</p>



<pre><code>/images-to-process/2024/09/11/184502_5579cb0b97c990f7.jpeg
/images-to-process/2024/09/11/184502_5cd386a19afce9af.jpeg
/images-to-process/2024/09/11/184502_a900fdd2064e3073.jpeg
/images-to-process/2024/09/11/184502_acbe3954657842dd.jpeg</code></pre>



<p>추천(그러나 데이터 쪽에서는 아래 방식을 바로 적용하기는 어렵습니다.)</p>



<pre><code>/images-to-process/5579cb0b97c990f7/2024/09/11/184502_5579cb0b97c990f7.jpeg
/images-to-process/5cd386a19afce9af/2024/09/11/184502_5cd386a19afce9af.jpeg
/images-to-process/a900fdd2064e3073/2024/09/11/184502_a900fdd2064e3073.jpeg
/images-to-process/acbe3954657842dd/2024/09/11/184502_acbe3954657842dd.jpeg</code></pre>



<p>이런 사항에서 하나의 bucket 에 적절히 나눈 위치에 데이터를 넣을려고 하던 나름의 고심이 전자인 것입니다. </p>



<p>그리고 2020년 겨울쯤에 s3에서 list 오퍼레이션에 대한 strong consistency 기능을 제공했습니다. 이게 얼마나 중요햐 하면, hive, spark에서는 s3의 폴더의 내용을 list로 읽어오는데, 이게 특정 시점에 서로 다를 수 있었습니다. 즉 내가 특정 잡이 끝나고, 저장을 했는데, 다른 곳에서는 안 보이거나, 내가 지웠는데, 누가 읽어가서 참조하는 엄청난 이슈죠. 이것도 꼼수를 통해서 변경해야 했는데, 굉장히 힘들었던 기억이 있네요.</p>



<p> 다시 한번 정리하자면, 결론은 후자가 더 좋다입니다. 그런데 왜 그랬는지도 한번 정리해 보면 좋을꺼 같습니다.</p>




			</div>

	
</article>

			

				
	
		
		</div></div>

Charsyam's Blog

인터넷에서의 위의 링크의 글을 읽게되었다. 데이터 엔지니어링에서 오래 업무를 본 사람들은 습관적으로 아래 이미지와 같은 형태로 데이터를 파티셔닝 하는 경우가 많다. 크게 버컷에 데이터 종류에 따라 나누고 s3://bucket/data 부분 그뒤에 데이터의 생성 날짜에 따라 year=YYYY/month=MM/day=DD 형태로 나누는 것이다.
 이렇게 나누면 뭐가 좋을까? 특정 데이터의 날짜로 읽거나 month로 읽거나 year 단위로 읽을 때 다른 데이터를 읽을 필요가 없다. 즉, 필요하지 않은 데이터를 자동으로 제거(pruning)이 가능해진다.  
s3://bucket/data/year=2025/month=01/day=01/events.parquet
 그런데 위의 방법이 나쁘니, 새로운 방식을 제안한다. 아래와 같이 그냥 하나에 쓰는 방식이다. 
s3://bucket/data/dt=2025-01-01/events.parquet
여기서 장점으로 든 예제는 다음과 같은 것이다. 2024년 1월 1일 부터 2025년 2월 10일까지의 데이터가 필요하면 어떻게 표현해야 하는가? 먼저 후자의 방식은 단순히 아래와 같이 간단히 기술이 된다.
WHERE dt >= ‘2025-01-01’ AND dt <= ‘2025-02-10’
그런데 전자의 방식은 좀 더 복잡해진다. 개별 DAY, MONTH, YEAR 단위는 쉽지만, 개별적으로 쪼개기는 쉽지 않기 때문에 코드는 아래와 같이 복잡해진다.
WHERE (year = ‘2024’ AND month = ‘01’ AND day = ‘01’)
   OR (year = ‘2024’ AND month = ‘01’ AND day = ‘02’)
   OR ...
   OR (year = ‘2025’ AND month = ‘02’ AND day = ‘10’)
단순히 보면 누가봐도 후자가 전자보다 좋아보인다. 그리고 현재로는 후자가 더 좋은 방법이다. 그러면 여기에 핵심은 왜 전자의 방식이 유행했나이다. 당연히 좋은 방식을 두고 왜 안좋은 전자를 많이 선택했을까? 데이터 엔지니어들이 혹시나 멍청했던 것일까?
 S3는 초기에 나왔던 버전과 현재의 버전의 기능과 성능이 많이 다르다. 실제로 Hive나 Spark 을 s3와 연결하는 것은 굉장한 도전이었던 시기도 있었다. 일단 이 문제의 특징을 몇 가지 살펴보면, 초기의 s3는 hot paritition 이슈가 있어서 prefix별로 shard 데이터를 저장하다 보니, 한 버킷이나 연결된 prefix안에 많은 파일이 있는 것이 좋지 않은 구조였습니다.
 이 경우에 전자의 방식도 좋은 방식은 아니지만, 후자는 더 성능 이슈를 일으킬 수 있습니다. 이 시기에 AWS의 권장 사항을 보면 아래와 같은 방법을 제시합니다.
비추천(비추천이지만 전자와 유사한…)
/images-to-process/2024/09/11/184502_5579cb0b97c990f7.jpeg
/images-to-process/2024/09/11/184502_5cd386a19afce9af.jpeg
/images-to-process/2024/09/11/184502_a900fdd2064e3073.jpeg
/images-to-process/2024/09/11/184502_acbe3954657842dd.jpeg
추천(그러나 데이터 쪽에서는 아래 방식을 바로 적용하기는 어렵습니다.)
/images-to-process/5579cb0b97c990f7/2024/09/11/184502_5579cb0b97c990f7.jpeg
/images-to-process/5cd386a19afce9af/2024/09/11/184502_5cd386a19afce9af.jpeg
/images-to-process/a900fdd2064e3073/2024/09/11/184502_a900fdd2064e3073.jpeg
/images-to-process/acbe3954657842dd/2024/09/11/184502_acbe3954657842dd.jpeg
이런 사항에서 하나의 bucket 에 적절히 나눈 위치에 데이터를 넣을려고 하던 나름의 고심이 전자인 것입니다. 
그리고 2020년 겨울쯤에 s3에서 list 오퍼레이션에 대한 strong consistency 기능을 제공했습니다. 이게 얼마나 중요햐 하면, hive, spark에서는 s3의 폴더의 내용을 list로 읽어오는데, 이게 특정 시점에 서로 다를 수 있었습니다. 즉 내가 특정 잡이 끝나고, 저장을 했는데, 다른 곳에서는 안 보이거나, 내가 지웠는데, 누가 읽어가서 참조하는 엄청난 이슈죠. 이것도 꼼수를 통해서 변경해야 했는데, 굉장히 힘들었던 기억이 있네요.
 다시 한번 정리하자면, 결론은 후자가 더 좋다입니다. 그런데 왜 그랬는지도 한번 정리해 보면 좋을꺼 같습니다.

[DATA] S3에서 데이터 파티션 하는 법의 진실…

댓글