BroadCast 지원 가능 메모리 문의

안녕하세요 민수님,일단 첫번째 질문에 대한 답변으로는 Spark에서 broadcast 변수를 사용할 때, 최대 메모리 크기는 Spark의 executor 메모리 및 드라이버 메모리 설정에 따라 달라집니다. 하지만 일반적으로 몇 가지 고려해야 할 사항이 있습니다.기본적으로 spark.driver.maxResultSize 설정에 영향을 받음기본값은 1GB이며, 더 큰 데이터를 브로드캐스트하면 OOM(Out of Memory) 에러가 발생할 수 있음.필요하면 값을 늘릴 수 있음 (spark.driver.maxResultSize=4g 등).spark.sql.autoBroadcastJoinThreshold 값기본적으로 10MB (10485760 바이트) 이상인 경우 자동 브로드캐스트가 비활성화됨.이 값을 늘리면 더 큰 데이터를 브로드캐스트할 수 있지만, 너무 크면 실행 성능이 저하될 수 있음.Executor 메모리 제약브로드캐스트 데이터는 각 Executor에서 메모리에 유지되므로, 개별 Executor의 메모리 크기에 따라 제한됨.두번째 질문에 대한 대답으로는 저희가 meta를 dim_table이라 할 경우 ...브로드캐스트 가능: dim_table이 작을 경우 (보통 100MB 이하).브로드캐스트 불가능: dim_table이 크거나, TB 크기의 테이블에서 여러 컬럼과 매핑할 경우.대안: Shuffle Join, Partition 조정, Bloom Filter 등을 활용하시면 될 듯 합니다.

total을 float으로 바꾸신 이유

안녕하세요 천천히꾸준하게님,좋은 지적인 것 같습니다. 하지만, 나중에 경력을 쌓으시면 아시겠지만, 코드는 명시적으로 개발하면 할수록 타 개발자와 협업하기가 좋습니다. 이부분에서는 total이 int임을 명시적으로 float로 변환함으로써 의도를 명확히 하려는 목적이었습니다.답변이 도움이 되었으면 좋겠습니다.

docker-compose

안녕하세요 비가얼어죽으면비동사,그러게요 "django_celery_beat_periodictask" does not exist 에러가 있는 걸 보니 마이그레이션이 안되었나 보네요.레퍼런스로 올려주셔서 감사합니다

저만 안 되는 것인가요? ㅠㅠ

안녕하세요 Inhwa Choi님,localhost를 사용할 때 어떤 운영체제에서는 0.0.0.0이 되고, 어떤 운영체제에서는 127.0.0.1이 되는 이유는 운영체제의 네트워크 설정 방식과 특정 소프트웨어의 기본 바인딩 주소 차이 때문입니다.운영체제 자체는 일반적으로 localhost를 127.0.0.1로 해석하지만, 특정 네트워크 설정이나 애플리케이션의 기본 바인딩 방식에 따라 0.0.0.0이 될 수도 있습니다.이를 확실히 구분하려면 /etc/hosts 파일과 애플리케이션의 네트워크 바인딩 옵션을 확인하는 것이 중요합니다.차이는 없으니, 별로 신경쓰지 않으시고 되는 걸로 하시면 됩니다 ㅎㅎ

standalone_celery 에만 작성된 task 들은 호출할 수 없나요?

안녕하세요 jh1one님,좋은 질문입니다. standalone_celery에 작성된 task를 실행하려면 해당 Docker 컨테이너 내부(standalone_celery)에서 실행해야 합니다. Django는 기본적으로 PYTHONPATH를 자동으로 설정해 주기 때문에 Python REPL에서 바로 import할 수 있지만, standalone_celery에서는 강의에서 설명한 대로 다소 어려울 수 있습니다. 그러나 PYTHONPATH를 적절히 설정하면 Python REPL에서도 동일하게 실행할 수 있습니다.그리고 standalone_celery 에 main.py 보시면 어떤 Task가 어디 Queue에 할당되어 있는지 나와있을 겁니다.제 팁으로는 조금 강의 더 들으시다가 Flower API를 사용하시는게 더 쉬우실 겁니다 😄마지막으로 Celery 의 task 에 작성된 함수들이 queue 로 실행된다은 거의 맞는 말입니다.밑에 AI인턴이 설명한대로, Queue에 Task가 설정되고, 그 Queue를 듣고 있는 Celery worker가 Task를 처리합니다.

index join 에 대한 질문

안녕하세요 junha.park님,Elasticsearch에서는 밑에 AI가 얘기한 것처럼 기본적으로 index 간 join을 지원하지 않습니다.Elasticsearch는 RDB처럼 join을 할 수 없기 때문에 데이터 중복을 감수하고 index를 설계하는 것이 일반적입니다. 이를 Document Denormalization이라고 합니다.따라서 dogs와 men 데이터를 하나의 document로 저장하는 방법이 가장 효율적입니다.{ "dog_name": "Buddy", "owner_name": "John", "owner_id": 123 } 이렇게 하면 하나의 index에서 바로 검색이 가능하므로 주인이 있는 개 vs 없는 개 비율을 쉽게 분석할 수 있습니다.또한 밑에 말한 것처럼 Kibana에서 Vega(데이터 시각화 DSL) 또는 Lens를 사용하여 두 개의 index를 조합해서 분석할 수 있다고 하는데 제가 안해봐서 뭐라 말씀을 못 드리겠네요.https://www.elastic.co/guide/en/kibana/current/vega.html 한번 보시면 도움이 될 것 같네요.

Logging 질문

안녕하세요 ansghltjd9님,Django의 runserver를 실행할 때 자동으로 리로드(Auto-reload)가 발생하는 이유는 django.utils.autoreload가 파일 변경을 감지하는 방식 때문입니다.Django의 개발 서버 (runserver)는 코드 변경을 감지하여 자동으로 재시작하는 기능이 있습니다. 이 기능은 django.utils.autoreload 모듈을 사용하여 특정 디렉터리의 파일 변경 여부를 감지합니다. 파일의 변경을 감지하는 주요 방식은 다음과 같습니다.파일의 수정 시간 (mtime) 감지Django는 실행 중인 Python 파일들의 mtime (modified time, 수정 시간)을 주기적으로 확인합니다.mtime이 변경되면 Django는 이를 코드 변경으로 간주하고 자동으로 리로드합니다.sys.modules를 이용한 파일 추적Python이 로드한 모든 모듈 (sys.modules)을 순회하면서 해당 파일의 변경 여부를 확인합니다.로그에서 보시면 ...{ "asctime": "2025-02-14 20:41:50,823", "levelname": "DEBUG", "name": "django.utils.autoreload", "message": "File C:\\Users\\moon\\miniforge3\\envs\\workout\\Lib\\site-packages\\PIL\\__init__.py first seen with mtime 1739352505.781736" }Django가 PIL (Pillow 라이브러리)의 __init__.py 파일을 감지하고, 이 파일의 mtime 값(1739352505.781736)을 처음 인식했다고 로그에 남겼습니다. 보기가 불편하시다면 자동 리로드 기능을 끄고 실행하는 방법도 있습니다.python manage.py runserver --noreload이렇게 하면 django.utils.autoreload가 동작하지 않으므로, 불필요한 리로드를 방지할 수 있습니다.

섹션2 ["환경 vs. 설정 vs. 구성"] 강의 자막 문의

안녕하세요 티읕이응님,예리하시네요 ㅎㅎㅎ 디자이너 님이 실수하신 것 같네요. 말씀하신 점이 맞습니다! 환경 / 구성 / 설정Environment / Configuration / Setting

시스템 디자인 2권이나 머신러닝에 대한 계획

안녕하세요 에반황님,좋은 질문 입니다. 아직까지는 계획에 없습니다. 제가 3권 다 보기는 했는데, 1권 이상은 특정한 산업에 있지 않는 이상 필요가 없어 보이더라구요. 하지만 필요한 자료가 있다 싶으면, 저희의 경험을 중심으로 다시 보충해보겠습니다.

파이썬 data insert to table

안녕하세요 hunter님,현재 코드에서는 executemany()를 사용해 Hive 테이블에 한 줄씩 데이터를 삽입하고 있습니다. 한 줄씩 삽입하는 방식(INSERT INTO VALUES)은 비효율적이며, 파일 단위로 한 번에 적재하는 것이 훨씬 빠릅니다. executemany() 대신 데이터를 CSV 또는 Parquet 파일로 저장한 후, Hive에 로드하는 방식이 더 적절합니다. 그리고 Google Sheets 데이터를 CSV로 변환하여 로드하는 것이 훨씬 빠를 수 있습니다 - get_all_values()는 전체 데이터를 한 번에 가져오므로 데이터가 많을 경우 속도가 느려집니다. 흠... 마지막으로 df.loc[i]를 사용한 반복문은 매우 비효율적이며, 성능을 크게 저하시킵니다. itertuples()을 사용하면 속도가 훨씬 빨라집니다.data = [ (row.a, row.b, row.v, row.d, row.e, row.f, row.g, row.h, row.i) for row in df_hc_list.itertuples(index=False) ]근데, 제가 하이브를 여기서 가르쳐드렸나요? 기억이...