세상의 모든 Software 지식을 정리

Handler 객체가 Post 메소드 안에 Runnable객체를 넣는 의미가 직접적으로 이해 되지 않아 문서를 본 결과. The  post  versions allow you to enqueue Runnable objects to be called by the message queue when they are received 상대방 측에서 메시지 큐로 부터 수신 했을 떄, 해당 Runnable 즉, 쓰레드 안에서 정의된 로직을 호출한다는 것이다.

1. name : 프로젝트 이름 2. version : 프로젝트 버전 3. scalaVersion : 스칼라 버전 4. libraryDependencies : 의존하는 라이브러리 들을 설정한다. 또한 해당 라이브러리가 빌드 시점 중 어느 시점에 의존할지 설정한다. (예를들어 컴파일할 떄, 패키징 할 때) 5. assemblyOption in assembly : set-assembly  플러그인의 옵션 libraryDependencies에는 sbt가 관리하는 프로젝트가 의존하는 라이브러리를 설정하는데, Seq형식으로 설정한다. 여러개가 존재하는 경우 쉼표를 통해 구분하며, 하나의 의존라이브러리는 "<groupId> % <artifactId> % <version>" % "<configuration>" 형식으로 지정한다. <configuration>은 해당 라이브러리가 어느 의존 단계에 포함되어야 할지를 의미한다. provided 인 경우는 컴파일 단계에는 클래스패스에 포함되고, 패키지 단계에서는 포함되지 않는 것이다.

로그 파일, 네트워크 튜닝, I/O튜닝, 파일 시스템 튜닝, 압축 등 하부 시스템 설정 파일 core-site.xml 파일은 HDFS와 맵리듀스에서 공통적으로 사용할 환경정보를 설정한다. core-site.xml파일이 없을 경우 core-default.xml을 오버라이드 한다. 참고 :  http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/core-default.xml

1. reset은 그 이전으로 이력을 다시 돌리는 것이고 2. revert는 이전 이력은 그대로 두고, 그 되돌릴 커밋의 코드만 원복시키는 것 ========================================================== 1.  Reset  1. git reset <옵션> <돌아가고싶은 커밋> 옵션의 종류는 hard, mixed, soft 세가지 존재 예) 해당 커밋이후의 이력은 표를 예매하고, 팝콘과 사이다를 구매 1) hard 돌아가려는 이력이후의 모든 내용을 지워버린다. 이렇게 하면 표를 예매하고, 팝콘과 사이다를 구매했던 모든 것들이 지워지고 모든것이 초기화 $ git reset --hard a3bbb3c 2) soft 돌아가려 했던 이력으로 되돌아 갔지만, 이후의 내용이 지워지지 않고, 해당 내용의 인덱스(또는 스테이지)도 그대로 있는 상태. 즉, 바로 다시 커밋할 수 있는 상태로 남은 것이다. 기억은 되돌렸지만, 표와 팝콘과 사이다는 손에 들려 있는 상태 $ git reset --soft a3bbb3c 3) mixed(옵션을 적지 않으면 mixed 로 동작) 역시 이력은 되돌려진다. 이후에 변경된 내용에 대해서는 남아있지만, 인덱스는 초기화된다. 커밋을 하려면 다시 변경된 내용은 추가해야하는 상태 $ git reset --mixed a3bbb3c 또는 되돌아가는 커밋을 커밋 해쉬를 통해서 직접 지정할 수도 있고, 현재부터 몇개의 커밋을 되돌릴 수 있다. $ git reset HEAD~6 위는 현재부터 6개 이전 이력으로 돌아가라고 상대적으로 지정 2. Revert Revert는 상태를 되돌린다고 볼 수 있다. 스포를 당한 커밋을  revert하고 현재 작성중인 코드만 본다면 reset과 동일한 (hard옵션 준거만 뺴고) 결과를 가집니다. 하지만 이력은 같지 않습니다. 이전 이력은 그대로 있고, 스

I/O 가 포함되지 않은 계산 중심의 동작을 실행할 떄는 스트림 인터페이스가 가장 구현하기 간단하며 효율적일 수 있다.(모든 스레드가 계산작업을 수행하는 과정에서는 프로세서 코어수 이상의 스레드를 가질 필요가 없다.) 반면 작업이  I/O 를 기다리는 작업을 병렬로 실행할 때는  CompletableFuture 가 더 많은 유연성을 제공하며 대기/계산(W/C) 의 비율에 적합한 스레드 수를 설정할 수 있다. 특히 스트림의 게으른 특성 때문에 스트림에서 I/O를 실제로 언제 처리할지 예측 하기 어려운 문제도 있다. ========================================================== 병렬 스트림에서는 스트림이 사용하는 쓰레드 풀의 크기가 고정되어 있어서 상점 수가 늘어나는경우 즉, 데이터 크기가 늘어나는 경우 유연하게 대응 할 수 없다.

1. RDD 의 구조와 특징 RDD는 대량의 데이터를 요소로 가지는 분산 컬렉션이다. 거대한 배열과 리스트 등의 자료구조를 생각하면 이해하기 쉽다. RDD는 여러 머신으로 구성된 클러스터 환경에서  분산처리를 위해 설계되었고, 내부는 파티션이라는 단위로 나뉜다. 스파크는 파티션이 분산처리 단위이다. RDD를 파티션 단위로 여러머신에서 처리하므로 한 대의 머신으로 처리할 수 있는 것보다 더 큰 데이터를 다룰 수 있다 사용자는 예를들어 HDFS 등의 분산 파일 시스템에 있는 파일 내용을 RDD로 로드하고, RDD를 가공하는 형식으로 대량의 데이터를 분산처리할 수 있다. 스파크에서는 이런 가공은 변환(transformation) 이라 할 수 있다. 그리고 RDD의 내용에 따라 액션이라는 처리를 적용하여 원하는 결과를 얻는다. 이밖에도 RDD에는 불변(immutable) 즉, 내부 요소 값이 변경 불가한 성질과, 생성이나 변환이 지연 평가되는 성질이 있따. 2. RDD 다루기 RDD에는 변환과 액션 두 종류의 처리를 적용할 수 있다. 변환(Transformation) 변환이란 RDD를 가공하고 그 결과 새로운 RDD를 얻는 처리다. 변환 처리 후의 RDD가 가지는 요소는 변환 처리 전의 RDD에 들어있던 요소를 가공하거나 필터링해 생성된다. 변환은 다시 두 종류로 구분된다. 첫 번째, 변환 처리 전의 RDD가 가지는 요소를, 같은 RDD의 다른 요소들과 관계없이 처리할 수 있는 종류 사각형은 RDD 둥근 사각형은 파티션 그 안에 있는 것은 요소이다. filter 요소를 필터링한다. map 각 요소에 동일한 처리를 적용한다. flatmap 각 요소에 동일한 처리를 적용하고 여러 개의 요소를 생성한다.

1. 활용 배경 반복적인 처리와 연속으로 이루어지는 변환처리의 고속화 시행착오에 적합한 환경 제공 서로 다른 처리를 통합해 이용할 수 있는 환경 제공 1-1. 반복적인 처리와 연속으로 이루어지는 변환처리의 고속화 특정한 데이터셋에 대해 반복처리와 연속으로 이루어지는 변환처리를 고속화할 목적으로 개발되었다. 그전에는 맵리듀스가 널리 활용 되었다. 데이터의 지역성을 의시간 처리와 내결함성 그리고 확장성 등의 기능을 종합적으로 제공함으로써 복수의 머신으로 구성된 환경을 통한 병렬분산머신 처리를 더 쉽게 실현할수 있게 되었고, 그 결과 맵리듀스는 대량의 데이터 처리가 필요한 사용자들에게 널리 보급되었다. 맵리듀스는 기본적으로 입력데이터를 스토리지에서 읽고 복수의 머신에서 분산처리를 수행한 후 그 결과를 스토리지에 보존한다. 이 처리가 한번에 끝나지 않는 경우에는 데이터 플로형식으로 처리되어 읽기 -> 분산처리 -> 보존을 반복 수행한다. 맵 리듀스의 단점은 중간과정을 모두 메모리에 담을 수 없다는 것이다. 하지만 하드웨어의 발전으로 메모리의 크기가 커지면서 모든 데이터를 메모리에 담을 수 있게 되며 스파크를 사용하게 되었다. 1-2. 시행착오에 적합한 환경 제공 지금까지는 데이터의 통계분석과 머신러닝과 같은 처리를 하려면 표 계산 소프트웨어, 파이썬, R, 매틀랩 또는 BI툴을 이용했다. 이러한 것들은 결과를 바로 얻을 수 있는 것이 특징이었고, 따라서 시행착오를 겪어가며 데이터 해석을 한정적으로 하기에 적합한 환경이라 할 수 있었다. 하지만 한 대의 서버에서 처리할 수 있는 용량을 넘어서는 데이터셋에 대해서는 이런 종류의 툴이 현실적이지 않다. 거대한 용량의 데이터를 다룰 떄는 스케일 아웃과 같은 방법을 선택하고 여러 대의 머신으로 구성해 병렬 분산처리를 수행할 필요가 있다. 1-3. 다양한 처리를 통합할 수 있는 유연한 환경 배치처리, 스트림처리, SQL처리, 머신러닝 그

1. 잡 패키징  로컬 잡 실행자는 잡을 실행할 떄 단일 JVM을 사용하므로 모든 잡에 필요한 모든 클래스가 로컬의 클래스 경로에 존재하면 문제없이 잘 동작한다. 하지만 분산환경은 조금 복잡하다. 잡을 시작할 떄  필요한 모든 클래스를 잡 JAR파일에 패키징해서 클러스터로 보내야한다. * 클라이언트 클래스 경로 hadoop jar <jar>로 지정하는 클라이언트의 클래스 경로는 다음과 같이 구성된다. 잡 JAR 파일 잡 JAR 파일의 lib 디렉토리에 있는 모든 JAR파일과 classes 디렉토리 HADOOP_CLASSPATH에 정의한 클래스 경로 이는 가끔 로컬 잡 실행자를 잡 JAR 파일 없이 실행 (hadoop CLASSNAME) 할 때 HADOOP_CLASSPATH 의존 클래스와 라이브러리를 지정해야 하는 이유를 설명해준다. * 태스크 클래스 경로 클러스터(의사분산 모드)에서 맵과 리듀스 태스크는 개별 JVM 으로 실행되며 클래스 경로로 HADOOP_CLASSPATH를 지정해도 소용없다.  HADOOP_CLASSPATH는 클라이언트 측 설정이며 따라서 잡을 제출하는 드라이버 JVM의 클래스 경로에만 해당되기떄문이다. 잡 JAR파일 잡 JAR파일의 lib 디렉토리에 있는 모든 JAR파일과 classes디렉토리 -libjars 옵션이나 DistributedCache 혹은 Job의 ddFileToClassPath()메소드를 사용해서 분산 캐시에 추가한 모든 파일 * 의존 라이브러리 패키징 클라이언트와 태스크의 클래스 경로를 지정하는 다양한 방식이 있고, 각 방식에 따라 잡의 의존 라이브러리를 포함하는 옵션이 있다. 라이브러리를 푼 후 잡 JAR에 넣고 다시 패키징 한다. 잡 JAR의 lib디렉토리에 라이브러리를 패키징한다. 잡 JAR와 다른 위치에 라이브러리를 두고, 이를 HADOOP_CLASSPATH와 -libjars를 이용해서 클라이언트의 클래스

1. version https://docs.docker.com/compose/compose-file/compose-versioning/ ========================================================== 1. List stacks or apps $ docker stack ls 2. Run the specified Compose file $ docker stack deploy -c <composefile> <appname> 3. List running services associated with an app $ docker service ls 4. List tasks associated with an app $ docker service ps <service> 5. Inspect task or container $ docker ========================================================== 2. Service 이 항목밑에 실행하려는 서비스를 기록한다 3. volumes docker run 으로앱 컨테이너를 실행할 때 --volume 을 사용하여 데이터를 로컬컴퓨터와 도커 컨테이너의 데이터를 연결하는 기능 4. environment  doker run 에서 -e 옵션에 적었던 내용들이다. 5. healthcheck 검사에 사용할 명령 (test)을 3초간격으로 열번시도하는 것 예) healthcheck :        test: "pg_isready -h localhost -p 5432 -q -U postgres"        interval: 3s       timeout: 1s        retries: 10 ========================================================= 예) docker run

1. FROM 어떤 이미지를 기반으로 할지 설정한다. Docker 이미지는 기존에 만들어진 이미지를 기반으로 생성한다. 예) <이미지이름>:<태그> 형식이다. (ubuntu:14.04) 2. MAINTAINER 메인테이너 정보이다. 3.  RUN Shell 스크립트 혹은 명령을 실행한다. 이미지 생성ㅈ 중에는 사용자 입력을 받을 수 없으므로  apt-get install 명령에서 -y 옵션을 사용한다. (yum install도 동일) 4.  VOLUME 호스트와 공유할 디렉토리 목록이다.  docker run 명령에서 -v 옵션으로 설정할 수 있다. 예) -v /root/data:/data  호스트의 /root/data 디렉토리를 도커 컨테이너의 /data 디렉토리에 연결한다. 5. CMD 컨테이너가 시작되었을 때, 실행할 실행 파일 또는 스크립트이다. 6. WORKDIR CMD 에서 설정한 실행 파일이 실행될 디렉토리이다. 7. EXPOSE 호스트와 연결할 포트번호