전체 글 (31) 썸네일형 리스트형 데이터중심 애플리케이션 설계 #3 - 저장소와 검색 OLTP 초창기 비즈니스 데이터 처리는 커머셜 트랜잭션(commercial transaction)에 해당했다. 금전 거래가 아닌 영역으로 데이터베이스가 확장되었음에도 트랜잭션이라는 용어는 변하지 않고 논리 단위 형태로서 읽기와 쓰기 그룹을 나타내고 있다. 이러한 애플리케이션은 대화식이기 때문에 이 접근 패턴을 온라인 트랜잭션 처리 (OLTP)라고 한다. OLAP 데이터베이스를 데이터 분석에도 점점 더 많이 사용하기 시작했고, 몇가지 전형적인 특성이 OLTP와 달라 특성에 맞춰 개발되었다. 우선 몇가지 전형적인 특성은 다음과 같다. 특성 OLTP OLAP 주요 읽기 패턴 질의당 적은 수의 레코드, 키 기준으로 가져옴 많은 레코드에 대한 집계 주요 쓰기 패턴 임의 접근, 사용자 입력을 낮은 지연 시간으로 기.. 데이터중심 애플리케이션 설계 #2 - 데이터 모델과 질의 언어 이 장에서는 데이터 저장과 질의를 위한 다양한 범용 데이터 모델을 살펴본다. 특히 관계형 모델과 문서모델, 그리고 몇 가지 그래프 기반 데이터 모델을 비교한다. 또한, 다양한 질의 언어를 살펴보고 사용 사례도 비교한다. 관계형 모델과 문서 모델 오늘날 가장 잘 알려진 데이터 모델은 1970년 에드가 코드가 제안한 관계형 모델을 기반으로 한 SQL이다. 데이터는 (SQL에서는 테이블이라 불리는) 관계(relation)로 구성되고, 각 관계는 순서 없는 튜플(tuple)(SQL에서 로우(row)) 모음이다. 관계형 데이터베이스의 근원은 1960년대와 1970년대에 메인프레임 컴퓨터에서 수행된 비즈니스 데이터 처리에 있다. 이 사용 사례는 보통 트랜잭션 처리와 일괄처리였다. 관계형 모델의 목표는 정리된 인터페.. 데이터중심 애플리케이션 설계 #1 - 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션 오늘날 많은 애플리케이션은 계산 중심과는 다르게 데이터 중심적이다. 일반적으로 데이터 중심 애플리케이션은 공통으로 필요로 하는 기능을 제공하는 표준 구성 요소로 만든다. 예를들어 다음과 같다. 구동 애플리케이션이나 다른 애플리케이션에서 나중에 다시 데이터를 찾을 수 있게 데이터를 저장 - 데이터베이스 읽기 속도 향상을 위해 값비싼 수행 결과를 기억 - 캐시 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링할 수 있게 제공 - 검색 색인 비동기 처리를 위해 다른 프로세스로 메시지 보내기 - 스트림 처리 주기적으로 대량의 누적된 데이터를 분석 - 일괄 처리 이번 장에서는 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 데이터 시스템을 구축하기 위한 기초적인 노력이 무엇인지 살펴보고, 그 노력들인 .. 하둡 완벽 가이드 - 21. 주키퍼 사용자의 입장으로만 하둡을 바라보게 되어 깊이가 부족하다는 생각을 하게 되었다. 하둡 완벽 가이드를 읽고 이해한대로 정리한다. 주키퍼는 하둡의 분산 코디네이션 서비스로, 분산 애플리케이션을 구축할 수 있다. 분산 애플리케이션의 부분 실패(partial failure)가 가장 큰 분산 애플리케이션 작성에 어려움이다. 네트워크로 연결된 두 노드 사이에 메시지가 전송된 후 네트워크가 끊긴 경우의 상황이다. 100% 피할 수는 없어서 주키퍼를 사용한다고 해도 부분 실패가 완전히 사라지는 것은 아니며 완벽히 감출 수도 없다. 그러나, 안전하게 처리할 수 있다. 쥬키퍼의 특징 * 단순하다 * 제공하는 기능이 풍부하다 * 고가용성을 제공한다. * 느슨하게 연결된 상호작용에 도움을 준다. * 라이브러리다. * 쓰기 위.. 하둡 완벽 가이드 - 19. Spark 사용자의 입장으로만 하둡을 바라보게 되어 깊이가 부족하다는 생각을 하게 되었다. 하둡 완벽 가이드를 읽고 이해한대로 정리한다. 아파치 스파크는 대용량 데이터 처리를 위한 클러스터 컴퓨팅 프레임워크다. 스파크는 맵리듀스를 사용하지 않고 클러스터 기반으로 작업을 실행하는 자체 분산 런타임 엔진이 있다. YARN기반으로 실행할 수 있고, 하둡 파일 포맷과 HDFS 같은 기반 저장소를 지원한다. 잡 사이의 대용량 작업 데이터셋을 메모리상에 유지하는 특성으로, 매번 디스크에서 데이터셋을 읽는 맵리듀스 워크플로우에 비해 10배 이상 더 빠르다. 반복적 알고리즘이나 대화형 분석과 같은 애플리케이션에 적합하다. 인메모리 캐싱 뿐 아니라 DAG 엔진과 사용자 경험을 제공하여 사용자에게 큰 매력이 있다. (https://.. 하둡 완벽 가이드 - 15. SQOOP 사용자의 입장으로만 하둡을 바라보게 되어 깊이가 부족하다는 생각을 하게 되었다. 하둡 완벽 가이드를 읽고 이해한대로 정리한다. 스쿱은 HDFS 외부의 스토리지 저장소에 있는 데이터에 맵리듀스 프로그램이 접근할 수 있게 하는 외부 API 이다. 구조화된 데이터 저장소에서 데이터를 추출해서 하둡으로 보내 처리할 수 있도록 해주는 오픈 소스 도구다. 스쿱으로 데이터를 HBase로 옮길 수도 있다. 스쿱의 작동 방식과 데이터 처리 파이프라인에서 스쿱을 활용하는 방법을 살펴보자. 15.1 스쿱 얻기 스쿱은 여러 곳에서 내려받을 수 있다. 내려받아 sqoop 명령어로 호출할 수 있다. 15.2 스쿱 커넥터 스쿱 커넥터는 외부 저장 시스템에서 데이터를 하둡으로 임포트하거나 하둡에서 외부 저장 시스템에 익스포트 할 수.. 하둡 완벽 가이드 - 13. PARQUET 사용자의 입장으로만 하둡을 바라보게 되어 깊이가 부족하다는 생각을 하게 되었다. 하둡 완벽 가이드를 읽고 이해한대로 정리한다. 아파치 파케이는 중첩된 데이터를 효율적으로 저장할 수 있는 컬럼 기준 저장 포맷이다. 컬럼 기준 저장 포맷은 파일 크기와 쿼리 성능 측면 모두에서 효율성이 높은 장점이 있다. (동일한 컬럼의 값을 나란히 모아서 저장하기 때문에 인코딩 효율이 높다.) 파케이의 가장 큰 장점은 진정한 컬럼 기반 방식으로 중첩 구조의 데이터를 저장할 수 있다는 것이다. 중첩된 필드를 다른 필드와 상관없이 독립적으로 읽을 수 있어 상당한 성능 향상을 얻을 수 있었다. 또 다른 특징은 파케이 포맷을 지원하는 수많은 도구가 있다. 프로젝트를 언어 중립 방식으로 파일 포맷을 정의하는 명세 부분과 다양한 언어.. 하둡 완벽 가이드 - 11. 하둡 관리 사용자의 입장으로만 하둡을 바라보게 되어 깊이가 부족하다는 생각을 하게 되었다. 하둡 완벽 가이드를 읽고 이해한대로 정리한다. 11.1 HDFS 11.1.1 영속적인 데이터 구조 네임노드, 보조 네임노드, 데이터 노드가 영속적으로 사용하는 데이터를 디스크에 어떻게 구성하는지 알아보자. 네임노드 디렉터리 구조 ${dfs.namenode.name.dir}/ ├── current │ ├── VERSION │ ├── edits_0000000000000000001-0000000000000000019 │ ├── edits_inprogress_0000000000000000020 │ ├── fsimage_0000000000000000000 │ ├── fsimage_0000000000000000000.md5 │ ├── .. 이전 1 2 3 4 다음
