out_of_anjoong.dev

먼저 객체 지향 프로그래밍이란 인간 중심적 프로그래밍 패러다임이라고 할 수 있습니다. 현실 세계의 사물들을 객체라고 보고 그 객체로부터 개발하고자 하는 애플리케이션에 필요한 특징들을 프로그래밍 하는 것이다. 객체는 속성과 기능으로 이루어져 있다.

장점과 단점

💡장점
- 모듈화, 캡슐화로 인해 유지보수에 용이하다.
- 객체 자체가 하나의 프로그램이기에 재사용에 용이하다.
- 에러를 컴파일 단계에서 잡아낼 수 있으므로 버그 발생이 줄어듦.
- 데이터 모델링을 할 때 객체와 매핑하는 것이 수월하기 때문에 요구사항을 보다 명확하게 파악 가능하다.

💡단점
- 대부분의 객체지향 프로그램은 속도가 상대적으로 느려지고, 메모리를 많이 사용하는 경향이 있다.
- 객체 간의 정보 교환이 모두 메시지 교환을 통해 일어나므로 실행 시스템에 많은 overhead가 발생한다.
- 코드를 설계하고 작성하는데에 많은 시간이 소요된다.

4가지 특징

• 추상화
  - 어떤 대상/집단의 공통적이면서 본질적인 특징을 추출하여 정의하는 것
• 상속
  - 상위 클래스의 모든 것을 하위 클래스가 이어받는 것.
  - 기존에 구현한 클래스를 재활용 함으로써 코드 재사용성을 높일 수 있음.
• 다형성
  - 어떤 객체의 속성이나 기능이 상황에 따라 여러 형태로 변할 수 있다는 것을 의미
  - 메서드 오버라이딩/오버로딩이 있다.
  - 오버로딩 : 같은 이름의 메서드 여러개를 가지면서 매개변수의 유형과 개수를 다르게 하여 다양한 유형의 호출에 응답할 수 있게 하는 기술
  - 오버라이딩 : 상위 클래스가 가지고 있는 메서드를 하위 클래스가 재정의해서 사용
• 캡슐화 : 데이터와 코드의 형태를 외부로부터 알 수 없게하고, 데이터의 구조와 역할, 기능을 하나의 캡슐 형태로 만드는 방법

객체 지향 설계의 5원칙 S.O.L.I.D

• SRP(Single Responsibility Principle) : 단일 책임 원칙
  - 클래스는 단 하나의 책임만 가져야 한다는 원칙
  - 책임은 하나의 '기능 담당' 으로 보면 됨.
  - 한 책임의 변경으로부터 다른 책임이 변경이 되는 연쇄작용 방지.
• OCP(Open Closed Principle) : 개방 폐쇄 원칙
  - 확장에 열려있어야 하며 수정에는 닫혀있어야 한다는 원칙
  - 새로운 변경 사항이 발생했을 때
      - 유연하게 코드를 추가함으로써 애플리케이션 기능을 확장. (확장에 열려있음)
      - 객체를 직접적으로 수정을 제한함. (수정에 닫혀있음)
• LSP(Listov Substitution Principle) : 리스코프 치환 원칙
  - 서브 타입은 언제나 부모 타입으로 교체할 수 있어야 한다는 원칙
  - 다형성 원리를 이용하기 위한 원칙
• ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
  - 인터페이스를 각각 사용에 맞게 잘게 분리해야 한다는 설계 원칙
  - 인터페이스를 사용하는 클라이언트를 기준으로 분리함으로써 클라이언트의 목적과 용도에 적합한 인터페이스를 제공하는 것이 목표
• DIP(Dependency Inversion Principle) : 의존 역전 원칙
  - 어떤 클래스를 참조해서 사용해야하는 상황에 그 클래스를 직접 참조하는 것이 아니라 그 대상의 상위 요소(추상 클래스 or 인터페이스)를 참조하라는 원칙
  - 클래스간의 결합도(coupling)을 낮추는 것

사용법

1. 문자열 합치기
SELECT CONCAT('문자열', '합치기');
-> 문자열합치기

2. 숫자 합치기
SELECT CONCAT(123, 456, 789);
-> 123456789

3. 숫자와 문자 합치기
SELECT CONCAT('문자열', 1004)
-> 문자열1004

대화형 셸

pyspark
#1 어디 폴더 아래서든 터미널에서 입력

./pyspark
#2 bin 폴더에서 입력

1. pip install pyspark로 설치.
2. apache spark 다운로드 페이지에서 다운.

스파크 애플리케이션

• 애플리케이션
  API를 써서 스파크 위에서 돌아가는 사용자 프로그램. 드라이버 프로그램과 클러스터의 실행기로 이루어져 있습니다.
• SparkSession
  스파크 코어 기능들과 상호 작용할 수 있는 진입점을 제공하며 그 API로 프로그래밍을 할 수 있게 해주는 객체. 스파크 셸에서 스파크 드라이버는 기본적으로 SparkSession을 제공하지만 스파크 애플리케이션에서는 사용자가 객체를 생성해서 써야 합니다.
• 잡(job)
  스파크 액션(save(), collect() 등)에 대한 응답으로 생성되는 여러 태스크로 이루어진 병렬 연산.
• 스테이지(stage)
  각 잡은 스테이지라 불리는 서로 의존성을 가지는 다수의 태스크 모음으로 나뉩니다.
• 태스크(task)
  스파크 이그제큐터로 보내지는 작업 실행의 가장 기본적인 단위.

• 애플리케이션 안의 드라이버가 스파크세션 객체 생성.
• 스파크 셸을 사용할 땐 셸에 포함되어있는 형태이며 SparkSession 객체가 미리 만들어진다.
• 스파크 셸로 상호 작용하는 작업 동안 드라이버는 스파크 애플리케이션을 하나 이상의 스파크 잡으로 변환한다. 그리고 각 잡은 DAG로 변환된다. 또한 DAG에서 각각의 노드는 하나 이상의 스파크 스테이지에 해당한다.
• 어떤 작업이 연속적 또는 병렬적으로 수행되는지에 맞춰 스테이지에 해당하는 DAG 노드가 생성된다. 종종 스파크 이그제큐터끼리의 데이터 전송이 이루어지는 연산 범위 경계 위에서 스테이지가 결정되기도 한다.(셔플이라 불리는 노드끼리의 데이터 교환이 스테이지의 경계가 되는 경우)
• 각 스테이지는 최소 실행 단위이며 스파크 이그제큐터들 위에서 연합 실행되는 스파크 태스크들로 이루어진다. 각 태스크는 개별 CPU 코어에 할당되고 데이터의 개별 파티션을 갖고 작업한다. 이렇게 병렬처리가 되는 것.

트랜스포메이션, 액션, 지연 평가

• 트랜스포메이션
  • 이미 불변성의 특징을 가진 원본 데이터를 수정하지 않고 하나의 스파크 데이터 프레임을 새로운 데이터 프레임으로 변형.
  • 트랜스포메이션의 결과는 즉시 계산되는 것이 아니라 계보(lineage)라 불리는 형태로 기록된다. 기록된 리니지는 실행 계획에서 후반쯤에 스파크가 확실한 트랜스포메이션들끼리 재배열하거나 합치거나 해서 더 효육적으로 실행할 수 있도록 최적화.
  • 스파크는 리니지에 각 트랜스포메이션을 기록해 놓고 데이터 프레임들은 과정 중 변하지 않기 때문에 단순히 기록된 리니지를 재실행하는 것만으로도 복원할 수 있으며 덕분에 장애 상황에도 유연성을 확보할 수 있다.
  • 의존성의 정도에 따라 두가지로 분류된다.
    • 좁은 의존성 : 하나의 입력 파티션을 연산하여 하나의 결과 파티션을 내놓는 트랜스포메이션
      예) filter(), contains()
    • 넓은 의존성 : 하나의 입력 파티션을 연산하여 여러 결과 파티션을 내놓는 트랜스포메이션
      예) orderBy(), groupBy()
  • 예 : orderBy(), groupBy(), filter(), select(), join() 
• 액션
  • 하나의 액션은 모든 기록된 트랜스포메이션의 지연 연산을 발동시킨다.
  • 쿼리 계획 안의 어떤 것도 액션이 호출되기 전에는 실행되지 않음.
  • 쿼리 실행 계획의 일부로서 기록된 모든 트랜스포메이션들의 실행을 시작하게 한다.
  • 예 : show(), take(), count(), collect(), save()
• 지연평가
  • 액션이 실행되는 시점이나 데이터에 실제 접근하는 시점까지 실제 실행을 미루는 스파크의 전략.
  • 스파크가 사용자의 연계된 트랜스포메이션들을 살펴봄으로써 쿼리 최적화를 가능하게 하지만 리니지와 데이터의 불변성은 장애에 대한 데이터 내구성을 제공.

스파크 UI

스파크가 배포된 방식에 맞춰 드라이버가 웹 UI를 띄우게 되며 기본적으로 4040 포트를 사용한다.(http://localhost:4040)
스파크 UI에서는 다음과 같은 다양한 수치와 내용을 볼 수 있다.

• 스케줄러의 스테이지와 태스크 목록
• RDD 크기와 메모리 사용의 요약
• 환경 정보
• 실행 중인 이그제큐터 정보
• 모든 스파크 SQL 쿼리