0. 들어가며 이번 시간에는, 파이썬의 데코레이터에 대해서 발표해보도록 하겠다. 1. Decorator 란? 파이썬을 사용하다보면, 함수 혹은 메서드 위에 “@” 골뱅이가 붙은 특이한 이름을 본 적이 있을 것이다. 이러한 특이한 문법을 decorator라고 하는데, 영어 사전에서 decorator는 “장식자”이라는 뜻을 가지고 있다. 파이썬의 decorator 역시 동일한 의미로 사용된다. 어떤 함수가 있을 때, 해당 함수를 직접 수정하지 않고, 함수에 기능을 추가 /변경 / 확장 하고자 할 때 decorator를 사용한다. decorator는 함수를 인자로 받고, 또 다른 함수를 반환하는 고차함수 이다. 고차함수 ? 함수를 인자로 받아서, 함수를 반환하는 함수 파이썬에서 함수는 일급 객체로 취급되기 때문에 가능하다. 일급객체 ? → 아래에서 살펴보자. 그렇다면, 도대체 어떤 기능 이길래 추가 /변경 / 확장 모두 가능한 것일까? 지금부터 알아보자. 1.1. 데코레이터 기본 예시

시작 하면서 최근 KRM ver2.0 프로젝트를 시작하면서 웹서버를 구현하기 위해 SQLAlchemy를 사용하면서 모델링을 했습니다. 작업을 하면서 SQLAlchemy에 대해 공부한 내용을 공유해 보겠습니다. SQLAlchemy? SQLAlchemy는 파이썬을 위한 SQL 툴킷 및 Object-Relational Mapping(ORM) 라이브러리로, 데이터베이스와의 상호작용을 보다 쉽고 직관적으로 할 수 있게 도와줍니다. SQLAlchemy는 데이터베이스 연결 관리, 트랜잭션 관리, 스키마 정의 및 관리 등 다양한 기능을 제공합니다. SQLAlchemy 구조 크게 Core와 ORM으로 나뉘어져 있습니다. Core (SQL Expression Language): SQLAlchemy의 Core는 SQL 표현 언어를 사용하여 데이터베이스 쿼리를 생성하고 실행하는 데 중점을 둡니다. SQLAlchemy Core는 SQL을 직접 작성하고 데이터베이스와 상호작용할 수 있는 저수준 인터페이스를 제공합니다. Engine 데이터베이스와의 연결을 관리하는 핵심 구성 요소입니다. Engine 객체는 데이터베이스와의 상호작용을 위한 연결 풀(Connection Pool) 및 데이터베이스 드라이버를 포함하여 SQLAlchemy의 다른 부분과의 통신을 조정 Engine의 주요 기능 데이터베이스 연결 설정: Engine은 데이터베이스 URL을 통해 데이터베이스 연결 정보를 설정합니다. 연결 풀 관리: Engine은 연결 풀을 관리하여 데이터베이스 연결의 효율성을 높이고 성능을 최적화합니다. 연결 풀은 데이터베이스 연결을 재사용하여 연결 생성 및 소멸에 따른 오버헤드를 줄입니다. 트랜잭션 관리:

안녕하세요! 오늘은 제가 Airflow를 사용하면서 겪었던 몇 가지 트러블슈팅 경험을 공유하고자 합니다. 제 경험이 여러분의 Airflow 작업에 도움이 되기를 바랍니다. 디렉토리 구조 제가 구성한 Airflow의 디렉토리 구조는 다음과 같습니다. 추가한 디렉토리에서 import 시 에러 발생 새로운 디렉토리인 config와 db에서 import하려고 시도했을 때 import 오류가 발생했습니다. 이는 프로젝트 경로를 path에 추가하여 해결했습니다. path를 추가하며 운영 환경과 개발 환경의 경로가 다르기 때문에 다른 문제가 발생했는데 이는 아래에서 다시 설명드리겠습니다. plugins와 dags/utils 처음에는 azure_conn과 slack_message 두 개의 스크립트를 plugins 디렉토리에 저장했습니다. 하지만 GCP Composer 서비스에서는 dags 폴더 하위에 폴더를 생성하도록 권장하기 때문에 코드 재사용성을 위해 두 스크립트를 dags/utils 디렉토리로 이동했습니다. plugins 디렉토리는 Airflow 시스템의 기본 기능 확장에 사용합니다. 출처: https://cloud.google.com/composer/docs/how-to/using/installing-python-dependencies?hl=ko#use_packages_that_depend_on_shared_object_libraries API 호출 에러 사례 스케줄러나 웹 UI를 통해 DAG를 실행할 때 Negsignal.SIGSEGV 오류가 발생하여 requests 호출이 중단되었습니다. 로컬에서 테스트 실행해 보니 문제 없이 동작했지만, 이 오류는 이미 GitHub 디스커션에 등록되어 있었습니다. 출처: https://github.com/apache/airflow/discussions/24463#discussioncomment-4404542 원인은 명확하게 밝혀지지 않았지만, macOS에서는 프록시 정보를 가져오는 시스템 호출이 특정 조건 하에서 예상치 못한 방식으로 작동하여 메모리 접근 오류인 SIGSEGV(세그먼테이션 폴트)를 발생시키는 것으로 추측됩니다. 해결방법은 dag에 아래의 코드를 추가해 프록시 설정을 초기화하였습니다. 실행 환경 차이로 인한 코드 불일치 위 에러들로 인해 실행 환경과 개발환경 간 코드가 불일치했습니다. 이를 해결하고자 config/airflow_config/config.json을 두어 실행 환경을 읽어 환경에 따라 같은 코드로 다르게 동작하도록 수정했습니다. Connections 등록 후 PW를 까먹은 경우

0. 들어가며 저번 시간에는 동시성. 즉, 제어권에 대한 Blocking/NonBolocking. 또 작업의 순서를 논하는 Sync/Async에 대해 간단하게 살펴보았다. 그렇다면 이번 시간에는 다음 순서로 파이썬의 GIL 및 스레드 환경에 대해 살펴보자. 0-1. 들어가기 앞서 ! 오늘 발표를 조금 더 잘 이해할 수 있도록 하기 위해, 몇가지 용어에 대한 설명을 준비하였다. 메모리란 ? 메모리는 컴퓨터가 프로그램과 데이터를 저장하고 처리하는 데 사용되는 저장 공간이다. 프로그램의 실행 중에 생성되는 데이터는 물리적인 메모리에 저장 되며(주로 RAM), 이 데이터는 스레드가 실행되면서 읽고 쓰게 된다. 프로세스란 ? 실행 중에 있는 프로그램을 의미한다. 작업(Task)과 같은 의미로 쓰인다. 프로세스는 최소 하나의 스레드를 가지는데, 실제로 작업(Task)이 스레드 단위로 동작한다. 스레드란 ? 스레드는 프로그램 내에서 실행되는 흐름의 단위. 일반적으로 한 프로그램은 하나의 스레드를 가지고 있지만, 프로그램의 환경에 따라 둘 이상의 스레드를 동시에 실행할 수 있다. 이것이 바로 멀티스레딩이다. 프로세스 구조 프로세스의 데이터와 명령어가 있는 영역은 Code(Text), Data, Stack, Heap이다. 💡각 프로세스는 별도의 공간(독립된 메모리)에서 실행되고 프로세스끼리는 자원의 공유를 하지 않는다. 그렇다보니, 프로세스 간의 자원을 공유하기 위해서는 별도의 통신이 필요하다. 스레드 구조 스레드는 Stack만 따로 할당받고, Code(Text), Data, Heap 영역은 프로세스의 자원을 공유한다. 💡자원을 공유하다보니, 시스템의 자원과 처리 비용이 멀티 프로세싱에 비해 적다. (통신의 부담X) 하지만 자원을 공유하고 있다 보니, 멀티 스레딩 환경에서 동기화의 문제가 발생할 수 있다.

안녕하세요, 오늘은 TDD(Test-Driven Development)에 대해 이야기하려 합니다. TDD 소프트웨어 개발 방법론 중 하나로, 개발 과정에서 테스트를 우선하여 작성하고 이를 통과시키는 것에 초점을 두는 방법론입니다. 코드를 작성하기 이전에 테스트 케이스를 작성하고, 이를 통과하기 위한 그에 맞는 기능을 작성하는 작업을 반복하여 개발합니다. TDD의 장점과 한계 TDD의 장점: 품질 향상: 개발자는 코드의 동작을 확실히 이해하고 테스트 케이스를 통해 코드의 정확성을 검증할 수 있어, 더 견고하고 안정적인 코드를 작성할 수 있습니다. 리팩토링 지원: 코드를 작은 단위로 분리하고 테스트 가능한 형태로 작성하여 코드의 구조와 설계를 개선하기 쉽게 합니다. 빠른 피드백: 작은 단위의 테스트를 빠르게 실행하고 결과를 확인하여 버그를 빠르게 발견하고 수정할 수 있으며, 코드 변경에 대한 피드백을 신속하게 받을 수 있습니다. 협업 강화: 테스트 코드가 개발 프로세스의 일부로 문서화되어 있어 다른 개발자들과의 협업을 용이하게 하며, 코드의 동작을 이해하고 검증하는 데 도움이 됩니다. TDD의 한계: 시간과 노력: 테스트 코드를 작성하기 위해 추가적인 시간과 노력이 필요하며, 개발 시간이 늘어날 수 있습니다. 설계에 대한 이해: 테스트 케이스를 작성하기 위해 개발자는 코드의 설계에 대한 깊은 이해가 필요하며, 이를 갖추지 않으면 테스트 케이스가 미흡해질 수 있습니다. 복잡한 시나리오의 테스트: 복잡한 시나리오나 UI, 성능 테스트 등은 TDD로 테스트하기 어려울 수 있습니다. 변동이 많은 요구사항: 요구사항이 자주 변경되는 경우, 테스트 케이스를 계속 수정해야 하는 상황이 발생할 수 있습니다. 출처: https://semaphoreci.com/wp-content/uploads/2022/02/tdd-vs-waterfall.webp 이러한 장점과 한계로 인해 TDD는 초기에는 추가 비용이 들 수 있지만, 시간이 지남에 따라 비용을 절감할 수 있는 특징을 지녔습니다. TDD의 사이클 Lifecycle of the Test-Driven Development method 출처: https://ko.wikipedia.org/wiki/테스트_주도_개발 Write Test: 기능을 검증할 테스트 케이스를 작성

0. 들어가기 앞서 지난 시간에는 파이썬의 GIL 제약과 그 제약으로 인해 “찐”효율을 내지 못하는 멀티 스레드 프로그래밍에 대해서 알아보았다. 이번 시간에는 파이썬 비동기의 핵심 키워드 네이티브 코루틴인 Asyncio, async, await를 이해하기 전 이것들의 근간이라 불리는 코루틴(Corutine)에 대해서 알아보자. 들어가기 앞서, 복습 차원에서 지난 시간 내용을 간략하게 정리하자 1. 제네레이터 1.1. 제네레이터 제네레이터는 쉽게 말해서, 여러개의 데이터를 미리 만들어 놓지 않고 필요한 때마다 즉석에서 하나씩 만들어낼 수 있는 객체를 의미한다. 일반적인 함수와 달리 상태를 유지할 수 있다. 즉, 제네레이터는 yield 표현식을 사용하여 값을 반환하고, 다음 호출 시 마지막으로 실행된 yield 표현식 이후부터 실행을 재개한다. 일반함수는 return을 만나면 실행이 끝나버린다. 하지만 제네레이터는 yield 구문에서 “일시정지”의 상태로 값을 외부로 내보낸다. 그 이후에 필요할 때 다시 실행 흐름을 이어나갈 수 있다. 함수 내부에서 사용된 지역 변수등이 메모리에 그대로 유지되어 있기 때문이다. 아래 코드를 살펴보자. 함수 return_abc()는, 알파벳을 1초마다 하나하나 리스트에 적재하는 코드이다. print를 찍어본다면 어떻게 될까? 너무 당연한 결과이다. 그렇다면 해당 함수를 for loop에 돌려보면 어떻게 될까? 이 결과 역시 너무나도 쉽게 예상할 수 있다. 여기서 3초라는 시간을 잘 기억해주길 바란다. 위에서 제네레이터는 데이터를 미리 만들어두지 않고, 필요할 때마다 하나씩 만들어내는 객체를 뜻한다 했다. 이것도 코드를 통해 알아보자. 뭔가 위의 코드랑 별로 달라진게 없어보인다. print를 찍어보자. !! 예상했던 것과는 달리 제네레이터가 출력 되었다 !! 위에서 언급했던 것처럼 제네레이터는 “필요할 때마다” “하나씩” 만들어 낸다고 했으니, 한번 for문을 통해서 “하나씩” 값을 받아와 보자.

이번 글에서는 python FastAPI의 특징과 FastAPI내에서 Pydantic을 사용한 코드를 확인해 보겠습니다. Fast API Fast API란? FastAPI는 Python 프레임워크 중 하나입니다. Python 프레임워크들 중 django, flask 와 같이 비교를 많이 하며, 빠른 속도로 인해 인기가 많아진 프레임워크입니다. FastAPI에서 제공하는 기능들을 간략히 보면 아래와 같습니다. API 문서 자동 생성 (Swagger와 ReDoc 스타일 동일) 의존성 주입 위주의 설계를 통한 DB 등에 대한 관리 편리 비동기 동작으로 빠른 성능 보장 (Starlette) Pydantic을 사용한 Validation 체크 뛰어난 공식문서 가이드 Python Framework 깃허브 스타 github star history 그래프를 보면 FastAPI(노란색)의 스타가 급격히 증가하는 것을 확인 할 수 있습니다. 그래프를 통해 FastAPI를 많이 사용한다는 의미는 될 수 없겠지만, 개발자들 사이에서 관심을 많이 갖고 있는것은 확인 할 수 있을것 같습니다. FastAPI의 특징 특징들을 Fast API 공식문서를 통해 자세하게 확인해 보겠습니다. 파이썬 3.8+ 버전의 Type hint를 사용하는 트랜디하고 높은 성능을 가진 파이썬 프레임워크 빠름: NodeJS 및 Go와 동등한 매우 높은 성능을 제공 실제 파이썬 기반의 프레임워크들을 비교한 내용을 확인해 보면 성능이 상위에 존재하는 것을 확인 할 수 있습니다. 빠른 코딩: 기능 개발 속도를 약 200%~300% 향상 버그 감소: 인간(개발자)이 유발한 오류의 약 40% 감소 직관적: 뛰어난 편집기 지원. 디버깅 시간이 줄어듭니다.

0. 개요 아무것도 모르는 대학생 시절에, 학부 인턴을한 적이 있다. 그때 팀장님이 신입 면접을 보고 오신 뒤, 나에게 질문을 하신 적이 있다. “oo아 동기와 비동기 차이를 설명해 봐” 동기 - “하나하나 순차적으로 실행하는 것 !” 비동기 - “동시에 실행되는 것 !” 이라고 대답한 기억이 있다. 아마 이렇게 대답한 나는 그 당시에 동기 / 비동기를 아래 사진과 같이 이해하고 있었던 것 같다. 내가 이해한 "동기" 내가 이해한 "비동기" 얼핏 보기엔 맞는 대답이기도 하다. 하지만 지금 와서 생각해 보면 “하나하나 순차적으로 실행하는 것 !”의 대답은, Blocking Sync에 대한 설명일 수도 있고, Blocking Async에 대한 설명일 수도 있다. 또, “동시에 실행되는 것 !” 의 대답은, NonBlocking Sync일 수도 있고 NonBlocking Async일 수도 있다. 물론, 이론적으론 그렇다. 해당 개념을 잘 모르는 사람에게는, Sync와 Async의 단어 자체는 익숙할 수 있어도, Blocking과 NonBlocking이 앞에 붙는 순간 머리가 아파올 수 있다.

개요 개발을 하면서 과거에 작업했던 코드를 다시 봐야 하는 상황이 종종 있다. 과거에 깨끗하지 않게 코드를 작성했다면, 코드를 다시 이해하고 원인을 찾는 부분에서 시간을 소요 할 가능성이 높다. 특히, 서비스 중인 프로그램에서 버그가 발생해 빠르게 이슈 대응을 해야 한다면, 머리가 새하얘질 것 이다. 또한, 이런 경험을 한 적이 있을 것이다. 시간이 부족해서 빠르게 개발하고, ‘아.. 나중에 리팩토링 해야겠다.’ 라고 생각한 경우도 있을 것이다. 하지만, 리팩토링을 하는 Task를 따로 추가하는 경우는 매우 희박한 경험들이 있을 것이다. 이런 경험을 하면서 개발 초기 부터 이해가 잘되는 코드를 만들기 위한 방법을 찾아 보게 되었고, 클린 코드에 대해 알게 되면서 학습을 진행했다. 클린 코드를 알기 전 개발에 급급해서 만들었던 과거의 코드 클린 코드란? 한 개발자는 클린 코드에 대해 다음과 같이 말했다. 그래디 부치(Grady Booch) ”클린 코드는 단순하고 직접적이다. 클린 코드는 잘 쓴 문장처럼 읽힌다. 클린 코드는 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다." 이 외에도 여러 개발자들의 말을 정리하면 다음과 같다. 다른 사람이 읽기 쉬운 코드 유지 보수가 쉬운 코드 간단 명료하고, 의도가 분명한 코드 클린 코드에 대해 많은 말들이 있지만 개인적으로 클린코드의 핵심은 라고 생각 된다. “누구에게나” 라고 생각한 이유는 프로젝트는 팀원들과 같이 진행을 하기 때문에 내가 작성한 코드를 팀원들이 읽기 때문이다.

아파치 프로젝트 아파치 프로젝트는 오픈 소스 소프트웨어 개발을 위한 비영리 조직입니다. 하둡은 아파치 프로젝트의 핵심 프로젝트 중 하나입니다. 아파치 프로젝트는 하둡의 개발, 유지 관리, 보급을 담당하고 있습니다. 아파치 프로젝트는 하둡의 안정성과 성능을 향상시키기 위해 지속적으로 노력하고 있습니다. 또한, 하둡의 사용을 지원하기 위한 다양한 도구와 리소스를 제공하고 있습니다. KHP(카카오하둡) KHP는 카카오가 자체 개발한 하둡 배포판입니다. KHP는 하둡의 최신 버전을 기반으로 개발되었으며, 카카오의 요구 사항에 맞게 최적화되어 있습니다. KHP는 다음과 같은 특징을 가지고 있습니다. 높은 확장성: KHP는 대규모 클러스터 환경에서의 안정적인 운영을 지원합니다. 높은 성능: KHP는 하둡의 성능을 향상시키기 위한 다양한 최적화 기술을 적용하고 있습니다. 쉽고 편리한 관리: KHP는 하둡의 관리를 단순화하기 위한 다양한 기능을 제공합니다. KHP는 카카오의 빅데이터 플랫폼의 기반으로 사용되고 있습니다. 또한, 카카오 외에도 다양한 기업과 기관에서 KHP를 사용하고 있습니다.

MapReduce는 대규모 데이터를 분산 환경에서 처리하기 위한 프로그래밍 모델입니다. MapReduce는 입력 데이터를 키-값 쌍으로 변환하는 Map 단계와, 동일한 키를 가진 데이터를 집계하는 Reduce 단계로 구성됩니다. MapReduce는 다음과 같은 특징을 가지고 있습니다. 병렬 처리: MapReduce는 입력 데이터를 여러 노드에 분산하여 처리합니다. 이를 통해 대규모 데이터를 효율적으로 처리할 수 있습니다. 간결한 프로그래밍: MapReduce는 단순한 프로그래밍 모델을 제공합니다. 이를 통해 개발자가 대규모 데이터를 쉽게 처리할 수 있습니다. 확장성: MapReduce는 확장성이 뛰어납니다. 이를 통해 대규모 데이터 처리 환경에 쉽게 적용할 수 있습니다. MapReduce의 구조 MapReduce는 다음과 같은 구조로 구성됩니다. JobTracker: JobTracker는 MapReduce 작업을 관리하는 서버입니다. JobTracker는 MapReduce 작업을 분배하고, 작업의 진행 상황을 추적합니다. TaskTracker: TaskTracker는 MapReduce 작업을 수행하는 서버입니다. TaskTracker는 JobTracker의 명령에 따라 MapReduce 작업을 수행합니다. MapReduce의 작동 방식 MapReduce는 다음과 같은 방식으로 작동합니다. 사용자는 MapReduce 작업을 생성합니다. JobTracker는 MapReduce 작업을 분배합니다. TaskTracker는 MapReduce 작업을 수행합니다. JobTracker는 작업의 진행 상황을 추적합니다. 사용자는 JobTracker를 통해 MapReduce 작업을 생성할 수 있습니다. JobTracker는 MapReduce 작업을 여러 TaskTracker에 분배합니다. TaskTracker는 JobTracker의 명령에 따라 MapReduce 작업을 수행합니다. JobTracker는 작업의 진행 상황을 추적합니다. MapReduce의 단계 MapReduce는 다음과 같은 두 단계로 구성됩니다. Map 단계: Map 단계는 입력 데이터를 키-값 쌍으로 변환합니다. Map 단계는 입력 데이터를 한 줄씩 읽어 키-값 쌍으로 변환합니다. Reduce 단계: Reduce 단계는 동일한 키를 가진 데이터를 집계합니다. Reduce 단계는 Map 단계의 출력을 키-값 쌍으로 받고, 동일한 키를 가진 데이터를 집계합니다. MapReduce는 다양한 분야에서 활용되고 있습니다. 예를 들어, 빅데이터 분석, 디지털 아카이빙, 미디어 스트리밍 등에서 MapReduce가 사용되고 있습니다. MapReduce의 장점 MapReduce는 다음과 같은 장점을 가지고 있습니다. 병렬 처리: MapReduce는 입력 데이터를 여러 노드에 분산하여 처리합니다. 이를 통해 대규모 데이터를 효율적으로 처리할 수 있습니다. 간결한 프로그래밍: MapReduce는 단순한 프로그래밍 모델을 제공합니다. 이를 통해 개발자가 대규모 데이터를 쉽게 처리할 수 있습니다. 확장성: MapReduce는 확장성이 뛰어납니다. 이를 통해 대규모 데이터 처리 환경에 쉽게 적용할 수 있습니다. MapReduce의 단점 MapReduce는 다음과 같은 단점을 가지고 있습니다. 복잡성: MapReduce는 복잡한 구조를 가지고 있습니다. 따라서 MapReduce를 사용하려면 충분한 이해가 필요합니다. 성능: MapReduce의 성능은 네트워크 대역폭에 따라 제한될 수 있습니다. MapReduce의 활용 사례 MapReduce는 다음과 같은 분야에서 활용되고 있습니다.

HDFS(Hadoop Distributed File System)는 하둡 에코시스템의 핵심 구성 요소 중 하나로, 대용량 데이터를 저장하고 관리하기 위한 분산 파일 시스템입니다. HDFS는 수백 대 또는 수천 개의 서버에 분산된 데이터를 저장하여 대규모 데이터 처리를 가능하게 합니다. HDFS는 다음과 같은 특징을 가지고 있습니다. 분산: HDFS는 데이터를 여러 서버에 분산하여 저장합니다. 이를 통해 대규모 데이터를 저장하고 관리할 수 있습니다. 내결함성: HDFS는 데이터의 손실을 방지하기 위해 내결함성을 갖추고 있습니다. 데이터는 여러 서버에 복제되어 저장되며, 서버 하나가 고장나더라도 데이터를 복구할 수 있습니다. 효율성: HDFS는 데이터를 효율적으로 저장하고 관리합니다. 데이터는 블록 단위로 저장되며, 블록의 크기는 64MB에서 128MB 사이로 조정할 수 있습니다. HDFS는 다음과 같은 용도로 사용될 수 있습니다. 대규모 데이터 저장: HDFS는 수백 TB 또는 수 PB 이상의 데이터를 저장할 수 있습니다. 대규모 데이터 분석: HDFS는 대규모 데이터를 분석하기 위한 플랫폼으로 사용될 수 있습니다. 디지털 아카이빙: HDFS는 디지털 아카이빙을 위한 플랫폼으로 사용될 수 있습니다. HDFS의 구조 HDFS는 다음과 같은 구조로 구성되어 있습니다. NameNode: NameNode는 HDFS의 메타데이터를 저장하는 서버입니다. 메타데이터에는 파일의 이름, 크기, 위치 등이 포함됩니다. DataNode: DataNode는 실제 데이터를 저장하는 서버입니다. DataNode는 NameNode의 명령에 따라 데이터를 저장하고 관리합니다. HDFS의 작동 방식 HDFS는 다음과 같은 방식으로 작동합니다. 사용자가 파일을 생성하면 NameNode는 파일의 메타데이터를 저장합니다. NameNode는 DataNode에 파일을 저장할 위치를 지시합니다. DataNode는 NameNode의 지시에 따라 파일을 저장합니다. 사용자는 NameNode를 통해 파일을 생성, 수정, 삭제할 수 있습니다. NameNode는 DataNode에 파일을 저장할 위치를 지시하며, DataNode는 NameNode의 지시에 따라 파일을 저장하고 관리합니다. HDFS의 장점 HDFS는 다음과 같은 장점을 가지고 있습니다. 대규모 데이터 저장: HDFS는 수백 TB 또는 수 PB 이상의 데이터를 저장할 수 있습니다. 내결함성: HDFS는 데이터의 손실을 방지하기 위해 내결함성을 갖추고 있습니다. 효율성: HDFS는 데이터를 효율적으로 저장하고 관리합니다. HDFS의 단점 HDFS는 다음과 같은 단점을 가지고 있습니다.

오늘은 대용량 데이터 처리를 위한 프레임워크인 Hadoop에 대해 간단히 소개해드리려고 합니다. Hadoop이란? Hadoop은 Apache Software Foundation에서 개발한 오픈소스 프레임워크로, 대용량 데이터 처리를 위한 분산 처리 시스템입니다. Hadoop은 MapReduce와 HDFS라는 두 가지 주요 기술을 기반으로 합니다. MapReduce는 대용량 데이터를 처리하기 위한 분산 처리 프레임워크입니다. MapReduce는 데이터를 작은 단위로 나누어 병렬 처리하는 방식으로 대용량 데이터를 효율적으로 처리할 수 있습니다. HDFS는 대용량 데이터를 저장하기 위한 분산 파일 시스템입니다. HDFS는 데이터를 여러 대의 서버에 분산 저장하여 대용량 데이터를 효율적으로 저장하고 관리할 수 있습니다. Hadoop의 특징 Hadoop의 주요 특징은 다음과 같습니다. 분산 처리: Hadoop은 대용량 데이터를 처리하기 위해 분산 처리 방식을 사용합니다. 확장성: Hadoop은 클러스터 규모를 쉽게 확장할 수 있습니다. 내구성: Hadoop은 데이터의 손실을 방지하기 위해 다양한 내구성 기능을 제공합니다. 오픈소스: Hadoop은 오픈소스 소프트웨어로, 누구나 무료로 사용할 수 있습니다. Hadoop의 적용 Hadoop은 다양한 분야에서 대용량 데이터 처리를 위해 사용되고 있습니다. Hadoop의 주요 적용 분야는 다음과 같습니다.

오늘은 디자인 패턴 중 하나인 Observer 패턴에 대해 간단히 소개해드리려고 합니다. Observer 패턴이란? Observer 패턴은 객체의 상태 변화를 관찰하는 객체들을 등록하고, 객체의 상태가 변경될 때마다 등록된 객체들에게 알림을 보내는 패턴입니다. 즉, 객체의 상태 변화를 관찰하고 싶은 객체들을 객체에 등록하고, 객체의 상태가 변경될 때마다 등록된 객체들에게 알림을 보내는 방식으로 객체의 상태 변화를 관리합니다. Observer 패턴의 장점 Observer 패턴을 사용하면 다음과 같은 장점이 있습니다. 객체의 상태 변화를 관찰하고 싶은 객체들을 쉽게 관리할 수 있습니다. 객체의 상태 변화를 관찰하는 객체들을 쉽게 추가하거나 제거할 수 있습니다. 객체의 상태 변화를 관찰하는 객체들 간의 결합도를 낮출 수 있습니다. Observer 패턴의 예시 Observer 패턴의 예시로 게임의 캐릭터를 생각해 볼 수 있습니다. 게임의 캐릭터는 자신의 상태가 변경될 때마다, 이를 관찰하고 있는 다른 캐릭터들에게 알림을 보냅니다. 다음은 Observer 패턴을 사용하여 게임의 캐릭터를 구현한 예시입니다. Python Code 위 코드에서 Character 클래스는 observers라는 리스트를 사용하여 Observer 객체들을 관리합니다. notifyObservers() 메서드는 observers 리스트에 등록된 모든 Observer 객체들에게 알림을 보냅니다. Enemy 클래스는 Character 클래스를 상속받아 구현됩니다. Enemy 클래스는 hp 필드를 사용하여 적의 체력을 관리합니다. changeState() 메서드는 적의 체력이 0 이하가 되면, notifyObservers() 메서드를 호출하여 플레이어에게 알림을 보냅니다. Player 클래스도 Character 클래스를 상속받아 구현됩니다. Player 클래스는 attack_power 필드를 사용하여 플레이어의 공격력을 관리합니다. update() 메서드는 notifyObservers() 메서드를 호출하여 적에게 알림을 보냅니다.

오늘은 디자인 패턴 중 하나인 Singleton 패턴에 대해 간단히 소개해드리려고 합니다. Singleton 패턴이란? Singleton 패턴은 클래스에 단 하나의 인스턴스만 생성되도록 하는 패턴입니다. 즉, 클래스의 인스턴스를 생성하는 방법을 제한하여 클래스에 단 하나의 인스턴스만 생성되도록 합니다. Singleton 패턴의 장점 Singleton 패턴을 사용하면 다음과 같은 장점이 있습니다. 클래스에 단 하나의 인스턴스만 생성되도록 보장할 수 있습니다. 클래스의 인스턴스를 공유할 수 있습니다. 클래스의 인스턴스를 캡슐화할 수 있습니다. Singleton 패턴의 예시 Singleton 패턴의 예시로 게임의 주인공을 생각해 볼 수 있습니다. 게임의 주인공은 항상 하나만 존재해야 합니다. 따라서 게임의 주인공을 Singleton 패턴으로 구현할 수 있습니다. 다음은 Singleton 패턴을 사용하여 게임의 주인공을 구현한 예시입니다. Python Code 위 코드에서 Hero 클래스는 __instance라는 클래스 변수를 사용하여 Singleton 패턴을 구현합니다. __instance 변수는 Hero 클래스의 인스턴스를 참조합니다. Hero 클래스의 getInstance() 메서드는 __instance 변수가 None이면 새로운 Hero 인스턴스를 생성하고, None이 아니면 __instance 변수에 저장된 인스턴스를 반환합니다.

안녕하세요, 개발자 여러분! 오늘은 디자인 패턴 중 하나인 Factory Method 패턴에 대해 간단히 소개해드리려고 합니다. Factory Method 패턴이란? Factory Method 패턴은 객체를 생성하는 책임을 서브클래스에게 위임하는 패턴입니다. 즉, 객체의 생성 방법을 클라이언트 코드에서 결정하지 않고, 서브클래스에서 결정하도록 합니다. Factory Method 패턴의 장점 Factory Method 패턴을 사용하면 다음과 같은 장점이 있습니다. 객체의 생성 방법을 클라이언트 코드에서 분리할 수 있습니다. 객체의 생성 방법을 확장하기 쉽습니다. 객체의 생성 방법을 캡슐화할 수 있습니다. Factory Method 패턴의 예시 Factory Method 패턴의 예시로 자동차 공장을 생각해 볼 수 있습니다. 자동차 공장은 자동차를 생산하는 역할을 합니다. 하지만 자동차의 종류는 다양합니다. 따라서 자동차 공장은 자동차의 종류에 따라 다른 자동차를 생성해야 합니다. 이 경우 Factory Method 패턴을 사용하여 자동차의 종류에 따라 다른 자동차를 생성할 수 있습니다. 다음은 Factory Method 패턴을 사용하여 자동차 공장을 구현한 예시입니다.

오늘은 개발자라면 꼭 알아야 할 디자인 패턴에 대해 간단히 소개해드리려고 합니다. 디자인 패턴이란? 디자인 패턴은 소프트웨어 설계에서 자주 발생하는 문제를 해결하기 위한 일반적인 해결책입니다. 이 패턴들은 미리 만들어진 청사진과도 같은데, 커스터마이징하여 코드에서 반복되는 설계 문제를 해결할 수 있습니다. 디자인 패턴의 장점 디자인 패턴을 사용하면 다음과 같은 장점이 있습니다. 코드의 재사용성 및 유지보수성을 높일 수 있습니다. 설계의 일관성을 유지할 수 있습니다. 프로젝트의 규모가 커질수록 발생할 수 있는 문제들을 예방할 수 있습니다. 디자인 패턴의 종류 디자인 패턴은 크게 생성 패턴, 구조 패턴, 행위 패턴으로 나눌 수 있습니다. 생성 패턴은 새로운 객체를 생성하는 방법에 대한 패턴입니다. 디자인 패턴 공부 방법 디자인 패턴을 학습하는 방법은 크게 두 가지가 있습니다. 책이나 강의를 통해 이론적으로 학습하는 방법 실제 프로젝트에 적용해보면서 학습하는 방법