2015.08.10

빅데이터의 9가지 문제

Andrew C. Oliver | InfoWorld
때로는 큰 배의 옆에 구멍이 났는데 업계에서 구명보트를 팔기를 기대하면서 배가 가라앉기 시작할 때까지 기다리기로 결정하는 경우가 있다. 때로는 손잡이를 한 방향으로 돌릴 경우에만 열리는 아래층 욕실의 문과 닮은 작은 결함도 있다. 언젠가 고치겠다고는 하지만, 이미 12년 동안 고치겠다는 말만 반복해 왔다.

이처럼 빅데이터 기업이 직면하고 있는 극단적인 상황이나 양 극의 사이로 귀결될 9가지 문제에 관해 이야기하고자 한다.

빅 데이터의 문제 1: 일반용도의 GPU 프로그래밍
CPU는 여전히 값 비싼 부품이며, GPU와 비교했을 때는 더욱 그렇다. GPU의 표준이 향상되고 드라이버 문제가 적었다면 시장 전체가 개방되었을 것이다. 현재 GPU의 비용이 매우 낮기는 하지만 프로그램이 어렵고 광범위한 모델을 위한 프로그램이 실제적으로 불가능하다는 점 때문에 그 장점이 상쇄되고 있다.

이런 상황에서 누군가는 ODBC 또는 JDBC 같은 것을 작성하는 어려운 일을 하고 AMD 또는 엔비디아(Nvidia)에 시장이 그래픽 카드 단독 시장보다는 크다는 것을 납득시키고 있다. 예를 들어 스파크(Spark)에 일반적인 구속력이 있어 어렵게 생각할 일이 없다가 사람들이 갑자기 무모하게 "GPGPU"를 개발하기 시작한다고 가정해 보자.

사람들인 이미 이런 제품을 개발하고 있다. 하지만 시장을 얻기 위해서는 비밀 유지가 성공의 핵심이라고 여기는 AMD와 엔비디아뿐만이 아니라 인텔 등의 경쟁자들과 협력해야 한다. 나도 그럴 수 있었으면 좋겠다!

빅 데이터의 문제 2: 복수의 작업부하 스케일링
독커(Docker)가 있다. 얀(Yarn)이 있다. 스파크, 테즈(Tez), 맵리듀스(MapReduce) 등도 있다. 또한 우선순위가 다른 풀(Pool) 등도 있다. 자바(Java) war 파일 등을 배치한다면 PaaS에서 "자동 스케일(Autoscale)"이 가능하지만 하둡(Hadoop)을 원할 경우에는 특별하다.

또한 스토리지와 처리 사이의 상호작용은 어떤가? 때로는 스토리지를 임시로 확장하고 분산해야 한다. "월말" 배치를 실행하고 독커 이미지를 모든 곳에 자동으로 배치해야 한다. 그리고 자주 사용하지 않을 때는 시스템이 배치를 철회한 후에 자원이 필요한 다른 것을 배치해야 한다. 애플리케이션 또는 작업부하는 아무런 무리가 없어야 한다.

우리는 아직 이런 수준에 도달하지 못했다. 쉐프(Chef) 레시피와 스크립트 작성이 적성이 맞기를 바란다.

빅 데이터의 문제 3: NoSQL 배치
일부 리눅스(Linux) 박스를 ssh와 sudo로 이미지화하고 여기에 암바리(Ambari)를 지정하며 하둡만큼 복잡한 것을 설치할 수 있으면서 몽고DB(MongoDB)와 대부분의 다른 데이터베이스도 다루어야 할까? 물론 쉐프 레시피를 작성할 수 있지만 왜 그래야 할까?

필자가 J보스(JBoss)에서 근무할 때는 하이버네이트(Hibernate)와 이후 JPA/EJB3 튜닝을 자주 했었다. 대부분 로그를 들여다 보고 n+1 스타일의 쿼리(Query)가 있는 곳을 찾으며 이것들을 join으로 변경하고 상황을 악화시킨 바보 같은 캐시 구성을 제거하는 것이 일이었다.

때로는 반대의 경우도 있었다. 시스템의 모든 어설픈 테이블을 합쳤다가 되돌리는데 영원의 시간이 걸리기도 했다. 때로는 OEM(Oracle Enterprise Manager)과 그 분석에서 살펴본 더욱 복잡한 시스템으로 인해 보고서가 이런 문제에 대한 힌트를 제공하는 횡설수설에 기초한 이상한 언어로 바뀌기도 했다. 하지만 항상 2개의 테이블을 함께 사용한다는 사실을 발견할 수 있었고 이 패턴을 확인했다. 심지어 그 코딩을 고려하기도 했다.

이제 NoSQL 시스템을 튜닝할 때는 같지만 다른 양상을 보이는 문제들을 발견하곤 한다. 과도한 트립 대비 과도하게 복잡한 쿼리가 있거나 인덱스가 yourwhere 절과 일치하지 않는다 (범위 병합). 즉, 우리는 질 나쁘거나 복잡한 쿼리가 동작하는 방식을 최적화하기 위해 많은 노력을 기울였지만 개발자 교육 수준을 넘어서는 쿼리에 대해서는 의문을 품지 않았다. 이것은 마치 이것을 개발할 수 있었던 상태에서 이렇게 말하는 것과 같다. "당신이 이 쿼리들을 보냈는데 이렇게 해야 할 것 같다..."

개인적으로 이런 부분은 자동화가 가능하리라 생각한다. 단지, 먹이사슬에서 더 높은 곳으로 이동했기 때문에 더 이상 이런 일을 하지 않아도 된다는 사실이 기쁘다고 말할 수 밖에 없다.

빅 데이터의 문제 5: 분산형 코드 최적화
우버(Uber) 기능과 너무나 많은 사소한 기능을 갖춘 No. 4의 스파크 버전이 등장할 것이라 생각한다. 컴파일러에서 개발자는 루프 안에서 의존적이지 않은 연산 등을 감지하고 자동으로 끌어내 병렬화하는 옴터마이저(Optimizer)를 작성할 수 있다. 개인적으로 분산형 컴퓨팅에서 중요한 부분이 있다고 생각한다. "데이터 공학자"는 문제를 제대로 분산시키지 못하고 메모리를 낭비하는 형편 없는 파이썬(Python)을 작성한다. 그러면 똑똑한 누군가가 그의 뒤를 이어 그가 무엇을 하려 했는지 이해하고 이를 직접 최적화해야 한다.

이런 문제는 개발자가 선호하는 컴파일러 이론서와 닮은 구성이 많다. 앞으로는 제플린(Zeppelin) 또는 스파크(Spark) 자체가 형편 없는 코드를 수정하고 클러스터와 잘 호환되도록 조치를 취할 것이라고 생각한다.

빅 데이터의 문제 6: 디-디스트리뷰터(De-distributor)
필자는 하둡을 처음으로 접해 보았을 때는 하이브(Hive)에서 일부 작은 테이블을 위한 셀렉트 카운트(Select Count, *)를 입력하는 것이었다. "아 정말 끔찍하다"고 생각했었다. 어떤 문제를 보고 잘 분산되지 않을 것이라고 생각할 수 있는 반면에 (줄 수 등의) 추가적인 데이터 없이도 분산이 굳이 필요 없다는 것을 알 수 있다. 때로는 이런 것들이 더욱 큰 규모의 작업(룩업 테이블(Lookup Table) 등)의 일부이지만 하이브 또는 스파크 또는 HDFS 또는 YARN 모두 모든 문제가 분산된다고 가정하고 있다. 때로는 내재적으로 더욱 빠르기 때문에 가능한 분산되지 않는 것이 좋다. 필자는 수천 줄의 테이블에서 *를 선택하면서 맵리듀스 작업을 시작하는 등의 바보 같은 소리를 하고 있다.

빅 데이터의 문제 7: 기계 학습 맵핑
"그건 클러스터링 문제이다." 또는 "그건 투영(Projection)이다."고 말할 수 있는 경우가 많다. 하지만 기업의 공통적인 부분을 지도화하고 문제를 기술하며 이를 자신이 사용해야 하는 알고리즘에 맵핑하는 수고를 하는 사람은 없는 것 같다.

재정적인 부분을 차치하더라도 기업의 10-30% 정도는 실제로 업계에서 유일무이한 특성을 지니기 때문에 영업, 마케팅, 재고, 노동력 등을 일반 모델로 맵핑한 후 사용할 알고리즘을 기술할 수 있다. 이 작업을 통해 우리가 사업을 영위하는 방식이 바뀔 뿐 아니라 시장이 크게 확장될 것이다. 이를 단지 비즈니스쪽을 좀 더 강조하는 빅 데이터를 위한 디자인 패턴으로 생각하자.

빅 데이터의 문제 8: 보안
우선, 왜 켈베로스(Kerberos)가 싱글 사인-온(Single Sign-On)을 위한 유일한 수단일까? 웹에는 켈베로스가 없다. (물론 사람들이 그렇게 하긴 하지만 레딧(Reddit)에는 주판 매니아를 위한 공간도 있다).

둘째로 이상한 업체 경쟁 때문에 하둡이 모두에게 불리한 방식으로 왜곡되고 있다. 기본적인 인증과 권한의 경우 하둡의 여러 섹션을 불완전하게 지원하면서 다른 것들은 지원하지 않는 2개의 완전히 다른 스택이 있어야 할까? (더 작고, 더 빠르고, 더 강한) 암호화로 경쟁할 수도 있지만 레인저(Ranger) 또는 센트리(Sentry) 등은 모든 하둡 프로젝트에 적용되는 단일한 접근 및 인증 메커니즘이 없을까? 솔직히 NoSQL 영역에서는 더욱 심하다. "우리는 오픈 소스를 사랑한다"고 말하는 벤더들은 자사의 "기업" 비전매 특허 에디션에 100여 줄의 LDAP 통합 부분을 적용하여 오픈 소스 사랑을 증명하곤 한다.

빅 데이터의 문제 9: 추출하고 변형하며 불러오라
ETL은 모든 빅 데이터 프로젝트에서 예산을 소리 없이 갉아 먹는다. 할 일이 있지만 대신에 플룸(Flume), 우지(Oozie), 피그(Pig), 스쿱(Sqoop), 케틀(Kettle)을 작성하고 있다. 또한 데이터가 멀리 있고 번잡하기 때문에 과잉이 발생하게 된다. 하지만 이를 더욱 원활하게 할 수 있는 계획을 갖고 있는 사람은 아무도 없다. 이 문제는 매우 심각하다.

빅 데이터 부분에서 자신이 가장 선호하는 기술로 인한 "OMFSM으로 이미 해결” 문제는 무엇인가? editor@itworld.co.kr


2015.08.10

빅데이터의 9가지 문제

Andrew C. Oliver | InfoWorld
때로는 큰 배의 옆에 구멍이 났는데 업계에서 구명보트를 팔기를 기대하면서 배가 가라앉기 시작할 때까지 기다리기로 결정하는 경우가 있다. 때로는 손잡이를 한 방향으로 돌릴 경우에만 열리는 아래층 욕실의 문과 닮은 작은 결함도 있다. 언젠가 고치겠다고는 하지만, 이미 12년 동안 고치겠다는 말만 반복해 왔다.

이처럼 빅데이터 기업이 직면하고 있는 극단적인 상황이나 양 극의 사이로 귀결될 9가지 문제에 관해 이야기하고자 한다.

빅 데이터의 문제 1: 일반용도의 GPU 프로그래밍
CPU는 여전히 값 비싼 부품이며, GPU와 비교했을 때는 더욱 그렇다. GPU의 표준이 향상되고 드라이버 문제가 적었다면 시장 전체가 개방되었을 것이다. 현재 GPU의 비용이 매우 낮기는 하지만 프로그램이 어렵고 광범위한 모델을 위한 프로그램이 실제적으로 불가능하다는 점 때문에 그 장점이 상쇄되고 있다.

이런 상황에서 누군가는 ODBC 또는 JDBC 같은 것을 작성하는 어려운 일을 하고 AMD 또는 엔비디아(Nvidia)에 시장이 그래픽 카드 단독 시장보다는 크다는 것을 납득시키고 있다. 예를 들어 스파크(Spark)에 일반적인 구속력이 있어 어렵게 생각할 일이 없다가 사람들이 갑자기 무모하게 "GPGPU"를 개발하기 시작한다고 가정해 보자.

사람들인 이미 이런 제품을 개발하고 있다. 하지만 시장을 얻기 위해서는 비밀 유지가 성공의 핵심이라고 여기는 AMD와 엔비디아뿐만이 아니라 인텔 등의 경쟁자들과 협력해야 한다. 나도 그럴 수 있었으면 좋겠다!

빅 데이터의 문제 2: 복수의 작업부하 스케일링
독커(Docker)가 있다. 얀(Yarn)이 있다. 스파크, 테즈(Tez), 맵리듀스(MapReduce) 등도 있다. 또한 우선순위가 다른 풀(Pool) 등도 있다. 자바(Java) war 파일 등을 배치한다면 PaaS에서 "자동 스케일(Autoscale)"이 가능하지만 하둡(Hadoop)을 원할 경우에는 특별하다.

또한 스토리지와 처리 사이의 상호작용은 어떤가? 때로는 스토리지를 임시로 확장하고 분산해야 한다. "월말" 배치를 실행하고 독커 이미지를 모든 곳에 자동으로 배치해야 한다. 그리고 자주 사용하지 않을 때는 시스템이 배치를 철회한 후에 자원이 필요한 다른 것을 배치해야 한다. 애플리케이션 또는 작업부하는 아무런 무리가 없어야 한다.

우리는 아직 이런 수준에 도달하지 못했다. 쉐프(Chef) 레시피와 스크립트 작성이 적성이 맞기를 바란다.

빅 데이터의 문제 3: NoSQL 배치
일부 리눅스(Linux) 박스를 ssh와 sudo로 이미지화하고 여기에 암바리(Ambari)를 지정하며 하둡만큼 복잡한 것을 설치할 수 있으면서 몽고DB(MongoDB)와 대부분의 다른 데이터베이스도 다루어야 할까? 물론 쉐프 레시피를 작성할 수 있지만 왜 그래야 할까?

필자가 J보스(JBoss)에서 근무할 때는 하이버네이트(Hibernate)와 이후 JPA/EJB3 튜닝을 자주 했었다. 대부분 로그를 들여다 보고 n+1 스타일의 쿼리(Query)가 있는 곳을 찾으며 이것들을 join으로 변경하고 상황을 악화시킨 바보 같은 캐시 구성을 제거하는 것이 일이었다.

때로는 반대의 경우도 있었다. 시스템의 모든 어설픈 테이블을 합쳤다가 되돌리는데 영원의 시간이 걸리기도 했다. 때로는 OEM(Oracle Enterprise Manager)과 그 분석에서 살펴본 더욱 복잡한 시스템으로 인해 보고서가 이런 문제에 대한 힌트를 제공하는 횡설수설에 기초한 이상한 언어로 바뀌기도 했다. 하지만 항상 2개의 테이블을 함께 사용한다는 사실을 발견할 수 있었고 이 패턴을 확인했다. 심지어 그 코딩을 고려하기도 했다.

이제 NoSQL 시스템을 튜닝할 때는 같지만 다른 양상을 보이는 문제들을 발견하곤 한다. 과도한 트립 대비 과도하게 복잡한 쿼리가 있거나 인덱스가 yourwhere 절과 일치하지 않는다 (범위 병합). 즉, 우리는 질 나쁘거나 복잡한 쿼리가 동작하는 방식을 최적화하기 위해 많은 노력을 기울였지만 개발자 교육 수준을 넘어서는 쿼리에 대해서는 의문을 품지 않았다. 이것은 마치 이것을 개발할 수 있었던 상태에서 이렇게 말하는 것과 같다. "당신이 이 쿼리들을 보냈는데 이렇게 해야 할 것 같다..."

개인적으로 이런 부분은 자동화가 가능하리라 생각한다. 단지, 먹이사슬에서 더 높은 곳으로 이동했기 때문에 더 이상 이런 일을 하지 않아도 된다는 사실이 기쁘다고 말할 수 밖에 없다.

빅 데이터의 문제 5: 분산형 코드 최적화
우버(Uber) 기능과 너무나 많은 사소한 기능을 갖춘 No. 4의 스파크 버전이 등장할 것이라 생각한다. 컴파일러에서 개발자는 루프 안에서 의존적이지 않은 연산 등을 감지하고 자동으로 끌어내 병렬화하는 옴터마이저(Optimizer)를 작성할 수 있다. 개인적으로 분산형 컴퓨팅에서 중요한 부분이 있다고 생각한다. "데이터 공학자"는 문제를 제대로 분산시키지 못하고 메모리를 낭비하는 형편 없는 파이썬(Python)을 작성한다. 그러면 똑똑한 누군가가 그의 뒤를 이어 그가 무엇을 하려 했는지 이해하고 이를 직접 최적화해야 한다.

이런 문제는 개발자가 선호하는 컴파일러 이론서와 닮은 구성이 많다. 앞으로는 제플린(Zeppelin) 또는 스파크(Spark) 자체가 형편 없는 코드를 수정하고 클러스터와 잘 호환되도록 조치를 취할 것이라고 생각한다.

빅 데이터의 문제 6: 디-디스트리뷰터(De-distributor)
필자는 하둡을 처음으로 접해 보았을 때는 하이브(Hive)에서 일부 작은 테이블을 위한 셀렉트 카운트(Select Count, *)를 입력하는 것이었다. "아 정말 끔찍하다"고 생각했었다. 어떤 문제를 보고 잘 분산되지 않을 것이라고 생각할 수 있는 반면에 (줄 수 등의) 추가적인 데이터 없이도 분산이 굳이 필요 없다는 것을 알 수 있다. 때로는 이런 것들이 더욱 큰 규모의 작업(룩업 테이블(Lookup Table) 등)의 일부이지만 하이브 또는 스파크 또는 HDFS 또는 YARN 모두 모든 문제가 분산된다고 가정하고 있다. 때로는 내재적으로 더욱 빠르기 때문에 가능한 분산되지 않는 것이 좋다. 필자는 수천 줄의 테이블에서 *를 선택하면서 맵리듀스 작업을 시작하는 등의 바보 같은 소리를 하고 있다.

빅 데이터의 문제 7: 기계 학습 맵핑
"그건 클러스터링 문제이다." 또는 "그건 투영(Projection)이다."고 말할 수 있는 경우가 많다. 하지만 기업의 공통적인 부분을 지도화하고 문제를 기술하며 이를 자신이 사용해야 하는 알고리즘에 맵핑하는 수고를 하는 사람은 없는 것 같다.

재정적인 부분을 차치하더라도 기업의 10-30% 정도는 실제로 업계에서 유일무이한 특성을 지니기 때문에 영업, 마케팅, 재고, 노동력 등을 일반 모델로 맵핑한 후 사용할 알고리즘을 기술할 수 있다. 이 작업을 통해 우리가 사업을 영위하는 방식이 바뀔 뿐 아니라 시장이 크게 확장될 것이다. 이를 단지 비즈니스쪽을 좀 더 강조하는 빅 데이터를 위한 디자인 패턴으로 생각하자.

빅 데이터의 문제 8: 보안
우선, 왜 켈베로스(Kerberos)가 싱글 사인-온(Single Sign-On)을 위한 유일한 수단일까? 웹에는 켈베로스가 없다. (물론 사람들이 그렇게 하긴 하지만 레딧(Reddit)에는 주판 매니아를 위한 공간도 있다).

둘째로 이상한 업체 경쟁 때문에 하둡이 모두에게 불리한 방식으로 왜곡되고 있다. 기본적인 인증과 권한의 경우 하둡의 여러 섹션을 불완전하게 지원하면서 다른 것들은 지원하지 않는 2개의 완전히 다른 스택이 있어야 할까? (더 작고, 더 빠르고, 더 강한) 암호화로 경쟁할 수도 있지만 레인저(Ranger) 또는 센트리(Sentry) 등은 모든 하둡 프로젝트에 적용되는 단일한 접근 및 인증 메커니즘이 없을까? 솔직히 NoSQL 영역에서는 더욱 심하다. "우리는 오픈 소스를 사랑한다"고 말하는 벤더들은 자사의 "기업" 비전매 특허 에디션에 100여 줄의 LDAP 통합 부분을 적용하여 오픈 소스 사랑을 증명하곤 한다.

빅 데이터의 문제 9: 추출하고 변형하며 불러오라
ETL은 모든 빅 데이터 프로젝트에서 예산을 소리 없이 갉아 먹는다. 할 일이 있지만 대신에 플룸(Flume), 우지(Oozie), 피그(Pig), 스쿱(Sqoop), 케틀(Kettle)을 작성하고 있다. 또한 데이터가 멀리 있고 번잡하기 때문에 과잉이 발생하게 된다. 하지만 이를 더욱 원활하게 할 수 있는 계획을 갖고 있는 사람은 아무도 없다. 이 문제는 매우 심각하다.

빅 데이터 부분에서 자신이 가장 선호하는 기술로 인한 "OMFSM으로 이미 해결” 문제는 무엇인가? editor@itworld.co.kr


X