이 글이 2014년 것이라는 게 가장 슬픈 점임
지금은 Airflow, dbt, Snowflake 같은 더 많은 추상화 계층이 생겨서, 사실상 RAM에 다 들어가는 데이터셋에도 이런 걸 덧씌우는 상황임
스타트업들이 하루 10GB도 안 되는 로그를 처리하려고 분산 클러스터에 월 5천 달러를 태움. 이유는 ‘Modern Data Stack’을 쓰면 승진이 되지만, bash 스크립트로 해결하면 ‘비확장적’이라며 무시당하기 때문임. 효율성과 인센티브가 완전히 어긋나 있음
최근 면접에서 ‘스케일링 문제’라며 이야기하지만, 실제로는 한 대의 머신에 충분히 들어가는 경우가 많았음
하루 1GB의 JSON을 ingest하는 사례도 있었는데, 내가 “한 대로 충분하다”고 설명했더니 “기술적으로 맞지만 우리가 원하는 답이 아니다”라며 탈락시킴
요즘 머신은 TB 단위 RAM과 수백 개의 코어를 갖고 있음. 한 대의 머신이 이미 어마어마하게 큼
이건 단지 승진뿐 아니라 채용 구조의 문제이기도 함
DevOps 경력자를 뽑을 때 화려한 프레임워크 경험을 강조하니, 결국 그들이 회사에 와서도 똑같은 걸 반복함
아무도 반대하지 않으니, 결국 데스크탑 한 대로 충분한 일을 복잡하게 만들어버림
지난 20년간 ‘멋져 보이는 기술’ 대신 ‘맞는 기술’을 써왔는데, 결국 해고당했음 최신 프레임워크가 거의 없는 이력서로 1년 넘게 구직 중이라 스스로 바보 같다는 생각이 듦
회사에서도 비슷한 걸 봄. 하루 몇 GB의 데이터를 여러 시스템으로 돌리느라, 예전엔 파이썬 스크립트로 일주일 만에 끝내던 걸 이제는 몇 달씩 걸리고 자주 깨짐
요즘은 128GB RAM 노트북도 흔하고, 서버는 훨씬 더 큼
2014년엔 4GB가 일반적이었지만 지금은 SSD 스트리밍 속도도 빨라서, 로컬 SSD에서 읽는 게 클러스터보다 나을 때도 많음
글쓴이임!
예전 글이 여전히 도움이 된다니 기쁨임
상황이 더 나빠졌다는 의견에 동의하지만, 한편으로는 microservices 맹신에서 벗어나는 움직임도 보여서 다행임
성능 개선을 위해 노력하는 모든 분들께 응원 보냄. 아직 희망이 있음
Adam, 고마움!
글을 여러 번 다시 읽었고, 영감을 받아 Waters-Series를 JavaScript로 포팅해서 스트림 파이프라이닝을 구현했음
요즘 업계는 Spark나 분산 툴이 데이터 엔지니어링의 정답이라는 인식이 너무 강함
웹 개발에서 SPA 프레임워크를 과하게 쓰는 현상과 비슷함
내 조언은 이러함:
매니저는 특정 기술(Spark, React)을 요구하지 말고, 문제 해결 능력 있는 엔지니어에게 맡길 것
기술 리드는 “우리 파이프라인은 20GB까지 처리 가능하고, 더 커지면 X/Y/Z로 확장할 계획”이라고 솔직히 말할 것
매니저가 듣고 싶은 건 ‘모든 게 무한 확장된다’가 아니라 ‘안정적으로 돌아간다’는 확신임
대부분의 회사는 소규모 데이터를 다룸
데이터 크기는 멱법칙을 따르기 때문에, 페타바이트급 데이터를 다루는 엔지니어는 극소수임
하지만 연봉 상승을 위해 그런 경험을 이력서에 넣으려다 보니 과도한 엔지니어링이 생김
예전에 유명 유니콘에서 일할 때, 매니저가 “다음 분기에 Spark를 써야 한다”고 했음
이유를 물었더니 “그냥 써야 한다”였음. 아마도 이력서용 혹은 누군가의 정치적 이유였던 듯함
글과 관련된 역사 이야기임 mrjob이라는 툴은 Hadoop 없이 로컬 모드로도 실행 가능했음
작은 데이터셋에서는 클러스터보다 훨씬 빠름. 특히 AWS EMR 같은 임시 클러스터보다도 빠르게 끝남
하지만 저자의 접근법이 그보다도 더 효율적이었을 것 같음
MapReduce는 대규모 확장을 쉽게 해주는 대신, 작은 데이터에는 비효율적인 제약이 많았음
2010년대 초반엔 mrjob으로 페타바이트급 데이터를 처리했지만, 지금은 거의 쓰이지 않음
데이터 엔지니어로 일할 때, Bash/Python 스크립트를 C#으로 다시 써서 JSON 처리 속도를 1GB/s까지 끌어올렸음
단순히 스트리밍 파싱 같은 최적화만으로도 큰 차이를 냈음
그래서 궁금함 — 도대체 어느 정도 데이터부터 클러스터링이 진짜 의미가 있을까?
반대로 15년 전엔 복잡한 C# 시스템을 bash + Python으로 바꿔서 훨씬 빨라졌던 적도 있음
내 기준으로는 하루 이상 걸리는 작업이면 분산 처리를 고려할 만함
예전에 PyCon 패널에서 유명 데이터 과학자가 “Excel이 Pandas보다 낫다”고 말했음
데이터가 크면 샘플링해서 Excel로 분석했다고 함. 요즘은 LLM 덕분에 간단한 Python/Bash 스크립트도 쉽게 작성 가능함
처리 시간 외에도, 로컬 디스크에 안 들어가는 데이터가 또 다른 기준임
S3 같은 오브젝트 스토리지에서 직접 읽고 쓰는 게 가능하고, 요즘은 100GB/s 속도도 가능함
이 댓글에 나온 체스 데이터셋은 약 14TB임
디스크엔 들어가지만 일반 노트북엔 불가능한 크기임
JSON을 스트리밍으로 파싱하는 방법이 궁금함. 대부분의 파서는 전체를 읽어야 문법 검증이 가능한데, 이걸 어떻게 해결했는지 알고 싶음
데이터의 ‘크기’는 무엇을 하느냐에 따라 달라짐
예를 들어 수술 데이터에서 단순 통계는 bash로 충분하지만, 의사 경험과 성공률의 상관관계를 계산하려면 복잡도가 급격히 증가함
그래서 기업 입장에서는 “우린 Spark를 쓴다”고 말하는 게 “질문마다 맞춤 엔진을 만든다”고 말하는 것보다 훨씬 쉬움
하지만 SQLite만으로도 50GB~2TB 데이터를 처리할 수 있음
언급된 모든 문제를 단일 서버에서 간단한 도구로 해결 가능함
Hacker News 의견들
이 글이 2014년 것이라는 게 가장 슬픈 점임
지금은 Airflow, dbt, Snowflake 같은 더 많은 추상화 계층이 생겨서, 사실상 RAM에 다 들어가는 데이터셋에도 이런 걸 덧씌우는 상황임
스타트업들이 하루 10GB도 안 되는 로그를 처리하려고 분산 클러스터에 월 5천 달러를 태움. 이유는 ‘Modern Data Stack’을 쓰면 승진이 되지만, bash 스크립트로 해결하면 ‘비확장적’이라며 무시당하기 때문임. 효율성과 인센티브가 완전히 어긋나 있음
하루 1GB의 JSON을 ingest하는 사례도 있었는데, 내가 “한 대로 충분하다”고 설명했더니 “기술적으로 맞지만 우리가 원하는 답이 아니다”라며 탈락시킴
요즘 머신은 TB 단위 RAM과 수백 개의 코어를 갖고 있음. 한 대의 머신이 이미 어마어마하게 큼
DevOps 경력자를 뽑을 때 화려한 프레임워크 경험을 강조하니, 결국 그들이 회사에 와서도 똑같은 걸 반복함
아무도 반대하지 않으니, 결국 데스크탑 한 대로 충분한 일을 복잡하게 만들어버림
최신 프레임워크가 거의 없는 이력서로 1년 넘게 구직 중이라 스스로 바보 같다는 생각이 듦
2014년엔 4GB가 일반적이었지만 지금은 SSD 스트리밍 속도도 빨라서, 로컬 SSD에서 읽는 게 클러스터보다 나을 때도 많음
글쓴이임!
예전 글이 여전히 도움이 된다니 기쁨임
상황이 더 나빠졌다는 의견에 동의하지만, 한편으로는 microservices 맹신에서 벗어나는 움직임도 보여서 다행임
성능 개선을 위해 노력하는 모든 분들께 응원 보냄. 아직 희망이 있음
글을 여러 번 다시 읽었고, 영감을 받아 Waters-Series를 JavaScript로 포팅해서 스트림 파이프라이닝을 구현했음
요즘 업계는 Spark나 분산 툴이 데이터 엔지니어링의 정답이라는 인식이 너무 강함
웹 개발에서 SPA 프레임워크를 과하게 쓰는 현상과 비슷함
내 조언은 이러함:
매니저가 듣고 싶은 건 ‘모든 게 무한 확장된다’가 아니라 ‘안정적으로 돌아간다’는 확신임
데이터 크기는 멱법칙을 따르기 때문에, 페타바이트급 데이터를 다루는 엔지니어는 극소수임
하지만 연봉 상승을 위해 그런 경험을 이력서에 넣으려다 보니 과도한 엔지니어링이 생김
이유를 물었더니 “그냥 써야 한다”였음. 아마도 이력서용 혹은 누군가의 정치적 이유였던 듯함
글과 관련된 역사 이야기임
mrjob이라는 툴은 Hadoop 없이 로컬 모드로도 실행 가능했음
작은 데이터셋에서는 클러스터보다 훨씬 빠름. 특히 AWS EMR 같은 임시 클러스터보다도 빠르게 끝남
하지만 저자의 접근법이 그보다도 더 효율적이었을 것 같음
MapReduce는 대규모 확장을 쉽게 해주는 대신, 작은 데이터에는 비효율적인 제약이 많았음
2010년대 초반엔 mrjob으로 페타바이트급 데이터를 처리했지만, 지금은 거의 쓰이지 않음
데이터 엔지니어로 일할 때, Bash/Python 스크립트를 C#으로 다시 써서 JSON 처리 속도를 1GB/s까지 끌어올렸음
단순히 스트리밍 파싱 같은 최적화만으로도 큰 차이를 냈음
그래서 궁금함 — 도대체 어느 정도 데이터부터 클러스터링이 진짜 의미가 있을까?
내 기준으로는 하루 이상 걸리는 작업이면 분산 처리를 고려할 만함
데이터가 크면 샘플링해서 Excel로 분석했다고 함. 요즘은 LLM 덕분에 간단한 Python/Bash 스크립트도 쉽게 작성 가능함
S3 같은 오브젝트 스토리지에서 직접 읽고 쓰는 게 가능하고, 요즘은 100GB/s 속도도 가능함
디스크엔 들어가지만 일반 노트북엔 불가능한 크기임
데이터의 ‘크기’는 무엇을 하느냐에 따라 달라짐
예를 들어 수술 데이터에서 단순 통계는 bash로 충분하지만, 의사 경험과 성공률의 상관관계를 계산하려면 복잡도가 급격히 증가함
그래서 기업 입장에서는 “우린 Spark를 쓴다”고 말하는 게 “질문마다 맞춤 엔진을 만든다”고 말하는 것보다 훨씬 쉬움
언급된 모든 문제를 단일 서버에서 간단한 도구로 해결 가능함
이 글은 예전에 여러 번 HN에 올라왔음
2018년 버전, 2022년 버전, 2024년 버전 모두 같은 제출자가 올렸음
예전 Shakti 웹사이트의 소개 문구가 떠오름
“1K 행: Excel / 1M 행: Pandas / 1B 행: Shakti / 1T 행: Only Shakti”
출처
많은 개발자가 Windows 환경에서 배워서 CLI 도구에 익숙하지 않음
하지만 CLI는 암묵적 루프, 필드 자동 분리, 정규식 병렬 적용 등 강력한 기능을 제공함
덕분에 빠르게 ad-hoc 솔루션을 만들 수 있고, 대규모 시스템을 쓰기 전의 좋은 출발점이 됨
체스 데이터를 더 크게 확장해 벤치마크를 다시 해보면 어떨까 생각함
요즘 Lichess 데이터셋은 약 7B 게임, 2.34TB 압축(14TB 비압축)임
이런 규모에서 Hadoop이 이길 수 있을까 궁금함
다만 그만큼 전용 서버 관리가 필요함
EMR은 데이터 접근 빈도가 낮을 때(하루 1~10회) 병렬 처리를 위해 설계된 모델임