분류 전체보기
-
[스파크 완벽 가이드] 1. 아파치 스파크란Software Development/Big Data 2022. 5. 8. 17:43
1.1 아파치 스파크의 철학 통합 빅데이터 애플리케이션 개발에 필요한 통합 플랫폼을 제공하자. 간단한 데이터 읽기, SQL 처리, ML, 스트림 처리까지 데이터 분석 작업을 같은 연산 엔진과 일관성 있는 API로 수행할 수 있도록 설계. 컴퓨팅 엔진 스파크는 데이터 저장소 시스템의 데이터를 연산하는 역할만 수행할 뿐 영구 저장소 역할은 수해하지 않는다. 데이터 이동은 높은 비용을 유발한다(가장 크게 영향을 받는 자원은 네트워크). 라이브러리 다양한 외부 라이브러리를 지원한다. 1.2 스파크의 등장 배경 하드웨어 성능 향상이 멈췄다(2005년). 애플리케이션 성능 향상을 위해 병렬 처리가 필요했다. 1.3 스파크의 역사 UC버클리에서 2009년 스파크 연구 프로젝트로 시작.
-
데이터베이스 인터널스Software Development/Database 2022. 4. 27. 18:24
Database Internals를 읽고 주요 내용을 요약 정리합니다. 데이터베이스 비교 데이터베이스 시스템 선택은 장기적인 결과를 초래할 수 있다. 마이그레이션 작업은 쉬운 것이 아니기 때문에 개발 초기 단계에 성능, 일관성 문제 운영 문제 등 여러 요소를 고려해야 한다. 최악의 경우 애플리케이션의 많은 부분을 수정해야 한다. 데이터베이스를 비교하기 전에 목표를 명확하게 세우자. 성능과 확장성에 관련된 문제는 시간이 지나거나 사용량이 증가했을 때 나타난다. 운영 환경과 최대한 유사한 환경에서 오랫동안 테스트하는 것이 가장 좋다. 데이터베이스 선택은 장기적인 결정이라 최신 버전에 정확히 무엇이 변경됐고 왜 변경됐는지 파악하고 업그레이드 전략을 세워 두는 것이 좋다. 데이터베이스 개발업체가 지금까지 어떤 ..
-
[엔터프라이즈 데이터 플랫폼 구축] 1. 빅데이터 기술 기초 다지기Software Development/Data Platform 2022. 1. 15. 19:30
엔터프라이즈 데이터 플랫폼 구축을 읽고 요약, 정리 및 개인적인 의견을 담기위해 이 글을 씁니다. 하둡에 영감을 준 구글에서 발행한 논문들의 내용을 보면 이런 시스템을 만들게 된 이유는 순수하게 정말로 필요했기 때문이었다. 당시에는 이런 기술이 아예 존재하지 않았다. 대규모 데이터를 처리하려면 다수의 프로세서와 다수의 메모리를 장학한 소수의 고사양 서버를 도입하고, NAS나 SAN에 저장된 데이터를 고사양 서버에 보내서 처리하고, 결과를 다시 스토리지에 저장하는 방법밖에 없었다. 이 방식은 현실성과 비용 효율성이 떨어지게 되었다. 기존 기술도 다수의 서버에서 실행도리 수 있지만, 분산된 컴포넌트 사이의 커뮤니케이션에 크게 의존해야 했는데, 이런 방식은 임달의 법칙에 따라 병렬성이 증가할수록 효율은 떨어지..
-
[엔터프라이즈 데이터 플랫폼 구축] 0. 들어가며Software Development/Data Platform 2022. 1. 15. 19:07
엔터프라이즈 데이터 플랫폼 구축을 읽고 요약, 정리 및 개인적인 의견을 담기위해 이 글을 씁니다. 여는 글 1960년대부터 분산 스토리지와 연산에 대해 학계와 업계는 연구해왔다. 그러나 실존적이고 실용적이며 유용하고, 대용량 확장성을 지원하면서도 안정적인 시스템은 구글이 인터넷 문제를 직면하면서 등장했다. 당시에는 전체 웹을 수집해서 인덱싱하고 분석하기란 불가능했다. GFS와 MapReduce 프레임워크에 대한 연구가 빅데이터 산업을 만들어냈다. 이는 더그 커팅과 마이크 카파렐라의 오픈 소스 하둡 프로젝트의 발현으로 이어졌다. 이제는 S3 같은 클라우드 스토리지를 비롯해 IoT환경과 데이터 분석을 위한 아파치 쿠두 등이 생겨났다. 들어가며 규모: 모던 데이터 플랫폼에 모든 데이터를 저장하고 나중에 필요할..
-
[MongoDB] collection.count(), collection.countDocuments({})Software Development/Database 2022. 1. 14. 00:48
MongoDB에서 흔히 전체 문서가 얼마나 저장되어 있는지 세기 위해서 db.collection.find({}).count(), db.collection.count()를 실행합니다. 그러나 위의 방법은 권장하지 않습니다. 왜냐하면 find({}) 처럼 쿼리에 조건이 없거나 그냥 count()를 실행할 경우, 메타데이터에서 값을 가져오기 때문입니다. 메타데이터에서 값을 가져오기 때문에 실행하면 굉장히 빠르게 값을 반환하는 것을 볼 수 있습니다. 이런 현상은 몽고디비가 샤딩됐을 때, 고아 문서가 적절히 필터링되지 못하거나 몽고디비가 비정상적으로 종료하게 되면 count가 적절하지 않을 수 있습니다. Wired Tiger storage engine을 쓰는 mongod가 비정상적으로 종료됐을 때 count()가..
-
[데이터 중심 애플리케이션] 스트림 처리Software Development/Database 2022. 1. 9. 16:07
일간 일괄 처리의 문제점은 입력 변화가 하루가 지나야 반영된다는 것인데 성격 급한 사용자가 느끼기에는 너무 느리다. 고정된 시간 조각이라는 개념을 완전히 버리고 단순히 이벤트가 발생할 때마다 처리해야 한다. 이 방법이 스트림 처리의 기본 개념이다. "스트림"은 시간 흐름에 따라 점진적으로 생상된 데이터를 일컫는다. 이 개념은 유닉스의 stdin과 stdout, 자바의 FileInputsStream 같은 파일 시스템 API, TCP 연결, 인터넷 상의 오디오와 비디오 전송 등 많은 곳에서 등장한다. 이벤트 스트림 전송 일괄 처리 환경에서 작업은 입출력이 파일이다. 스트림 처리에서는 입력이 파일일 떄 대개 첫 번째 단계로 파일을 분석해 레코드의 연속으로 바꾸는 처리를 한다. 스트림 처리 문맥에서 레코드는 보..
-
[데이터 중심 애플리케이션] 일괄 처리Software Development/Database 2021. 12. 26. 01:36
시스템의 3가지 유형 서비스(온라인 시스템) 클라이언트로부터 요청이나 지시가 올 때까지 기다린다. 요청 하나가 들어오면 서비스는 가능한 빨리 요청을 처리해서 응답을 되돌려 보내려 한다. 응답 시간은 서비스 성능을 측정할 때 중요한 지표다. 일괄 처리 시스템(오프라인 시스템) 일괄 처리 시스템은 매우 큰 입력 데이터를 받아 데이터를 처리하는 작업을 수행하고 결과 데이터를 생산한다. 수 분에서 수 일이 걸리기 때문에 대개 사용자가 작업이 끝날 때까지 대기하지 않는다. 일괄 처리 작업의 주요 성능 지표로는 처리량이 대표적이다. 처리량은 입력 데이터 중 특정 크기만큼 처리할 때 걸리는 시간으로 나타낸다. 스트림 처리 시스템(준실시간 시스템) 일괄 처리 시스템과 마찬가지로 요청에 대해 응답하지 않으며 입력 데이터..
-
[데이터 중심 애플리케이션 설계] 일관성과 합의Software Development/Database 2021. 12. 5. 04:29
내결함성을 지닌 분산 시스템을 구축하는 데 스이는 알고리즘과 프로토콜의 몇 가지 에를 얘기한다. 네트워크에서 패킷이 손실되고, 순서가 바뀌고, 중복되거나 임의의 시간 동안 지연이 발생할 수 있다. 시간은 최선을 다하더라도 근사치밖에 쓸 수 없다. 노드는 멈출 수 있고 언제라도 죽을 수 있다. 내결함성을 지닌 시스템을 구축하는 가장 좋은 방법은 유용한 보장을 해주는 범용 추상화를 찾아 이를 구현하고 애플리케이션에서 이 보장에 의존하게 하는 것이다. 트랜잭션을 사용함으로써 애플리케이션은 충돌이 없고 다른 누구도 데이터베이스에 동 시 접근하지 않으며 저장 서비스는 완전히 믿을 수 있는 것처럼 행동할 수 있다. 충돌, 경쟁 조건, 디스크 장애가 발생하더라도 트랜잭션 추상화가 이런 문제들을 숨겨서 애플리케이션이 ..