빅데이터 소개와 하둡. 데이터 엔지니어링/데이터 분석의 분리

IT 분야에서 일하시지 않는 분의 입장에서는 빅데이터가 아니라도 어쨌든 데이터가 중요하다는 건 알겠는데 하둡은 뭐고 뭘 배워야 빅데이터의 무슨 기술을 어떻게 써먹을 수 있는지 모르겠다는 지적이 있었다.

양파씨는 친절하므로 기일게 설명할 수 있다. 설명하는 거 좋아한다. 너무 좋아해서 탈이다. 이 시간에 일을 좀 더 열심히 해야 하는 거 아닌가 하는 불안감이 있다 (...).

IT에 대해 잘 모르시는 분들을 위해서 비유를 들어서 쓰겠다고 말하고 싶지만 양파씨는 비유 쓰는 거 심히 좋아해서 지적 자주 받았다. 그래도 제가 좋아하니까 그냥 비유로 가겠습니다.

빅데이터 이전에는 구석시 시대였던 것처럼 자주 얘기하는데 웬만한 회사에서는 60년대 부터 데이터를 저장하고 처리하고 백업하고 보고서 만들고 했다. 회사 덩치가 조금만 커도 데이터 웨어하우스가 있었다. (지금도 있다. 빅데이터에 대해서 아무리 기사 많이 나고 한다지만 큰 회사 메인 데이터베이스는 오라클 등의 RDBMS가 99% 라는 데에 소정의 금액을 걸 수 있다.)

요식업에 비교하자면 기존 데이터 웨어하우스나 데이터베이스는 큰 냉장고로 생각하면 된다. 당신은 피자집을 운영하고, 그 피자집 부엌에서는 피자 베이스에 여러가지 토핑을 얹어서 파는데 빨리 만들 수 있도록 토핑을 종류별로 플라스틱 그릇에 넣어서 쭉 늘어놓는다. 매일 피자집 문 열기 전에 재료를 다듬어서 냉장고에 가지런히 정리해두고 요리 카운터 위 플라스틱 그릇에도 재료를 덜어서 쭉 늘어놓는다. 그리고 재료가 떨어지면 냉장고에서 다시 꺼내온다.

재료를 데이터라고 할 때, 그 재료를 다듬어서 냉장고에 넣는 과정을 ETL 이라고 한다. Extract, Transform, Load 의 약자인데, 필요한 자료를 뽑고 변형해서 로딩한다는 뜻이니까, 재료 다듬어서 필요없는 부분은 버리고 양념 더하거나 요리해서 냉장고에 넣는 과정이 ETL 이다.

그 중에서 금방 쓸 재료를 그릇에 담아서 손이 쉽게 닿는 곳에 놓는 것은, 자주 찾는 데이터를 메모리에 로딩해 두거나 좀 더 작은 테이블에 요약 정리 버전을 저장해두는 데에 비교 가능하다. 하드에서 읽는 것보다는 메모리에서 읽는 것이 훨씬 빠르고, 작은 요약 테이블을 만들어 놓으면 큰 테이블 찾기보다 쉽기 때문이다.

그러므로 기존 데이터 웨어하우스는, 들어오는 데이터를 ETL 로 처리해서 데이터베이스에 저장하고 (냉장고), 파워 유저들은 그 데이터를 가지고 보고서를 만들고 그래프를 만들고 한다. 여기서 저장하고 데이터를 준비해두는 부분까지가 데이터 웨어하우스이고, 파워유저들이 그 데이터로 보고서를 만들고 그래프를 만들고 하는 부분을 비즈니스 인텔리전스, BI 라고 보통 한다. 피자 만드는 사람이라고 할 수 있다. 그런데 피자 만들다 보니까 새로운 재료가 필요하다, 혹은 다른 방법으로 재료를 요리하는 것이 필요하다 하면 데이터 웨어하우스 팀한테 그 재료를 준비해 달라고 할 수 있겠다.

지난 30년 동안 사실 이 노하우는 거의 정형화 되어 있었다. 데이터가 들어오는 방법은 조금씩 다를지 모르고, 냉장고 브랜드가 다를 수 있으며, 부엌 구조나 일하는 방식은 조금씩 다를지 몰라도 냉장고 한 번 써본 사람이 다른 냉장고 쓰는 법을 특별히 배워야 되고 그런 건 아니잖소. SQL 할 줄 알면, 데이터베이스마다 조금씩 다르긴 해도 기본은 똑같다. 오라클이 유명했던 것은 전세계 유수 식당에 냉장고, 그러니까 데이터베이스를 왕창 팔아서이다.

자, 여기서 주의해야 할 것은, 사실 BI 는 빅데이터랑 큰 상관이 없다. BI 의 기술 개발 및 혁신은 '피자 만들기' 이지 '재료 공수법'이 아니어서 빅 데이터 기술 몰라도 할 수 있는 것들이다. 엄청 구하기 힘든 재료로 피자를 만든다고 하자. 중국에서 구한 백년 달걀과 알라스카에서 구한 북극새 알, 아프리카 사자 콩팥으로 만든 피자라고 해도 결국 토핑으로 만들어진 이상은 피자 위에 올리고 굽는 건 똑같다. 재료 구하는 방법이 달라진 것이지 만드는 사람 입장에선 별 차이 없다. (물론 희한한 재료라면 다듬는 방법을 따로 배워야할 수 있겠다.)

자, 그럼 다들 하둡 하둡 하는데 하둡이 머에요?? 질문하는 분들을 위해서.

여기서 다른 비유로 넘어가겠습니다. 죄송합니다. 말씀드렸듯이 제가 비유를 좀 좋아합니다.

당신은 대학의 조교다. 시험치면 점수를 매겨야 한다. 지금까지는 클래스 하나만 맡았기 때문에 하루 날 잡아서 50개 매기면 땡이었다.

그런데 대학의 예산 삭감으로 당신은 갑자기 200명의 시험지를 매기게 되었다. 당신은 아주아주 열심히 일하고 좀 더 빨리 매기는 방법을 개발함으로서 200명 시험지도 해결 할 수 있게 되었다. (Vertical scaling 이라고 한다. DBA 들이 퍼포먼스 튜닝하는 것도 이 방법에 해당되겠다. 작은 서버 쓰던 것을 서버 메모리 늘리고 하드 늘리고 더 빠른 프로세서로 바꾸는 방법이다)

당신이 이렇게 빨리 일을 해결했으면 상을 못 줄망정, 이젠 대학은 당신에게 대학교 학생이 만 명 시험지를 싹 다 맡기면서 이것도 매기라고 한다. 당신이 모르느 과목이 대부분이다!! 시험 형식도 다 다르다!

당신은 집에 애가 넷이라서 일을 때려 칠 수도 없다. 이것을 어떻게 해결할까??

여기서 혼자 매기는 것은 완전히 불가능하고 (==>서버 하나의 메모리 올리거나 하드 용량 늘리기, 프로세서 비싼 걸로 바꾸기. 버티컬 스케일링), 친구들 몇 명 불러서 시키는 것도 불가능하다 (==>제대로 되지 않은 분산 처리).

체계적으로 시험지를 나눠서 알바 학생들에게 주고, 각각 매겨오면 그것을 정리하고 종합해서 처리하는 방법이 필요하다. (Horizontal 스케일링). 알바 학생이 한 50명 된다면 걔네들이 백퍼센트 다 성실할 수는 없는 일이다. 아플 수도 있고, 상을 당할 수도 있고, 실연당하고 술 너무 마셔서 빵꾸낼 수도 있고, 더 좋은 알바 자리 찾아서 안 나올 수도 있다. 그러므로 '알바가 빵꾸낼 경우 대체할 수 있는 방법'을 미리 만들어둬야 한다. 시험지 카피도 해둬야 한다. 알바한테 그냥 줬다가 술처먹고 잃어버리거나 도둑맞거나 하면 안 되잖소?

그렇게 관리하고 처리하고 카피 만들어두고 혹시라도 빵꾸나면 수습하고, 다 매긴 시험지 모아서 결과 보고할 수 있게 하는 시스템이 하둡이다. 간단히 말해서 분산처리 시스템이다.

보통 수퍼마켓에서 재료를 사다가 다듬어서 냉장고에 넣어놓고 피자 토핑으로 올려서 파는 피자 가게가 보통의 패러다임이었다고 하자. 그러다가 정말 구하기 힘든 재료를 아프리카에서 공수해다가, 알라스카에서 날라온 재료와 조합을 해서 섬세한 타이밍에 맞춰 이태리의 장인이 만든 치즈를 섞어 파는 피자를 개발한다고 하자. 실제로 피자 만드는 사람 입장에서는 어쨌든 다듬어진 재료 가지고 피자 만드는 건 똑같다. 그렇지만 예전과 달리 타이밍 맞추고 어쩌고 하는 것이 더 까다로와졌다.

이것은 데이터 분석 하는 사람들의 입장이다. 내가 피자를 디자인하는 사람이 아닌 이상은, 예전에 하던 일과 똑같지만 오히려 더 만들기 까다로와졌다거나, 사용하는 툴이 달라진 것 밖에 못 느낄 수가 있다. 그러므로 예전에는 빠른 SQL 서버에서 잘 정리된 데이터를 분석하고 했었는데, 이제는 느린 하이브로 돌려야 한다. SQL 과 비슷한 것 같으면서 하이브는 훨씬 더 느리고 불편하다.

페이스북이 개발한 하이브의 엄청난 파워라면 바로 '아프리카의 재료와 알라스카의 재료'를, 동네 수퍼에서 사는 것처럼 거의 비슷하게 제공한다는 것인데, 보고서 작성하는 사람이야 그게 뭔지 알바 아니고 편하게 냉장고에서 꺼내 쓰고 싶은 사람 입장에서는 그저 불편해진 것만 보일 수 있다는 사실. (하이브는 "재료 다듬기 방법"이라고 할 수 있겠다. 예전 방법은 SQL 인데, 하이브는 SQL 이랑 비슷해 보이지만 조금씩 다르고, 훨씬 더 큰 용량의 데이터를 처리할 수 있는 장점이 있지만 예전에는 회사 메인 서버에서 SQL 만 돌렸다면 훨씬 느리게 느껴질 수 있다.)

말했듯이 피자 만드는 사람 입장에서는 (데이터 분석가) 툴이 좀 느려지고 복잡해진 거 외에는 별 다른 점이 없을 수 있으나, 두 분야의 사람에게는 천지개벽, 미친 듯한 변화를 의미한다. 하나는 피자 디자인 하는 사람이고, 다른 하나는 재료 조달팀이다.

피자 디자인하는 사람이 예전에는 수퍼마켓에서 고르고 골라 토핑 재료를 구했다면, 이제는 전세계에서 엄청나게 다양한 재료가 갑자기 펑! 하고 생겨난 셈이라 무한한 가능성으로 정말 신나고 즐겁고 피자 메뉴 디자인 할 맛 난다고 할 수 있겠다. 그러므로 지금까지 계속 데이터로 뭔가 하려던 사람들에게 빅데이터는 엄청나게 다양한 데이터를 분석할 수 있다는 말이고 이전에는 꿈도 못 꾸던 분석 및 연구가 가능하다는 말이다.

그렇지만 데이터를 이해하지 못하는 사람에게는, 그냥 주어진 자료로 윗분들이 원하시는 리포트 만드는 입장에서는 빅데이터는 별 의미가 없다. 아, 시각화는 빅데이터에서 '레스토랑 인테리어'에 해당된다. 물론 다양한 재료로 특이한 메뉴를 개발하면 좋지만, 그런 거 없어도 인테리어는 충분히 멋있게 할 수 있거든. 인테리어 업자가 공사할 때, 그 식당이 어떤 음식 파는지 참고는 하겠지만 재료 조달을 어떻게 하는지, 부엌 내에서 어떻게 일 흐름을 관리하는지는 알 필요 없잖소?

시각화는 예전에도 있었다. 단지 인터넷/모바일의 폭발과 빅데이터 현상이 맞물리면서 온갖 툴이 쏟아졌다. 안 중요하다는 건 아니고, 아주 대단한 프로그래밍 실력 없이 시각화 잘 할 수 있는 툴이 많다는 말이다.

재료 조달팀에게 빅데이터는 사실 악몽이다. 예전에는 오토바이타고 가서 동네 수퍼마켓에서 이것저것 들고 들어와 가지런하게 정리정돈만 해주면 됐는데, 이제는 온 세계로 날아가서 공수해와야 하고, 엄청난 양의 재료를 예전과 다름없이 쓸 수 있도록 해줘야 한다.

여기서 빅데이터의 분야가 갈라진다. 지난 십년 간의 IT 산업의 혁명적인 변화라면 상용화된 분산처리, IT 인프라 아웃소싱과 데이터인데 이게 안 중요하다는 게 아니고, 이제는 데이터 엔지니어링과 스케일 아웃 엔지니어링이 다른 분야로 따로 떨어져 나가서 데이터 분석하는 사람 입장에서는, 특히 이미 데이터 엔지니어링 팀이 데이터 파이프라인/인프라를 만들어두었거나 벤더의 제품을 쓰는 회사에서는 그리 큰 기술 없이도 데이터 사용이 가능하다. 그래서 빅데이터의 "빅"은 데이터 엔지니어가 걱정할 일이고 데이터 분석하는 사람은 걱정 안 해줘도 된다고 했었다.

큰 회사에서는 거의가 자신들만의 데이터 수집 처리 파이프라인을 만들고 있긴 한데, 이마저도 빠르게 아웃소싱 조짐을 보이고 있다. 웬만한 큰 테크 회사에서는 (우리팀을 포함해서) 특수화 되지 않은 데이터 수집처리 파이프라인 서비스를 (generic data service), KPMG 같은 회사에서는 회계 뿐만 아니라 자신들이 운영 방식을 잘 이해하는 인더스트리에 팔 수 있는 데이터 모델이나 컨설팅, 그 외 데이터 상품을 준비하고 있다. 데이터 엔지니어링이 지금 AWS 인프라 서비스만큼 상용화/표준화 되는 날이 얼마 안 남았다.

하둡 엔지니어나 그 외 데이터 엔지니어들에게 안 좋은 소식 같지만, 어차피 그 쪽 사람들은 거의 다 컴퓨터 사이언스 전공 기반인 사람들이었지 "데이터 엔지니어" 학위 따서 온 사람 없을 거다. 코딩은 그냥 코딩. 분산처리는 앞으로도 한참 갈 거라 걱정 안 해줘도 잘 사실 것 같습니다.

by Yangpa

https://www.facebook.com/londonyangpa/posts/1708788986073248

달달 맵싹! 양파의 개발 이야기 - 빅데이터 소개와 하둡. 데이터 엔지니어링/데이터 분석의 분리