채니의 mimimimamimimo 블로그

오픈소스란? 소스코드를 공개하여 누구나 수정,배포할 수 있게 만든 소프트웨어

1980년대부터 하드웨어 뿐만이 아니라 소프트웨어에도 저작권이 필요하다는 인식이 생겼다. (빌게이츠 힘씀)

그래서 라이센스가 생겨서 모두 돈주고 쓰게 됐지만 여기에 반감을 가진 사람들이 프리웨어 선언을 함!

*프리웨어-공짜가 아니라 수정,재배포가 자유롭게 가능하다는 것

ㄴ리눅스->레드햇,우분투,데비안

ㄴ그 외->안드,크롬,mysql.. : 아, 오픈소스의 정의를 정확히 알게 되니 왜 mysql이 오픈소스라서 써야하는지 알겠군! 안드는 근데 오픈소스라도 수정은 구글만 가능함.

+권한을 사용자에게 더 줄 거냐, 원 저작자에게 더 줄거냐의 문제?

원저작자에게...:

GPL  (마음대로 쓸 수는 있지만 수정한 것은 수정한 것도 오픈해야함. 기업이 불리),

LGPL  (LGPL은 less gpl로, 컴파일 된 파일을 호출만 하는거면 공개안해도 된다는거)

사용자에게...

MIT,BSD,Apache  (수정한 뒤 오픈하지 않아도 됨. 되도록 이 쪽 라이센스를 쓰자!)

+모바일 측면(갑자기 왜 나오는지는 모르겠지만..)

v1~v3.0/v3.1~v5.0/v5.1~

같은 안드로이드라도 이렇게 세가지 다른 os다. 메모리 관리법이 다르기 때문.

초기버전은 지원하려면 3배는 많은 비용이 드는데 아직 동남아는 초기버전 쓰는 곳 많아서

지원범위 정할 때 신중히..! (앱 성공하려면 중국진출을 해야한다..)

중국은 aosp라고 안드중에서도 딴거 다 뺴고 os만 들어있는 os 기반으로 쓴다. 즉

한국의 안드개발자와 중국의 안드개발자 스타일 많이 다르다는 것.

~~~모바일에선 사용자가 많아도 수익이 적다.

장비나 오라클 사지도 못하고, 많은 사용자를 어떻게 견디냐?

그 대안으로 백엔드도 오픈소스화 되는거임(아 모바일 때문에 오픈소스가 중요해진거구나..)

~~~

+백엔드 측면

Node.js를 예로 들자. 이 기술의 장점은~

->싱글스레드 사용.(여기서 os 공부한게 도움이 되는구나!ㅠㅠ)

원래 user level에서 락킹(멀티스레드에서만 고려)걸고 이런 저런 처리를 하는데 node.js는 커널레벨에서 처리. golang도 즉, cpu가 4개면 스레드 하나만 뜨는게 아니라 cpu갯수만큼 스레드 띄우고

모든걸 비공개로 해서 콜백만 받아서 처리함으로서 개발자의 실수를 줄인다. 

->npm(노드를 사용한 라이브러리 집합)이 엄청 커짐. 개발 생산성이 높아짐

->논블로킹 I/O

유저레벨의 io작업때문에 다른 유저레벨의 스레드가 기다리는게 아니라 io를 커널에 위임해뒀다가 호출하는 구조임.

->node.js의 js는 사실 껍데기고, 그 안의 소스는 사실 c++로 되어있어서 빠르다

이렇기 때문에, 어디에 적합하냐면~~

->restful api에 적합.

->db에 접속해서 data 가져오는 등 많은 I/O를 처리하는데 적합하다.

->실시간 처리에 강함

//여기까지 이해 잘 안가면 운영체제 카테고리의 글들 다시 읽자

어디에 부적합하냐면~~

->멀티스레드 앱

->큰데이터 연산(게다가 이건 python으로 다하지)

->cpiu 부하걸리는 작업(=> golang이 보완책)

->복잡한 비즈니스 로직(스프링이 건재한 이유. 스프링 클라우드 생기면서...자바가 강하게 지키고 있다)

아 이래서, node.js거리는구나! 그리고 각각 맞는 분야가 있으니 무작정 spring 버리자는거도 아님!

경사 오진당~~~~

여기부터 좀 가볍게 적는다!

+DB 측면

+mongoDB

NoSQL 사용하는 DBMS 종류이다. 

NoSQL은 스키마가 없고, 데이터가 삽입될 때 스키마하 함께 추가되는 것이 특징이다.(자세한 것은 db 카테고리 글)

+json은 텍스트, 바이너리로 바꾼건 bson

몽고db,,약간 하둡처럼 master와 여러대의 slave로 아키텍쳐가 이루어져 있다.

하둡도 비정형 데이터 대상이라서 그런가?

+오토샤딩 지원!(샤딩은 nodql 글에서 전체 갱신문제 관련)

+redis

read의 성능을 어떻게 더 끌어낼 것인가?

+이런 분산환경들을 관리하는 오픈소스가 zookeeper,etcd 등이 있음.

+클라우드 측면..

사용자 특정 시간에만 늘어나면 그 시간 전에 서버 쉽게 추가하도록 스케줄링 가능. 

글로벌하게 서비스가 성장할 경우(직접 방문해서 다 하는게 아니라 aws 같은 애한테 맡김)

but 공유자원이기 때문에 IOPS 문제 보장 안될 때가 있음. 그러니 그거 보완은 사서 써야함.  많이 비쌈.

클라우드 환경에서 고려해야할 것 몇 가지

1.IOPS

2.Disk Queue Length

3.CPU Steal Time

+aws는 1년에 20시간은 장애나도 보장안하니 애저를 하나 더 돌리고 있거나 백업서버 준비해야함

클라우드 문제 발생할 가능성 많은데 여기 적진 않을 것. 필요시 찾아보자

오픈스택 캠프 참고

스케일업/아웃 비용->하둡 글

그래서 서비스가 돌아가면 이런 구조로 돌아간다! 굉장히 복잡...이렇게 큰 구조를 가장 빡세게 쓰는 곳은 현재

넷플릭스. aws에서 모든걸 하고있다. aws에서 로드밸런싱 처리, 특정부하 이상오면 튕기는 서킷브레이크,로그를 처리하는 ELK 스택 등의 일을

처리하는게 스프링 클라우드임. 이래서 아직 자바는 죽지 않은거고..너무 복잡한 서비스는 스프링 쓰는거구나.

*hadoop 2.0 기준* 

#빅데이터 청년인재 2기

#부산정보산업진흥원 하둡기반 빅데이터 처리

# https://www.slideshare.net/KeeyongHan/hadoop-introduction-10

# https://cskstory.tistory.com/entry/%EB%A7%B5%EB%A6%AC%EB%93%80%EC%8A%A4-MapReduce-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

사전지식

빅데이터 분석 프로세스

RDBMS와 NRDBMS의 차이

RDBMS)관계형 데이터베이스다. 그래서 관계가 깨지면 의미가 없어지므로 데이터 무결성이 중요하고, 무결성을 위해서 스키마로 데이터 입력을 거르는 것이다. 하지만 이렇게 하면 입력되지 않는 데이터가 발생한다. 대표적 문법으로 sql

NRDBMS)비관계형 데이터베이스다. 위와 다르게 스키마가 없다. 예를 들어서, char의 길이를 10까지 할당할 수 있을 때 길이11의 char가 들어오면 할당 가능 길이를 11로 동적으로 바꿔준다(?).  하지만, 기존 데이터에서 수정을 하려면 모든 데이터를 다시 만들어야해서 (?) 사용성이 떨어진다. 대표적 문법으로 Nosql(Not only sql)

하둡은 NRDBMS를 기반으로 한다. 

텍스트 데이터 위주였던 과거와 달리, 이미지와 영상과 같은 비정형 데이터들이 급격히 증가하기 때문에 그것을 처리하는 것이 많이 연구되고 있다.

분산파일시스템

컴퓨터 네트워크를 통해 공유하는 여러 호스트 컴퓨터의 파일에 접근할 수 있게 하는 파일 시스템이다. 

네트워크를 통해 접근하는 파일들은 프로그램과 사용자의 하나의 로컬 디스크에 있는 파일처럼 다룰 수 있다.

즉, 서버증설시 스케일아웃이 되는데

스케일아웃은 저렴한 서버를 여러대 쓰기 때문에 비용이 저렴하고, 장애가 생기더라도 전체가 마비되지 않는다.

하지만, 분산해서 처리하기 때문에 관리 편의성이 떨어진다. (병렬적인 처리:웹 앱, 분산처리 등에 쓰임)

스케일업은 하나의 서버를 비싼 것으로 맞춰두고 더 필요하면 더 좋은 하드웨어를 계속 달아가는 것이다. 관리에는 편하지만 비용증가의 부담이 크고 확장에는 한계가 있다. 또한, 일부가 마비되면 전체가 마비될 수 있다.

일괄처리방식(batch),실시간 시스템

일괄처리방식) 일정 기간마다 주기적으로 한꺼번에 업무 처리...Hadoop ..why?)

실시간시스템)  작업 수행이 요청되었을 때, 이를 제한된 시간안에 처리해 결과를 내주는 것

소개

아파치 하둡은 대량의 데이터를 처리할 수 있는 큰 컴퓨터 클러스터에서 동작하는 분산 응용 프로그램을 지원하는 프리웨어 자바 소프트웨어 프레임워크이다. 분산처리 시스템인 구글 파일 시스템을 대체할 수 있는 하둡 분산 파일 시스템(HDFS)과 분산처리시스템(MapReduce)를 구현한 것이다.

배경

2006년 야후에서 일하던 더그 커팅이 구글 분산파일시스템에 대응하는 무료 라이브러리를 개발하고자 했고, 개발된 이후 아파치 재단으로 넘어가 관리되는 중이다.

구조

+namenode~datanode부분 글씨 너무 작아서...

->통신으로 3초마다 heartbeat 체크. 에러나면 그 노드 버리고 다른 노드로 블록 복사한다.

클라이언트가 파일을 쓰려면, 먼저 파일을 로컬에 저장한다.

만약 파일크기가 정했던 블록 크기를 넘으면 Namenode를 만나고, Namenode는 블록이 저장될 시작위치와 간격(Datanode사이의)을 클라이언트에게 전달함. 클라이언트는 받은 데이터노드 첫부분부터 차례로 저장되고, 이 과정을 replication pipelining이라 함.

클라이언트가 파일을 읽으려면, Namenode에게서 블록ID를 받아내서 읽는다. (블록 크기 넘으면 ID를 여러개 받는다)

클라이언트가 하둡 잡 실행을 요청하면 하나의 잡 요청(맵리듀스코드 jar파일,입력위치,출력위치 등)을 JobTracker가 받고, 그

매퍼와 리듀스들을 TaskTracker에서 나누어준다. 

이 과정을 하둡 웹 인터페이스로 확인할 수도 있다.

분산처리방식, 연속적인 작업을 나눠서 처리한다는 것부터 작업의 부분 부분이 서로 종속성이 없다는 것을 뜻한다. 

그 대표적인 경우를 txt파일에서 어떤 단어의 카운트를 하는 것이라고 할 수 있다.

txt파일에서 서로 연관성이 없기 때문에 파일을 나눠 가지고 각각의 카운트를 한 뒤에 취합해서 총 합을 구해주면 된다.

여기서, 각각의 카운트를 하는 과정:맵리듀스의 매퍼 역할

총 합을 구하는 과정: 맵리듀스의 리듀스 역할

위의 그림이 일련의 과정이다. 왼쪽에서 오른쪽으로 갈수록 맵의 크기가 작아지므로, 맵리듀스라고 부른다. 

맵리듀스 알고리즘은 가장 단순하게 만들어야한다. 그래야 수많은 서버에 흩어서 병렬로 처리할 수 있기 때문이다. 처리의 순서가 중요하다든지 실패했을때 다시하려면 몇단계 전으로 돌아가야 하는 상황은 있어서 안된다. 즉, 기준이 되는 값은 하나여야 한다.(이 말 매우 격공...알고리즘 풀 때 자꾸 예외에서 걸리는걸 느끼고 모든 경우를 고려하려면 단순해야 한다는걸 느낀 적이 있지)

자세한 설명은 아래 링크를..

https://cskstory.tistory.com/entry/%EB%A7%B5%EB%A6%AC%EB%93%80%EC%8A%A4-MapReduce-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

구성

-HDFS (공통 패키지)

-MaReduce (공통 패키지)

-OS level abstraction (공통 패키지)

-하둡 에코시스템(관련 패키지)

-Jar file

-하둡 구동 스크립트

확장

취사선택해서 아키텍쳐 구성하면 된다.(대신 릴리즈 호환성이 문제될 수 있으니 주의!)

장점,쓰이는 곳

-오프라인 배치 프로세싱에 최적화

-소수의 비싼 서버보다 다수의 저렴한 서버 이용 가능

-데이터의 지역성을 최대한 이용함

-병렬도 높은 처리: Text Grep,Web Crawling..

-로그분석

-머신러닝:Search Ranking..

단점,주의할 점

-소규모이거나 대용량(페타바이트급) 처리가 필요하지 않으면 옮길 이유 없음

-스킬셋으로 가진 사람 드물고 서포트 부실

-추가는 가능하지만 수정은 파일전체 새로 써야함 (그래서 상용으로는 못쓰고 분석,시각화로만 쓴다)

-실시간 처리 불가

이 기술에 관한 고찰

-SPARK와의 비교

스트리밍 데이터 처리 가능과 불가능의 차이. 하지만 스파크도 결국 하둡 파일시스템을 쓰고  각각 다른 것이지

어느 것이 좋다고 비교할 수 없다. 스파크는 ram에서 돌리고 하둡은 애초에 ram에 올리기 너무 커서 느려도 디스크에서(?) 작업하되 병렬처리를 하는 것이기 때문이다. 매우매우 크지 않으면 스파크를 쓰는 것이 유연하다고 생각이 든다. 

-버전 1과의 비교

노드 다 올라오는거 확인하고 env파일 하나하나 안써도 되는거