블로그 이미지
SQL Server VS. 석이 minsouk@hotmail.com MSSQL 쿼리성능 관련해 궁금한 사항이 있다면 언제나 누구나 TeamViewer + Line (네이버 japan 메신저) 에 minsouk1 추가 후 연락주세요~ 010-9967-0955 보미아빠

카테고리

보미아빠, 석이 (431)
밥벌이 (16)
싸이클 (1)
일상 (1)
Total180,046
Today14
Yesterday64

달력

« » 2017.06
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

공지사항

Real Time Analytics

실시간 분석의 모든것


스트리밍 데이터의 여러 측면을 소개

중급 독자에게 PoC 의 자신감을 위해서


1부

스트리밍분석 아키텍처

스트리밍 데이터 시스템의 아키텍처 자체와 시스템 운영 측면

개념과 특징 소개

가용성 확장성 응답대기시간의 맥락에서 살펴본다.

구현하거나 설정하는데 필요한 기본지식에 초점


3,4장 동작 시스템을 설계하고 조정하는데 필요한 도구의 소개

개발하거나 기존 소프트웨어 시스템에 적용하는데 두가지의 당단점 논의


5,6장 한번 움직인 데이터는 저장되어야 한다.

유명한 스트리밍 처리 소프트웨어와 데이터 저장을 위한 옵션


2부

인프라 애플리케이션의 다양한 문제

대시보드 경고 시스템은 2부에서 다룰 첫번째 애플리케이션이다.


7장 최종 사용자에게 보내지는 데이터 전달 (웹 기반 환경에서의 대시보드 시각화 생성)


8장 지속적 집계를 위해 스트리밍 환경을 위한 데이터 수집을 다룬다.

다중 해상도 시계열 데이터의 집계에 대해 살펴본다.


9장 통계화 확률의 기초

이전에 관측된 행동과 현재 행동이 정말 다를까?


10장 스케치 확률 자료구조


11장 집계를 넘어서는 수준

각 주제만으로 너무 많은 양이다. 스트리밍 데이터를 위한 확률과 기계학습 모형

최적화와 A/B 테스트 (어떤게 더 좋은거야? 잘못된 추정도 될 수 있겠지만 이런것을 극복하기 위해 더많은 데이터를 모으던지 이 문제를 해결하기 위해 12장의 메커니즘을 소개한다. )


12장

멀티암드 밴티드


필요한 도구

JVM

JDK

이클립스

메이븐 빌드 시스템

확률의 입문 (자유아카데미) 음 .....


코드 예제

주소 찾아봐라 있다.











chapter 1

스트리밍 데이터 소개

1) 지속적 데이터 전달

2) 느슨하게 구조화된 데이터

3) 높은 카디널리티 (데이터가 열라게 다양하다.)


1.1 스트리밍 데이터의 원천

동작 시스템 : 링크드인, 야후 페이스북 의 웹 분석이나 온라인 광고를 위한 데이터 핸들링을 위해 시작

처리 시스템 : 소셜 미디어 데이터를 처리


1.1.1 운영 모니터링

수만대 서버의 온도, 팬속도, 파워서플라이 전압, 디스크 드라이브 상태, 프로세서 작업량, 네트워크 활동량 스토리지 액세스 시간 등


1.1.2 웹분석

웹사이트의 구조가 다양한 관심 메트릭에 어떤 영향을 주는지 알아내는 실험


1.1.3 온라인 광고

환경 및 사이트 별 지출되는 돈, 구매 수

현재 수행중인 캠페인의 관리와 최적화를 위해


1.1.4 소셜 미디어

자연어, 실시간 데이터 원천으로 쓰기엔 엄청나게 어려운것.


1.1.5 모바일 데이터와 사물 인터넷

스마트 홈

사람의 생체데이터를 장시간에 걸쳐 수집 (longitudinal data : 장기적으로 변화되는 데이터) 문제 예방을 목표로 시간의 흐름에 따라 혈압을 추적 등


1.2 스트리밍 데이터만의 특징

1.2.1 항상 켜져 있고, 항상 흐르는

첫째 데이터 수집 자체는 매우 강건해야 한다. 수집 시스템의 다운은 영구적 데이터 손실

긍정적 측면

항상 충분한 데이터가 있고 모자라면 더 기다리면 된다.

부정적 측면

분석을 위한 표준 접근법의 대부분이 스트리밍 형태의 데이터에 적합하지 않다. 그렇다고 이 방법을 사용하지 말라는 말이 아니고 통계적 기법은 잡음 있는 데이터의 분석에 사용 가능한 최적의 도구이다.

유의성 (p-value, 유의확률 값) 을 정지규칙이라 생각하지만 그럲지 않을지도...등...

https://ko.wikipedia.org/wiki/P-value

http://blog.naver.com/ssacstat/220455144806

https://ko.wikipedia.org/wiki/68-95-99.7_%EA%B7%9C%EC%B9%99


1.2.1 느슨한 구조화

JSON (JavaScript Object Notation)

유연한 구조에 담에 전달


1.2.2 높은 카디널리티
롱테일 특징을 가지고 있고, 현재 데이터의 일반 상태가 미래 데이터의 일반 상태가 될 지 알 수 없다.

1.3 인프라 및 알고리즘
인프라 없는 알고리즘은 흥미로운 연구논문
애플리케이션 없는 인프라는 대부분 자원의 낭비
알고리즘이나 인프라 하나에 집중한다면 "만들면 그가 올것이다." 라는건데 이런건 통하지 않는다.
조직의 다양한 사용자가 인프라 및 알고리즘에 액세스할 수 있게 하는것이 목표이고
사람들이 사용하고 발전시키고 확장해야 성공적인 프로젝트가 된다.



chapter 2

실시간 스트리밍 아키텍처의 설계


2.1 실시간 아키텍처의 구성요소


2.1.1 수집

로그포멧의 정의  

구조가 정의되지 않으면 :

JSON  - 메시지를 보낼 때마다 스키마를 같이 보낸다. 상대적으로 큰 대역폭이 필요

구조가 잘 정의되어 있으면 IDL(Interface Definition Language)을 써라

Thrift(페이스북) , Protocol Buffers(Protobuf) (구글)

Avro (아파치) : 위 두개와 비슷한데, 스키마 표현을 JSON 으로 읽기 쓰기 할 수 있다.


2.1.2 데이터 흐름

0 세대

강한결함 - 애플리케이션을 특정 애플리케이션에 한정된 계측으로 분류하는데 사용

1 세대

결합제거 - 파일로 쌓아, 하둡이 이런 환경에 최적화 됨

2 세대

신뢰를 조금씩 깨기 시작

RPC 사용하기 시작함 Scribe나 Avro 같은 2세대 시스템은 일반적으로 안정성을 희생하면서 속도를 향상시킴

3 세대

1세대 로그 모델의 신뢰성과 2세대 RPC 모델을 결합

소규모 배치 형태로 수행

ActiveMQ 같은것들이 있고 Queue 시스템은 순서를 유지하는데 성능에 큰 걸림돌임

일반적인 분산 시스템은 이러한 순서가 불필요하고 만약 필요하면 클라이언트에 의해 처리되는 편이 좋다.


Queue 의 의미 체계가 불필요하다라고 해서 나온것들이 카프카나 플룸이다. 이는 신뢰성을 보장하고 순서 의미체계를 거의 버리고 있다.



2.1.3 처리

1세대

하둡 맵리듀스

2세대

카산드라 (데이터베이스를 이용해 계측화된 스트리밍 집계 시스템을 구현)

현재 2세대는 한정된 구현을 뛰어넘어 스트리밍 연산을 처리함

스톰은 시스템 연산의 다른 부분간 방향성 비순환 그래프 메커니즘 (DAG) 제공

http://m.blog.daum.net/hijava/26

아직 프로젝트들이 젋어서 궁합을 잘 알아봐야 한다.


이미 맵리듀스 모델은 대화형 쿼리에 대한 수요를 충족하기 휘애 더 복잡한 연산을 구현하는 능력을 갖추어가고 있다.


맵리듀스를 사용하지 않고 SQL 구현 (SQL on Hadoop)

클라우데라의 임팔라

스팅어

타조

Hive

Presto


2.1.4 저장소

남아돌고 목적에 따라 잘 골라써라 (성능특성에 따라서)

SQL on Hadoop
http://www.jaso.co.kr/482


ACID 를 버리고 성능을 우선시 한다.

원자성

부분적으로 실행되다가 중단되는일은 없어 (돈을 이체하는데 여기는 빠지고 저기는 안들어 가있고)

일관성

트랜잭션이 완료되면 남/여만 있어 (제한을 잘 지켜서 들어가 있어, constraints, triggers, cascades)

그런데 일부에선 다음과 같이 모호하게 설명한다...무슨 뜻인지 알고나 쓴건지...("트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성있는 데이타베이스 상태로 변환한다. 즉, 트랜잭션 실행의 결과로 데이터베이스 상태가 모순되지 않는다." 이렇게 설명하면 보통 무슨 뜻인지도 모르더라... )

고립성

트랜잭션을 외부에서 못봄(lock)

영속성

commit이 되면 장비가 죽었다 살아도 복구해 그 상태가 복구됨



Atomicity[edit]

Atomicity requires that each transaction be "all or nothing": if one part of the transaction fails, then the entire transaction fails, and the database state is left unchanged. An atomic system must guarantee atomicity in each and every situation, including power failures, errors, and crashes. To the outside world, a committed transaction appears (by its effects on the database) to be indivisible ("atomic"), and an aborted transaction does not happen.

Consistency[edit]

The consistency property ensures that any transaction will bring the database from one valid state to another. Any data written to the database must be valid according to all defined rules, including constraintscascadestriggers, and any combination thereof. This does not guarantee correctness of the transaction in all ways the application programmer might have wanted (that is the responsibility of application-level code) but merely that any programming errors cannot result in the violation of any defined rules.

Isolation[edit]

The isolation property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e., one after the other. Providing isolation is the main goal of concurrency control. Depending on the concurrency control method (i.e., if it uses strict - as opposed to relaxed - serializability), the effects of an incomplete transaction might not even be visible to another transaction.

Durability[edit]

The durability property ensures that once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors. In a relational database, for instance, once a group of SQL statements execute, the results need to be stored permanently (even if the database crashes immediately thereafter). To defend against power loss, transactions (or their effects) must be recorded in a non-volatile memory.



레디스 - 단일장비로 구성된 마스터 슬레이브 저장소

카산드라 - 분산 및 일관성 유지 SQL 을 지원하나 제한적

몽고디비 - 인덱스된 도큐먼트 저장소 (다양한 구조를 수용 JSON 사용, 키 값 저장소와 달리 도큐먼트간 참조에 대한 추상화를 제공)


2.1.5 전달


웹통신


XMLHttpRequest (XHR)기능을 사용 이런 기술의 집합을 AJAX (Asynchronous Javascript And XML) 이라 한다. 이는 기본적으로 폴링(Polling) 으로 동작하는데, 비 효율적이여서 롱 폴링(Long Polling) 기법을 사용해 상호작용하도록 만들려는 수많은 방법이 개발되고 있다. 이들을 통칭해 코멧(Come) 이라 한다.

http://m.mkexdev.net/71


현재 사용되는 표준은 SSE (Server-Sent event) 나 웹소켓 (WebSocket) 이다.

SSE 가 단방향에서는 유리하고 쉽다.

WebSocket 양방향이 지원되어 하는경우에 좋다.

그러니 우리는 대부분 SSE 가 좋을것 같다.....


웹 렌더링

CSS 나 DOM 사용

CSS : cascading style sheets

DOM : Document Object Model (음...객체지향 모델로서 구조화된 문서를 표현하는 형식으로 HEML 문서의 요소를 제어, 동적으로 내용 구조 스타일에 접근 가능하다.)


2.2 실시간 아키텍처의 특징


주요 특징은 고가용성, 낮은 응답대기시간, 수평적 확장!


2.2.1 고가용성

정지에 대단히 민감하다. 정지되면 데이터를 다시 받을 방법이....없을수도...

부하분산과 데이터 복제에 의존한다 혹은


마스터가 없는 구조도 있다. (카산드라)

카프카, 몽고디비는 큐에 쓰여진 데이터가 사용가능한 상태로 유지되도록 보장하기 위해 마스터-슬레이브 형식의 복제를 이용한다.


2.2.2 낮은 응답대기시간

배치 단위를 작게해서 거의 실시간 ms 응답시간

안정성을 낮추고 속도를 올리다. (다 체크 안하면 빠르잖아....그말이지)


2.2.3 수평적 확장성

수평적 확장 / 수직적 확장

수평적 확장을 위해 여러 서버로 작업을 분배

고장으로 복구하거나 알려주는 알고리즘도 필요한데 복잡하다......-> 야후의 주키퍼가 쓰자

3장에서 살펴보자


2.3 실시간 프로그래밍을 위한 언어


2.3.1 JAVA

2.3.2 스칼라와 클로저

스칼라 : 실시간 처리 플랫폼인 삼자의 구현에 사용됨

클로저 : 리스프언어를 기반으로 한 JVM 이다. 함수기반 언어인가 보다.


lisp 언어 아래와 같은 특징이 있는 언어

1) 함수 객체를 동적으로 생성할 수 있다.
2) 함수 객체를 변수에 대입할 수 있다.
3) 함수 객체를 함수의 인수로 전달할 수 있다.
4) 함수 객체를 함수의 반환값으로 반환할 수 있다.


함수형 언어는 상태(state)를 저장하는 변수의 사용을 없애는 것을 목표로 한다.

함수형 코드에서는 함수의 출력값은 그 함수에 입력된 인수에만 의존하므로
인수 x에 같은 값을 넣고 함수 f를 호출하면 항상 f(x)라는 결과가 나온다.
프로그램의 동작을 이해하고 예측하기가 훨씬 쉽게 된다.
이것이 함수형 프로그래밍으로 개발하려는 핵심 동기중 하나이다


2.3.3 JavaScript
2.3.4 Go
구글 개발팀에서 만든 언어...아직은...좀....근데 잘 돌아가는 게 많음

2.4 실시간 아키텍처 체크리스트

각자의 목적이 있으며, 어떤 일반적인 방법으로 그것들을 비교하는 것은 핵심을 놓치는 일이다.
어느 패키지, 프레임워크 언어가 주어진 환경에서 가장 잘 동작하는가에 대한 간단한 의견을 제시한다.

2.4.1 수집
아까 JSON, 쓰리프트, 프로토버프 이야기가 나왔는데 이번에는
언어를 뭐로 쓸것인가 인데, JAVA도 좋긴하나 스칼라의 수집라이브러리나 경량 프레임 워크를 쓰라고 가이드한다.
Go 도 자주 쓰인다고 한다. 5만이상의 동시 연결은 Go에서 통상적인 것이다. ....하하하하

2.4.2 테이터 흐름
통합되어야 할 시스템이 있으면 플룸
아니면 카프카지..

2.4.3 처리
스톰이나 삼자이냐 인데
삼자가 스톰보다 설계가 명료하고 카프카를 네이티브하게 지원해 카프카 기반 환경과 쉽게 통합될 수 있다. 처음 사용자에게는 스톰이 더 좋은 프레임워크이다.

2.4.4 저장소
레디스 - 개념확인 메모리 데이터베이스 소규모(레디스 3.0 부터는 클러스터 지원됨)
카산드라 - 매우많은 데이터 (디스크 기반, SSD 쓰면 좋다)
몽고DB - 풍부한 자료구조

2.4.5 전달
SSE 가 좋은 경우도 있다.
웹소켓은 비 HTTP 기반이다 SSE 는 단순히 HTTP 연결이므로 구 버전 브라우저에서도 폴리필(Polyfill)을 사용해 SSE 를 시뮬레이션 할 수 있다. 아까 SSE 는 단방향에 유리하고 WebSocket 은 양방향에 유리하다고 해따.

2.5 마치며
이제 주키퍼 부터 실전에서 다루어 보아라....





* 람다 아키텍처
http://bcho.tistory.com/984





이 게시물은 그냥 혼자 생각을 정리중인 페이지 이므로 틀린 내용이 있을수 있다.

 

수집 - 처리 - 시각화 - 분석 을 분산시스템을 이용해 빠르고 효율적으로 하자

Streaming 처리에서 주요 포인트 : 가용성, 확장성, 응답대기시간

항상 켜저 있는 데이터 상태, 느슨하며 변화하는 자료구조, 높은 카디널리티 차원의 문제가 항상 뒤따른다.


ELK

Elastic Search 검색엔진

Logstash - collect parse transform log (로그수집)

Kibana 시각화


hortonworks 제공 엔터프라이즈 hadoop

YARN (HDFS 위에 올라가 있는 Data Operating System) Cluster Resource Management


Pig (Script)

Hive (SQL)

Cascading (Java Scala)

HBase (NoSQL)

Storm (Stream)

Spark (In-Memory) Storm 과 Spark 는 비슷하지만 인메모리라는 점에서 Spark 가 훨씬 빠르다.

Solr (Search)

others




ZooKeeper : 분산 lock 제어, 통합설정관리, 네이밍 서비스, 단일 시퀀스, 클러스터 멤버쉽, life 상태 자원모니터링

http://techblog.netflix.com/2012/04/introducing-exhibitor-supervisor-system.html

 

Kafka 분산 메시지 처리

http://www.infoq.com/articles/apache-kafka

차세대 분산 메시지 처리 시스템 열라게 빠름 ZooKeeper 위에서 동작

 

 

 

 

 

 

 

 

Flume 분산 로그 수집

Flume은 스트림 지향의 데이터 플로우를 기반으로 하며 지정된 모든 서버로 부터 로그를 수집한 후 하둡 HDFS와 같은 중앙 저장소에 적재하여 분석하는 시스템을 구축해야 할 때 적합하다. 

http://www.nextree.co.kr/p2704/


 


Storm

실시간 스트림 데이터 처리 프레임워크로 불리며, ETL의 Transform 을 담당한다고 보면 된다.

kafka 로 수집한 메시지 정보를 어떤 규칙에 따라 가공해야 할 경우 Storm 을 이용한다

이 후 저장을 위해서는 Hbase 에 저장한다.

https://storm.apache.org/


Hive

페이스북에서 개발한 hadoop 용 SQL (비교적 느림) 그들의 경쟁자 클라우데라 임팔라 Impala 타조 tajo 샤크 shark

맵리듀스의 한계로 상호작용적 분석에는 부적합

 

SQL in hadoop 아파치 하이브, 스팅어(차세대 하이브를 이끌기위한 광범위한 커뮤니티의 노력)

SQL on 클라우데라 임팔라, 페이스북 프레스토, IBM big SQL, 아파치 Tajo, 피보탈 HAWQ

상호작용 분석을 위해 다양한 기법 적용 in-memory, MPP, LLVM

 

HBase

레코드 단위의 실시간 처리를 위한 NoSQL 카산드라 몽고디비 등 결쟁제품과 달리 하둡 클러스터에서 동작

 

Phoenix

세일즈포스에서 공개, 복합키 스킵 스캔, 이차 색인 등 다양한 퇴적화 도입 되었으나, 고급 분석함수와 조인 등의 SQL 기능 구현이 부족한 부분이 있어 보완할 방법이 필요하다. 사실 데이터 로컬리티 문제로 MPP 상용 데이터베이스에서도 문제를 해결하기 어려워하는 부분이 있다.

 

Tajo

하이브의 맵리듀스 등 병목구간을 제거한 분산 데이터웨어하우스. 한국 업체인 그루터 등이 참여

SQL분석가능 DB Client 이용 분석

빅데이터 잘 몰라도 사용관리 가능

column based partirioning table 가능

 

 

Tapole (올챙이)

하이브 등 다양한 DB를 지워하는 편리한 웹 DB 클라이언트

Tajo 등 JDBC 커넥터를 제공하는 데이터베이스 클라이언트 툴

 

 

Pig

하둡 데이터 처리용 스크립트 언어

 

Kinesis

스트림 기반으로 데이터를 수집하고 KCL (Kinesis client library) 를 이용하여 Kinesis에 저장된 데이터를 KCL 데몬을 이용하여 S3에 저장. 잘쓰면 가격이 싸단다. 암호화 인증처리 해줘야 한다.

Kinesis firehose : KCL 이 필요없으면 이게 더 편할수 있음

 

EC2 Spot Instance

싸게 입찰받으면 쓰고 있다가 상위 입찰자가 나타나면 2분전 알람을 주고 바로 회수함

 

Flink

Streaming dataflow 엔진을 기반으로 한 스트리밍 & 배치 프로세싱 플랫폼

 

Pinpoint

대구모 분산 시스템의 성능을 분석하고 문제를 진단 처리하는 플랫폼

bytecode instrumentation 방식 읽어보니 쥑이는디~

http://d2.naver.com/helloworld/1194202

 


Zeppelin

Spark 코드를 작성/관리/실행할 수 있고 데이터 visualization 까지 한번에 할 수 있는 툴

HDFS/HBase/MapReduce -> Spark 한방에 메모리에서

코드도 훨씬 쉬움

이걸로 가야겠네....


EMR

Amazone Elastic MapReduce



 

 

 

 

 

 

딴 이야기

protoNow

기획자, 디자이너, 개발자의 스마트한 프로토타이핑 툴

서마트한 협업!

http://dev.naver.com/projects/prtnow

 

 

 

 

실시간 처리와 분석은 내가 보기엔 좀 다른 이야기 인듯하다.

 

중 소 규모(수 TB이하)의 로그 분석이나 데이터 분석은 아파치 관련 솔루션은 별로인듯 하다. 예를들면 1TB 로그를 분석하기 위해서 하둡애코 시스템을 사용한다. 라고 생각하면 좀 바보스러운 짓인듯 하다. 전통적인 오라클 엑사 데이터나 SQL Server 2016으로 수 TB 분석은 서버 1대로 대부분의 결과를 수초에서 수분대에 커버 가능다. 로그에서 어떤 패턴을 찾는데 이런 공개 솔루션들은 오히려 시스템을 꾸미고 새로운 영역을 배워야 하는 입장일때 지원을 충분히 받을수 없다는 것은 큰 부담일 수 있다. 하지만, 이런 상용 데이터베이스(엑사 데이터, SQL Server 2016)를 비용 문제로 쓸 수 없다면 문제는 달라진다.

 

비교적 작은(수 TB) 데이터로 부터 패턴을 찾고 내용을 분석하기 위해서는 전통적인 접근이 훨씬 빨라 보이고 알고있는 특정 이벤트를 값싸게 찾는것은 무료 솔루션이 확실히 이득이 있는듯 하다. 또는 초 대형(수 PB) 인프라를 꾸미기 위해서는 이런 오픈소스 기반의 분산 분석 시스템만이 답일수도 있다. 내가 하는것이 무엇인지 정확히 인지해야 할 듯 하다.

 

일단 분석이 되어 어떤 이벤트를 모니터링 해야겠다는 것이 결정되면 시스템은 무료로 충분히 꾸밀 수 있다. 근데 뭘 모니터링 할것인가? ....찾아야 한다. 필요한게 뭔지는 운영자 개발자들이 가장 많이 알고 있지 않을까? 우리 시스템에서 무엇을 어떤 시간안에 모니터링 해야 하는데 하지 못하는게 무엇인가?는 인터뷰가 가장 빠르지 않을까? 분석이 되어 모니터링 해야할 이벤트가 정해지면 그 때 실시간 분석이 뒤따른다. 가장 중요한것은 도메인 전문가 인듯...

 

 

 

모니터링 할 이벤트가 정해지면 그에 따른 최적의 솔루션을 찾아야 한다. 로그 수집서버를 꾸민다면 플룸이 좋은듯 하고, 실시간 분석은 spark 제플린에 따라갈 것이 없을듯 하다. 이건 이후 문제인듯


 

저작자 표시 비영리 변경 금지
신고
Posted by 보미아빠

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

티스토리 툴바