1. Software Engineering Process

• 1.1 Definition and Importance

  • Process Models
  • Learn from Well-Established Industry
  • The process Framework
  • A Generic Process Model

• 1.2 Process Flows

  • Simple Process Flows
    • 1.2.1 Linear Process Flow
    • 1.2.2 Iterative Process Flow
  • 1.2.3 Evolutionary Process Flow
  • 1.2.4 Parallel Process Flow

• 1.3 Task Sets in Software Engineering

  • 1.3.1 Identifying a Task Set

• 1.4 Process Assessment and Improvement

• 1.5 Prescriptive Process Models

  • 1.5.1 Waterfall Model

  • 1.5.2 Prototyping Model

  • 1.5.3 Spiral Model

  • 1.5.4 Unified Process Model

    (01-02 - Software Engine…)

전체적 요약

소프트웨어 공학 프로세스 개요

• 소프트웨어 공학 프로세스는 프레임워크 활동(의사소통, 계획, 모델링, 개발, 배포)과 우산 활동(프로젝트 관리, 위험 관리, 품질 보증 등)을 포함한다
• 프로세스 모델은 이 기본 프레임워크를 바탕으로 만들어지며, 활동들의 적용 방식과 순서에 따라 다양한 모델이 존재한다

프로세스 흐름과 모델

• 프로세스 흐름에는 선형, 반복, 진화, 병렬 등 다양한 유형이 있으며, 각각의 특성에 따라 적용된다
• 처방적 프로세스 모델(Prescriptive Process Models)은 구조와 질서를 중시하지만, 변화가 잦은 소프트웨어 개발 환경에서는 유연성이 필요할 수 있다

주요 프로세스 모델

• 폭포수(Waterfall) 모델은 순차적 프로세스로, 각 단계가 고정된 순서로 진행된다
• 프로토타이핑 모델은 사용자 피드백을 기반으로 반복적으로 소프트웨어를 개선하는 방식이다
• 나선형(Spiral) 모델은 위험 관리에 중점을 두고 각 반복에서 위험을 분석하며 소프트웨어를 개발한다
• 통합 프로세스(Unified Process) 모델은 객체지향 설계를 기반으로 한 반복적이고 점진적인 개발 방법론이다

내용정리!!!

1. Software Engineering Process

• 1.1 Definition and Importance

  • Process Models

  • Learn from Well-Established Industry

    !

    공통점

    이미지에서 보여주는 요소들은 모두 품질 관리와 효율적인 프로세스를 강조. 소프트웨어 개발에서도 산업 표준과 측정 가능한 품질을 유지하면서, 체계적으로 작업을 진행하는 것이 중요하다는 점을 시사함.

    • ISO 9001:2015: 국제 품질 관리 표준. 일관된 품질 보장을 위해 필요.
    • 압력계: 데이터 기반의 정확한 측정이 중요하다는 점을 상징.
    • Ford Q1: 높은 품질 기준을 의미하며 지속적 관리 필요.
    • 작업자들: 팀워크와 기술 도구 활용의 중요성을 보여줌

  • The process Framework

    • process models(프로세스 모델)은 이 framework를 바탕으로 만들짐. 기본적으로 소프트웨어 개발 프로세스는 framework activities(의사소통, 계획, 모델링, 개발, 배포)와 umbrella activities(위험 관리, 품질 보증 등)를 포함. 이 활동들이 각기 다른 방식으로 적용되면서 다양한 프로세스 모델들이 만들어지는것.

      예를 들어:

      • Waterfall 모델은 프레임워크 활동들을 순차적으로 진행하는 방식이고, 모든 활동이 완료된 후에 다음 단계로 넘어감.

      • Agile 모델은 각 프레임워크 활동을 반복적으로 수행하면서, 소프트웨어를 점진적으로 완성.

        즉, process models는 이 기본 프레임워크의 활동들이 어떻게 적용되고 순서가 어떻게 구성되는지에 따라 달라짐.

  • A Generic Process Model

    • Generic Process Model은 소프트웨어 개발의 기본 틀을 제공하는 모델로, 프레임워크 활동(의사소통, 계획, 모델링, 개발, 배포)과 우산 활동(프로젝트 관리, 위험 관리, 품질 보증 등)을 포함. 이 모델은 각 활동을 단계별로 반복하거나 병렬로 수행해 소프트웨어 개발을 체계적으로 관리하는 방식. 다양한 프로세스 모델(예: 워터폴, 애자일)들이 이 기본 구조를 기반으로 만들어짐.

      2. Process Flows

      • Simple Process Flows
    • 1.2.1 Linear Process Flow
    • 1.2.2 Iterative Process Flow
      • 1.2.3 Evolutionary Process Flow

        Iterative Process Flow는 특정 단계를 여러 번 반복해서 점차 개선해 나가는 방식. 예를 들어, 설계 단계에서 잘못된 부분을 찾아 수정한 다음, 다시 개발을 진행하는 식으로 작업을 반복.

  • Evolutionary Process Flow*는 소프트웨어 전체를 점차 완성해 나가는 방식. 즉, 한 번의 반복을 통해 부분적으로 완성된 소프트웨어가 나옴. 그리고 그 소프트웨어는 계속 진화하면서 더 완벽해짐. 각 사이클마다 새로운 기능이나 개선된 버전이 나오고, 사용 가능한 부분적인 제품을 제공함. 따라서, Iterative는 특정 단계를 개선하는 데 초점이 있고, Evolutionary는 전체 소프트웨어를 점차 발전시키는 데 초점이 있다는 차이가 있음.

1.2.4 Parallel Process Flow

3. Task Sets in Software Engineering

• 3.1 Identifying a Task Set

   - 진짜 해야되는 일 sw engineering action의 목표 달성을 위해
   - A task set lists로 구성
       - A list of tasks to be accomplished
       - A list of work products to be produced
       - A list of quality assurance filters to be applied

  4. Process Assessment and Improvement

  • 존재 ≠ 소프트웨어의 질, 고객 만족 보장
  • process criteria 만족 시키는지 평가되어야됨
  • numeric measures로 평가 돼야됨!!!!! software analytics(metrics)나

✅ 질문에 대한 답 with GPT Q. process assessment and improvement가 umbrella activity에 포함이 되는건가요? 차이점 요약: - Process Assessment는 전체 프로세스의 성과 평가에 중점을 두고, 개선할 부분을 찾기 위한 평가에 가까워요. - Umbrella Activities는 개발 전 과정에 걸쳐 발생하는 지속적인 관리 활동으로, 프로세스를 원활하게 진행되도록 돕는 역할이에요. 따라서, Process Assessment는 주로 평가와 개선을 위한 것이고, Umbrella Activities는 개발 과정의 전반적인 관리에 초점을 맞춘다고 볼 수 있어요.

5. Prescriptive Process Models

orderly

• If prescriptive process models strive for structure and order, are they appropriate for a software world that thrives on change?

  • 구조와 질서를 중시하므로, 변화가 잦은 소프트웨어 세계에서는 적합하지 않을 수 있음

• If we reject traditional process models and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

  • 전통적인 모델을 버리고 덜 구조화된 모델을 채택해도, Agile이나 Evolutionary 모델 같은 방식으로 유연성을 유지하면서도 필수적인 조정과 일관성을 유지할 수 있음

1.5.1 Waterfall Model

• 순차적 프로세스 모델. 각 단계가 고정된 순서대로 진행되며, 한 번 완료된 단계는 다시 돌아가지 않는 것이 특징.

  - linear process flow 기반

  1.5.2 Prototyping Model
  • Prototyping 모델은 Evolutionary Process Flow에서 나온 모델
• 프로토타입 개발: 소프트웨어의 일부 기능이나 UI를 빠르게 개발하여 시제품을 만든다.
  • 사용자 피드백: 사용자가 프로토타입을 직접 사용해보고 피드백을 제공한다.
  • 반복적 개선: 사용자 피드백을 반영하여 소프트웨어를 반복적으로 개선하고 발전시킨다.
  • 최종 소프트웨어: 최종적으로 완성된 소프트웨어는 여러 차례의 반복적 개선 과정을 거쳐 사용자 요구를 정확히 반영한다.

장점

• 사용자 참여가 활발하여 요구사항이 명확해지고, 소프트웨어의 최종 품질이 향상됨.
• 변화에 유연하여, 프로젝트 진행 중에 요구사항이 변경되더라도 빠르게 반영할 수 있음.
• 제품이 초기부터 시각화되기 때문에, 사용자가 실제로 어떻게 작동할지 미리 경험할 수 있음.

단점

• 프로토타입에 의존할 위험 (temptation to ship a prototype)
• 시간과 비용 초과 (프로토타입 버려지는거에 대해서..)
  • 요구사항 완벽 정의 X
  • 설계의 품질 저하

1.5.3 Spiral Model

✅질문에 대한 답 with GPT Spiral 모델과 Prototyping 모델은 둘 다 반복적이고 점진적인 개발을 통해 소프트웨어를 완성하는 점에서는 비슷하지만, 중요한 차이점이 있어:

1. 목적과 초점

Spiral 모델: - Spiral 모델은 위험 관리에 중점을 두고, 각 반복에서 위험을 분석하고 그에 따른 결정을 내려가면서 소프트웨어를 개발해. - 각 반복 주기마다 위험을 줄이기 위해 위험 평가가 필수적으로 포함되며, 점진적으로 더 완성도 높은 소프트웨어를 목표로 해. - Spiral 모델은 대규모 프로젝트나 고위험 프로젝트에 적합하며, 여러 단계를 거쳐 계속해서 발전하는 방식이야. Prototyping 모델: - Prototyping 모델은 사용자 요구사항을 명확히 하기 위한 것이 목적이야. 초기 프로토타입을 만들어 사용자가 직접 테스트해보고 피드백을 제공받아, 요구사항을 구체화하는 데 중점을 둬. - 위험 관리보다는 사용자와의 피드백을 통해 요구사항을 점진적으로 개선하는 것이 핵심이야.

        - **빠른 피드백**과 **사용자 요구사항 반영**을 위해 프로토타입을 반복적으로 개발하고 수정해.

2. 프로토타입 사용 여부

Spiral 모델: 프로토타입을 필요에 따라 만들 수 있지만, 필수 요소는 아니야. 중요한 것은 위험 분석과 이를 기반으로 한 반복적 개발이야. Prototyping 모델: 프로토타입을 필수적으로 사용하며, 이를 기반으로 사용자 피드백을 받아 개발을 진행해.

3. 위험 관리

Spiral 모델: Spiral 모델은 각 반복에서 위험을 평가하고, 그 위험을 줄이기 위한 결정을 내리는 것이 핵심이야. 이는 고위험 프로젝트에서 매우 중요해. Prototyping 모델: 위험 관리에 대한 명확한 단계는 없고, 주로 사용자 요구사항에 초점을 맞춰서 개발이 이루어져.

결론:

Spiral 모델은 위험 관리를 중심으로 점진적으로 발전하는 방식이고, Prototyping 모델은 사용자 요구사항을 구체화하기 위해 프로토타입을 반복적으로 개선하는 방식이야. 둘 다 반복적 개발을 하지만, 목표와 초점이 다르기 때문에 동일한 모델은 아니야

1.5.4 Unified Process Model

Unified Process Model은 소프트웨어 개발에서 객체지향 설계와 분석을 기반으로 한 반복적이고 점진적인 개발 방법론. 이 모델은 소프트웨어를 여러 반복 주기(iteration)로 나눠서 개발하고, 각 주기마다 소프트웨어의 완성도를 높여가는 방식으로, 유스케이스(Use Case)를 중심으로 시스템을 개발하는 것이 특징. ** 주요 단계**:

• Inception(개념 단계): 프로젝트의 범위를 정의하고, 주요 요구사항을 파악.
  • Elaboration(정교화 단계): 시스템의 구조와 설계를 구체화하며, 핵심 위험을 해결.
  • Construction(구축 단계): 실제 소프트웨어를 개발하고, 반복적으로 기능을 추가.
• Transition(전환 단계): 소프트웨어를 사용자에게 배포하고, 피드백을 반영하여 수정.
  • 객체지향 설계: 객체지향 기법을 사용해 소프트웨어를 설계하며, 유지보수와 확장성을 고려.

✅질문에 대한 답 with GPT Linear Process Flow vs Waterfall Model 차이가 뭐얌 구체적으로

요약:

• Linear Process Flow는 단순히 단계가 순차적으로 진행되는 흐름을 설명하는 것이고,
• Waterfall 모델은 Linear Process Flow를 기반으로 한 구체적인 소프트웨어 개발 방법론이에요.

데이터 아키텍처는 어떻게 정의해볼 수 있을까? 엔터프라이즈 아키텍처에 대해 먼저 정의하는 것이 필수적이다.

💡 엔터프라이즈 아키텍처는 기업의 변화를 지원하는 시스템 설계로, 신중한 트레이드오프 평가를 통해 도달한 유연하고 되돌릴 수 있는 의사결정으로 달성된다.

• 단방향 의사결정, 양방향 의사결정, 변경관리 등 의사결정과 밀접한 관련이 있는 주제들이 존재한다!
• 기술적 솔루션은 그 자체를 위한 것이 아니라 비지니스 목표를 지원하기 위해 존재한다 !
• 유연성과 트레이드 오프의 균형을 유지해야한다.

아래는 데이터 아키텍처에 대한 책의 정의이다.

💡 데이터 아키텍처는 기업의 진화하는 데이터 요구 사항을 지원하는 시스템 설계로, 트레이드오프에 대한 신중한 평가를 통해 유연하고 되돌릴 수 있는 결정을 내림으로써 실현된다.

데이터 아키텍처 구성요소

• 운영 아키텍처 : 무엇을? (인력, 프로세스 및 기술과 관련한 필요 기능의 요건을 포괄)
• 기술 아키텍처: 어떻게?(엔지니어링 수명 주기를 통해 데이터를 수집, 저장, 변환 및 제공하는 방법을 개략적으로 설명)

우수한 아키텍처란?

• 유연성과 트레이드오프를 적절히 실현!
• 재사용 가능한 공통 구성요소
• 민첩성
• 가역성

등등을 포함!

3.2 우수한 데이터 아키텍처의 원칙

AWS Well-Architected 프레임워크

1. 운영 우수성
2. 보안
3. 신뢰성
4. 성능효율성
5. 비용 최적화
6. 지속가능성

구글 클라우드의 클라우드 네이티브 아키텍처를 위한 5대 원칙

1. 자동화를 위한 설계
2. 상태의 스마트한 관리
3. 관리형 서비스 선호
4. 심층 방어 연습
5. 항상 아키텍처 설계

위의 원칙들을 토대로 우수한 아키텍처가 되기 위한 원칙을 조금 더 자세히 살펴보자!!!

원칙 1: 공통 컴포넌트를 현명하게 선택해라

민첩성을 실현할 수 있어야 한다. 공통 컴포넌트는 적절한 사용 사례로 누구나 접근 가능해야하며, 동시에 부정 접근을 방지해야한다.

클라우드 플랫폼은 공통 컴포넌트를 채택하기 이상적인 장소다.

원칙 2: 장애에 대비하라

모든 것은 항상 실패한다. - 베르너르 포헐스, AWS CTO

• 가용성: IT 서비스 또는 컴포넌트가 작동 가능한 상태에 있는 시간의 비율
• 신뢰성: 지정된 간격 동안 의도된 기능을 수행할 때 시스템이 정의된 표준을 충족할 확률
• 복구 시간 목표: 서비스 또는 시스템 장애의 최대 허용 시간
• 복구 시점 목표: 복구 후 허용 가능한 상태다. 복구 시점 목표는 허용 가능한 최대 데이터 손실을 나타낸다.

원칙 3: 확장성을 위한 아키텍처를 설계하라

1. 확장 가능한 시스템은 상당한 양의 데이터를 처리할 수 있도록 스케일 업 할 수 있다.
2. 확장 가능한 시스템 규모를 스케일 다운할 수 있다.
3. 0으로 확장할 수도 있다
4. 탄력적 시스템은 부하에 따라 동적으로 확장할 수 있고, 이상적으로는 자동화된 방식으로 확장할 수 있다.

단, 부적절하게 확장 전략 도입하면 시스템이 지나치게 복잡해지거나 비용이 너무 많이 들 수도 있으니 조심!

원칙 4: 아키텍처는 리더십이다

리더십이 기술에 대한 명령과 통제 방식을 의미하지는 않는다.

모범 사례를 학습하고 공통의 목표를 추구해야한다! 리더십을 연습하고 아키텍트의 조언을 구하자><

원칙 5: 항상 아키텍처에 충실하라

단순히 기존 상태를 유지하는 역할만 수행하는 게 아니라, 기술의 변화에 대응해 새롭고 흥미로운 것들도 끊임없이 설계해라

원칙 6: 느슨하게 결합된 시스템을 구축하라

한 팀이 다른 팀에 의존하지 않고도 시스템을 테스트, 배포, 변경할 수 있도록 시스템 아키텍처가 설계되면, 해당 팀은 작업을 수행할 때 의사소통이 거의 필요하지 않다.즉, 아키텍처와 팀 모두 느슨하게 결합되어 있다.

1. 지금부터 모든 팀은 서비스 인터페이스를 통해 데이터와 기능을 공개한다.
2. 각 팀은 이러한 인터페이스로 서로 소통해야 한다.
3. 네트워크를 통한 서비스 인터페이스 호출을 사용한 것이다.
4. 어떤 기술을 사용하는지는 중요하지 않다. HTTP, CORBA, Pub/sub, 사용자 정의 프로토콜 등 무엇이든 상관없다.
5. 모든 서비스 인터페이스는 예외 없이 처음부터 외부화할 수 있도록 설계되어야 한다. 즉 팀은 외부의 개발자에게 인터페이스를 공개할 수 있도록 계획하고 설계해야 한다. 예외는 없다.

API의 뒤에 데이터와 서비스를 두면서 → 느슨한 결합 가능해짐 → AWS 탄생함!

원칙 7: 되돌릴 수 있는 의사결정을 하라

원칙 8: 보안 우선순위를 지정하라

강화된 경계 보안 모델과 제로 트러스트 보안 모델

공동 책임 모델

보안 엔지니어로서의 역할도 해야한다.

원칙 9: 핀옵스를 수용하라

핀옵스는 진화하는 클라우드 재무 관리 분야이자 문화적 관행으로, 엔지니어링 재무 기술 및 비지니스 팀이 데이터 기반 지출 결정을 위해 협업할 수 있도록 지원함으로써 조직이 비지니스 가치를 극대화할 수 있게 해준다.

3.3 주요 아키텍처 개념

1. 도메인과 서비스

아키텍처의 구성 요소 설명 전에 도메인과 서비스 개념에 대해서 이해하는게 필요함

도메인: 실제 설계하는 주제 영역

서비스: 작업 달성 기능 집합

ex. 예를 들어보자

판매 도메인: 주문 서비스, 송장 서비스, 상품 서비스

회계 도메인: 송장 서비스, 급여 서비스, 매출채권 서비스

2. 분산시스템/확장성/장애에 대비한 설계

확장성: 시스템 요량을 늘려서 성능을 개선하고 수요를 처리하는 거!

탄력성: 확장성이 뛰어난 시스템을 동적으로!! 확장하는거!

가용성: 작동 가능한 상태에 있는 시간의 비율

신뢰성: 시스템이 지정된 간격 동안 의도한 기능을 수행할 때 정의된 표준을 충족할 가능성(확률)이다.

이들의 관계는 어떨까? 신뢰성이 낮으면 가용성이 저하되겠지! 탄력성은 신뢰성을 확장시킨다!

문제점

일반적으로, 단일 머신으로는 높은 가용성과 신뢰성을 제공할 수 없다.

대안

분산 시스템을 활용해 전체 확장 용량을 늘림ㄱ뫄 동시에 가용성, 신뢰성 높인다!

수평확장시스템: 부하와 자원 요건을 충족하는 더 많은 머신을 추가할 수 있다.

ex. 리더노드 1 → 워커노드, 워커노드, 워커노드 (3)

리더노드 : 워크로드의 인스턴스화, 주요 창구를 담당

워커노드: 작업 분산 받고 결과를 리더 노드로 반환

분산 아키텍처의 중복성: 머신이 정지했을 경우, 다른 머신이 이어 받을 수 있도록 데이터 복제!

클러스터는 용량 복원을 위해 더 많은 머신을 추가할 수 있다.

분산시스템의 활용: 클라우드 데이터 웨어하우스 객체 스토리지 시스템에는 분산 개념이 거의 모두 포함된다!

3. 강한 결합 vs 느슨한 결합: 계층, 모놀리스, 마이크로서비스

강한결합: 도메인과 서비스의 모든 부분이 다른 모든 도메인과 서비스에 필수적으로 의존하며 긴밀하게 결합된 패턴!!!!

단일 계층 아키텍처: 서버 ( DB↔애플리케이션 )

강한 결합의 본질! 장애 위험 때문에 운영 환경에선 권장 X

모놀리스: 가능한 한 많은 것을 한 지붕 아래에 포함 = 강한결합! 컴포넌트의 모듈화가 부족, 재사용이 불가능하고 어려울 수 있음. 이에 대한 대안으로 분산형모놀리스 논의 시작됐는데 뒷장에 나온다고.. (코드 베이스 → 데이터베이스)

느슨한 결합: 서로 너무 의존하지 않으면서..분산형 도메인과 서비스가 있음

다중 계층 아키텍처: 가장 널리 쓰이는 3-tier architecture ( 데이터 계층 → 애플리케이션/로직 계층 → 프레젠테이션 계층 ) 상향식 구조

상향식 구조로, 강한 결합의 문제점을 분리로 해결한 버전이다. 계층적이며 하위 계층이 반드시 상위 계층에 의존하지는 않는다. 반면 상위 계층은 하위에 의존!

애플리케이션에서 데이터 분리, 프레젠테이션에서 애플리케이션 분리!

+) 비공유 아키텍처: 단일 노드가 각 요청을 처리하고, 다른 노드들이 해당 노드 또는 서로 간에 메모리, 디스크, CPU등 자원을 공유하지 않음.

+) 공유 디스크 아키텍처: 모든 노드에서 접근할 수 있는 동일한 디스크와 메모리를 공유해야 하는지 여부에 따라 결정

마이크로서비스: 개별적이고 분산되어 있으며, 느슨하게 결합된 서비스로 구성. 서비스의 분리와 새로운 병렬 아키텍처! (서비스 → DB, 서비스→ DB …)

문제점: 좀 많이 복잡할 수 있음.

대안: 1. 도메인 분리를 고려 2. 중앙집중화 3. 데이터 메시 (3장 뒷부분)

4. 사용자 접근: 싱글 vs 멀티테넌트

싱글: 사용자(or 테넌트) 가 독립된 소프트웨어 인스턴스 가짐

멀티테넌트: 하나의 소프트웨어 인스턴스를 다들 공유!

멀티테넌시의 고려사항: 성능과 보안!

테넌시 개념은 클라우드 컴퓨팅에서 특히 많이 사용된다… 그 중에서도 아마 모든 클라우드는 멀티테넌시를 채택함!

5. 이벤트 기반 아키텍처

keyword: 생산자, 이벤트 라우터, 소비자

이벤트: 상태의 변화

아키텍처 구조: 생산자 → (이벤트)→ 이벤트 라우터 → (이벤트) → 소비자

장점: 이벤트의 상태를 여러 서비스에 분산시킴. 즉, 장애가 발생하거나 오프라인이 되거나 여러 소비자 또는 서비스가 동일한 이벤트에 접근하도록 할 때 유용.

서비스가 느슨하게 결합된 경우 항상 이벤트 중심 아키텍처가 후보가 됨!

6. 브라운필드 vs 그린필드

둘의 차이점은 백지상태부터 시작하느냐, 기존의 것을 재설계해서 활용하느냐의 차이!

브라운필드: 기존의 코드를 리팩토링

(스탱글러패턴) : 기존의 것을 외과적으로, 한 번에 하나씩 대체

옛날꺼 폐기하면서 성장함으로써 성공을 입증하고, 결국 레거시가 완전히 대체되는 시점이 옴!

그린필드 프로젝트 : 완전 반대! 레거시 얽매이지 않고 새롭게 출발

쉬운 경향, but 이력서 주도의 개발으로 변질될 수 있음. 유행에 대한 강박 생길 수도

3.4 데이터 아키텍처의 사례 및 유형

1. 데이터 웨어하우스

보편화 배경

• 확장성이 뛰어난 종량제 모델 (cf. 종량제 모델은 고객이 사용한 만큼만 기한 내에 돈을 지불하는 방식)

→ 인건비와 자원을 대폭 줄일 수 있었다.

주목할만한 점 : 조직과 기술

조직: 팀의 구조와 프로세스

1. OLTP에서 OLAP 분리: 비지니스 성장에 따라 데이터를 별도의 물리적 시스템으로 옮기면서 운영 시스템의 부하가 줄고 분석 성능이 향상!
2. 데이터 중앙 집중화 및 구성: ETL을 사용해 데이터 가져옴. 추출(데이터 원천에서), 변환(ETL 시스템에서), 적재 (데이터 마트에)
   • (데이터 원천 → ETL 시스템 → 데이터 웨어하우스 → 데이터 마트)

기술: MPP 시스템의 등장 (Massively Parallel Computer)

1. SQL 시맨틱 지원
2. 행기반 → 열기반으로의 전환!!!! : 클라우드 데이터 웨어하우스에서 더 큰 데이터와 쿼리 지원할 수 있도록

ETL의 변형 ELT: 데이터를 운영 시스템에서 데이터웨어하우스 스테이징 영역으로 어느 정도 직접 이동이 가능. 변환은 데이터 웨어하우스에서 직접 처리됨! 데이터 웨어하우스와, 데이터 처리 도구의 방대한 계산 능력을 활용. 데이터 일괄 처리. 기록

• 데이터 원천 → ETL (스테이징 → 데이터 웨어하우스) → 분석, 데이터 과학, 보고
• 이벤트를 스트리밍해 스테이징 영역에 저장한 후 데이터 웨어하우스 내에서 변환하므로 스트리밍 배치에서도 인기 많았음

클라우드 데이터 웨어하우스

• Amazon Redshift
• Google Big Query
• Snowflake

On-demand 방식(사용자의 요구가 있었을 때 그 요구에 따라 서비스를 제공하는 것)의 스핀업(to create virtual machine using cloud computing ex. to spin up a new server)

클라우드 데이터 웨어하우스가 제공하는 기능 영향이 매우 크기 때문에, 데이터 웨어하우스 용어가 폐기될 수도 있음..!! MPP시스템에서 제공하는 것보다 훨씬 광범위한 기능 갖춘 새로운 데이터 플랫폼으로 발전하고 있다.

데이터마트

단일 하위 조직이나 부서 / 비지니스 라인에 초점 맞춰 분석 및 보고서를 제공하도록 설계된 웨어하우스의 한층 더 정교한 하위집합이다.

데이터 마트가 왜 필요할까?

1. 분석가와 보고서 개발자가 데이터에 더 쉽게 접근
2. 많은 변환 단계 제공 (분석 쿼리에 복잡한 데이터 조인 및 집계가 필요한 경우 데이터 마트에서 진행함으로써 전체적인 성능 크게 향상)

2. 데이터 레이크

정형과 비정형 모두 중앙 위치에 저장하고 엄격한 데이터 구조적 제한을 가하지 않는다!

역사

1. HDFS에서 데이터레이크 1.0이 시작됨
2. 클라우드의 인기 증가
3. 데이터 레이크 → 사실상 무제한 스토리지 용량 갖춘 클라우드 기반 객체 스토리지로 옮겨감 !

기능

• 모든 크기와 유형의 방대한 데이터 저장 가능
• 온디맨드로 스핀업해 거의 무제한에 가까운 컴퓨팅 성능 이용 가능
• 맵리듀스, 스파크, 레이, 프레스토, 하이브 등 원하는 데이터 처리 기술을 선택해 작업 수행 가능

단점 (매우 치명적임..)

• 쓰레기 매립장이 되어버림
• 데이터 늪, 다크 데이터, WORN 같은 용어의 탄생
• 데이터는 스키마 관리, 데이터 카탈로그 작성 및 검색 도구가 거의 없는 상태에서 관리 불가능한 크기로 증가했기 때문!
• 본질적으로 쓰기 전용 : 사용자 레코드를 지정 삭제 해야하는 GDPR과 같은 규제 도입이 골칫거리

3. 융합, 차세대 데이터 레이크, 데이터 플랫폼

데이터 레이크 하우스

데이터 웨어하우스 + 데이터 레이크

• 웨어하우스의 요소인 제어, 데이터 관리, 데이터 구조를 통합
• 레이크 요소: 객체 스토리지에 데이터 저장하고 다양한 쿼리 및 변형 엔진 지원
  • 단순 레이크와의 차이점: 데이터를 쏟아붓기만하고 갱신/삭제 안하는 레이크랑은 다르게 ACID 트랜잭션 지원!

클라우드 데이터 웨어하우스

(데이터 레이크와 유사)

• 컴퓨팅과 스토리지 분리
• 페타바이트 규모의 쿼리 지원
• 다양한 비정형 데이터 및 반정형 객체 저장
• 스파크/빔과 같은 고급 처리 기술과 통합

데이터 플랫폼

데이터 웨어하우스와 데이터 레이크의 기능을 융합

중요성이 증가하고 있음 !!!

4. 모던 데이터 스택

모던 데이터 스택: 현재 유행하는 분석 아키텍처! 향후 몇 년 동안 더 널리 사용되리라 예상되는 추상화 유형을 강조함.

• 클라우드 기반의 플러그 앤 플레이(PnP: 간편하게 연결해서 바로 사용할 수 있는) 방식 사용
• 모듈식 → 복잡성 낮춤!
• 사용자 기반, 커뮤닡, 코드리뷰
• 통합 data platform과 잘 어울림
• 기본 컴포넌트: 데이터 원천 → 클라우드 기반 데이터 커넥터와 통합 → 클라우드 데이터 웨어하우스 → BI와 시각화
• 이해하기 쉬운 가격 책정과 구현을 갖춘 PnP 모듈 방식의 핵심이 미래에는 중요할 것임 !

5. 람다 아키텍처

등장 배경

• 카프카의 등장! : 스트리밍 데이터 관련 작업의 인기가 폭발함
• 배치 및 스트리밍 데이터를 단일 아키텍처로 작동하는 방법을 찾아야 했다.

람다 아키텍처

• 배치, 스트리밍이 서로 독립적으로 작용
• 원천 시스템은 추가만 가능하고, 데이터 처리할 때는 스트림과 배치라는 두 목적지로 도달
• 인스트림 : 데이터 전달 ! (속도에서 가장 낮은 지연시간으로 전달하는 것이 목표)
• 배치계층 : 처리, 집계
• 서빙계층: 두 계층 쿼리 결과 집계
• 아키텍처 모습: 원천 시스팀 → 스트림처리, 배치처리 → 전달 (스트림쿼리, 배치쿼리) ↔ 쿼리

문제점

• 가장 권장되지는 않음 !
• 코드 베이스다르면 어렵기 때문
• 그래서 밑에 카파 아키텍처에 대해 알아보자

6. 카파 아키텍처

• 람다의 단점 보완
• 주요 특징: 스트림 처리 플랫폼을 모든 데이터 처리의 백본으로 사용!
  • 스트림 소스 → 스트림처리 → 서빙계층 ↔ 쿼리

장점

• 실시간 이벤트 스트림 직접 읽고 대량 데이터 청크 재생해 일괄 처리하여 동일한 데이터에 실시간 및 배치 처리 매끄럽게 적용할 수 있음

채택 X 이유

1. 스트리밍 자체는 사실 많은 기업에게 여전히 미지의 영역
2. 스트리밍 시스템 이용하기 때문에 복잡하고 비용 많이 듦. 반대로 배치 스토리지와 프로세싱은 방대한 데이터셋에 비해 훨씬 효과적이고 비용 효율적임

7. 데이터 흐름 모델, 통합 배치, 스트리밍

핵심과제 배치 및 스트리밍 데이터를 통합하는 것 !!

• 포인트 1. 여러 코드 경로를 통합

카파 아키텍처의 문제점

• 통합 큐잉 및 스토리지 계층에 의존하지만, 실시간 통계 수집이나 배치 작업하려면 다른 도구 써야된다.

데이터 흐름 모델, 아파치 프레임워크 (구글)로서의 해결

• 모든 데이터를 이벤트로 간주 !
  • 지속적인 실시간 이벤트 스트림은 무한 데이터
  • 배치 처리는 단순히 경계가 있는 유한 이벤트 스트림
• 따라서, 실시간 처리와 배치 처리는 거의 같은 코드 사용해 같은 시스템에서 이뤄짐 !
• 슬라이드나 텀블링 등 다양한 윈도 중에서 하나를 실시간 집계를 위해 선택

8. IoT용 아키텍처

사물인터넷: 주변 환경에서 주기적으로 또는 지속해서 데이터를 수집해 목적지로 전송하는 장치에서 데이터를 생성

장치 : 데이터 수집하는 장치는 모두 IoT 장치이다.

장치와 인터페이스:

• IoT 게이트웨이 : 장치를 연결하고 인터넷상의 적절한 수신처에 안전하게 라우팅하는 허브
• 적은 전력으로 장치 연결
• 중간 기착지 역할
• 장치의 스웜은 물리적 위치마다 하나씩 다수의 IoT 게이트 웨이 활용함

수집

• 이벤트 수집 아키텍처로 유입될 수 있다.

스토리지

• 지연 요건에 따라 크게 달라짐
  • 원격 센서: 배치 객체 스토리지
  • 모니터링 및 자동화 설루션: 실시간에 가까운 응답

서빙

• 패턴이 엄청 다양
• 역 ETL

9. 데이터 메시

개념

(중앙 집중식 데이터 레이크 및 데이터 웨어하우스 같은)데이터 모놀리식 데이터 플랫폼 ↔ 운영 데이터와 분석 데이터

사이에서 환경이 구분되는 ‘데이터 격차’에 대한 최근의 대응책이다.

포인트

• 중앙집중식 X ! 탈중앙화!
• 중앙 소유의 레이크에서 데이터 보내는 대신, 쉽게 소모할 수 잇는 방식으로 데이터셋 호스팅하고 제공

핵심 구성 요소

• 도메인 지향 분산형 데이터 소유권 및 아키텍처
• 제품으로서의 데이터
• 플랫폼으로서의 셀프서비스 데이터 인프라
• 통합 컴퓨팅 거버넌스

10. 기타 데이터 아키텍처 예시

종류 엄청 다양

• 아키텍처에는 데이터 패브릭, 데이터 허브, 확장 아키텍처, 메타데이터 우선 아키텍처, 이벤트 기반 아키텍처, 라이브 데이터 스택 등 수많은 종류 있음.

데이터 엔지니어의 역할

• 새로운 아키텍처가 조직에 어떻게 도움되는지 주목
• 한 가지 접근 방식에 집착 X
• 잠재적 가치 파악 → 심화 학습 → 구체적 결정 → 비지니스 긍정적 영향 초래

3.5 데이터 아키텍처 설계 담당자는 누구인가?

아키텍트의 역할

• 최신상태 유지
• 기술과 데이터의 상태에 부합하는 아키텍처

경계의 모호

• 데이터 엔지니어와 아키텍트 역할 경계가 모호해지고 있따 !

1. 데이터 생성

원천시스템 (source system)

데이터 엔지니어링 수명 주기에서 사용되는 데이터 원본이다. 예시) IoT 장치, 메시지 대기열, 트랜잭션 데이터베이스 등

원천 시스템의 평가: 주요 고려사항

• 데이터 원천데이터의 본질적인 특징 (애플리케이션? IoT 장치의 스웜?)
• 원천 데이터의 유지 기간
• 데이터의 생성 속도
• 출력 데이터의 일관성
• 에러 발생 / 중복포함 / 동시 출발, 늦게 도착 / 스키마 / 얼마나 자주 가져와야하는지
• 상태가 있는 시스템의 경우 변경 관리
• 다운스트림 사용 위한 데이터 제공업체 누구? 데이터 원천에서 데이터 조회하면 성능 영향 있는지?
• 업스트림, 원천 의존관계
• 늦거나 누락된 데이터 품질 검사

스키마

• 데이터의 계층 구성 정의

1. 스키마리스 : 스키마 없다는 거 아님. 도큐먼트 EB에 데이터 기록될 때
2. 고정스키마 : 관계형 데이터베이스 스토리지

어느쪽이 됐든 스키마는 변한다! 스키마의 진화는 애자일 접근 방식에서 장려됨!

데이터 엔지니어의 핵심은 원천 시스템 스키마에서 → 원시데이터 입력받고 → 유용한 출력으로 변환!!!!

스키마 진화하고 있어서 어려워지고 있지만 중요함…

2. 데이터 저장

데이터 저장은 복잡한 단계의 하나이기도 하다.

1. 클라우드의 데이터 아키텍처는 여러 스토리지 솔루션 활용함
2. 복잡한 변환 쿼리 지원하는 데이터 스토리지 솔루션은 순수하게 스토리지로서만 작동하는 경우가 거의 없고 많은 솔루션이 복잡한 변환쿼리를 지원한다. (Amazon S3 Select등)
3. 저장은 데이터 엔지니어링 수명 주기의 한 단계이지만 수집, 변환, 서비스 제공과 같은 다른 단계에도 자주 관여한다.

• 저장은 여러 파이프라인 위치에서 발생
• 전체 수명 주기에 걸쳐서 실행되고 영향을 미친다.

ex) 아파치 카프카, 펄사

스토리지 시스템 평가: 주요 엔지니어링 고려 사항

• 아키텍처의 요구 속도와 잘 맞는지
• 병목 현상
• 부자연스러운 행동
• 높은 random access 비율
• 향후 예상되는 확장을 처리하는지
• 용량 제한
• 메타데이터
• SLA에 따라 데이터 취득?
• 순수 스토리지? 쿼리 패턴 요구?
• 스키마 구애? 유연 스키마(카산드라)? 강제 적용 스키마?
• 데이터 거버넌스를 위해 품질, 계보 어떻게 추적?
• 법령 준수?

데이터 접근 빈도 이해

1. 핫데이터

   가장 자주 엑세스 되는 데이터

2. 미온적 데이터

   가끔 (ex. 매주/매월) 액세스되는 데이터

3. 콜드데이터

   거의 쿼리되지 않으며 아카이브 시스템에 저장하는 데 적합

   • 벤더가 월 스토리지 비용은 매우 저렴 but 데이터 검색 비용은 높은 특화된 스토리지 계층을 제공

스토리지 시스템 선택

범용 스토리지 권장 사항 없음. 모든 스토리지는 장단점, 트레이드 오프가 있다!

따라서 질문 목록들을 잘 따져서 고려하는게 중

3. 데이터 수집

수집 단계에서의 주요 고려사항

• 수집 중 데이터 사용 사례? 여러 버전 생성 대신 데이터 재사용 가능한가?
• 데이터 안정적으로 생성하고 수집? 필요시 해당 데이터 사용할 수 있는가?
• 수집 후 데이터 목적지는?
• 데이터에 얼마나 자주 접근?
• 데이터는 보통 어느 정도의 용량으로 도착?
• 데이터 형식은?
• 다운스트림 스토리지 및 변환 시스템에서 형식 처리 가능?
• 원천 데이터 다운스트림에서 즉시 사용할 수 있는 양호한 상태? 얼마나 오래 사용? 사용 할 수 없는 이유는?
• 데이터가 스트리밍 소스에서 전송된 경우 목적지에 도달하기 전에 데이터 변환해야 하는가? 데이터가 스트림 자체 내에서 변환되는 형태의 변환이 적절한가?

배치 vs 스트리밍

스트리밍: 우리가 다루는 대부분의 데이터는 본질적으로 스트리밍! 원천에서 지속해서 생성되고 갱신됨

• 다운스트림 시스템에 데이터를 실시간으로 연속해 제공할 수 있음

배치 수집:스트림을 큰 청크로! 처리하는 전문적이고 편리한 방법!!!

• 미리 설정된 시간 간격에 따라 or 데이터가 미리 설정된 크기 임곗값에 도달하면 수집됨
• 수집이 한 방향으로 이뤄짐!
• 배치로 분할되면 다운스트림 소비자의 지연 시간이 본질적으로 제한됨

동향

이벤트 스트리밍과 처리 플랫폼이 보편화됨에 따라, 데이터 스트림의 지속적 처리에 대한 접근성과 인기가 높아지고 있음.

배치 스트림 주요 고려 사항

스트리밍 굉장히 매력적이지만, 배치 수집보다 적절한지 자문해보아야함.

• 데이터를 실시간으로 수집하면 다운스트림 스토리지 시스팀이 데이터 흐름 속도를 처리할 수 있는가?
• 밀리초 단위의 실시간 데이터? or 매분마다 데이터 축적하고 수집하는 마이크로 배치 접근이 효과적?
• 스트리밍 수집 사례는? 어떤 이점? 데이터 실시간 → 개선된 데이터에 어떤 조치 취하지?
• 시간, 비용, 유지보수, 다운타임, 기회비용
• 인프라 장애 발생 시 스트리밍 파이프라인과 시스템이 안정적이고 다중화되어 있는지
• 사용 사례에 가장 적합한 도구는? 관리형 서비스(Kinesis, GCD) ? or 인스턴스 구축?(Kafka, spark 등) 후자라면 관리는 누가? 비용? 트레이드오프?
• ML 모델 배포 시 온라인 예측 및 지속적 훈련으로 얻는 이점은?
• 실제 운영 인스턴스에서 데이터를 가져오는가? 수집 프로세스의 영향도는?

푸시 vs 풀

푸시 : 데이터베이스, 객체 저장소, 파일 시스템과 관계 없이 원천시스템은 타깃에 데이터를 씀

ex) CDC(change data capture)

데이터베이스에서 행이 변경될 때마다 메시지 트리거 ! 메시지는 큐에 푸시되고 수집 시스템이 해당 메시지를 가져감

풀 : 원천시스템에서 데이터를 검색함.

ex) ETL 프로세스 (추출, 변환, 적재)

• 추출(extract) 부분은 풀 수집 모델을 다룸!

  정해진 일정에 따라 현재 소스 테이블의 스냅숏을 쿼리

4. 데이터 변환

데이터 수집했으면 다운스트림 사용 사례에 유용한 형태로 변경해야겠지?

적절히 변환을 안해주면.. ML에 유용하지가 않음!

변환 단계의 주요 고려사항

• 변환에 드는 비용과 투자수익률(ROI)는 얼마? 관련 비지니스 가치는?

• 변환은 단순하고 독립적인지!

• 비지니스 규칙은?

• 변환은 수명주기의 다른단계와 얽히는 경우가 많음

• 수집중에 변환되거나 원천시스템에서 변환됨.

  ex. 수집 프로세스에 전송하기 전에 이벤트 타임스탬프를 레코드에 추가

• 데이터 정제와 같은 변환 작업은 최종 소비자에게 가치를 더해줌

• 비지니스 로직은 모델링에서 데이터 변환의 주요 원인이 됨.

  • ex 판매의 의미 = 12개의 사진 프레임을 30달러, 총 360달러에 구입했다는 의미
  • 회계 규칙의 논리를 추가해야함.

5. 데이터 서빙

이제 데이터로부터 가치를 창출해보자!

가치 : 데이터가 실용적으로 사용될 때 가치가 있다! 소비되지 않거나 쿼리되지 않는 데이터는 걍 단순 비활성 상태일 뿐…. 데이터 허영은 기업의 주요 리스크임.

1. 분석

   

   1. 운영분석

      운영의 상세 사항에 중점두고 보고서 사용자가 즉시 수행할 수 있는 작업을 촉진

      ex. 재고 물품에 대한 실시간 뷰, 앱 상태에 대한 실시간 대시보드

      현재에 중점 두기 때문에 BI처럼 과거 동향과는 관련 없음

   2. BI & 애드혹

      기업의 과거와 현재 상태 설명 위해 데이터 수집! 비지니스 로직과 정의에 대한 레포 유지함.

      기업의 데이터 성숙도 높아짐에 따라 애드혹 데이터 분석에서 셀프 서비스 분석으로 전환해 IT 부서의 개입 없이도 비지니스 사용자가 데이터 접근 가능해질 수 있음.

   3. 임베디드 분석 (고객 대면 분석)

      기업은 수천 명 이상의 고객에게 별도의 분석 및 데이터를 제공할 수 잇고, 고객은 이때 다른 고객이 아닌 자기자신의 데이터만 확인할 수 있어야함!!!!

      데이터 유출, 취약성과 관련해 피해 범위 최소화해야함

      모든 장소에서 테넌트 or 데이터 수준의 보안을 적용한다.

      멀티 테넌시

      ✅ 멀티테넌시(Multi-tenancy)는 소프트웨어 아키텍처에서 여러 개의 사용자가 하나의 소프트웨어 애플리케이션 또는 시스템을 공유하지만, 각 사용자는 자신의 데이터와 구성을 가지고 있는 방식을 의미합니다. 이 개념은 특히 클라우드 컴퓨팅 환경과 SaaS(Software as a Service) 모델에서 중요합니다. 라고 지피티가 알려줌!

2. 머신러닝

   데이터 엔지니어가 ML에 능숙하면 좋다..!

   ML서빙 단계에 고려해야할 사항이 있다.

   • 신뢰할 수 있는 특성 엔지니어링을 수행하기에 충분한 품질의 데이터? 품질 요구사항 및 평가는 팀이 개발
   • 데이터 검색 가능? 가치 데이터 쉽게 찾을 수 있음?
   • 조직적 경계는 어떻게 되지?
   • 데이터셋이 편향되지 않았는지, 실제 상황 반영하는지

3. 역ETL

   수명주기의 출력 측에서 처리한 데이터를 다시 가져와서 원천 시스템에 공급하는 것.

   ex. 마케팅 분석가는 데이터 이용해서 입찰가 계산한 다음에 다시 구글 애즈에 업로드할 수 있음

   역ETL은 아직 초기 단계지만 앞으로 더 발전할 것임. 점점 중요해지고 있음.

2.2 수명주기의 드러나지 않는 요소들

1. 보안

보안을 최우선으로 생각해야하며, 위험을 이해해야함!!!!

• 최소 권한 원칙 실행해야한다. (필수적인 데이터와 자원에만 접근할 수 있도록)
• 접근 타이밍과 관련이 있다. 해당 작업을 수행하는데 필요한 기간동안만 허용한다.

2. 데이터 관리

1. 데이터 거버넌스

   • 데이터 품질, 무결성, 보안 및 사용성 보장하기 위한 관리 기능
   • 핵심 범주는 발견가능성(쉽게 찾아 쓸 수 있어야), 보안, 책임!
     • 하위범주 : 메타데이터, 개인정보보호 등

   1. 발견가능성 : 데이터 중심 기업에선 데이터를 사용할 수 있고 검색할 수 있어야함. 안정적으로 접근할 수 있어야하고 데이터 출처와 다른 데이터와의 관계, 데이터 의미를 알아야한다.

      1. 메타데이터 : 데이터에 관한 데이터. 데이터 검색하고 제어하는 데 필요한 데이터
         1. 비지니스 메타데이터 : ex. ‘고객’에 대한 정의
         2. 기술 메타데이터 : 파이프라인 메타데이터, 데이터 계보, 스키마
         3. 데이터 계보 메타데이터: 원본과 변경하상, 종속성을 시간에 따라 추적
         4. 스키마 메타데이터: DB, 데이터 웨어하우스, 데이터 레이크 or 파일 시스템 같은 시스템에 저장된 데이터 구조 설명
         5. 운영 메타데이터: 다양한 시스템의 운영 결과를 설명. 작업 id, 앱 런타임 로그, 프로세스 사용되는 데이터 및 오류 로그에 대한 통계 포함
         6. 참조 메타데이터: 다른 데이터를 분류하는 데 필요한 데이터로, 조회 데이터라고도 한다. 내부 코드, 지리적 코드, 측정 단위 및 내부 달력 표준 등이 표준 사례.

   2. 데이터 책임

      데이터의 일부를 관리할 개인을 지정하는 것을 의미함. 문제가 있는 데이터에 대해 책임지는 사람이 없으면 품질 관리 어렵기 때문이당.

      데이터 책임의 수준 : 다양할 수 있음. 테이블, 로그 스트림 혹은 여러 테이블에 걸쳐 발생하는 단일 필드 엔티티처럼 세분화될 수도

   3. 데이터 품질

      데이터를 원하는 상태로 최적화하는 것으로 ‘기대하는 것과 비교해 어떤 결과를 얻을 수 있을까? 라는 질문을 중심으로 한다.

      1. 정확도: 실제로 정확한가? 중복된 값 있는가? 수치가 정확한가?

      2. 완전성: 기록은 완전한가? 모든 필수 필드에 유횻값이 포함되는가?

      3. 적시성: 기록 시기 적절하게 이용할 수 있는가?

         ✅ 마스터 데이터 : 직원, 고객, 제품 및 위치와 같은 비지니스 엔티티에 대한 데이터임. 마스트 데이터도 잘 관리해야되고… MDM(마스터 데이터 관리)는 골든 레코드로 알려진 일관된 엔티티 정의 구축하는 관행임.

2. 데이터 모델링 및 설계

   • 데이터 분석과 과학을 통해 비지니스 통찰 얻어야한당! 데이터를 사용 가능한 형태로 변환하는 프로세스를 데이터 모델링 및 설계라고 한다.
   • 데이터 모델링은 API 호출, MySQL 테이블 스키마에 대한 JSON 응답 설계도 다 포괄하는 개념임.
   • 원천 데이터 다양해지면서 모델링 어려워짐.

3. 데이터 계보

   데이터가 수명 주기 거치면서 어떤 시스템이 데이터에 영향 줬는지, 데이터가 전달 변환될 때 어떤 데이터가 구성됐는지를 데이터 계보를 통해 알 수 있음

   • 데이터 계보 : 데이터 처리하는 시스템과 의존하는 업스트림 데이터 모두 축적해서 수명 주기 전체에 걸쳐 데이터의 감사 추적을 기록함
   • DDOD (data observability driven development) : 계보를 통해 데이터 관찰. 개발, 테스트, 최종 생산 과정에 적용돼 기대에 부응하는 품질과 적합성 제공함.

4. 저장 및 운영

5. 데이터 통합 및 상호 운용성

   여러 도구와 프로세스 전반에 걸쳐 데이터를 통합하는 프로세스임.

   • 맞춤형 DB 연결이 아닌 범용 API를 통해 이뤄지는 경우가 늘고 있음
     • ex. 데이터 파이프라인은 세일즈포스의 API에서 데이터 가져와 S3에 저장하고 Snowflake의 API를 호출해 테이블 적재 → API 다시 호출 쿼리 실행 → S3로 결과 이송 → 스파크가 데이터 소비
   • 데이터 시스템과의 상호 작용의 복잡성은 감소했지만, 시스템 수와 파이프라인의 복잡성은 극적으로 증가했다! 따라서 오케스트레이션 필요

6. 데이터 수명 주기 관리

   데이터 레이크 등장으로 데이터 보관 및 파기를 무시하게 됨. 스토리지 무한대로 추가할 수 있는데 왜 굳이 데이터 폐기해야할까?

   • 클라우드에 점점 더 많은 데이터가 저장되고 있음
   • GPR과 CCPA같은 개인정보보호 및 데이터 보존법에 따라 ‘잊혀질 권리’ 존중 위해 적극적으로 파기 해야함.
   • WORM(write once read many)가 기본 스토리지 패턴인 데이터 레이크에서 데이터 파기가 어려워졌음. 메타데이터, 데이터 계보 등으로 마지막 단계 간소화해야

7. 고급 분석 및 ML을 위한 데이터 시스템

8. 윤리 및 개인정보 보호

   윤리와 개인정보보호는 데이터 엔지니어링 수명 주기에 영향 미침.

   ex. 개인식별정보 및 중요한 ㅈ어보 마스킹 처리

   규제요건과 컴플라이언스에 대한 처벌 점점 더 엄격해지고 있음. 잘 이해해야

3. 데이터옵스

1. 자동화
   • 변경관리(환경, 코드 및 데이터 버전 제어), CICD, 코드로 구성된 데브옵스와 유사한 프레임워크 및 워크플로 가짐
   • Airflow Dagster와 같은 오케스트레이션 프레임워크
   • 워크로드를 줄이고 비지니스에 제공하는 가치 높일 수 있는 자동화를 지속해서 구현하려고 해야함.
2. 모니터링 및 관찰 가능성
   • 중요한 결정 내리고 한참 뒤에 오류 발견하면 안되니까 데이터와 생성 시스템을 감시하고 관찰해야한다.
3. 사고 대응
   • 실수는 필연적으로 발생한다.
   • 사고 대응은 기술과 도구에만 국한하지 않는다.
   • AWS의 최고 기술 책임자(CTO)인 베르너르 포헐스 - ‘모든 것은 항상 망가진다’ (ㅜㅜ)
   • 재해에 대비하고 가능한 신속 효율적으로 대응할 준비 해야함
   • 보고 하기 전에 미리 문제 발견해야됨
   • 선제 대처와 사후 대응 다 중요

4. 데이터 아키텍처

1. 비지니스 요구 사항 이해하고 새로운 요구사항 수집
2. 1의 요건 변환해 비용과 운영 간소화를 균형 있게 유지하며 데이터 캡처하고 제공하는 새로운 방법 설계
3. 기술 및 도구의 트레이드오프 파악

5. 오케스트레이션

오케스트레이션: 많은 작업이 예약된 순서대로 최대한 빠르고 효율적으로 실행되도록 조정하는 프로세스(Airflow 등)

• DAG(directed acyclic graph)의 형태로 작업 종속성에 따라 메타데이터를 구축
• DAG는 한번만 실행되거나 매주, 매일, 매시간, 5분 등 일정한 간격으로 실행되도록 스케줄링 가능
• 감지 및 모니터링 가능
• 특정 조건 벗어나거나 데이터가 제시간에 도착 안하면 경고 보내기도
• 작업 기록 기능, 시각화 및 경고 기능 구축
• 오케스트레이션은 엄밀히 말해 ‘배치 개념’임
  • 대안은 스트리밍 DAG. BUT 여전히 유지 구축 보수 어려움 그치만 펄사(Pulsar)와 같은 차세대 스트리밍 플랫폼은 운영 부담 줄이는 거 목표로하고 있음!!!

6. 소프트웨어 엔지니어링

2000-2010: 저수준 프레임워크 C, C++, Java에서 맵리듀스 잡 작성

2010 중반: 추상화한 프레임워크 사용 시작

소프트 엔지니어링의 공통 영역

1. 코어 데이터 처리 코드 : 더 추상적/관리쉬워짐. 그치만 처리 코드 여전히 작성해야됨.
   • 언어: Spark, SQL, Beam 등의 프레임워크와 언어에 능숙하고 생산성 뛰어나야 함
   • 코드 테스트 방법론: 단위, 회귀, 통합, 앤드투엔드, 스모크 등의 적절한 코드 테스트 방법론을 이해하는 것이 중요함
2. 오픈 소스 프레임워크 개발
   • 빅데이터 시대엔 하둡 생태계에서 프레임워크 폭발적 증가.
   • 새로운 내부 도구를 엔지니어링 하기 전에 사용할 수 있는 도구의 환경 조사하는 게 좋음! (TCO)총 소유 비용과 기회비용에 주목하자..
   • 해결해야 할 문제 해결하는 오픈 소스는 이미 있을 것이당!!!
3. 스트리밍
   • 다양한 윈도잉 방법론을 적용할 코드를 작성해야함
   • 윈도잉을 사용하면 실시간 시스템에서 추적 통계와 같은 중요한 측정 지표 계산할 수 있음!
   • 개별 이벤트 처리하는 다양한 함수 플랫폼 (OpenFaaS, AWS람다, GCF) 또는 스트림을 분석해 보고 및 실시간 작업을 지원하는 전용 스트림 프로세서(Spark, Beam, Pulsar) 등 다양한 프레임워크 중 선택할 수 있다.
4. 코드형 인프라
   • 인프라 관리 부담은 기업들이 데이터브릭스나 아마존(EMR)같은 관리형 빅데이터 시스템과 클라우드 데이터 웨어하우스로 이전함에 따라 감소하고 있다.
   • 클라우드 환경에서 인프라 관리하는 경우, IaC 프레임워크로 대응하는 사례 늘고 있음.
   • 헬름 등의 도구 써서 컨테이너와 쿠버네티스 사용하는 IaC의 개념도 있다!
   • 버전 제어와 배포 반복성 실현
5. 코드형 파이프라인
   • 오케스트레이션 시스템의 핵심 개념
   • 일반적으로 python사용해서 데이터 작업과 데이터 간의 족속성 선언
6. 범용 문제 해결
   • 파이브트랜, 에어바이트, 마틸리언과 같은 프레임워크 사용할 때 기존 커넥터가 없는 데이터 원천에 직면. 사용자 정의 코드 작성해야됨
   • API 이해, 데이터 풀링 및 변환 수행, 예외 처리하는 등 소프트웨어 엔지니어링에 익숙해야함.

데이터 엔지니어링에 대해 전문가들은 어떤 정의를 내리고 있을까?

💓 ...데이터 엔지니어는 조직의 데이터 인프라를 구축하고 운영해 데이터 분석가와 데이터 과학자가 추가 분석을 수행할 수 있도록 준비한다… -알텍스소프트의 ‘데이터 엔지니어링의 개념, 프로세스 및 도구’

데이터 엔지니어링의 첫 번째 유형은 SQL 중심이다… 데이터 엔지니어링의 두 번째 유형은 빅데이터 중심이다…-제시 앤더슨

1.1.1 데이터 엔지니어링 정의

수 많은 용어 정의가 있지만 우리 나름대로 앞으로 책을 읽어가며 사용할 용어를 채택해야됨! 아래와 같음.

💓 데이터 엔지니어링은 원시 데이터를 가져와 분석 및 머신러닝과 같은 다운스트림 사용 사례를 지원하는 ‘고품질의 일관된 정보를 생성하는 시스템과 프로세스의 개발, 구현 및 유지 관리이다. 데이터 엔지니어링은 보안， 데이터 관리， 데이터 운영， 데이터 아키텍처， 오케스트레이션， 소프트웨어 엔지니어링의 교차점이다. 데이터 엔지니어는 원천 시스템에서 데이터를 가져오는 것부터 시작해 분석 또는 머신러닝과 같은 사용 사례에 데이터를 제공하는 것으로 끝나는 데이터 엔지니어링 수명 주기를 관리한다.

1.1.2 데이터 엔지니어링 수명 주기

핵심은

• 데이터 생성
• 데이터 저장
• 데이터 수집
• 데이터 변환
• 데이터 서빙
• • 드러나지 않는 요소
    • 보안 / 데이터관리 / 데이터옵스 / 데이터 아키텍처 / 오케스트레이션 / 소프트웨어 엔지니어링

1.1.3 데이터 엔지니어의 진화

1980년~2000년 : 데이터 웨어하우징 → 웹

데이터웨어하우스 : 1989년, 빌 인먼

✅ 데이터 웨어하우스는 POS 트랜잭션, 마케팅 자동화, 고객 관계 관리 시스템 등의 여러 소스에서 가져온 구조화된 데이터와 반구조화된 데이터를 분석하고 보고하는 데 사용되는 엔터프라이즈 시스템입니다. 데이터 웨어하우스는 임시 분석과 커스텀 보고서 생성에 적합합니다. 데이터 웨어하우스는 현재 데이터와 과거 데이터를 모두 한곳에 저장할 수 있으며, 시간 흐름에 따른 장기간의 데이터 동향을 확인할 수 있도록 설계되었으므로 비즈니스 인텔리전스의 주요 구성요소입니다. 출처: https://cloud.google.com/learn/what-is-a-data-warehouse?hl=ko

인터넷 : AOL, 야후, 아마존 등 1990년

2000년대 초: 현대 데이터 엔지니어링의 탄생

• 차세대 시스템 : 비용 효율적, 확장성, 가용성, 안정성
• 빅데이터 시대의 시작 (모놀리식 서비스 분산, 분리)
• 구글 논문 → 아파치 하둡
• 아마존 EC2, S3, NoSQL → AWS → 구글 클라우드, 마이크로소프트 애저, 디지털 오션 등 퍼블릭 클라우드의 잇따른 등장

2000년대와 2010년대: 빅데이터 엔지니어링

• 실시간 데이터 혁명
• 이벤트 스트리밍
• 빅데이터 엔지니어 단순화!!!!와 추상화!!!!!(복잡하고 어려운 기술 사용에 집중하지 않아도되게됨)

2020년대: 데이터 수명 주기를 위한 엔지니어링

• 분산, 모듈화, 관리, 고도의 추상화
• 모던 데이터 스택 : 조립된 상용 오픈 소스/서드파티제품들의 모음
• 데이터 수명 주기 엔지니어로 데이터 엔지니어를 더 정확하게 묘사할 수 있게 됨
• 저수준의 프레임워크 세부 사항에 방해 받지 않음!!!
• 데이터 관리와 통제에 더 집중
• 탈중앙화 민첩성
• 현재를 데이터 수명 주기 관리의 황금기로 봄!

1.1.4 데이터 엔지니어링과 데이터 과학

• 하위 세 부분에 소비하는 시간이 거의 70-80%
• 데이터 엔지니어가 계층 구조 최하단에 있는 작업 집중할 때 DS도 성공할 수 있는 견고한 기반 구축할 수 있음

1.2 데이터 엔지니어링 기술과 활동

기술 역량 中 드러나지 않는 요소 : 비용, 민첩성, 확장성, 단순성, 재사용성, 상호 운용성

• 소프트웨어 엔지니어링, 네트워킹, 분산 컴퓨팅, 스토리지 / 기타 저수준의 세부사항 역시 정교하게 이해해야함

1.2.1 데이터 성숙도와 데이터 엔지니어

데이터 성숙도 : 조직 전체에 걸쳐 더 높은 데이터 활용률, 기능, 통합을 향해 나아가는 과정. BUT 매출에 의해 결정되는 단순한 것은 아님… 중요한 것은 데이터가 경쟁 우위로 활용되는 방식!

1. 데이터로 시작하기
   1. 데이터를 이제 막 시작하는 기업! 회사에는 애매모호하고 느슨하게 정의된 목표가 있거나 없을 수도..
2. 데이터로 확장하기
   1. 공식적인 데이터 요청 관행을 가짐 데이터 관행을 수립하고 확장성 있고 견고한 데이터 아키텍처 구축을 해야함
3. 데이터로 선도하기
   1. 이 단계에서 기업은 데이터 중심. DE가 작성한 자동화된 파이프라인과 시스템을 통해 사내 직원은 셀프 서비스 분석과 ML수행 가능

1.2.2 데이터 엔지니어의 배경과 기술

• 소프트웨어 엔지니어, ETL 개발, 데이터베이스 관리, 데이터 과학, 데이터 분석과 같은 인접한 분야에서 전환하기가 가장 쉽다
• 데이터 엔지니어는 정의상 데이터와 기술을 모두 이해해야 한다.
• 데이터 엔지니어는 데이터 소비자(데이터 분석가 및 데이터 과학자)의 요구 사항과 조직 전체에 걸친 데이터의 광범위한 의미를 이해해야 한다.
• 데이터 엔지니어링은 전체적인 (종합적인) 실무이며 최고의 데이터 엔지니어는 비즈나스 및 기술적 관점에서 그들의 책임을 판단한다.
• 한마디로 만능…

1.2.3 비지니스 책임

• 비기술자 및 기술자와 커뮤니케이션
• 비지니스 요건과 제품 요건 살펴보고 수집하는 방법 이해
• 애자일, 데브옵스, 데이터 옵스의 문화적기반 이해
• 비용 관리
• 지속적 학습

1.2.4 기술 책임

수명주기 드러나는 요소 + 드러나지 않는 요소

코딩도 할 줄 알아야됨

상세한 아키텍처 잘 들여다볼 수 있어야됨

SQL, 파이썬, JVM언어, 배시 등

✅ 새로운 기술이 등장했을 때 그 흐름에 동참하지 못하면 도태될 것이다. - 스튜어트 브랜던 ㄷ ㄷ ㄷ ㄷ

1.2.5 A에서 B로 이어지는 데이터 엔지니어링 역할의 연속성

A(analysis)형 데이터 과학자 : 분석 , 통찰력, 추상화

B(build)형 데이터 과학자 : 강력한 프로그래밍 기술, 시스템 구축

1.3 조직 내 데이터 엔지니어

1.3.1 내부 vs 외부 대면 데이터 엔지니어

외부 대면 데이터 엔지니어 : sns, iot, 전자 상거래 등 외부용 앱 사용자와 연계/피드백 루프가 있음

내부 대면 데이터 엔지니어 : BI 대시보드, 보고서, 비지니스 프로세스, 데이터 과학, ml 모델용 데이터 파이프라인과 데이터 웨어 하우스 생성 / 유지보수 등

1.3.2 데이터 엔지니어와 기타 기술 역할

• 데이터 생산자와 데이터 소비자 사이에서의 허브 역할
• 데브옵스 엔지니어와 같이 운영 역할 하는 사람들과도 소통

업스트림 이해관계자

데이터 아키텍트, 소프트웨어 엔지니어, 데브옵스 엔지니어와 사이트 신뢰성 엔지니어

다운스트림 데이터 소비자

데이터 과학자, 데이터 분석가, 머신러닝 엔지니어

1.3.3 데이터 엔지니어와 비지니스 리더십

• 비기술적 역할도 수행
• 이니셔티브 주도 : CEO, CIO, CTO, CDO, CAO, CAO-2
• 데이터 엔지니어 및 PM, 제품 관리자
• 데이터 엔지니어와 기타 관리 역할 : 다양한 수신 요청 처리, 특정 관리자, 프로젝트 OR 제품에 할당된 자원으로 작업