데이터 분석 생태계의 보완 요소

엔지니어링, 시각화, BI, 실험 설계, 인과 추론

데이터 분석의 핵심 기술(통계, 머신러닝, AI) 외에도 실무에서 필수적인 데이터 엔지니어링, 시각화, 비즈니스 인텔리전스, 실험 설계, 인과 추론 등 데이터 분석 생태계를 구성하는 보완 요소들을 다룬다.

Statistics
Data Science
Data Engineering
저자

Kwangmin Kim

공개

2025년 12월 08일

1 데이터 분석 생태계 개요

1.1 데이터 분석 가치 사슬

원천 데이터
    ↓
[데이터 엔지니어링] ← 수집, 저장, 변환, 관리
    ↓
정제된 데이터
    ↓
[분석 및 모델링] ← 통계, ML, DL, AI
    ↓
분석 결과
    ↓
[시각화 및 BI] ← 대시보드, 리포트
    ↓
인사이트
    ↓
[실험 설계 및 검증] ← A/B 테스트, 인과 추론
    ↓
의사결정 및 실행
    ↓
비즈니스 가치

2 데이터 엔지니어링 (Data Engineering)

  • 데이터 분석 및 머신러닝 모델 구축을 위해 데이터를 수집, 저장, 변환, 관리하는 전체 과정을 의미한다.
  • 정제되지 않은 원천 데이터를 분석 가능한 형태로 가공하는 파이프라인을 구축하는 일이다.

2.1 핵심 활동

2.1.1 데이터 수집 (Data Collection)

데이터 소스:
- 데이터베이스 (RDBMS, NoSQL)
- API 연동
- 로그 파일
- 웹 크롤링
- IoT 센서
- 외부 데이터 제공자

수집 방식:
- 배치 (Batch): 정해진 시간에 대량 수집
- 스트리밍 (Streaming): 실시간 연속 수집

2.1.2 데이터 저장 (Data Storage)

저장소 유형:
- Data Warehouse: 구조화된 데이터 (예: Snowflake, BigQuery, Redshift)
- Data Lake: 원시 데이터 모든 형식 (예: S3, HDFS, Azure Data Lake)
- Data Lakehouse: Warehouse + Lake 통합 (예: Databricks, Delta Lake)

2.1.3 데이터 변환 (Data Transformation)

데이터를 원천 시스템에서 분석 가능한 형태로 변환하는 과정이다. ETL과 ELT는 이 과정의 작업 순서가 다른 두 가지 접근법이다.

2.1.3.1 ETL vs ELT 비교

ETL (Extract-Transform-Load) - 전통적 방식

작업 순서:

1. Extract (추출): 원천 시스템에서 데이터 추출
   ↓
2. Transform (변환): 별도의 처리 서버에서 데이터 변환 및 정제
   ↓
3. Load (적재): 변환된 데이터를 Data Warehouse에 저장

특징: - 변환 작업이 Data Warehouse 외부에서 발생
- 별도의 ETL 서버 필요
- 변환된 깨끗한 데이터만 적재

장점: - Data Warehouse 부하 감소
- 민감 정보 사전 제거 가능
- 네트워크 트래픽 절감 (필요한 데이터만 적재)

단점: - ETL 서버 추가 비용
- 변환 로직 수정 시 재처리 시간 오래 걸림
- 확장성 제한

적합한 경우: - 온프레미스 환경
- 작은 규모 데이터
- 변환 로직이 복잡하고 안정적인 경우

예시:

MySQL 데이터베이스 (원천)
    ↓ 추출
ETL 서버 (Talend, Informatica)
    ↓ 변환: 결측치 제거, 형식 통일, 집계
Redshift Data Warehouse (목적지)
    ↓ 적재: 이미 깨끗한 데이터

ELT (Extract-Load-Transform) - 최근 트렌드

작업 순서:

1. Extract (추출): 원천 시스템에서 데이터 추출  
   ↓
2. Load (적재): 원시 데이터를 그대로 Data Warehouse에 저장  
   ↓
3. Transform (변환): Data Warehouse 내부에서 SQL/쿼리로 변환

특징: - 변환 작업이 Data Warehouse 내부에서 발생
- 원시 데이터(Raw Data)를 먼저 저장
- 클라우드 Data Warehouse의 강력한 컴퓨팅 파워 활용

장점: - 빠른 데이터 적재 (변환 없이 바로 적재)
- 유연성 높음 (나중에 다양한 방식으로 변환 가능)
- 확장성 우수 (클라우드 자원 활용)
- 원시 데이터 보존 (감사, 재분석 가능)

단점: - Data Warehouse 스토리지 비용 증가
- 변환 작업이 Data Warehouse 리소스 사용
- 데이터 품질 관리 복잡

적합한 경우: - 클라우드 환경 (BigQuery, Snowflake, Redshift)
- 대규모 데이터
- 빠른 데이터 수집이 중요한 경우
- 변환 요구사항이 자주 변하는 경우

예시:

다양한 원천 (MySQL, API, 로그파일)
    ↓ 추출
BigQuery Data Warehouse
    ↓ 적재: 원시 데이터 그대로 저장 (raw_data 테이블)
    ↓ 변환: dbt로 SQL 쿼리 실행
        - 결측치 처리
        - 형식 통일
        - 집계 테이블 생성
최종 분석용 테이블 (clean_data, analytics_table)

2.1.3.2 왜 ELT가 최근 트렌드인가?

1. 클라우드 Data Warehouse의 발전
- BigQuery, Snowflake, Redshift 등은 강력한 컴퓨팅 파워를 제공
- 변환 작업을 빠르게 처리 가능
- 스토리지 비용 하락

2. 유연성 요구 증가
- 비즈니스 요구사항이 자주 변경
- 원시 데이터 보존 → 언제든 다시 변환 가능

3. 실시간 분석 수요
- 데이터를 먼저 적재 → 빠른 가용성
- 변환은 필요할 때 수행

4. dbt(data build tool) 같은 도구의 등장
- SQL 기반 변환을 코드로 관리
- 버전 관리, 테스트, 문서화 자동화

2.1.3.3 ETL vs ELT 비교표

구분 ETL ELT
변환 위치 외부 ETL 서버 Data Warehouse 내부
적재 데이터 변환된 데이터 원시 데이터
속도 느림 (변환 후 적재) 빠름 (바로 적재)
유연성 낮음 (재변환 어려움) 높음 (SQL로 재변환 쉬움)
확장성 제한적 우수 (클라우드 자원)
비용 ETL 서버 비용 Storage 비용
적합 환경 온프레미스 클라우드
복잡도 높음 낮음 (SQL 기반)
원시 데이터 보존 어려움 쉬움

2.1.3.4 실무 예시 비교

시나리오: 월별 매출 집계

ETL 방식:

1. MySQL에서 주문 데이터 추출 (100만 건)
   ↓
2. ETL 서버에서 변환
   - 날짜 형식 통일
   - 취소 주문 제외
   - 월별 집계 (→ 12건)
   ↓
3. Data Warehouse에 12건만 적재

ELT 방식:

1. MySQL에서 주문 데이터 추출 (100만 건)
   ↓
2. BigQuery에 100만 건 그대로 적재
   ↓
3. BigQuery에서 SQL로 변환
   CREATE TABLE monthly_sales AS
   SELECT 
     DATE_TRUNC(order_date, MONTH) as month,
     SUM(amount) as total_sales
   FROM raw_orders
   WHERE status != 'cancelled'
   GROUP BY month;

차이점: - ETL: 12건만 적재 → 스토리지 절약, 하지만 원시 데이터 없음 - ELT: 100만 건 적재 → 나중에 다른 기준으로 재집계 가능

2.1.3.5 변환 작업의 주요 내용

변환 작업은 ETL이든 ELT이든 데이터를 분석 가능한 형태로 만드는 과정이다.

1. 데이터 정제 (Data Cleansing) - 결측치 처리: NULL 값 제거 또는 대체 - 이상치 처리: 비정상 값 제거 또는 보정 - 중복 제거: 동일 레코드 삭제

2. 데이터 통합 (Data Integration) - 여러 소스 결합: JOIN 연산 - 스키마 매칭: 다른 구조의 데이터 통합

3. 데이터 표준화 (Data Standardization) - 형식 통일: 날짜, 전화번호, 주소 포맷 통일 - 단위 변환: USD → KRW, kg → g - 코드 표준화: 약어 → 전체 이름

4. 데이터 집계 (Data Aggregation) - 일별 → 월별 합계 - 거래 내역 → 고객별 총액

5. 특징 생성 (Feature Engineering) - 파생 변수 생성: 나이 → 연령대 - 비율 계산: 전환율, 증가율 - 범주화: 연속형 → 범주형### 데이터 파이프라인 (Data Pipeline)

  • 데이터가 소스에서 최종 목적지까지 이동하며 변환되는 자동화된 흐름
  • 주요 도구:
    • 워크플로우 오케스트레이션: Apache Airflow, Prefect, Dagster
    • 데이터 통합: Apache Kafka, Apache Spark
    • ETL 도구: dbt, Talend, Informatica

예시 파이프라인:

1. 일일 매출 데이터 추출 (MySQL)
   ↓
2. 데이터 정제 및 변환 (Python/Spark)
   ↓
3. Data Warehouse 적재 (BigQuery)
   ↓
4. 집계 테이블 생성 (dbt)
   ↓
5. 대시보드 업데이트 (Tableau)

2.1.4 데이터 품질 관리 (Data Quality)

품질 차원:
- 정확성 (Accuracy): 올바른 값 - 완전성 (Completeness): 결측치 최소화 - 일관성 (Consistency): 형식 통일 - 적시성 (Timeliness): 최신 데이터 유지 - 유효성 (Validity): 비즈니스 규칙 준수

2.2 데이터 엔지니어링의 중요성

“Garbage In, Garbage Out”
아무리 좋은 분석 도구와 모델이 있어도, 양질의 데이터가 없으면 무용지물이다. 데이터 엔지니어링은 데이터 분석의 기반 인프라를 제공한다.

실무 통계:
- 데이터 과학자는 시간의 60-80%를 데이터 수집 및 정제에 소비 - 잘 구축된 데이터 파이프라인은 분석 속도를 10배 이상 향상

2.3 주요 기술 스택

영역 도구/기술
프로그래밍 Python, SQL, Scala
빅데이터 Apache Spark, Hadoop
스트리밍 Apache Kafka, Apache Flink
오케스트레이션 Apache Airflow, Prefect
클라우드 AWS (S3, Glue), GCP (BigQuery), Azure
데이터베이스 PostgreSQL, MongoDB, Cassandra

3 데이터 시각화 (Data Visualization)

분석된 데이터를 차트, 그래프, 대시보드 등의 시각적 형태로 표현하여 사람들이 데이터를 쉽게 이해하고 인사이트를 얻을 수 있도록 돕는 기술이다.

3.1 핵심 원칙

3.1.1 명확성 (Clarity)

  • 메시지를 즉시 이해할 수 있어야 함
    • 불필요한 요소 제거
    • 직관적인 차트 유형 선택
    • 명확한 레이블과 제목

3.1.2 정확성 (Accuracy)

  • 데이터를 왜곡 없이 표현
  • 주의사항:
    • Y축 시작점 조작 금지
    • 적절한 스케일 사용
    • 3D 차트 지양 (왜곡 발생)

3.1.3 효율성 (Efficiency)

  • 최소한의 시각 요소로 최대 정보 전달

Edward Tufte의 Data-Ink Ratio:

Data-Ink Ratio = 데이터 표현 잉크 / 전체 사용 잉크

높을수록 효율적

3.1.4 미학 (Aesthetics)

  • 보기 좋은 디자인으로 몰입도 향상
    • 조화로운 색상 팔레트
    • 일관된 스타일
    • 적절한 공백 활용

3.2 시각화의 중요성

  • 의사소통 효율성: 복잡한 통계 결과나 머신러닝 모델의 특징도 시각화를 통해 비전문가에게 효과적으로 전달할 수 있다.
  • 의사결정 속도: 숫자 테이블보다 시각화가 3배 이상 빠른 인사이트 도출을 가능하게 한다.

4 비즈니스 인텔리전스 (Business Intelligence, BI)

  • 기업의 데이터를 수집하고 분석하여 과거와 현재의 비즈니스 현황에 대한 통찰력 있는 보고서와 대시보드를 제공하는 과정 및 기술이다.

4.1 BI vs Analytics

구분 BI Analytics
시간 관점 과거~현재 미래
핵심 질문 “무엇이 일어났나?” “무엇이 일어날 것인가?”
목적 성과 모니터링, 진단 예측, 최적화
기술 SQL, OLAP, 시각화 ML, 통계 모델링
사용자 경영진, 관리자 데이터 과학자, 분석가
산출물 대시보드, 정기 리포트 예측 모델, 시나리오 분석
  • 관계: BI와 Analytics는 상호 보완적이다. BI가 “무엇이 일어났는지” 파악하면, Analytics가 “왜 일어났고, 앞으로 무엇을 해야 하는지” 답한다.

4.2 BI 시스템 구성 요소

4.2.1 데이터 소스

  • 운영 데이터베이스 (OLTP)
  • 외부 데이터
  • 파일 시스템

4.2.2 ETL 프로세스

  • 데이터 추출 (Extract)
  • 데이터 변환 (Transform)
  • 데이터 적재 (Load)

4.2.3 데이터 웨어하우스 (Data Warehouse)

  • OLAP (Online Analytical Processing) 큐브
  • 스타 스키마 / 스노우플레이크 스키마
  • 차원 테이블 + 팩트 테이블

4.2.4 분석 및 보고 도구

  • 대시보드
  • 애드혹 쿼리
  • 정기 리포트

4.3 BI의 한계와 Analytics의 필요성

  • BI의 한계:
    • 과거 데이터 중심 (후행 지표)
    • “왜?”에 대한 답 제한적
    • 미래 예측 불가
      Analytics로 보완:
    • 예측 모델링
    • 원인 분석
    • 시나리오 시뮬레이션
    • 최적화 추천

5 실험 설계 (Experiment Design) 및 A/B 테스트

  • 어떤 변화(신제품, 마케팅 전략 등)가 실제 목표 지표에 긍정적인 영향을 미치는지 과학적으로 검증하기 위한 방법론이다.

5.1 A/B 테스트 기본 개념

5.1.1 구조

대조군 (Control Group) vs 실험군 (Treatment Group)
- 대조군: 기존 버전 (A)
- 실험군: 새로운 버전 (B)

무작위 할당 (Randomization)
- 사용자를 무작위로 두 그룹에 배정
- 편향 제거

5.1.2 프로세스

  1. 가설 수립: “새로운 버튼 색상이 클릭률을 높일 것이다”
  2. 실험 설계
    • 대조군: 파란색 버튼
    • 실험군: 빨간색 버튼
    • 샘플 크기 계산
    • 실험 기간 설정
  3. 실험 실행
    • 트래픽을 50:50으로 분할
    • 데이터 수집
  4. 통계적 검증
    • 유의성 검정 (t-test, chi-square)
    • p-value 확인 (보통 < 0.05)
  5. 의사결정
    • 유의미한 차이 → 실험군 채택
    • 차이 없음 → 대조군 유지

5.2 실험 설계 원칙

5.2.1 SMART 목표 설정

  • Specific: 구체적 (예: “클릭률 5% 향상”)
  • Measurable: 측정 가능
  • Achievable: 달성 가능
  • Relevant: 비즈니스 목표와 관련
  • Time-bound: 기한 명확

5.2.2 단일 변수 (Single Variable)

한 번에 하나의 변수만 테스트
- 잘못된 예: 버튼 색상 + 문구 동시 변경 → 무엇이 원인인지 불명확
- 올바른 예: 버튼 색상만 변경 → 명확한 원인 파악

5.2.3 충분한 샘플 크기

통계적 검정력 (Power) 확보
- 일반적으로 Power = 0.8 (80%)
- 샘플 크기 계산기 활용
- 너무 적으면 유의미한 차이 감지 불가

5.2.4 충분한 실험 기간

시간적 변동 고려
- 요일 효과 (주중 vs 주말)
- 계절성
- 일반적으로 최소 1-2주 권장

5.3 고급 실험 설계

5.3.1 A/B/n 테스트

3개 이상의 변형 비교
- A: 기존
- B: 변형 1
- C: 변형 2
- 다중 비교 문제 주의 (Bonferroni 보정)

5.3.2 다변량 테스트 (Multivariate Test)

여러 요소의 조합 테스트
- 예: 버튼 색상(2) × 문구(2) = 4가지 조합
- 복잡하지만 상호작용 효과 파악 가능

5.3.3 밴딧 알고리즘 (Multi-Armed Bandit)

탐색 vs 활용의 균형
- 초기: 모든 변형 탐색
- 점차: 성과 좋은 변형에 트래픽 집중
- A/B 테스트보다 빠른 최적화

5.4 주요 지표 (Metrics)

5.4.1 주 지표 (Primary Metric)

의사결정 기준:
- 클릭률 (CTR)
- 전환율 (Conversion Rate)
- 매출 (Revenue)

5.4.2 보조 지표 (Secondary Metrics)

부작용 모니터링:
- 이탈률
- 체류 시간
- 다른 페이지 전환율

5.4.3 Guardrail Metrics

최소 성능 보장:
- 페이지 로딩 속도
- 오류율
- 고객 만족도

5.5 실험의 중요성

데이터 분석 가설의 실전 검증:
데이터 분석을 통해 얻은 가설이나 모델의 예측이 실제 환경에서 유효한지 확인하는 필수 과정이다.

의사결정 리스크 감소:
직관이나 경험이 아닌 객관적 데이터로 의사결정하여 실패 비용을 최소화한다.

6 인과 추론 (Causal Inference)

  • 단순히 변수들 간의 상관관계(correlation)를 넘어, 한 변수가 다른 변수의 원인이라는 인과 관계(causation)를 밝히는 통계적/계량 경제학적 방법론이다.

6.1 상관관계 vs 인과관계

6.1.1 상관관계 (Correlation)

  • 두 변수가 함께 변하는 패턴
  • 예시:
    • 아이스크림 판매량 ↑ → 익사 사고 ↑
    • 하지만 아이스크림이 익사를 유발하지 않음
    • 공통 원인: 여름 날씨 (교란 변수)

6.1.2 인과관계 (Causation)

  • 한 변수의 변화가 다른 변수의 변화를 직접 야기
    • 조건 (Bradford Hill Criteria):
      1. 시간적 선행성: 원인이 결과보다 먼저
      2. 상관관계 존재
      3. 용량-반응 관계
      4. 그럴듯한 메커니즘
      5. 일관성
      6. 특이성

6.2 인과 추론의 핵심 개념

6.2.1 반사실 (Counterfactual)

  • “만약 처치를 받지 않았다면 어땠을까?”
  • 문제: 같은 개인이 동시에 두 상태에 있을 수 없음 (근본적 인과 추론의 문제)
  • 해결: 비슷한 대조군을 통해 반사실 추정

6.2.2 평균 처치 효과 (ATE: Average Treatment Effect)

  • 처치를 받은 경우와 받지 않은 경우의 평균 차이
ATE = E[Y(1) - Y(0)]

Y(1): 처치를 받았을 때 결과
Y(0): 처치를 받지 않았을 때 결과

6.2.3 교란 변수 (Confounder)

  • 처치와 결과 모두에 영향을 주는 제3의 변수

예시:

교육 수준 → 소득 (인과관계인가?)
         ↑
      IQ (교란 변수)

6.3 주요 인과 추론 방법

6.3.1 무작위 대조 실험 (RCT: Randomized Controlled Trial)

  • 무작위 할당으로 처치군과 대조군 구성
  • 장점:
    • 교란 변수 통제
    • 인과관계 입증의 골드 스탠다드
  • 단점:
    • 비용과 시간 소요
    • 윤리적 제약 (예: 의료 실험)
    • 실현 불가능한 경우 많음

6.3.2 성향 점수 매칭 (PSM: Propensity Score Matching)

방법:
1. 처치 받을 확률(성향 점수) 계산
2. 비슷한 성향 점수를 가진 처치군-대조군 매칭
3. 매칭된 쌍에서 ATE 계산

장점:
- 관찰 데이터에서 사용 가능
- 교란 변수 통제

단점:
- 관측되지 않은 교란 변수는 통제 불가
- 매칭의 질에 의존

예시: 마케팅 캠페인 효과 분석:
- 처치군: 캠페인 대상 고객
- 대조군: 비슷한 특성을 가진 비대상 고객 매칭

6.3.3 도구 변수 (IV: Instrumental Variable)

  • 처치와 상관있지만, 결과와는 오직 처치를 통해서만 영향을 주는 변수 활용

조건:
1. 관련성 (Relevance): 도구 변수가 처치와 상관
2. 외생성 (Exogeneity): 도구 변수가 교란 변수와 무관
3. 배제 제약 (Exclusion): 도구 변수가 결과에 직접 영향 없음

예시: 교육의 소득 효과
- 문제: 능력이 교란 변수
- 도구 변수: 의무교육 법령 (교육 연수에 영향, 소득에 직접 영향 없음)

6.3.4 이중 차분법 (DID: Difference-in-Differences)

  • 처치 전후의 변화를 처치군과 대조군에서 각각 계산하고, 그 차이를 비교
DID = (처치군_후 - 처치군_전) - (대조군_후 - 대조군_전)
  • 가정: 평행 추세 (Parallel Trends): 처치가 없었다면 두 그룹의 추세가 동일했을 것
  • 예시: 최저임금 인상의 고용 효과
    • 처치군: 최저임금 인상한 주
    • 대조군: 인상하지 않은 주
    • 전/후 고용 변화 비교

6.3.5 회귀 불연속 (RDD: Regression Discontinuity Design)

  • 특정 기준점(cutoff)을 경계로 처치 여부가 결정될 때, 경계 부근의 불연속을 활용
  • 예시: 장학금의 학업 성취도 효과
    • 기준: 시험 점수 80점
    • 처치: 80점 이상 → 장학금 지급
    • 79점 vs 81점 학생 비교 (거의 비슷하지만 장학금 여부만 다름)

장점:
- 강력한 인과 추론
- RCT에 가까운 설득력

단점:
- 기준점 부근에서만 적용 가능
- 외적 타당도 제한

6.3.6 합성 대조군 (Synthetic Control)

  • 여러 대조군을 가중 평균하여 처치군과 가장 유사한 “합성” 대조군 생성
  • 예시: 특정 국가의 정책 효과
    • 처치군: 정책 시행 국가
    • 합성 대조군: 여러 비시행 국가들의 가중 평균 (시행 전 추세가 유사하도록)

6.4 인과 추론의 중요성

  • 올바른 의사결정: “이 마케팅 캠페인 때문에 매출이 올랐다”와 같은 인과적 주장을 하려면, 단순한 상관관계 분석을 넘어 인과 추론 방법론이 필요하다.
  • 정책 평가: 정부 정책, 기업 전략의 실제 효과를 과학적으로 평가하여 자원 낭비를 방지한다.

머신러닝과의 차이:
- 머신러닝: 예측 (Prediction) - “무엇이 일어날 것인가?”
- 인과 추론: 인과 (Causation) - “왜 일어났는가? 개입하면 무슨 일이 생기는가?”

6.5 인과 추론 주요 도구

Python:
- DoWhy: Microsoft의 인과 추론 라이브러리
- CausalML: Uber의 인과 머신러닝
- EconML: Microsoft의 이질적 처치 효과

R:
- MatchIt: 성향 점수 매칭
- AER: 도구 변수
- Synth: 합성 대조군

7 데이터 분석 생태계 통합 관점

7.1 역할 분담

요소 역할 핵심 질문
데이터 엔지니어링 인프라 구축 “데이터를 어떻게 준비할까?”
통계/ML/DL/AI 분석 및 모델링 “무슨 패턴이 있고, 무엇을 예측할 수 있나?”
시각화/BI 의사소통 “어떻게 전달할까?”
실험 설계 검증 “정말 효과가 있나?”
인과 추론 인과 관계 “왜 그런 일이 일어났나?”

7.2 실무 프로젝트 흐름

  1. 비즈니스 문제 정의
  2. 데이터 엔지니어링
    • 데이터 수집 및 파이프라인 구축
  3. 탐색적 데이터 분석 (EDA)
    • 통계적 분석
    • 시각화
  4. 모델링
    • 머신러닝/딥러닝 모델 구축
  5. 모델 평가 및 해석
    • 통계적 검정
    • 특징 중요도 분석
  6. 대시보드 및 리포트 (BI)
    • 결과 시각화
    • 정기 모니터링
  7. A/B 테스트
    • 실제 환경 검증
  8. 인과 추론 (필요 시)
    • 정책 효과 평가
    • 전략 ROI 계산
  9. 의사결정 및 실행
  10. 지속적 모니터링 및 개선

7.3 참고 자료

  1. Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit (3rd ed.)
  2. Kleppmann, M. (2017). Designing Data-Intensive Applications
  3. Tufte, E. R. (2001). The Visual Display of Quantitative Information (2nd ed.)
  4. Kohavi, R., Tang, D., & Xu, Y. (2020). Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing
  5. Pearl, J., & Mackenzie, D. (2018). The Book of Why: The New Science of Cause and Effect
  6. Angrist, J. D., & Pischke, J.-S. (2009). Mostly Harmless Econometrics

Subscribe

Enjoy this blog? Get notified of new posts by email: