빅 데이터의 종말 (2023)

 (motherduck.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • BigQuery 초기 엔지니어 경험을 바탕으로 보면, 많은 조직의 병목은 데이터 크기보다 데이터 활용 방식과 비용 구조에 가까웠음
  • BigQuery 고객과 업계 피드백에서 대다수 데이터 웨어하우스는 1TB 미만이었고, 많이 쓰는 고객의 중앙값도 100GB보다 훨씬 작았음
  • 클라우드의 스토리지·컴퓨트 분리는 저장량을 크게 늘렸지만, 분석 컴퓨트 수요는 최근 데이터와 집계 중심이라 같은 비율로 커지지 않음
  • BigQuery에서 연간 1,000달러 이상 쓰는 고객 쿼리의 90%가 100MB 미만을 처리했고, 거대한 데이터셋을 가진 고객도 대형 쿼리를 자주 실행하지 않았음
  • 오래된 데이터는 규제, 소송, 의미 퇴색, 특수 처리 로직 때문에 부채가 될 수 있어 원본 보관보다 집계·삭제·요약이 나은지 점검해야 함

빅 데이터 공포와 실제 병목의 차이

  • 10년 넘게 데이터에서 실행 가능한 통찰을 얻기 어려운 이유가 데이터 크기 때문이라는 메시지가 반복돼 왔음
  • 대규모 확장을 처리할 새 기술을 사면 해결된다는 처방이 뒤따랐지만, 새 도구 구매와 레거시 시스템 이전 뒤에도 많은 조직은 여전히 데이터를 이해하는 데 어려움을 겪음
  • 2023년의 상황은 빅 데이터 경고가 시작되던 시기와 달라짐
    • 예측됐던 데이터 대격변은 오지 않았음
    • 데이터 크기는 다소 커졌지만, 하드웨어는 더 빠른 속도로 커짐
    • 벤더는 여전히 확장성을 내세우지만, 실무자는 그것이 현실 문제와 어떻게 연결되는지 의문을 갖기 시작함

BigQuery 경험에서 본 고객 데이터 규모

  • Google BigQuery 창립 엔지니어였던 필자는 공개 발표에서 1PB 쿼리를 실행하며 대규모 데이터 처리 능력을 시연했음
  • 이후 BigQuery 고객 문제를 디버깅하고, 책 2권을 공동 집필했으며, 2018년부터 제품 관리자로 고객 대화와 제품 지표 분석을 맡음
  • 가장 놀라운 관찰은 “BigQuery” 사용자 대부분이 실제로는 Big Data를 갖고 있지 않았다는 점임
    • 큰 데이터를 가진 고객도 전체 데이터셋의 작은 일부만 쓰는 워크로드가 많았음
    • BigQuery 출시 당시에는 빠른 처리 속도가 공상과학처럼 보였지만, 이후 더 전통적인 처리 방식도 따라잡음
  • 글의 그래프들은 정확한 수치가 아니라 기억에 기반한 손그림이며, 중요한 것은 정확한 값보다 분포의 형태임
  • 근거는 쿼리 로그, 거래 사후 분석, 벤치마크 결과, 고객 지원 티켓, 고객 대화, 서비스 로그, 공개 블로그 글, 직관에서 나옴

대부분의 조직은 그렇게 많은 데이터를 갖고 있지 않음

  • “Big Data가 온다”는 영업 슬라이드는 곧 모두가 데이터에 압도될 것이라는 메시지를 전달했지만, 10년 뒤에도 그런 미래는 실현되지 않았음
  • BigQuery 고객 규모를 보면 대다수 고객의 총 저장 데이터는 1TB 미만이었음
    • 수백 PB 데이터를 가진 고객도 있었지만, 크기는 빠르게 줄어드는 거듭제곱 법칙 분포를 따름
    • 스토리지 비용을 월 10달러 미만으로 내는 고객이 수천 명 있었고, 이는 약 0.5TB에 해당함
    • 서비스를 많이 사용하는 고객 중에서도 중앙값 저장량은 100GB보다 훨씬 작았음
  • Gartner, Forrester 같은 업계 애널리스트와의 대화에서도 대다수 기업 데이터 웨어하우스는 1TB보다 작다는 피드백을 받음
    • 업계 감각상 데이터 웨어하우스의 적절한 규모는 100GB 정도였음
    • BigQuery 팀은 이 규모를 벤치마크 노력의 주요 초점으로 삼음
  • 한 투자자가 포트폴리오 회사를 조사한 결과, 데이터 크기가 상대적으로 클 가능성이 높은 기술 기업에서도 가장 큰 B2B 회사는 약 1TB, 가장 큰 B2C 회사는 약 10TB였고 대부분은 훨씬 작았음
  • 중간 규모 사업체 예시에서도 데이터가 쉽게 거대해지지 않음
    • 고객 1,000명이 매일 주문 1건과 100개 라인 아이템을 만든다고 해도 하루 데이터는 1MB 미만 수준이며, 3년 뒤에도 1GB 정도임
    • 마케팅 DB에 리드 100만 개와 수십 개 캠페인이 있어도 리드 테이블은 1GB 미만이고, 캠페인 추적도 몇 GB 수준일 가능성이 높음
    • SingleStore가 2020~2022년 빠르게 성장하던 Series E 유니콘 기업이었을 때도 재무 웨어하우스, 고객 데이터, 마케팅 캠페인 추적, 서비스 로그를 합쳐 몇 GB 정도였음

스토리지와 컴퓨트 분리가 만든 착시

  • 현대 클라우드 데이터 플랫폼은 모두 스토리지와 컴퓨트 분리를 채택해, 고객이 단일 폼팩터에 묶이지 않게 함
  • 이 변화는 지난 20년 데이터 아키텍처에서 스케일아웃보다 더 중요한 변화일 가능성이 큼
    • 관리가 어려운 shared-nothing 구조 대신 shared disk 구조는 스토리지와 컴퓨트를 독립적으로 키울 수 있게 함
    • S3와 GCS 같은 확장 가능하고 충분히 빠른 객체 스토리지는 데이터베이스 설계 제약을 완화함
  • 실제로는 데이터 크기가 컴퓨트 크기보다 훨씬 빠르게 늘어남
    • 데이터는 시간에 따라 생성되며, 정적인 사업에서도 저장량은 시간에 따라 선형 증가함
    • 분석은 대체로 최근 데이터를 대상으로 하므로 컴퓨트 수요는 저장량처럼 커질 필요가 적음
    • 오래된 데이터는 변하지 않기 때문에 계속 스캔하는 것은 낭비에 가깝고, 중요한 답은 집계로 만들 수 있음
  • 온프레미스에서 스토리지·컴퓨트 분리가 있는 클라우드로 옮긴 고객은 저장량이 크게 늘어도 컴퓨트 수요는 크게 변하지 않는 경우가 많았음
    • BigQuery의 한 대형 리테일 고객은 온프레미스 데이터 웨어하우스가 약 100TB였지만 클라우드 이전 뒤 30PB로 늘어남
    • 저장량은 300배 늘었지만 컴퓨트 비용이 같은 비율로 늘지는 않았고, 분석에 수십억 달러를 쓰지 않았음
  • 이 구조는 확장 가능한 객체 스토어를 쓰면 예상보다 훨씬 적은 컴퓨트로 충분할 수 있고, 분산 처리가 필요 없을 수도 있음을 보여줌

실제 쿼리 워크로드는 전체 데이터보다 훨씬 작음

  • 분석 워크로드가 처리하는 데이터량은 직관보다 작을 가능성이 큼
    • 대시보드는 집계 데이터로 만들어지는 경우가 많음
    • 사용자는 최근 1시간, 하루, 일주일 데이터를 주로 봄
    • 작은 테이블은 더 자주 쿼리되고, 거대한 테이블은 더 선택적으로 쿼리됨
  • BigQuery에서 연간 1,000달러 이상 쓰는 고객의 쿼리를 분석했을 때 90%의 쿼리가 100MB 미만을 처리함
    • 특정 고객의 쿼리량이 결과를 왜곡하지 않도록 여러 방식으로 나눠 분석함
    • 데이터를 읽지 않는 메타데이터 전용 쿼리는 제외됨
    • GB 범위 쿼리는 높은 백분위로 올라가야 나타났고, TB 범위 쿼리는 매우 드물었음
  • 거대한 데이터 크기를 가진 고객도 거대한 데이터를 거의 쿼리하지 않았음
    • 큰 쿼리를 실행할 때는 주로 보고서 생성 목적이었고, 성능은 우선순위가 아니었음
    • 한 대형 소셜 미디어 회사는 월요일 임원 보고를 위해 주말에 매우 큰 쿼리를 실행했지만, 이는 주중 수십만 개 쿼리 중 극히 일부였음
  • 최신 분석 데이터베이스는 실제 읽는 데이터를 줄이는 여러 기법을 사용함
    • 컬럼 프로젝션으로 필요한 필드만 읽음
    • 파티션 프루닝으로 좁은 날짜 범위만 읽음
    • 클러스터링이나 자동 마이크로 파티셔닝을 통한 세그먼트 제거로 데이터 지역성을 활용함
    • 압축 데이터 위 계산, 프로젝션, 프레디케이트 푸시다운도 쿼리 시점의 I/O를 줄임
  • I/O 감소는 필요한 계산량을 줄이고, 비용과 지연시간을 낮춤

데이터 처리 비용은 작게 쿼리하도록 압박함

  • 스케일아웃으로 빠르게 처리할 수 있다는 사실이 저렴한 처리를 뜻하지는 않음
  • 1,000개 노드를 써서 결과를 얻는다면 비용이 매우 커질 수 있음
  • BigQuery 시연에서 실행하던 1PB 쿼리는 소매가 기준 5,000달러였음
  • 이런 비효율은 PB 규모로 운영하지 않는 팀에게 부담이 되는 big data tax의 일부임
  • 데이터 처리량을 줄이려는 금전적 유인은 바이트 스캔 과금 모델이 아니어도 적용됨

대부분의 데이터는 거의 쿼리되지 않음

  • 처리되는 데이터의 큰 비율은 24시간 미만의 최신 데이터임
  • 데이터가 1주일쯤 지나면 가장 최근 하루 데이터보다 쿼리될 가능성이 약 20배 낮아짐
  • 한 달이 지나면 데이터는 대체로 그대로 남아 있고, 드문 보고서 실행 때나 쿼리됨
  • 저장 데이터의 연령 분포는 접근 패턴보다 훨씬 완만함
    • 많은 데이터가 빨리 버려지기도 하지만, 많은 데이터는 테이블 끝에 계속 추가됨
    • 최근 1년 데이터가 전체 데이터의 30%뿐이어도 데이터 접근의 99%를 차지할 수 있음
    • 최근 1개월 데이터가 전체 데이터의 5%뿐이어도 데이터 접근의 80%를 차지할 수 있음
  • 데이터가 시간이 지나며 잠잠해지면 실제 작업 집합은 예상보다 관리 가능한 크기가 됨
    • 10년치 1PB 테이블이 있어도 실제로 자주 접근하는 것은 당일 데이터뿐일 수 있음
    • 당일 데이터는 압축 기준 50GB 미만일 수 있음

단일 머신의 경계는 계속 밀려남

  • Big Data를 “단일 머신에 들어가지 않는 것”으로 정의하면, 해당되는 워크로드 수는 매년 줄어들고 있음
  • 2004년 Google MapReduce 논문이 쓰였을 때는 일반적인 데이터 워크로드가 단일 범용 머신에 들어가지 않는 일이 흔했음
  • 2006년 AWS가 EC2를 출시했을 때 제공 인스턴스는 단일 코어와 2GB RAM뿐이었고, 많은 워크로드가 이 머신에 맞지 않았음
  • 현재 AWS의 표준 인스턴스는 물리 서버 기준 64코어와 256GB RAM을 사용함
    • 2006년 EC2 초기 인스턴스보다 RAM이 두 자릿수 배수로 커짐
    • 메모리 최적화 인스턴스에 더 지불하면 RAM을 추가로 두 자릿수 배수까지 키울 수 있음
    • 24TB RAM이나 445 CPU 코어보다 더 필요한 워크로드가 얼마나 되는지 질문하게 됨
  • 클라우드에서는 큰 VM의 비용이 컴퓨트 파워에 따라 선형에 가깝게 증가함
    • 서버 전체를 쓰는 VM은 서버의 1/8을 쓰는 VM보다 8배 비쌀 뿐임
    • 원래 Dremel 논문의 3,000개 병렬 노드 벤치마크와 비슷한 성능을 오늘날 단일 노드에서 얻을 수 있다고 봄

데이터는 자산이 아니라 부채가 될 수 있음

  • Big Data의 또 다른 정의는 “무엇을 버릴지 판단하는 비용보다 데이터를 계속 보관하는 비용이 더 낮은 상태”임
  • 많은 조직의 데이터 레이크는 필요해서가 아니라 지우지 않았기 때문에 커진 거대한 늪에 가까움
    • 무엇이 들어 있는지 모름
    • 정리해도 안전한지 모름
  • 데이터 보관 비용은 물리적 바이트 저장 비용보다 큼
    • GDPR, CCPA 같은 규제에서는 특정 데이터 사용을 추적해야 함
    • 일부 데이터는 일정 기간 안에 삭제해야 함
    • 데이터 레이크의 parquet 파일에 전화번호가 너무 오래 남아 있으면 법적 요구사항을 위반할 수 있음
  • 오래된 데이터는 소송에서도 조직에 불리하게 쓰일 수 있음
    • 많은 조직이 잠재 책임을 줄이기 위해 이메일 보관 기간을 제한하듯, 데이터 웨어하우스의 데이터도 불리한 증거가 될 수 있음
    • 5년 전 로그가 코드의 보안 버그나 SLA 미달을 보여준다면 오래 보관할수록 법적 노출이 길어질 수 있음
  • 데이터도 코드의 bit rot처럼 의미가 퇴색할 수 있음
    • 특수 필드의 정확한 의미를 사람들이 잊을 수 있음
    • 과거의 데이터 버그가 기억에서 사라질 수 있음
    • 예를 들어 짧은 기간 모든 customer id가 null로 설정됐거나, 거대한 사기 거래가 2017년 3분기 실적을 실제보다 좋게 보이게 했을 수 있음
    • 오래된 기간의 데이터를 꺼내는 비즈니스 로직은 “2019년 이전은 revenue, 2019~2021년은 revenue_usd, 2022년 이후는 revenue_usd_audited”처럼 점점 복잡해질 수 있음

Big Data 1%인지 점검하기

  • Big Data는 실제로 존재하지만, 대부분의 사람은 걱정할 필요가 없을 수 있음
  • 자신이 Big Data One-Percenter인지 판단하려면 다음 질문을 던질 수 있음
    • 정말 엄청난 양의 데이터를 생성하는가
    • 그렇다면 정말 한 번에 엄청난 양의 데이터를 써야 하는가
    • 그렇다면 정말 단일 머신에 들어가지 않을 만큼 큰가
    • 그렇다면 단순히 데이터를 쌓아두는 사람은 아닌가
    • 그렇다면 요약하는 편이 더 낫지 않은가
  • 이 질문 중 하나라도 “아니오”라면, 실제 보유한 데이터 크기에 맞는 새 세대의 데이터 도구 후보가 될 수 있음
  • 관련 예시로 현대적 BigQuery 대안이 언급됨
  • 조직은 언젠가 가질지도 모르는 데이터 크기에 겁먹기보다, 실제로 가진 데이터 크기와 실제 쿼리 패턴에 맞춰 도구와 보관 정책을 선택해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 예전 직장에서 데이터 과학자를 뽑을 때 즐겨 쓰던 함정 질문이 “최대 6TiB 데이터가 있다는 요구사항이면 어떤 스택/아키텍처를 만들겠느냐”였음
    BigQuery, Hadoop 같은 거창한 얘기를 들으며 하드웨어/소프트웨어/라이선스 비용까지 물어보면 연 수만 달러 견적이 나오곤 했음
    결국 합격자는 6TiB가 방 안의 6명이 스마트폰에 나눠 담을 수 있는 양이고, 199달러짜리 기업용 HDD 하나나 중복성을 위해 세 개면 충분하며, CSV로 메모리에 여러 번 올려 awk 스크립트로도 처리 가능하다는 걸 이해한 사람이었음
    나도 망치를 배우면 모든 게 못처럼 보이는 오류에 빠지기 쉽지만, 채용에서 “진짜 빅데이터”의 규모 감각을 모르는 건 탈락 사유였음

    • 채용 면접이라는 상황 자체가 답변에 영향을 줬을 수 있음. 지원자는 기술 면접을 통과하는 중이니 면접관이 기술 스택 이해도를 보려 한다고 기대하게 됨
      그런 답만으로 모든 일을 과도하게 설계한다고 결론 내리기보다는, 면접관이 우위에 있는 인위적인 상황에서 함정 질문에 걸렸다고 보는 편이 맞음
      최근 비슷한 연차와 경험의 면접관과 기술 면접을 봤는데 답을 망쳤고, 면접관은 내 나쁜 답변에 판단적인 태도를 보였음. 역할이 바뀌었다면 내가 더 잘 아는 주제로 그를 똑같이 곤란하게 만들 수 있었을 것임
      면접관이라면 우월한 위치를 남용하지 않도록 특히 조심해야 함. 회사에도 역효과이고, 앞에 있는 사람에게도 좋은 일이 아님
    • https://x.com/garybernhardt/status/600783770925420546 Gary Bernhardt의 2015년 글:
      “컨설팅 서비스: 당신이 빅데이터 문제를 가져오면, 내가 ‘당신 데이터셋은 RAM에 들어갑니다’라고 말하고, 당신은 50만 달러를 아낀 대가로 내게 1만 달러를 냅니다”
    • 어떤 사람들은 자기 데이터가 진짜 빅데이터가 아니라고 말하면 꽤 불쾌해함
      몇 년 전 어떤 이사가 Hadoop, API 게이트웨이, 여러 개발자, 연 수십만 달러 비용으로 IT가 만든 시스템을 보여줬는데, 현재 규모와 예측 가능한 미래 규모라면 그의 노트북에 꽂은 USB 드라이브와 Python 스크립트 몇 개로도 충분히 돌릴 수 있다고 말했더니 매우 짜증스러워했고, 그 뒤로 그 프로젝트에 다시는 관여하지 못했음
      회사에 만연한 허세 순환의 일부라고 봄. “우리가 단순한 일을 하고 있다”고 인정할 수 없는 구조임
    • 수직 확장 해법은 이해하지만, 솔직히 거의 모든 사용 사례에는 잘못된 해법임. 데이터 소비자는 awk를 원하지 않고, 원한다 해도 파티셔닝이나 열 지향 저장 없이 6TB를 매 쿼리마다 단일 CPU로 훑는 건 항상 느림
      이런 용도에는 보통 BigQuery가 괜찮았음. 콘솔 인터페이스가 임시 분석에 충분하고 Metabase, Tableau 같은 도구도 많이 연결할 수 있음
      올바르게 파티셔닝하면 비용도 과하지 않고, 문제가 되면 롤업 테이블을 추가하면 됨
    • .parquet 파일은 완전히 과소평가되어 있고, 아직도 이 형식을 모르는 사람이 많음
      CSV와 달리 데이터 타입을 보존하고, CSV보다 10배 작아서 6TB가 600GB가 되며, 읽기는 50배 빠름. Apache Foundation의 공개 표준이기도 함
      CSV처럼 쉽게 들여다볼 수는 없지만 그만한 절충은 가치 있음. CSV를 다운로드로 제공하는 곳이라면 어디든 .parquet도 함께 제공했으면 함

  • 전체적으로 글의 많은 부분에 동의하지만 몇 가지 단서가 있음. 첫째, MongoDB는 기준점으로 부적절함. MongoDB가 하는 일 중 PostgreSQL이 더 잘하지 못하는 걸 본 적이 없고, 빅데이터 해법은 NoSQL/MongoDB가 아니라 보통 열 지향 데이터베이스, 맵리듀스, Cassandra 같은 것임
    둘째, 성공을 계획해야 함. 기업의 95%는 유니콘이 되지 못하지만, 나머지 5%를 목표로 한다면 대비하지 않고는 도달할 수 없음. 고객이 5명일 때 확장성을 고려해 설계하는 이유는 지수 성장의 순간이 오면 붙잡기 위해서임
    다만 핵심 교훈은 맞음. 대부분의 데이터는 크지 않고, 전 세계 모든 사람에 대한 데이터도 100달러짜리 Chromebook에 들어갈 수 있음. 대부분 데이터는 드물게 조회되고 쿼리도 작으며, 빅데이터 작업의 첫 단계는 테라바이트를 실제 필요한 GB, MB, 때로는 KB 규모로 줄이는 일인 경우가 많음. 규제로 인해 데이터 비용도 커지고 있음

    • “성공을 계획하라”는 말은 어디서나 아키텍처 우주비행사들이 하는 말과 정확히 같음. 내 경험상 완전히 사실이 아니고, 오히려 생산성과 스타트업에 더 중요한 민첩성을 크게 떨어뜨리는 경우가 많음
      사람들은 계획만 세우지 않고 보통 구현까지 해버림. 다음 3개월을 계획하면 훨씬 민첩하고 생산적일 수 있음. 실행하지 못하면 유니콘이 될 수 없음
    • 갑자기 성공을 감당하느라 패닉에 빠지는 경우보다, 성공 대비를 너무 많이 해서 실패를 보장하는 경우를 훨씬 많이 봄
      두 번째 시스템 증후군과 생존자 편향의 조합 같음. 좋은 MVP의 난장판을 치운 사람들이 “예전에 이걸 했어야 했다”고 불평하지만, 실제로 미리 계획하고 설계했던 회사들은 살아남지 못해서 불평의 대상도 되지 않음
    • 사소한 지적이지만 8비트로는 사람마다 고유 정수 ID도 못 담음. 그건 사람당 8바이트가 필요하고, 그러면 이미 60GB 수준임
      나머지 내용에는 거의 다 동의하지만 이 부분은 틀려 보여서 그냥 넘길 수 없었음
    • “유니콘이 될 가능성을 만들려면 사업의 모든 부분을 지금과 나중을 위해 계획해야 한다”는 건 실제로는 역효과라고 봄
      스타트업의 활주로는 제한적이고, 엔지니어들이 몇 년 뒤에나 보상받을 일에 돈을 쓰고 있다면 그 시점이 오기 전에 실패할 확률을 높이는 것임
    • 고객이 5명일 때부터 확장성을 설계해야 지수 성장이 왔을 때 붙잡을 수 있다는 말에는 의문이 있음
      제품이 그렇게 강한 견인을 얻는 건 보통 사용자 기반의 존재와 필요에서 나온 복합 효과 때문임. 성장 중에 신규 사용자 추가에서 비틀거려도 이미 있는 사용자가 예전 제품으로 돌아가거나 다른 곳으로 갈 가능성은 낮음
      예전 Twitter는 매일 fail whale을 보는 게 일상이었지만 대부분 떠나지 않았고, 더 잘 확장되는 대안으로 대규모 이동이 일어나지도 않았음. 그런 지수 성장을 겪는 제품 자체가 드물고, 그 과정에서 확장에 고생하며 가용성이 나빠지는 건 흔함. 확장하지 못해서 실패한 지수 성장 제품이 실제로 무엇이 있었는지 궁금함

  • “빅데이터”가 유행하던 시절 Large Hadron Collider에서 연구자였음. 우리에게는 모든 데이터를 분석하는 게 의미 있는 사용 사례였고, 빈도주의 통계에서는 데이터가 많을수록 좋았음
    그런데 전 세계 슈퍼컴퓨터 네트워크를 쓰면서도, 거대한 작업이 끝나길 기다리는 것보다 빠른 로컬 저장소가 낫다는 걸 알게 됨. 결국 모든 대학원생이 분석 유연성을 크게 잃지 않으면서 관련 데이터를 정확히 1~5TB로 줄여냈음
    여기엔 Amdahl의 확장 법칙에 맞먹는 편의성의 법칙 같은 게 있는 듯함

    • 하나 만들어보자면 “1~5TB 데이터로 통계 분석을 못 한다면 방법론이 잘못됐다” 정도가 될 수 있음
      이건 수학보다는 인간의 한계에 가까워 보임. 우리가 활용할 수 있는 유연성에는 분명한 상한이 있음. 새로운 종류의 분석을 더 쉽게 실행할 방법이 생기면 바뀌겠지만, 하고 싶은 일의 수에 대해 로그처럼 증가할 듯함
    • 편의성의 법칙은 있다고 봄. 많은 기술이 일정한 지수 속도로 개선되는 이유도 설명해줌
      사람들은 매년 조금씩 더 낫게 만드는 편리한 방법을 찾는 데 매우 능하지만, 어떤 아이디어든 실행에는 최소 시간이 필요함
    • 80~90년대 NASA는 National Aerodynamic Simulator를 만들었는데, Cray 같은 대형 장비로 유한요소해석 시뮬레이션을 돌리던 시스템이었음. 지금 기준으로는 저가 그래픽카드 수준일지도 모름
      기억이 맞다면 그 장비의 대기열이 저렴한 하드웨어에서 작업을 돌리는 시간만큼 길거나 더 길었고, Beowulf 같은 대규모 병렬 처리 시스템이 그런 노력에서 나왔음
    • 편의성의 법칙이 정확하다고 봄. 상용 시스템 개발자들과 이야기해보면, 고객들은 항상 시스템을 최대한 싸게 만들라고 압박함
      저장하는 데이터베이스와 계산 크기를 줄이는 건 고객의 월 청구액을 최소화하는 훌륭한 방법임

  • 내 경험상 데이터는 지수적으로 계속 커지지만, 정보량은 그렇게 늘지 않음
    금융에서는 원하면 시계열 하나당 하루 1억 개 데이터 포인트를 쉽게 얻을 수 있고, 수천 개 시계열을 다룰 수도 있음. 하지만 그 표본 속도와 시계열 수는 대개 99.99% 중복임. 고유값이 대략 10차원 이후, 때로는 훨씬 더 이른 지점에서 거의 0으로 떨어지기 때문임
    절대 조회하지 않을 틱 데이터를 페타바이트 단위로 저장할 이유는 거의 없음. 많은 경우 수집 시점에 과감하고 손실 있는 차원 축소를 하고, 첫 몇 개 주성분과 이상치만 저장하며, 이전에는 무시할 만했던 새 요인이 중요해지는지 고유값 안정성을 감시하는 편이 훨씬 합리적임
    결과적으로 데이터셋이 훨씬 작아지고 다루기 쉬워지며, 실제로 쓸 수 있기 때문에 오히려 통찰을 주는 경우가 많음

    • 흥미로운데, 시간이 지나면서 고유벡터가 바뀌면 어떻게 처리하는지 궁금함
    • 고유값과 차원 얘기를 설명하는 자료를 알려줄 수 있으면 좋겠음
      흥미롭게 들리지만 내게는 완전히 새로운 주제임

  • “빅데이터”의 웃긴 점은 소프트웨어 수준에서 가장 기본적이고 명백한 최적화조차 피하게 만드는 비뚤어진 유인이 있었다는 것임. 하드웨어 요구사항이 커야 자신이 얼마나 대단한지 증명할 수 있었기 때문임
    예를 들면 “보스, 전체 데이터셋을 다 계산하는 대신 표본을 읽으면 이 보고서의 평균들을 노트북만으로 계산할 수 있습니다”라고 하면, 보스는 “표본이 무슨 뜻이지? 그 수학자/엔지니어 같은 잡소리로 뭘 암시하려는 건가? 내가 수백만 달러를 헛썼다는 뜻은 아니겠지?”라고 받아들이는 식임

    • 그 유행에는 Google 출신들이 스톡옵션을 현금화하던 흐름도 있었음
      빅데이터에 대한 영업 과장과 잡음, 그리고 누구의 데이터가 충분히 큰지를 겨루는 허세 경쟁이 한동안 매우 심했음
    • 이건 꽤 비꼬는 외부자의 시각이고 실제로는 맞지 않음. 나는 커리어 초기에 데이터 엔지니어로 컴퓨팅 비용 절감을 시도했음
      오랫동안 한 머신에서 64GB를 넘는 메모리를 얻기가 매우 어려웠고, 하드 상한이 있으면 구현 복잡도는 빠르게 치솟음
      데이터가 조금만 커져서 50번 중 1번 실패하는 프로세스는 매우 파괴적임. 팀은 이런 정기 크론 작업을 수십 개씩 굴리고, 각각이 자주 깨지면 온콜로 조각을 잘라내는 일만 하게 됨
      Hadoop과 MapReduce가 극도로 효율적이진 않았지만, 제대로 쓰면 괜찮았고 안정적으로 도는 게 훨씬 중요했음. 아무도 신뢰하거나 유지보수하지 못하고 매주 목요일 괴상한 세그멘테이션 오류로 죽는 비트 최적화 C++ 코드보다 낫다는 뜻임
      요즘이라면 그냥 Snowflake를 쓰겠지만, 당시에는 합리적인 도구였음

  • 이 글은 완전히 정확하진 않음. 원래 빅데이터는 세 가지 차원으로 정의됐음: 용량, 속도, 다양성
    용량은 대체로 해결됐고, 속도도 해결됐지만 비쌈. 다양성은 아직 해결되지 않았음
    오늘날 빅데이터는 “저장공간이나 컴퓨팅이 부족하다”가 아니라, “이걸 통합하고 이해할 인지 능력이 부족하다”에 가까움

    • 이 3V는 Michael Stonebraker 강연에서 처음 들었음. 그는 DBMS 분야의 전설이고 Turing Award 수상자임
      관련 강연들도 강력히 추천함. 대부분 YouTube에 있음
      [1] https://www.youtube.com/watch?v=KRcecxdGxvQ
      [2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
    • 여기서 “다양성”이 무슨 뜻인지 궁금함
    • 내게는 여전히 저장공간과 컴퓨팅이 부족함. 1년에 여섯 번, 2주씩 현장에 나가 데이터 수집을 하는데, 현장에서는 두 대의 항공기로 네 개 대역과 이중 편파의 합성개구레이더 수집을 함
      각 항공기에는 레이더 시스템 하나가 있고, 그 안에는 20TiB짜리 16드라이브 RAID-0 SSD 저장장치가 8개 있음. 보통 RAID를 꽉 채우지는 않아서 하루 약 176TiB, 2주 동안 7회 비행이면 배치당 1.2PiB, 연간 7.2PiB 정도 생성함
      비행 사이에 하루를 쉬어야 하는 이유는 앞치마 옆 격납고 구석에 대충 밀어 넣은 저장 서버로 광섬유를 통해 데이터를 내려받아야 하기 때문임. 이후 안전을 위해 두 번째 서버에 복제하고, 임무가 끝나면 전부 본부로 보내 저장·처리함
      이 데이터는 가치 있지만 “수십억 달러”급은 아님. 자원 추출, 지도 제작, 환경 및 측지 연구 등에 쓰이며, 2008년 이후 모든 바이트를 보관해왔음. 새 알고리즘이 나오면 옛 데이터를 새 표준으로 다시 처리할 수 있기 때문임
      파일은 800GiB~2TiB 단위로 GPU 처리 서버에 스트리밍하고, 압축이 안 됨. 포착하는 대부분인 우주 마이크로파 배경은 꽤 무작위적이기 때문임. 한때 테이프에 쓰면 인프라를 절반으로 줄일 수 있을 거라 착각했지만, 테이프 용량은 0으로만 된 기가바이트급 텍스트 파일을 저장할 때처럼 계산되는 듯했음
      GPU도 느리고 CPU도 느리고 PCIe 버스도 느리고 RAM도 느리고 내 타자 속도도 느림. 모든 게 항상 더 빨라져야 함
      모든 게 너무 느리고, 너무 어렵고, 너무 작음. 하드디스크는 너무 작고, Linux 커널 튜닝과 처리 클러스터로 가는 빠르고 안정적인 네트워크 설정은 너무 어려움. 단순 내부 동작 변경인 커널/패키지 업데이트도 우리만 겪는 방식으로 시스템을 깨뜨림
      기본 설정은 RAM이 희소하다는 환상 속에 있어서 네트워크 작업에 메모리를 아끼도록 되어 있음. 하지만 파일 서버에 RAM이 0.5TB 있으니 네트워크와 파일시스템을 빠르게 만들기 위해 전부 써줬으면 함. 결국 네트워크 스택 문서를 6시간 읽고 입출력을 2024년 수준의 상식으로 끌어올려야 함
      아마 지구상의 거의 모든 사람보다 sysctl.conf를 더 잘 알 것임
      자칭 빅데이터용 분산 영속 객체 저장소는 우리 작업부하에서 완전히 무너지거나 수억 달러가 듦. 객체 크기가 대략 1TB라고 말하면 분산 파일시스템 영업 담당자들이 답장을 멈춤. 어떤 벤더는 요구사항을 읽고 정보기관 고객 담당자에게 연결해주기도 했음. 나는 NSA가 아니고 NSA 예산도 없음
      가끔 Bloomberg에서 클라우드 기사를 읽은 MBA나 PMP가 온프레미스 데이터센터 비용을 보고 AWS나 Azure 이전을 묻는데, 돈과 시간 양쪽의 숫자를 보여주면 토할 듯한 표정을 짓고 주제를 바꿈
      게다가 벤더들은 모두 AI/클라우드 유행에 올라타서 우리에게 맞는 제품군을 단종하고 있음. 이제는 고객 데이터를 캐내 광고를 보여주려는 헤지펀드와 AI 스타트업들과 GPU를 두고 경쟁해야 함
      저장공간과 컴퓨팅이 부족하고, 가진 저장공간과 컴퓨팅도 너무 느림. DPU/IPU는 흥미롭지만 객체가 SQL 데이터베이스 쿼리나 압축 스트리밍 영상 조각보다 커지면 바로 한계에 부딪힘

  • 예전에 하루 20GB 분석 데이터를 만들던 회사에서 일했는데, 아마 내가 다룰 가장 큰 데이터였을 것임
    주니어 프로젝트로 배치와 실시간 집계를 하는 데이터 처리 작업을 작성하고, 결과를 Azure의 Parquet blob에 저장했음
    상사는 정기적으로 이해관계자 회의를 열어 무엇을 보관하고 버릴지 논의하게 할 만큼 똑똑했고, 좋은 알고리즘 덕분에 데이터를 하루 약 200MB로 압축할 수 있었음
    최근 2개월은 SQL Server에 올리고, 최근 2년은 더 집계해서 다른 서버에 넣었으며, 회사 전체가 Excel로 합리적인 시간 안에 쿼리했음. 원본 빅데이터는 언젠가 필요할 경우를 대비해 테이프 저장소에서 썩고 있음
    상사는 나쁜 관리자였지만 데이터를 잘 알았고, 돌이켜보니 많은 걸 제대로 했으며 나도 많이 배웠음

  • 여러 해 동안 “큰” 데이터 도구와 파이프라인의 과잉 엔지니어링을 봐왔음. 많은 사용 사례에서 데이터 웨어하우스와 데이터 레이크는 GB 또는 한 자릿수 TB 범위라서, 괜찮은 EC2 인스턴스에서 DuckDB를 돌리는 식으로 훨씬 단순화할 수 있음
    내 경험상 이렇게 하면 다른 시스템이 쿼리 실행을 시작하기도 전에 결과가 나옴. Athena를 보고 하는 말임
    요즘은 브라우저에서도 많은 쿼리를 돌릴 수 있다고 생각해서 DuckDB WASM(https://github.com/duckdb/duckdb-wasm)과 perspective.js(https://github.com/finos/perspective)의 도움으로 https://sql-workbench.com/를 만들었음

  • 그 유행 주기는 결국 “죽음의 고원”에 도달한 듯함. 유행에 극도로 휘둘리는 이 업계에서는 드물지 않은 결말임

    • 그냥 AI로 이름이 바뀐 것뿐임
      AI도 모든 데이터를 쓰고, 그 의미를 알아내기 위해 마법 같은 신경망을 붙임

  • 개인적으로 빅데이터의 주된 동력은 회사 창업자들의 자아였다고 봄. 당연히 우리 회사는 폭발적으로 성장해 지구 규모 성공을 거둘 테니, 규모에 맞게 설계해야 한다는 식임
    제품이 Series C에 도달하기 전까지 SQLite DB 하나면 충분한데도 이런 실수를 저지르는 건 비극적임. 모든 에너지는 아직 규모가 아니라 제품에 집중해야 함

    • 아님. 빅데이터는 실제로 큰 데이터 문제를 가진 사람들이 이끌었음
      Hadoop은 Google에 있던 것에서 영감을 받아 시작됐고, Oracle보다 저렴하고 나은 방식으로 데이터를 다루려는 전 세계 기업에서 인기를 얻었음
      Spark는 Hive/Pig 등의 복잡성에 대한 해법으로 나왔고, 회사들이 신뢰할 수 있는 데이터 파이프라인을 만들 수 있게 되자 그 위에 AI를 얹을 수 있게 됨
    • 다루는 데이터 종류에 따라 다름. 지리공간, 센싱, 원격측정 같은 중요한 데이터 모델은 “Hello, world” 단계에서도 페타바이트 규모에 도달할 수 있음
      링크 클릭, 메시지 전송, 구매처럼 의도적인 인간 행동에서 생성되는 데이터 모델은 보편적으로 작음. 인간 수와 인간이 초당 생성할 수 있는 의도적 사건 수에는 한계가 있기 때문임
      반면 기계가 생성하는 데이터 모델은 속도와 용량이 몇 자릿수 더 클 수 있고, 데이터 모델 크기에도 경계가 없음. 이런 데이터는 세상에 대한 많은 사실을 인간의 의도적 데이터 모델로는 얻을 수 없게 해주기 때문에 가장 흥미롭고 과소활용된 데이터인 경우가 많음
    • 대체로 맞지만, IoT나 GIS처럼 10TB 이상 데이터셋이 매우 흔한 예외도 있음
답변달기