1. 데이터 통합
•
책에서는 어떤 문제에 대한 해결책을 놓고 장점과 단점, 트레이드 오프에 대해 설명했습니다.
•
가장 적절한 소프트웨어 도구를 선택하는 것은 상황에 다릅니다.
◦
선택의 폭이 넓을 경우, 소프트웨어 제품과 그 제품이 잘 어울리는 환경 사이의 대응관계를 파악하는 것입니다.
◦
대응관계를 이해해도, 데이터를 사용하는 모든 다른 상황에 적합한 소프트웨어가 있을 확률은 낮습니다. 즉, 여러 다른 소프트웨어를 함께 엮어 사용해야 합니다.
1.1. 파생 데이터와 특화된 도구의 결합
•
예를 들어, OLTP 데이터베이스와 임의의 키워드를 대상으로 질의하는 전문 검색 색인을 통합하는 요구는 일반적입니다.
◦
PostgreSQL와 같은 데이터베이스는 간단한 애플리케이션을 만들기는 충분하지만 복잡한 검색 기능을 지원하기 위해서는 전문적인 탐색도구가 필요합니다.
◦
역으로 검색 색인은 일반적으로 지속성 있는 레코드 시스템으로는 적합하지 않으므로 많은 애플리케이션은 요구사항을 만족하기 위해 두 도구를 결합합니다.
•
데이터 통합의 필요성은 나무가 아닌 숲을 보기 위해 줌아웃해서 조직 전체 데이터플로를 고려할 때야 비로소 명확해집니다.
1.2. 일괄 처리와 스트림 처리
•
데이터 통합의 목표는 데이터를 올바른 장소에 올바른 형태로 두는 것이라 생각됩니다.
•
일괄 처리와 스트림 처리의 출력은 파생 데이터셋입니다.
•
일괄 처리와 스트림 처리는 여러 공통 원리가 있지만, 일괄 처리와 스트림 처리의 근본적인 주요 차이점은 스트림 처리는 끝이 없는 데이터셋 상에서 운영되는 반면 일괄 처리는 유한한 크기의 입력을 사용합니다.
•
스파크는 일괄 처리 엔진 상에서 스트림을 처리하는데 스트림을 마이크로 일괄 처리 단위로 나누어 일괄 처리합니다.
◦
반면 아파치 플링크는 스트림 처리 엔진 상에서 일괄 처리를 수행합니다.
◦
그러나 성능 특성은 다양하게 나타납니다.
2. 데이터베이스 언번들링
2.1. 데이터 저장소 기술 구성하기
위에서 데이터베이스가 제공하는 다양한 기능을 설명하고, 그 기능이 어떻게 동작하는지를 설명합니다.
•
보조 색인은 필드 값을 기반으로 레코드를 효율적으로 검색할 수 있는 기능입니다.
•
구체화 뷰는 질의 결과를 미리 연산한 캐시의 일종입니다.
•
복제 로그는 데이터의 복사본을 다른 노드에 최신 상태로 유진하는 기능입니다.
•
전문 검색 색인은 텍스트에서 키워드 검색을 가능하게 하는 기능으로 일부 관계형 데이터베이스는 이 기능을 내장합니다.
데이터베이스에 내장된 기능과 일괄 처리와 스트림 처리로 구축하는 파생 데이터 시스템 사이에는 유사점이 있스빈다.
2.2. 데이터플로 주변 애플리케이션 설계
•
애플리케이션 코드로 특화된 저장소와 처리 시스템을 조립하는 언번들링 데이터베이스 접근법은 "데이터베이스 인사이드 아웃"이라고 합니다.
•
현대 데이터 시스템은 내결함성과 확장성이 있어야 하고 지속성 있게 데이터를 저장해야 합니다.
◦
또한 데이터 시스템은 시간이 흐름에 따라 다른 그룹의 사람들이 개발한 이종 기술과도 통합이 가능해야 할 뿐 아니라 이미 존재하는 라이브러리와 서비스를 재사용 가능해야 합니다.
2.3. 파생 상태 관찰하기
•
추상적인수준에서 지난 절에서 설명한 데이터플로 시스템은 검색 색인이나 구체화 뷰 또는 예측 모델과 같은 파생 데이터셋을 생성하고 최산 상태로 유지하는 과정에 사용할 수 있으며, 이 과정을 쓰기 경로(write path) 라 부릅니다.
•
시스템에 정보를 기록할 때마다 일괄 처리와 스트림 처리의 여러 단계를 거친 다음 결과적으로 기록된 데이터를 모든 파생 데이터셋에 통합해 갱신합니다.
•
파생 데이터를 생성하는 이유는 질의할 가능성이 크며, 이를 읽기 경로(read path) 라고 합니다.
◦
사용자 요청을 처리할 때 먼저 파생 데이터셋을 읽고 그 결과를 어느 정도 가공한 후 사용자 응답을 만듭니다.
•
파생 데이터셋은 쓰기 경로와 읽기 경로가 만나는 장소입니다.
◦
파생 데이터셋은 쓰기 시간에 필요한 작업의 양과 읽기 시간에 필요한 작업의 양 간에 트레이드 오프를 나타냅니다.
3. 정확성을 목표로
•
모두가 신뢰성 있고 정확한 애플리케이션을 구축하기를 원합니다.
•
일관성은 종종 언급되지만 잘못 정의되기도 합니다.
•
동시성이 적고 결함이 없는 간단한 솔루션은 종종 정확하게 작동하는 것처럼 보일 때도 있지만 더 많은 요구 상황이 있는 환경에서는 미묘한 버그가 많습니다.
•
애플리케이션이 예측하지 못한 데이터의 깨짐이나 누락을 견딜 수 있다면 매우 단순해 질 수 있습니다.
◦
그러나 강력한 정확성 보장이 필요하다면 직렬성과 원자적 커밋이 확실한 방법이나 비용이 듭니다.
◦
확장성과 내결함성 속성을 제한합니다.
3.1. 데이터베이스에 관한 종단 간 논증
•
직렬성 트랜잭션 같은 비교적 강력한 안전성 속성을 지원하는 데이터 시스템을 사용해도 애플리케이션에 데이터 유실과 손상이 없을 것이라는 보장은 없습니다.
3.1.1. 연산자의 정확히 한 번 실행
•
내결함성에서 정확히 한 번(결과적으로 한 번) 시맨틱을 설명했으며 실패한다면 포기하거나 재시도하며, 재시도는 중복의 위험성이 있습니다.
•
정확히 한 번 연산은 동일한 결과를 최종적으로 얻기 위해 계산을 조정한다는 뜻입니다.
•
가장 효과적인 접근법 중 하나는 연산은 멱등으로 만드는 것입니다.
3.1.2. 중복 억제
•
스트림 처리 외에도 많은 곳에서 동일한 중복 제거 패턴이 발생합니다. (Ex. TCP)
•
그러나 이러한 부분도 TCP 연결 문맥 내에서만 작동하기 때문에 데이터베이스으 트랜잭션 커밋 성공 여부는 알 수 없습니다. 2단계 커밋 프로토콜을 구현해도 마찬가지 입니다.
•
데이터베이스 클라이언트와 서버 사이에서 중복 트랜잭션을 억제할 수 있더라도 최종 사용자 장치와 애플리케이션 서버 간 네트워크 상황도 고려할 필요가 있습니다.
4. 옳은 일 하기
4.1. 예측 분석
알고리즘에 의한 의사 결정이 점점 보편화되면서 사실이든 아니든 특정 알고리즘으로 위험성 있다고 딱지가 붙어진 사람은 많은 "아니오" 결정을 받습니다.
4.1.1. 편견과 차별
•
알고리즘이 내린 결정이 사람이 내린 결정보다 반드시 좋거나 나쁜 것은 아닙니다.
•
알고리즘에 투입된 입력에 시스템적 편견이 있다면 시스템은 그 편견을 학습하고 그 편견을 증폭해서 출력을 내보낼 가능성이 높습니다.
•
예측 분석 시스템은 오직 과거로부터 추정합니다.
•
데이터와 모델은 도구여야지 주인이 돼서는 안됩니다.
4.1.2. 책임과 의무
•
의사결정 자동화는 아직 책임과 의무에 대한 문제가 해결되지 않았습니다.
•
신용 점수는 과거의 행동을 요약하나, 예측 분석은 비슷한 사람이 과거에 어떤 행동을 했는지 기반을 두고 작동합니다.
•
의사결정에 데이터를 최우선으로 하는 맹목적인 믿음은 망상일 뿐이며 절대적으로 위험합니다.
•
데이터가 사람들을 해치지 않게 하고 그 대신 긍정적 잠재력을 실현하는 방법을 찾아야 합니다.
4.1.3. 피드백 루프
•
예측 분석이 사람들 삶에 영향을 미칠 때 특히 자기 강화 피드백 루프 때문에 치명적인 문제가 발생합니다.
•
피드백 루프가 언제 발생한지 항상 예측 가능한 것은 아니지만 전체 시스템을 생각하면 많은 결과를 예측할 수 있습니다.
◦
이 접근법은 시스템 사고라고 합니다.
