IT/모바일
제공 : 한빛 네트워크
저자 : Jim Stogdill
역자 : 한순보
원문 : Heavy data and architectural convergence
데이터 센터에서 데이터를 전달하는 네트워크에 비해 데이터는 상대적으로 더 대량화되고 있다.
최근 저는 산호세의 하둡 서밋(Hadoop Summit)에서 하루를 보냈습니다. 특히 한 세션이 저의 시선을 끌었는데, 그 세션이 RDBMS와 하둡 세계의 지속적 병합을 암시하기 때문입니다. EMC사의 Lei Chang이 그의 팀의 GOH 프로젝트(HDFS에서의 Greenplum DB)에 대해 자세한 발표를 했습니다. 그 프로젝트는 하둡 분산 파일 시스템에서 호스팅되는 Greenplum DB의 네이티브 데이터 구조를 사용하여 Greenplum DB를 직접 실행하는 것에 대한 가능성을 테스트합니다.
이러한 종류의 융합(Convergence)은 필연적입니다. 왜냐하면, 하둡과 대용량 병렬 처리(MPP) 데이터베이스, 심지어 리눅스 슈퍼 컴퓨팅 클러스터 모두가 적어도 표면적인 설계 패턴(기가비트 이더넷 혹은 고속 인터커넥트(interconnects)로 연결된 계산 혹은 저장을 하는 수평적인 분산 노드)을 공유하기 때문입니다. 또한, 점점 더 이것들에서 호스팅되고 있는 대규모 데이터의 무거움(heaviness)(그리고 호스트의 점착성, host stickness)이 바로 디자인을 주도하는 것이 됩니다.
Lei Chang의 슬라이드를 찾을 수는 없었지만, EMC사의 Donald Miner가 한 이전의 발표는 데이터 유연성이 그들의 작업(work)을 주도하고 있음을 명확히 했습니다(슬라이드 26-28을 참고하세요). 그들은 다수의 SQL과 특정 M/R의 데이터 복사본을 호스팅하는 기관이 필요하지 않은 분석 플랫폼을 제공하려고 합니다. 그들의 통합 분석 플랫폼은 MPP Greenplum DB, 하둡, 그리고 도구들을 포함합니다. 현재 많은 그들의 고객은 아마도 단순히 하둡 M/R과 SQL 모두에 접근하기 위해 같은 데이터를 두 번 저장해야만 합니다. 현재 계속해서 ETL(Extract, Transform, Load)을 왔다 갔다 하거나 준비가 된 데이터에 접근하기 위해 외부 테이블이나 Hive와 같이 느리고 유연하지 않은 선택할 수 있는 것에 의존하고 있습니다.
이전 회사에서 우리는 회사의 전략적인 분석에 기여하기 위해 하둡의 능력을 보여주려 디자인한 어떤 제품을 팔았습니다. 아이디어는 각각의 능력을 얻기 위해 하둡을 MPP RDBMS(이 경우에서 우리는 Greenplum DB와 Cloudera를 사용)과 결합하는 것이었습니다. 하둡은 구조화되지 않은 데이터를 다운스트림 SQL 분석을 위한 전통적인 트랜잭션 데이터 창고와 결합하기 위하여 다듬을 수 있습니다. 또한, 하둡은 비전통적 접근 방식을 사용하는 구조화되지 않거나(un-structured) 어느 정도만 구조화된(semi-structured) 데이터를 직접 분석하거나, 다른 기간의 전통적 트랜잭션 데이터의 매우 큰 캐시(cache)를 분석하는 데 사용할 수 있습니다. Greenplum DB 환경은 전통적 트랜잭션 데이터와 새롭게 다듬은 구조화되지 않은(un-structured) 데이터가 결합한 저장소에 SQL 접근을 제공합니다.
우리는 이 접근 방식의 가치를 증명했지만 불필요하게 복잡했습니다. 모든 것을 두 번 저장해야 하므로 그룹 내에서 SQL과 M/R 트라이브(tribes) 각각이 모든 것에 네이티브 접근을 해야 했기 때문입니다. 또한, HDFS에서 호스트하는 GPDB 외부 테이블을 사용했지만, 그러한 데이터를 포함하는 쿼리의 성능이 좋지 못했습니다.
거의 동시에 저는 어느 고객과 일을 하고 있었습니다. 그 고객은 리눅스 슈퍼 컴퓨팅 클러스터에 상당한 투자를 이미 했지만 그들의 프로세싱과 분석 일부를 상호 보완적인 하둡 클러스터로 옮기는 것에 대해 알아보고 있었습니다. 그들이 수행하는 분석의 절반 정도는 맵/리듀스로 처리할 수 있고 다른 절반은 여전히 MPI의 더 잘게 조각낸 병렬화(granular parallelism)가 필요했습니다. 하지만 두 별개의 클러스터가 필요하다면 모든 데이터는 프로세스 사이에서 옮겨 다녀야만 했을 것입니다. 데이터는 그대로 두고 단순히 노드에서 실행되고 있는 프로세스를 이동하는 것이 훨씬 더 흥미로웠습니다.
데이터 센터에서 데이터를 전달하는 네트워크에 비해 데이터는 상대적으로 더 대량화되고 있습니다. (그것을 처리하는 칩에 비해서, 실제로 빨라 지고 있지는 않습니다) 그래서 낮은 에너지 상태(low-energy state)는 가차 없이 정적인(stationary) 데이터로 이동하며 모바일 알고리즘으로 처리됩니다. 오늘날 이동성 알고리즘은 비슷하지만 다른 충분한 머신 클러스터를 구분하는 경계에 의해 방해받습니다. 하지만 Yarn (M/R 2.0), 하둡에서의 MPI, GOH와 같은 실험, Hive의 진화와 향상, 벌크 동기 병렬(Bulk Synchronous Parallel)과 다른 많은 모든 프로젝트 모두는 다른 시스템 타입에 현재 상주하는 데이터 관리 능력의 다른 모든 종류를 보여줄 수 있는 다용도 머신의 통합된 클러스터를 향한 융합의 가능성을 비춰줍니다. 또는 다른 식으로 그들이 호스트 할 수 있는 알고리즘의 종류보다는 상주하는 데이터에 의해 정의되는 경계를 가로지르는 실질적으로 더 나은 이동성 알고리즘과 함께 클러스터의 E.U 같은 무엇인가를 보게 될 것입니다.
SQL, M/R, MPI, 상주하는 데이터와 요구되는 프로세싱의 결합에 의존하는 다른 프로그래밍 패러다임 사이에서 머신(machines)과 같은 거대한 클러스터가 동적으로 적응하는 미래를 상상하기는 쉽습니다. 노드의 지역은 하둡, MPP SQL 혹은 필요한 데이터에 따라 때마다 느린 네트워크와 I/O를 건너 이동하지 않고도 무엇이든 자신을 표현하게 될 것입니다.
데이터가 완벽하게 동질화된 클러스터가 모든 데이터 타입에 대하여 모든 알고리즘 클래스를 지원하는 일종의 데이터 유토피아를 제가 묘사하고 있는 것 같습니다. 결코, 이러한 일이 일어나지 않으리라는 것은 우리 모두 알고 있습니다. 결국, 우리는 결코 핵심 데이터가 관리되고 모든 데이터가 즉시 제 3 정규형인 관계형 세계에조차도 근접하지 못할 것입니다. 하지만 우리는 아무리 불완전하더라도 추구할 수 있는 잘 이해된 이상향을 갖게 되었습니다. 아마도 이 데이터 중심 융합 클러스터는 우리의 구조화된(structured)/어느 정도만 구조화된(semi-structured)/구조화되지 않은(unstructured) 혼합된 데이터로 된 최근의 시대를 위한 이상향이 됩니다.
저자 : Jim Stogdill
역자 : 한순보
원문 : Heavy data and architectural convergence
데이터 센터에서 데이터를 전달하는 네트워크에 비해 데이터는 상대적으로 더 대량화되고 있다.
최근 저는 산호세의 하둡 서밋(Hadoop Summit)에서 하루를 보냈습니다. 특히 한 세션이 저의 시선을 끌었는데, 그 세션이 RDBMS와 하둡 세계의 지속적 병합을 암시하기 때문입니다. EMC사의 Lei Chang이 그의 팀의 GOH 프로젝트(HDFS에서의 Greenplum DB)에 대해 자세한 발표를 했습니다. 그 프로젝트는 하둡 분산 파일 시스템에서 호스팅되는 Greenplum DB의 네이티브 데이터 구조를 사용하여 Greenplum DB를 직접 실행하는 것에 대한 가능성을 테스트합니다.
이러한 종류의 융합(Convergence)은 필연적입니다. 왜냐하면, 하둡과 대용량 병렬 처리(MPP) 데이터베이스, 심지어 리눅스 슈퍼 컴퓨팅 클러스터 모두가 적어도 표면적인 설계 패턴(기가비트 이더넷 혹은 고속 인터커넥트(interconnects)로 연결된 계산 혹은 저장을 하는 수평적인 분산 노드)을 공유하기 때문입니다. 또한, 점점 더 이것들에서 호스팅되고 있는 대규모 데이터의 무거움(heaviness)(그리고 호스트의 점착성, host stickness)이 바로 디자인을 주도하는 것이 됩니다.
Lei Chang의 슬라이드를 찾을 수는 없었지만, EMC사의 Donald Miner가 한 이전의 발표는 데이터 유연성이 그들의 작업(work)을 주도하고 있음을 명확히 했습니다(슬라이드 26-28을 참고하세요). 그들은 다수의 SQL과 특정 M/R의 데이터 복사본을 호스팅하는 기관이 필요하지 않은 분석 플랫폼을 제공하려고 합니다. 그들의 통합 분석 플랫폼은 MPP Greenplum DB, 하둡, 그리고 도구들을 포함합니다. 현재 많은 그들의 고객은 아마도 단순히 하둡 M/R과 SQL 모두에 접근하기 위해 같은 데이터를 두 번 저장해야만 합니다. 현재 계속해서 ETL(Extract, Transform, Load)을 왔다 갔다 하거나 준비가 된 데이터에 접근하기 위해 외부 테이블이나 Hive와 같이 느리고 유연하지 않은 선택할 수 있는 것에 의존하고 있습니다.
이전 회사에서 우리는 회사의 전략적인 분석에 기여하기 위해 하둡의 능력을 보여주려 디자인한 어떤 제품을 팔았습니다. 아이디어는 각각의 능력을 얻기 위해 하둡을 MPP RDBMS(이 경우에서 우리는 Greenplum DB와 Cloudera를 사용)과 결합하는 것이었습니다. 하둡은 구조화되지 않은 데이터를 다운스트림 SQL 분석을 위한 전통적인 트랜잭션 데이터 창고와 결합하기 위하여 다듬을 수 있습니다. 또한, 하둡은 비전통적 접근 방식을 사용하는 구조화되지 않거나(un-structured) 어느 정도만 구조화된(semi-structured) 데이터를 직접 분석하거나, 다른 기간의 전통적 트랜잭션 데이터의 매우 큰 캐시(cache)를 분석하는 데 사용할 수 있습니다. Greenplum DB 환경은 전통적 트랜잭션 데이터와 새롭게 다듬은 구조화되지 않은(un-structured) 데이터가 결합한 저장소에 SQL 접근을 제공합니다.
우리는 이 접근 방식의 가치를 증명했지만 불필요하게 복잡했습니다. 모든 것을 두 번 저장해야 하므로 그룹 내에서 SQL과 M/R 트라이브(tribes) 각각이 모든 것에 네이티브 접근을 해야 했기 때문입니다. 또한, HDFS에서 호스트하는 GPDB 외부 테이블을 사용했지만, 그러한 데이터를 포함하는 쿼리의 성능이 좋지 못했습니다.
거의 동시에 저는 어느 고객과 일을 하고 있었습니다. 그 고객은 리눅스 슈퍼 컴퓨팅 클러스터에 상당한 투자를 이미 했지만 그들의 프로세싱과 분석 일부를 상호 보완적인 하둡 클러스터로 옮기는 것에 대해 알아보고 있었습니다. 그들이 수행하는 분석의 절반 정도는 맵/리듀스로 처리할 수 있고 다른 절반은 여전히 MPI의 더 잘게 조각낸 병렬화(granular parallelism)가 필요했습니다. 하지만 두 별개의 클러스터가 필요하다면 모든 데이터는 프로세스 사이에서 옮겨 다녀야만 했을 것입니다. 데이터는 그대로 두고 단순히 노드에서 실행되고 있는 프로세스를 이동하는 것이 훨씬 더 흥미로웠습니다.
데이터 센터에서 데이터를 전달하는 네트워크에 비해 데이터는 상대적으로 더 대량화되고 있습니다. (그것을 처리하는 칩에 비해서, 실제로 빨라 지고 있지는 않습니다) 그래서 낮은 에너지 상태(low-energy state)는 가차 없이 정적인(stationary) 데이터로 이동하며 모바일 알고리즘으로 처리됩니다. 오늘날 이동성 알고리즘은 비슷하지만 다른 충분한 머신 클러스터를 구분하는 경계에 의해 방해받습니다. 하지만 Yarn (M/R 2.0), 하둡에서의 MPI, GOH와 같은 실험, Hive의 진화와 향상, 벌크 동기 병렬(Bulk Synchronous Parallel)과 다른 많은 모든 프로젝트 모두는 다른 시스템 타입에 현재 상주하는 데이터 관리 능력의 다른 모든 종류를 보여줄 수 있는 다용도 머신의 통합된 클러스터를 향한 융합의 가능성을 비춰줍니다. 또는 다른 식으로 그들이 호스트 할 수 있는 알고리즘의 종류보다는 상주하는 데이터에 의해 정의되는 경계를 가로지르는 실질적으로 더 나은 이동성 알고리즘과 함께 클러스터의 E.U 같은 무엇인가를 보게 될 것입니다.
SQL, M/R, MPI, 상주하는 데이터와 요구되는 프로세싱의 결합에 의존하는 다른 프로그래밍 패러다임 사이에서 머신(machines)과 같은 거대한 클러스터가 동적으로 적응하는 미래를 상상하기는 쉽습니다. 노드의 지역은 하둡, MPP SQL 혹은 필요한 데이터에 따라 때마다 느린 네트워크와 I/O를 건너 이동하지 않고도 무엇이든 자신을 표현하게 될 것입니다.
데이터가 완벽하게 동질화된 클러스터가 모든 데이터 타입에 대하여 모든 알고리즘 클래스를 지원하는 일종의 데이터 유토피아를 제가 묘사하고 있는 것 같습니다. 결코, 이러한 일이 일어나지 않으리라는 것은 우리 모두 알고 있습니다. 결국, 우리는 결코 핵심 데이터가 관리되고 모든 데이터가 즉시 제 3 정규형인 관계형 세계에조차도 근접하지 못할 것입니다. 하지만 우리는 아무리 불완전하더라도 추구할 수 있는 잘 이해된 이상향을 갖게 되었습니다. 아마도 이 데이터 중심 융합 클러스터는 우리의 구조화된(structured)/어느 정도만 구조화된(semi-structured)/구조화되지 않은(unstructured) 혼합된 데이터로 된 최근의 시대를 위한 이상향이 됩니다.
TAG :
최신 콘텐츠