Category by "bigdata"

회계사는 기록을 수정해야 하면 이미 입력된 값을 지우지 않고 새로운 값을 다시 씁니다. 최종 결과를 구하려면 모든 항목을 재검토하고 합계액을 계산해야 합니다. 이러한 방식은 바로 오늘 포스트에서 살펴볼 로그 구조 스토리지(Log-Structured Storage)와 유사합니다. 또 다른 예로는 불변 스토리지(immutable storage)가 있습니다.

데이터베이스 시스템의 선택은 중요합니다. 성능, 일관성 문제, 운영의 어려움과 같은 이유로 데이터베이스를 변경하게 되는 경우가 발생할 수 있습니다. 데이터베이스를 변경할 때 마이그레이션이 쉽지 않을 수도 있기 때문에 초기 설계 단계에서 애플리케이션의 특성에 알맞는 데이터베이스를 선택해야 합니다.

이전 포스트에서는 데이터를 Bounded data와 Unbounded 데이터 구별하고, 그것을 처리하는 방법에 관해 살펴보았습니다. Unbounded data를 처리할 때 이벤트 시간과 처리 시간의 차이점에 대해서 다뤘습니다. 또한 윈도우 개념도 함께 알아보았습니다. 이번 포스트에서는 워터마크, 트리거, 어큐뮬레이션에 관해 자세히 살펴보겠습니다.

스트리밍 처리의 중요성이 점점 중요해지고 있습니다. Apache Spark Streaming부터 새로운 스트림 처리의 강자인 Apache Flink와 같은 스트리밍 처리 엔진 등의 사용 사례가 많아지고 있습니다. 그래서 이번 기회에 스트리밍 처리에 대한 기본 개념들에 대해 정리해보고자 합니다.

HBase는 데이터베이스 시스템에서의 커서와 유사한 스캔 기능을 제공합니다. 스캔은 HBase에서 순차적이고 정렬된 저장 구조를 활용하는 방식입니다. 스캔을 사용하면 로우 키를 기반으로 하여 여러 데이터를 가져올 수 있습니다. 스캔은 로우 키가 정확히 일치하지 않아도 사용이 가능합니다.

스트림 처리에서 바라보는 시간적 측면 중에 이벤트 시간(Event time) 기반으로 처리하는 방식에 대해 살펴보겠습니다. 최근에 데이터 처리 분야에서 스트리밍 애플리케이션 개발의 중요성이 더욱 커지고 있습니다. 만약 스트리밍 애플리케이션을 개발하게 되는 경우 애플리케이션의 목적에 따라 이벤트 시간(Event time)을 기준으로 처리할 것인지 처리 시간(Processing time) 기준으로 처리할 것인지 선택을 해야 할 것입니다.

HBase에 접근하기 위한 주요 인터페이스는 org.apache.hadoop.hbase.client의 HTable 클래스입니다. HTable 클래스를 통해서 HBase에 데이터를 저장하고 삭제하는 등 사용자 작업에 필요한 기능을 제공합니다. HBase에서 데이터를 변경하는 로우 단위의 모든 작업은 원자성(Atomic)이 보장됩니다. 원자성이 보장된다는 말은 무슨 의미일까요? 하나의 로우에 읽기나 쓰기 작업이 수행되는 동일 다른 클라이언트나 스레드에서 동일한 로우에 읽기나 쓰기를 시도해도 아무런 문제가 발생하지 않는다는 의미입니다.

이번 포스트에서는 애플리케이션을 개발할 때 관계형 데이터베이스가 아닌 NoSQL 데이터베이스를 선택할 때 참고할 수 있는 기준들을 살펴보면 도움이 될 것입니다. RDBMS와 NoSQL 데이터베이스의 대표적인 차이점은 스키마와 트랜잭션 속성이나 실제로 데이터를 저장하는 구조에서 살펴볼 수 있습니다. 애플리케이션을 개발할 때 애플리케이션이 가진 특징을 명확히 이해하고 있으면 다양한 데이터베이스 중에 알맞는 데이터베이스를 선택할 수 있을 것입니다.

이전 포스트에 이어서 파티셔닝에서 사용하는 리밸런싱 기법에 관해 살펴보고, 클라이언트에서 질의 요청을 어떻게 처리할 것인지에 관해 알아보겠습니다. 파티션 리밸런싱 리밸런싱이란 클러스터에서 한 노드가 담당하던 부하를 다른 노드를 옮기는 과정입니다. 이러한 리밸런싱이 필요한 경우는 시간이 지나면서 데이터베이스에 변화가 생기기 때문입니다.

데이터셋이 매우 크거나 질의 처리량이 매우 높은 경우 데이터를 파티션으로 쪼개야 합니다. 이번 포스트에서 이야기하는 파티셔닝은 대용량 데이터베이스에서 데이터를 작은 단위로 쪼개는 방법을 말합니다. 몽고DB, 엘라스틱서치, 솔라에서는 샤드라고 하며 HBase에서는 리전, 빅테이블에서는 태블릿(tablet), 카산드라와 리악에서는 vnode, 카우치베이스에서 vBucker이라고 부릅니다.

조인 여러 데이터셋에서 한 레코드가 다른 레코드와 연관되어 있는 것은 일반적입니다. 관계형 모델에서는 외래키, 문서 모델에서는 문서 참조, 그래프 모델에서는 간선이라고 부릅니다. 비정규화를 통해서 이러한 조인을 줄일 수는 있지만 완전한 제거는 어렵습니다. 배치 처리에서의 조인은 데이터셋 내의 모든 연관 관계를 다루는 것을 의미합니다.

배치 처리는 컴퓨터 연산의 오래된 형태 중에 하나입니다. 이미 배치 처리는 예전 부터 사용했습니다. 2004년에 발표된 구글의 맵리듀스는 과거 미국 인구 조사에서 천공 카드 집계기를 이용한 집계 처리와 유사합니다. 이와 같이 배치 처리는 입력 데이터로 집계 처리해서 결과를 보여줍니다.

데이터베이스와 스트림 메시지 브로커와 데이터베이스는 전혀 다른 범주의 도구로 바라볼 수 있지만 로그 기반 메시지 브로커는 데이터베이스에서 아이디어를 얻어 메시지 시스템에 적용하는데 성공하였습니다. 데이터베이스의 복제 로그(replication log)는 데이터베이스에 쓰는 이벤트 스트림으로 볼 수 있습니다. 변경 데이터 캡처(CDC, Change Data Capture) 변경 데이터 캡쳐는 데이터베이스에 기록하는 모든 데이터의 변경사항을 관찰해 다른 시스템으로 데이터를 복제할 수 있는 형태로 추출하는 과정을 말합니다.

일반적으로 배치 처리의 문제점은 입력의 변화가 특정 기간이 끝나야 반영이 되는 문제가 있습니다. 이러한 지연(Lag)을 줄이려면 더 자주 실행할 수 있도록 해야 합니다. 고정된 타임 슬라이스 별로 처리하는 것이 아닌 이벤트가 발생할 때마다 처리하도록 하는 것입니다.

이번 포스트에서는 HBase의 데이터 모델에 대해 살펴볼 예정입니다. 먼저 데이터 모델이란 무엇일까요? 데이터 모델이란 데이터를 인식하고 조작하는데 사용되는 모델을 말합니다. 데이터베이스를 사용하는 사람에게 데이터 모델은 데이터베이스 내의 데이터와 상호작용하는 방법을 이야기하는 것입니다. HBase에서 데이터 모델을 어떻게 표현하는지 살펴보기 전에 HBase에서 사용하는 용어를 먼저 살펴보도록 하겠습니다.

이번 포스트에서는 스파크에서 빈번히 사용되는 transformation인 reduceByKey와 groupByKey의 동작에 대해 살펴보겠습니다. 먼저 스파크에서 reduceByKey와 groupByKey를 사용하여 단어 세기 예제를 작성해보도록 하겠습니다. val words = Array("one", "two", "two", "three", "three", "three") val wordPairsRDD = sc.parallelize(words).map(word => (word, 1)) val wordCountsWithReduce = wordPairsRDD .

1. Apache Kafka 아파치 카프카(이하 카프카)는 여러 대의 분산 서버에서 대량의 데이터를 처리하는 분산 메시징 시스템입니다. 카프카는 여러 시스템과 장치를 연결하는 중요한 역할을 수행합니다. 카프카는 높은 처리량과 실시간 처리를 할 수 있습니다. 이러한 카프카는 다음의 4가지 특징을 가지고 있습니다.

동기식 복제와 비동기식 복제 이전 포스트에 이어서 복제에 관해 살펴보겠습니다. 복제는 동기 또는 비동기적으로 이루어집니다. 동기식 복제는 리더가 해당 팔로워가 쓰기를 수신했는지 확인해줄 때까지 기다리는 방식입니다. 아래의 그림에서는 Follwer1의 복제는 동기식으로 동작합니다. 동기식 복제의 장점은 팔로워가 리더와 일관성 있게 최신 데이터 복사본을 갖는 것을 보장합니다.

이번 장의 주제는 복제(Replication)입니다. 복제란 네트워크로 연결된 여러 장비에 동일한 데이터의 복사본을 유지하는 것을 의미합니다. 복제를 통한 이점은 다양합니다. 첫째로, 지리적으로 사용자와 가까운 곳에 데이터가 존재할 수 있어서 지연 시간(latency)을 줄여줍니다. 둘째로, 시스템에 일부 장애가 발생해도 지속적으로 동작할 수 있게 해 가용성(availability)를 높여줍니다.

이전 포스트에 이어서 세 번째 포스트입니다. 이전 포스트에서는 SS테이블과 LSM 트리에 관해 알아보았습니다. 이번 포스트에서는 데이터베이스에서 가장 많이 사용하고 일반적인 색인 유형인 B 트리에 대해서 살펴보겠습니다. B 트리 B 트리는 거의 대부분의 관계형 데이터베이스에서 표준 색인 구현으로 사용할 뿐만 아니라 비관계형 데이터에서도 사용합니다.

이전 포스트에 이어서 저장소와 검색을 계속 살펴보겠습니다. 이전 포스트 마지막 부분에 대한 설명은 해시 테이블을 통한 색인이 가진 제한사항에 대해 살펴보았습니다. 이러한 제한이 없는 색인 구조를 이어서 살펴보도록 하겠습니다. SS 테이블과 LSM 트리 위 그림과 같이 log-structured 저장소 세그먼트는 key-value 쌍의 시퀀스입니다.

이전 포스트에서는 데이터 모델과 질의 언어에 대해 알아보았습니다. 예를 들어 애플리케이션 개발자 관점에서 데이터베이스에 저장하는 데이터 포맷과 데이터를 다시 요청하는 메커니즘과 같은 것들을 살펴보았습니다. 이번 장에서는 데이터베이스 관점에서 데이터를 저장하는 방법과 데이터를 요청했을 때 다시 찾을 수 있는 방법에 대해서 살펴볼 예정입니다.

데이터를 위한 질의 언어 데이터베이스에 데이터를 질의하는 방법은 각각의 데이터 모델마다 조금씩 다릅니다. 일반적으로 알고 있는 관계형 모델의 경우는 SQL을 이용합니다. SQL은 선언형 질의 언어입니다. 그리고 선언형(declarative) 질의와 대조되는 질의 방식은 명령형(imperative) 질의 방식이 있습니다. 그러면 선언형과 명령형을 사용하여 데이터를 조회하는 방법을 한번 살펴보겠습니다.

데이터 모델은 소프트웨어 개발에 있어서 가장 중요한 부분 중에 하나입니다. 다양한 종류의 데이터 모델에 대해 이해를 하고 있고, 애플리케이션 요구사항에 가장 적합한 모델을 찾아서 개발을 해야 합니다. 데이터 모델에 따라 어떤 종류의 사용법은 쉽고 어떤 동작은 지원하지 않습니다.

Compute-intensive(계산 중심) vs Data-intensive(데이터 중심) 과거에는 CPU 성능이 애플리케이션을 제한하는 요소였지만 오늘날에는 그렇지 않습니다. 최근에는 데이터의 양, 데이터의 복잡도, 데이터의 변화 속도가 애플리케이션을 제한하는 요소가 되었습니다. 이렇게 애플리케이션에서 사용하는 데이터의 특징에 맞춰서 설계를 해야 합니다. 그래서 이러한 애플리케이션을 Data-intensive application(데이터 중심 애플리케이션)이라고 합니다.

이전 포스트에는 Oozie의 워크플로우 패턴중 하나인 fork-and-join 패턴에 관해서 알아보았습니다. 이번 시간에는 워크플로우 내에 액션의 결과에 조건을 주어 다음 액션을 어디로 수행할 것인지 결정할 수 있는 capture-and-decide 패턴에 대해 알아보도록 하겠습니다. capture-and-decide pattern capture-and-decide 패턴이라고 하니까 약간 어려운 느낌이 있지만 실제로는 간단한 패턴이죠.

이전 포스트에는 Oozie의 워크플로우 패턴중 하나인 Point-to-Point 패턴에 관해서 알아보았습니다. 이번 시간에는 fork-and-join 패턴에 대해 알아보도록 하겠습니다. fork-and-join pattern fork-and-join 패턴은 Fan-out 패턴이라고도 합니다. 이와 같은 형태의 워크플로우는 여러 액션들이 나누어 실행한 후 해당 액션들이 다 정상적으로 완료된 후 다음 액션을 수행해야하는 경우 많이 사용합니다.

Oozie가 무엇인지 궁금한 분들을 Apache Oozie 소개라는 이전 포스트를 참고하시기 바랍니다. 일반적으로 Oozie에서 많이 사용되는 워크플로우 패턴에 대해서 알아봅시다. 순차적 액션 수행 (Point-to-Point Pattern) 가장 간단한 형태로 수행하는 워크플로우 형태가 되겠습니다. 말그대로 순차적으로 액션을 수행할 때 사용합니다.

Oozie 개요 Oozie는 정식 홈페이지에 나와 있듯이 Hadoop ecosystem에서 사용하는 Workflow Scheduler(혹은 orchestration) 프레임워크입니다. Oozie에서 제공하는 기능은 크게 아래의 3가지와 같습니다. Scheduling 특정 시간에 액션 수행 주기적인 간격 이후에 액션 수행 이벤트가 발생하면 액션 수행 Coordinating 이전 액션이 성공적으로 끝나면 다음 액션 시작 Managing 액션이 성공하거나 실패했을 때 이메일 발송 액션 수행시간이나 액션의 단계를 저장 Oozie 용어 Action 우지에서 실행할 수 있는 하나의 작업 단위 MapReduce 작업, Spark 작업, Shell script 등 Workflow Action들의 제어와 의존 관계를 DAG(Directed acyclic graph) 표현 Coordinator Data sets과 Workflow를 실행하는 스케줄을 정의 Bundle 코디네이터의 모임 Oozie Architecture 우지는 Client-Server Model의 형태입니다.