Practice Test #3

예. 한 달에 한 번 급여를 지급 처리하는 것은 전형적인 batch workload입니다. 이를 규정하는 특징은 (1) 고정된 스케줄(매월), (2) 처리할 레코드 집합이 한정됨(해당 급여 기간의 모든 직원/급여 변경 사항), (3) 각 개별 payroll 이벤트가 발생하는 즉시 처리할 필요가 없음입니다. Batch 시스템은 낮은 latency보다 신뢰성, 감사 가능성(auditability), 처리량(throughput)을 우선합니다. 실제로 payroll은 종종 예약된 job으로 실행되어 근태(time/attendance)를 집계하고, 공제 및 세금을 적용하며, 하나의 통제된 실행에서 결과물(은행 파일, payslip, 원장(ledger) 엔트리)을 생성합니다. 왜 streaming이 아닌가? Streaming은 payroll 관련 이벤트를 거의 실시간(near real time)으로 지속적으로 처리하는 것을 의미합니다(예: 근무 시간이 기록되는 즉시 급여를 계산). 이는 월급 지급처럼 급여 주기 말에 결과가 필요한 일반적인 비즈니스 요구사항과는 다릅니다.

예. 초당 50개의 센서 측정값을 전송하는 풍력 터빈은 이벤트가 연속적이고 고속으로 흐르는 형태로 생성되기 때문에 streaming workload의 예입니다. 초당 50회라는 빈도는 데이터가 충분히 자주 도착하므로 자연스럽게 event stream으로 모델링되며, 이상 탐지, 예측 유지보수, 운영 대시보드, 알림과 같은 near-real-time use case를 지원하는 경우가 많습니다. Azure 관점에서 이 패턴은 IoT telemetry ingestion(Azure IoT Hub 또는 Event Hubs), real-time processing(Azure Stream Analytics, Databricks/Synapse Spark streaming), 그리고 hot/warm path를 위한 storage/analytics(Azure Data Explorer, Cosmos DB 또는 time-series에 최적화된 store)와 정렬됩니다. 이는 batch가 아닌데, 고장을 빠르게 감지하는 것이 목표라면 터빈 telemetry를 처리하기 위해 보통 몇 시간 또는 며칠을 기다리지 않기 때문입니다. 가치는 low-latency processing에서 나옵니다.

아니오. 하루에 한 번 측정값을 전송하는 가정용 전기 계량기는 streaming이라기보다 batch(또는 주기적) workload로 설명하는 것이 더 적절합니다. 데이터가 전자적으로 전송되더라도, 핵심 요소는 낮은 전송 빈도와 near-real-time 처리 요구사항이 없다는 점입니다. 일일 측정값은 일반적으로 청구, 사용량 요약, 추세 보고에 사용되며, 이러한 사용 사례는 더 높은 latency를 허용하고 보통 예약된 작업으로 처리됩니다. 왜 streaming이 아닌가? Streaming은 이벤트가 발생하는 대로 지속적으로 수집하고 처리하는 것을 의미하며, 보통 seconds-to-minutes 수준의 latency를 전제로 합니다. 하루 1회 telemetry는 연속적인 고속 스트림이 아니라 주기적 스냅샷입니다. Azure에서는 추가 요구사항(예: 즉각적인 정전 감지)으로 인해 더 빈번한 보고가 필요하지 않는 한, real-time stream processing 서비스보다는 예약된 ETL/ELT(예: Data Factory)를 통해 수집 후 처리하는 경우가 많습니다.

정답: A. control flow Azure Data Factory에서 control flow는 파이프라인 내에서 활동 실행 순서와 종속성을 오케스트레이션하는 기능입니다. 종속성 조건(예: 이전 활동이 Succeeds일 때만 활동 실행)과 If Condition, Switch, ForEach, Until, Wait, Execute Pipeline 같은 control activities를 사용하여, 이전 출력 또는 완료 상태에 의존하는 단계들을 조정합니다. 이는 “다른 파이프라인 활동의 출력에 의존하는 파이프라인 활동을 오케스트레이션”한다는 설명과 정확히 일치합니다. 다른 선택지가 틀린 이유: - B. Dataset: 활동에서 사용하는 데이터 구조와 위치(테이블, 파일, 폴더)를 정의하며, 실행 순서를 제어하지 않습니다. - C. Linked service: 데이터 저장소 또는 컴퓨팅에 대한 연결 정보(서버, 인증, 엔드포인트)를 저장하며, 오케스트레이션이 아닙니다. - D. Integration runtime: 데이터 이동 및 변환을 위한 컴퓨팅 인프라(Azure IR, Self-hosted IR)를 제공하며, 작업을 실행하지만 활동 간 종속성 로직을 정의하지는 않습니다.

Customer는 제공된 JSON 스니펫의 맥락에서 루트 객체입니다. 이 스니펫은 "customer"라는 최상위 속성을 보여주며, 그 값은 객체입니다(중괄호 { }를 사용합니다). 다른 이름의 속성 내부에 포함되어 있는 것으로 표시되지 않았기 때문에(예: { "order": { "customer": { ... } } } 같은 더 큰 객체 내부), 이 문서의 최상위/루트 객체로 취급됩니다. A(중첩 배열)가 아닌 이유: "customer"는 대괄호 [ ] 안에 있지 않으므로 배열이 아닙니다. B(중첩 객체)가 아닌 이유: "customer"가 중첩 구조를 포함하고 있기는 하지만, 질문의 의도는 "customer" 자체를 분류하는 것입니다. 이 스니펫에서 이는 설명 대상이 되는 주요/최상위 객체이므로 루트 객체로 분류하는 것이 가장 적절합니다.

Address는 중첩 객체입니다. "customer" 객체 내부에서 "address" 속성의 값은 중괄호 { }로 둘러싸여 있는데, 이는 객체를 나타냅니다. 또한 문서의 최상위 수준이 아니라 "customer" 객체 안에 존재하므로 중첩되어 있습니다. A(중첩 배열)가 아닌 이유: "address"는 대괄호 [ ]로 정의되어 있지 않으며, 여러 요소를 포함하지도 않습니다. "line 1", "line 2", "ZIP code"와 같은 속성을 가진 단일 객체입니다. C(루트 객체)가 아닌 이유: 루트 객체는 JSON 문서의 최상위 객체입니다. "address"는 명확히 "customer" 아래의 자식 속성이므로 루트가 될 수 없습니다.

소셜 미디어는 중첩 배열입니다. "social media" 속성은 대괄호 [ ]를 사용하여 정의되어 있으며, 이는 배열을 의미합니다. 해당 배열의 각 요소는 객체입니다(각 요소는 중괄호 { }를 가지며 "service"와 "handle"을 포함합니다). 또한 이 배열은 "customer" 객체 안에 포함되어 있으므로 중첩되어 있습니다. B(중첩 객체)가 아닌 이유: 배열 내부의 각 항목은 객체이지만, "social media" 속성 자체는 단일 객체가 아니라 객체들의 배열입니다. C(루트 객체)가 아닌 이유: "social media"는 최상위 레벨에 있지 않고 "customer" 내부의 속성이므로 루트 객체가 아닙니다.

정답: A. compute node 전반에 걸쳐 처리를 분산합니다. Azure Synapse Analytics dedicated SQL pool에서 MPP 엔진은 여러 compute node에 걸쳐 병렬로 실행되는 작업으로 업무를 분할하여 쿼리를 실행하도록 설계되었습니다. control node는 클라이언트 쿼리를 수신하고, 구문 분석 및 최적화를 수행한 다음, 쿼리 계획 단계들을 compute node에 분배하여 실행을 조정합니다. 각 compute node는 할당된 data distribution을 병렬로 처리하며, 이것이 대규모 분석 워크로드에서 MPP의 핵심 이점입니다. 다른 선택지가 틀린 이유: - B (control node 전반에 걸쳐 처리를 분산): Synapse는 여러 control node에 걸쳐 처리를 분산하지 않으며, control node는 주로 오케스트레이션을 수행합니다. - C (compute node 전반에 걸쳐 클라이언트 연결을 리디렉션): 클라이언트는 control node 엔드포인트에 연결하며, compute node는 클라이언트 연결 리디렉션에 사용되지 않습니다. - D (control node 전반에 걸쳐 클라이언트 연결을 리디렉션): 이 모델에는 연결 리디렉션을 위한 control node 풀(pool)이 없으며, control node가 조정 지점입니다.