하둡을 싫어하는 12가지 이유

피그(Pig)와 하이브(Hive)의 장벽이 크다 피그(Pig)에서는 하이브(Hive)에서 작성된 사용자 정의 함수(User Defined Function)를 사용할 수 없으며, 하이브 테이블에 접근하려면 HCatalog를 사용해야 한다. 하이브에서도 피그 UDF를 사용할 수 없는 것은 마찬가지다. 피그 스크립트를 작성하고 싶지 않든, 피그 스크립트를 작성하는 도중에 “하이브라면 정말 쉽게 해결할 수 있는 문제인데”라고 푸념하든, 결론은 두 플랫폼 간의 장벽은 너무나도 높다는 것이다.

모든 공유 라이브러리를 HDFS에 저장해야 한다 하둡에서 늘 반복되는 이야기다. 피그 스크립트를 하둡 분산파일 시스템(Hadoop Distributed File System, HDFS)에 저장하면 자동으로 모든 JAR 파일도 HDFS에 있는 것으로 간주된다. 이 상황은 우지(Oozie)를 비롯한 다른 도구에서도 반복된다. 조직 전체가 개별 공유 라이브러리 버전을 보유하는 것은 어찌 보면 낭비다. DL 가운데 절반 이상은 클라이언트를 설치한 모든 곳에 같은 JAR 파일이 저장되고 있어, 파일을 이중으로 저장해야 할 필요성이 있는지 의문이 든다. 피그에서는 해당 문제가 수정되고 있지만, 다른 플랫폼에서는 아직 개선되지 않고 있다.

우지(Oozie) 예전 스키마로 작성된 문서 샘플이 많다. 여기서 오류가 발생한다면, 일반적으로 이 오류는 개발자의 잘못과는 아무런 연관성이 없다. ‘프로토콜 오류’일 수도 있고, 스키마 검증기에는 통과했으나 서버에서는 실패한 스키마 오류일 수도 있기 때문이다. 우지는 도구도 없고 불안정하다는 측면에서 상당 부분 앤트(Ant) 또는 메이븐(Maven)과 비슷하다.

황당한 오류 메시지 사용자는 에러가 발생한 원인을 알면 이를 빠르게 수습할 수 있다. 하둡에서 자주 뜨는 황당한 메시지는 "failure, no error returned(실패, 오류가 반환되지 않았습니다)”인데, 이는 ‘무엇인가 잘못되었으니, 사용자 스스로 오류를 해결하라’는 것을 의미한다.

커베로스(Kerberos) 하둡에서 보안성을 확보하는 방법은 널리 사용되는 인증 기술인 커베로스(Kerberos)를 이용하는 것이다. 그런데 디렉터리 액세스 프로토콜(Lightweight Directory Access Protocol, LDAP)를 사용하면 하둡의 싱글 사인온(Single Sign On), SAML, 오스(OAuth) 뿐만 아니라, 인증 정보를 전달할 수 있는 그 어떤 수단도 통합되지 않는다(그 대신, 재인증해서 권한을 다시 부여한다). 더욱 재미있는 부분은 하둡 생태계의 각 도구들이 저마다 고유한 LDAP 지원을 구현하는 바람에 일관성이 없다는 점이다.

녹스(Knox) 자바로 LDAP 커넥터를 제대로 구현하려면 최소한 100번 이상의 시행착오를 거쳐야 한다. 녹스 코드를 보면 제대로 연결을 지원하지 않는다. 사실 필자는 자바나 다른 무언가에 대한 지나친 열의 때문에 녹스가 만들어졌다고 생각한다. 아파치 모듈인 mod_proxy, mod_rewrite을 사용해도 똑같은 기능을 할 수 있는데, ‘자바’라는 점을 제외한다면 이 모듈이 바로 녹스인 셈이다. 부팅하기 위해 녹스는 인증과 권한 부여 프로세스를 수행한 후, 이 정보를 하이브나 WebHDFS 등에 전달하지 않고 재차 수행한다.

하이브에서는 외부 테이블을 둘 수도, 삭제할 수도 없다 하이브에서 테이블을 관리할 경우, 테이블을 드롭(Drop)하면 하이브가 자동으로 테이블을 삭제한다. 그런데 외부 테이블은 삭제되지 않는다. "외부 테이블 드롭하기"와 같은 기능이 없어서 굳이 외부에서 이를 해야 하는 이유에 대해 납득이 되질 않는다. 하이브는 사실상 관계형 데이터베이스 관리 시스템(Relational DataBase Management System, RDMS)으로 발전하는 중인데, 업데이트(Update)와 삭제(Delete)가 없는 이유도 이해할 수 없다.

네임노드(Namenode) 실패 우지, 녹스를 비롯한 하둡의 여러 부분은 새로운 네임노드(Namenode)가 제공하는 고가용성(High Availability, HA) 특징을 따르지 않는다. 고가용성 하둡을 사용하는 방법은 다른 것을 아무것도 사용하지 않는 경우에 한정된다.

틀린 문서가 공유되고 있다 상투적인 불편이지만, <링크 페이지를 방문하면 37번 라인은 틀렸다는 것을 발견할 수 있다. 설상가상으로 전 세계 모든 게시물에 틀린 정보가 올라가 있다. 이는 코드를 실행해보는 사람조차 없음을 의미한다. 우지와 관련된 예제는 해당 버전의 스키마 검사조차 통과하지 못한다.

불완전한 암바리(Ambari) 암바리는 비판하기 어려운 면이 있다. 하둡의 아키텍처 관점에서 보면 암바리가 동작하는 것 자체가 놀라운 일이기 때문이다. 아무튼, 암바리는 100% 완전하지 않기 때문에 골칫거리가 될 수 있다. 예를 들어, 암바리는 다양한 HA 설정, 녹스를 포함한 많은 항목을 제대로 설치하지 않는다(때에 따라 설치는 되지만 제대로 동작하지 않기도 한다). 앞으로 개선될 것이라 확신하지만, ‘나중에 수동으로 설치하라’는 식의 답변은 더 이상 듣고 싶지 않다.

리포지토리(Repository) 관리 리포지토리(Repository)를 업그레이드하는 도중에 암바리를 설치하려는 시도를 해봤으나, 결과는 좋지 못했다. 가끔은 가장 빠른 미러를 찾는데, 호환만 가능하다면 전혀 신경쓰지 않는 부분이다. 이 문제를 해결할 수 있는 방법을 찾을 수는 있겠지만, 수백 개의 노드에 걸쳐 하둡 조각들을 처음 설치하는 작업은 여전히 골치 아픈 일이다.

널(Null) 포인터 예외가 발생하지 않는다 구문 오류나 그밖에 필자의 잘못으로 야기되는 널(Null) 포인터 예외가 있을 수 있다. 그런데 피그, 하이브, HDFS 등에서는 여전히 널 포인터 예외가 발생하지 않는다.