▲

명령줄 도구가 Hadoop 클러스터보다 235배 빠를 수 있다 (2014)

 (adamdrake.com)
8P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • 약 1.75GB의 체스 경기 데이터를 Hadoop 대신 명령줄 도구로 처리한 결과, 12초 만에 완료되어 Hadoop의 26분 대비 235배 이상 빠른 성능을 보임
  • grep, sort, uniq, awk, xargs, mawk 등 기본 셸 명령을 조합해 스트리밍 처리 파이프라인을 구성, 메모리 사용을 거의 0으로 유지
  • xargs 병렬 처리와 mawk 최적화를 통해 CPU 코어 활용도를 높이고, IO 병목을 최소화함
  • 동일한 데이터셋을 Hadoop 클러스터(7대의 c1.medium 인스턴스)로 처리할 때보다 비용과 유지보수 부담이 현저히 낮음
  • 단일 머신에서도 효율적인 데이터 분석이 가능함을 보여주며, 불필요한 Big Data 도구 사용에 대한 경각심을 제시함

서론: Hadoop보다 빠른 명령줄 처리

  • 약 2백만 건의 체스 경기 데이터를 Amazon EMR과 mrjob으로 분석한 사례를 보고, 동일 데이터를 명령줄 기반 스트리밍 처리로 재현
    • Hadoop 클러스터(7대 c1.medium)에서 26분 소요, 1.14MB/sec 처리속도
    • 로컬 노트북에서는 12초 만에 완료, 270MB/sec 처리속도
  • 단순한 결과 집계 작업은 Hadoop보다 셸 파이프라인이 훨씬 효율적임을 입증
  • 셸 명령을 조합하면 Storm과 유사한 병렬 스트림 처리 구조를 단일 머신에서 구현 가능

데이터 구조와 준비

  • 데이터는 PGN(Portable Game Notation) 형식의 체스 경기 기록으로, 각 경기의 결과는 "Result" 라인에 표시됨
    • "1-0"은 백 승, "0-1"은 흑 승, "1/2-1/2"는 무승부
  • GitHub의 rozim/ChessData 저장소에서 약 3.46GB 데이터셋 확보
    • Tom Hayden의 실험 데이터(1.75GB)의 약 두 배 규모

기본 파이프라인 구축

  • IO 한계 측정을 위해 cat *.pgn > /dev/null 실행 시 약 13초(272MB/sec) 소요
  • 기본 분석 파이프라인: 
    cat *.pgn | grep "Result" | sort | uniq -c
    • 실행 시간 약 70초, Hadoop 대비 약 47배 빠름
  • sort | uniq 대신 AWK를 사용해 결과를 직접 집계
    • 실행 시간 65초, 메모리 사용 거의 없음
    • grep이 단일 CPU 코어를 점유하며 병목 발생

병렬화 및 최적화

  • xargs를 이용해 grep 병렬화 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
    • 실행 시간 38초, 약 77배 속도 향상
  • grep을 제거하고 AWK 단독 필터링으로 단계를 단순화
    • 각 파일별 결과를 통합하기 위해 이중 AWK 파이프라인 구성
    • 실행 시간 18초, 약 174배 빠름
  • mawk로 교체 시 추가 최적화 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
    • 실행 시간 12초, Hadoop 대비 235배 빠름, 처리속도 270MB/sec

결론: 단순함의 효율성

  • 대규모 분산 처리가 필요한 경우를 제외하면, 단일 머신의 셸 도구 조합이 더 빠르고 경제적
  • Hadoop은 종종 관계형 DB나 단순 스크립트로 충분한 작업에도 과도하게 사용되고 있음
  • 명령줄 기반 스트리밍 분석은 성능, 구현 비용, 유지보수성 측면에서 우수한 대안임
▲
dongho42 16시간전  [-]

예전에 타코벨 프로그래밍이란 말이 있었는데 비슷한 철학 같네요

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 이 글이 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 데이터를 처리할 수 있음
      언급된 모든 문제를 단일 서버에서 간단한 도구로 해결 가능함

  • 이 글은 예전에 여러 번 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이 이길 수 있을까 궁금함

    • 빠른 SSD 여러 개를 한 서버에 넣으면 여전히 EMR+S3보다 빠를 것 같음
      다만 그만큼 전용 서버 관리가 필요함
      EMR은 데이터 접근 빈도가 낮을 때(하루 1~10회) 병렬 처리를 위해 설계된 모델임
    • 압축된 데이터는 로컬 SSD에 충분히 들어가고, 스트리밍 압축 해제도 가능함
    • 이런 데이터로 뭘 계산할지 궁금함. NVL72에서 실험해보면 재미있을 듯함
답변달기