[2부 분산 데이터]
12장: 데이터 시스템의 미래
1. 데이터 통합
1.1 파생 데이터에 특화된 도구의 결합
1.2 일괄 처리와 스트림 처리
2. 데이터베이스 언번들링
2.1 데이터 저장소 기술 구성하기
2.2 데이터플로 주변 애플리케이션 설계
2.3 파생 상태 관찰하기
3. 정확성을 목표로
3.1 데이터베이스에 관한 종단 간 논증
3.2 제약 조건 강제하기
3.3 적시성과 무결성
3.4 믿어라. 하지만 확인하라.
4. 옳은 일 하기
4.1 예측 분석
4.2 사생활과 추적
12장 데이터 시스템의 미래
1. 데이터 통합
- 가장 적절한 소프트웨어 도구를 선택하는 것은 상황에 따라 다름
=> 선택의 폭이 넓을 경우 첫번째 단계는 소프트웨어 제품과 그 제품이 잘 어울리는 환경 사이의 대응 관계를 파악하는 것
1.1 파생 데이터에 특화된 도구의 결합
- 데이터베이스와 검색색인 외에도 분석 시스템(데이터웨어하우스나 일괄처리 또는 스트림 처리 시스템)에 해당 데이터의 사본을 유지할 필요가 있음
=> 캐시나 원본 데이터에서 파생된 객체의 비정규화 버전을 유지하거나 머신러닝, 분류, 랭킹, 추천시스템으로 데이터를 전달하며 데이터 변화를 기반으로 한 알림을 보내기도 함
=> 데이터 통합의 필요성은 나무가 아닌 숲을 보기 위해 줌아웃 해서 조직 전체 데이터플로를 고려할때야 비로소 명확해짐
- 데이터플로에 대한 추론
=> 다른 데이터 접근 양식을 만족하기 위해 같은 데이터의 사본을 여러 저장소 시스템에 유지해야 할 때 입력과 출력을 분명히 할 필요가 있음
=> 파생 데이터 시스템은 이벤트 로그를 기반으로 갱신하면 결정적이고 멱등성을 지녀 결함에서 복구하기가 쉬워짐
- 파생 데이터 대 분산 트랜잭션
=> 서로 다른 데이터 시스템 간 일관성을 유지하는 고전적인 방법은 분산 트랜잭션
=> 분산 트랜잭션은 상호 배타적인 잠금을 사용해 쓰기 순서를 결정하는 반면, CDC와 이벤트 소싱은 순서를 결정하는데 로그를 사용
=> 분산 트랜잭션은 원자적 커밋을 사용해 변경 효과가 정확히 한 번 나타나도록 보장하는 반면, 로그 기반 시스템은 결정적 재시도와 멱등성을 기반으로 함
=> 트랜잭션 시스템은 일반적으로 선형성을 지원하는 반면, 파생 데이터 시스템은 비동기로 갱신되기 때문에 동시간 갱신 보장을 하지 않음
=> 훌륭한 분산 트랜잭션 프로토콜이 널리 지원되지 않는 상태에서 로그 기반 파생데이터가 이종 데이터 시스템을 통합하는 가장 장래성 있는 접근법
- 전체 순서화의 제약
=> 이벤트 로그의 순서 전체를 보장하는 것은 규모가 커지고 복잡해질수록 한계가 생김
=> 이벤트의 전체 순서를 결정하는 것을 공식적인 용어로 '전체 순서 브로드캐스트'라고 함
=> 대부분의 합의 알고리즘은 단일 노드가 전체 이벤트 스트림을 처리하기에 충분한 처리량을 가진 상황을 가정하고 설계
=> 이 알고리즘들은 이벤트 순서를 정하는 작업을 여러 노드에서 공유하는 메커니즘은 제공하지 않음
- 인과성 획득을 위한 이벤트 순서화
=> 이벤트 간 인과성이 없는 경우 전체 순서가 정해지지 않아도 동시에 발생한 이벤트는 임의로 순서를 정할 수 있어 문제 없음
1.2 일괄 처리와 스트림 처리
- 데이터 통합의 목표는 데이터를 올바른 장소에 올바른 형태로 두는 것
=> 이를 위해서는 입력을 소비해 형태를 바꾸고 필터링하고 집계해 모델을 학습하고 평가한 뒤 마지막에는 적절한 출력으로 기록해야 함
=> 일괄처리자와 스트림처리자는 이를 위한 도구임
- 파생 상태 유지
=> 일괄처리는 결정적이고 출력이 입력에만 의존하며 명시적 출력 외에는 다른 부수효과가 없는 순수 함수를 장려하며 입력을 불변으로 간주하고 출력은 추가전용으로만 사용
=> 스트림처리도 유사하지만 연산자를 확장해 상태를 관리할 수 있고 내결함성을 지니게 함
=> 입력과 출력을 잘 정의한 결정적 함수의 원리는 내결함성에 도움이 될 뿐 아니라 조직 내의 데이터플로 추론을 단순화 함
=> 데이터 파이프라인은 함수형 애플리케이션 코드를 통해 한 시스템의 상태 변화를 밀어넣고 그 결과를 파생시스템에 적용함
=> 이론적으로는 데이터 시스템이 파생 데이터 시스템은 동기식으로 운영할 수 있지만 비동기 방식을 통해 이벤트 로그 기반 시스템을 훨씬 견고하게 함
* 비동기 방식은 시스템 일부의 결함이 국소적으로 남아있게 해줌. 반면 분산 트랜잭션은 참여 장비 일부가 실패하면 어보트하기 때문에 나머지 시스템으로 실패가 확산되어 실패가 증폭되는 경향이 있음
=> 보조색인은 종종 파티션 경계를 넘나듦
=> 색인을 비동기 방식으로 유지한다면 파티션 간 통신에서 더욱 신뢰성있고 확장성이 좋아짐
- 애플리케이션 발전을 위한 데이터 재처리
=> 파생 데이터를 유지할 때 일괄처리와 스트림 처리는 모두 유용함
=> 스트림처리를 이용하면 입력의 변화를 빠르게 파생뷰에 반영할 수 있음
=> 일괄처리 시스템을 사용하면 누적된 상당한 양의 과거 데이터를 재처리해 기존 데이터셋을 반영한 새 파생뷰를 만들 수 있음
=> 재처리 없이 스키마를 변경하는 작업은 레코드에 새 선택적 필드를 추가하거나 새로운 타입의 레코드를 추가하는 것과 같은 간단한 것으로 제한됨
=> 파생 뷰를 사용하면 점진적 발전이 가능한데 점진적 이전의 장점은 처리의 모든 단계에서 뭔가 잘못됐을 때 쉽게 이전으로 되돌릴 수 있다는 점
- 람다 아키텍처
=> 일괄 처리를 과거 데이터를 재처리하는 데 사용하고 스트림 처리를 최근 갱신 데이터를 처리하는 데 사용한다고 할 때 두 방식을 조합해 사용하는 방법으로 제안됨
=> 핵심 아이디어는 입력 데이터를 불변 이벤트로서 증가하기만 하는 데이터셋에 추가하는 방식으로 기록해야 한다는 것
=> 하둡 맵리듀스 같은 일괄 처리 시스템과 스톰 같은 분리된 스트림 처리 시스템을 함께 운용
=> 람다 아키텍처 접근법에서 스트림 처리자는 이벤트를 소비해 근사 갱신을 뷰에 빠르게 반영한 후 일괄 처리자가 같은 이벤트 집합을 소비해 정확한 버전의 파생뷰에 반영
=> 람다 아키텍처는 데이터 시스템 설계를 향상시키는 데 영향을 준 아이디어이지만 몇 가지 문제점이 있음
1) 일괄처리와 스트림처리 양쪽 프레임워크에서 같은 로직을 유지해야 하는 데는 상당한 노력이 필요함
2) 스트림 파이프 라인과 일괄처리 파이프라인은 분리된 출력을 생산하기 때문에 사용자 요청에 대응하기 위해 출력을 병합해야 함
3) 전체 과거 데이터를 재처리할 수 있지만 대용량 데이터셋에서는 비용이 만만치 않기 때문에 증분으로 일괄처리하도록 설정하기도 함
* 낙오자 처리 문제나 일괄처리 사이 겹치는 경계에서 윈도우 다루기 같은 문제가 발생
- 일괄 처리와 스트림 처리의 통합
=> 같은 시스템에서 일괄처리 연산과 스트림 연산을 모두 구현해 람다 아키텍처의 장점만 살릴 수 있도록 함
=> 같은 시스템 내에서 일괄 처리와 스트림 처리를 통합하려면 아래 기능들이 필요
1) 최근 이벤트 스트림을 다루는 처리엔진에서 과거 이벤트를 재생하는 능력
2) 스트림 처리자에서 사용되는 정확히 한 번 시맨틱(결함이 발생하더라도 결함이 없었던 상황과 동일한 출력을 내는 것을 보장)
3) 처리시간 기준이 아니라 이벤트 시간 기준으로 윈도우를 처리하는 도구
2. 데이터베이스 언번들링
- 유닉스와 관계형 데이터베이스는 정보관리 문제를 다른 철학으로 접근
=> 유닉스는 논리적이지만 꽤 저수준인 하드웨어 추상화를 프로그래머에게 제공하는 것을 목적
*파이프와 바이트의 순차열일뿐인 파일이 개발됨
=> 관계형 데이터베이스는 디스크상의 자료구조, 동시성, 장애복구 등의 복잡성을 감추는 고수준 추상화를 제공
* SQL과 트랜잭션이 개발됨
2.1 데이터 저장소 기술 구성하기
- 데이터베이스가 제공하는 다양한 기능과 동작 방식
=> 보조색인은 필드값을 기반으로 레코드를 효율적으로 검색할 수 있는 기능
=> 구체화 뷰는 질의결과를 미리 연산한 캐시의 일종
=> 복제로그는 데이터의 복사본을 다른 노드에 최신상태로 유지하는 기능
=> 전문검색색인은 텍스트에서 키워드 검색을 가능하게 하는 기능으로 일부 관계형 데이터베이스에서 내장하고 있음
- 색인 생성하기
=> 데이터베이스는 테이블의 일관된 스냅숏을 사용해 스캔하고 색인할 필드값을 모두 골라 정렬하고 색인에 기록
=> 이후 일관된 스냅숏을 만든 이후에 실행된 쓰기의 백로그를 처리
=> 색인 생성을 완료하면 데이터베이스는 트랜잭션이 테이블에 쓸 때마다 꾸준히 색인에 반영
=> 모든 접근 패턴에 적합한 단일 데이터모델이나 저장형식이 없다고 한다면?
1) 연합 데이터베이스: 읽기를 통합
2) 언번들링 데이터베이스: 쓰기를 통합
- 언번들링이 동작하게 만들기
=> 데이터가 다른 기술 사이의 경계를 오간다면 멱등성을 기반으로 쓰기를 수행하는 비동기 이벤트 로그를 사용하는 편이 훨씬 더 강력하고 현실적인 접근법
=> 로그기반 통합의 큰 장점은 다양한 구성요소 간 느슨한결합(loose coupling)이고, 2가지 수준에서 이 장점이 드러남
1) 시스템 수준에서 비동기 이벤트 스트림을 사용하면 전체 시스템이 개별 구성요소의 장애나 성능저하가 생겨도 잘 견디게 만들 수 있음
2) 인적 수준에서 데이터 시스템을 번들링하면 소프트웨어 구성요소와 서비스를 다른 팀에서 각자 개발하고 개선하고 독립적으로 유지보수할 수 있음
- 언번들링 대 통합시스템
=> 언번들링이 실제로 미래에 사용될 방법이라고 하더라도 현재 형태의 데이터베이스를 대체하지는 못할 것임
=> 언번들링의 목표는 특정 작업부하에 대한 성능 측면에서 개별 데이터베이스와 경쟁하는 것이 아님
=> 몇 개의 다른 데이터베이스를 결합해 단일 소프트웨어로 가능한 것보다 더 넓은 범위의 작업부하에 대해 좋은 성능을 달성하기 위함임
2.2 데이터플로 주변 애플리케이션 설계
- 데이터베이스 인사이드 아웃 접근법
=> 애플리케이션 코드로 특화된 저장소와 처리시스템을 조립하는 언번들링 데이터베이스 접근법
- 파생함수로서의 애플리케이션 코드
=> 파생 데이터셋을 생성하는 함수가 보조색인 생성함수와 같은 비슷비슷한 표준함수가 아니라면 사용자 정의 코드를 써서 애플리케이션에 특화된 측면을 다뤄야 함
=> 관계형 데이터베이스는 일반적으로 데이터베이스 내에서 애플리케이션 코드를 실행할 수 있게 해주는 트리거, 스토어드 프로시저, 사용자 정의함수를 지원
- 애플리케이션 코드와 상태의 분리
=> 대부분의 프로그래밍 언어에서 변경가능한 변수의 변경을 구독할 수 없음
=> 단지 주기적으로 읽어 볼 수 밖에 없음
=> 관찰자패턴(observerp attern)이라는 알림기능을 직접 구현할 수 있지만 대부분의 언어는 이 패턴을 내장기능으로 지원하지 않음
=> 데이터베이스는 변경가능한 데이터에 대한 수동적 접근법을 상속함
=> 데이터베이스의 내용이 변경됐는지 확인하려면 폴링, 즉 주기적으로 질의를 반복하는 게 유일한 방법
- 데이터플로: 상태변경과 애플리케이션 코드 간 상호작용
=> 데이터플로 측면에서 애플리케이션을 생각한다는 것은 애플리케이션 코드와 상태관리 간의 관계를 재조정한다는 의미
=> 안정적인 메시지 순서화와 내결함성이 있는 메시지 처리는 상당히 엄격한 요구사항이지만 분산 트랜잭션보다 훨씬 저렴하면서 탄탄한 운영을 가능하게 함
=> 파이프로 연결한 유닉스 도구와 같이 스트림처리자를 구성해서 데이터플로를 중심으로 대형시스템을 구축할 수 있음
=> 각 연산자는 상태변경 스트림을 입력으로 받아 다른 상태변경 스트림을 출력으로 생산
- 스트림 처리자와 서비스
=> 변경 스트림 구독은 필요할 때 현재 상태를 조회하는 것보다 스프레드시트의 연산 모델에 더 가까움
=> 일부 데이터 변경이 있을 때 해당 데이터에 의존하는 파생데이터가 신속히 갱신됨
2.3 파생 상태 관찰하기
- 파생상태
=> 데이터플로 시스템은 검색색인이나 구체화 뷰 또는 예측모델과 같은 파생데이터셋을 생성하고 최신상태로 유지하는 과정에 사용할 수 있음 (쓰기 경로, write path)
=> 시스템에 정보를 기록할 때마다 일괄처리와 스트림처리의 여러 단계를 거친 다음 결과적으로 기록된 데이터를 모든 파생 데이터셋에 통합해 갱신
=> 파생 데이터셋을 생성하는 이유는 이후에 다시 질의할 가능성이 크기 때문임 (읽기 경로, read path)
=> 사용자 요청을 처리할 때 먼저 파생 데이터셋을 읽고 그 결과를 어느정도 가공한 후 사용자 응답을 만듦
- 구체화 뷰와 캐싱
=> 읽기 경로와 쓰기 경로 사이에 가능한 경계에는 색인만 있는 건 아님
=> 자주하는 검색 결과를 캐시하는 것도 가능
=> 적은 문서에서는 색인 없이 grep과 비슷하게 스캔하는 것도 가능함
=> 이런 관점에서 보면 캐시와 색인 그리고 구체화뷰는 읽기경로와 쓰기경로 사이의 경계를 옮기는 단순한 역할을 함
=> 이런 파생 데이터셋을 사용하면 쓰기경로에서 더 많을 일을 수행해 미리 결과를 계산할 수 있기 때문에 읽기 경로의 작업이 줄어듦
- 오프라인 대응 가능한 상태저장 클라이언트
=> 오프라인 우선 애플리케이션은 인터넷 연결 요구없이 같은 장치의 로컬 테이터베이스를 이용해 가능한 많은 일을 하고 네트워크 연결이 가능할 때 백그라운드에서 원격 서버와 동기화
=> 장치상 상태를 서버상 상태의 캐시로 생각할 수 있음
=> 클라이언트 앱의 모델객체는 원격데이터센터의 상태를 로컬에 복제한 것이고 화면의 화소는 클라이언트 앱의 모델객체를 보여주는 구체화 뷰
- 상태 변경을 클라이언트에게 푸시하기
=> 장치가 얼마동안 오프라인이라서 그 시간동안 서버에서 상태변경 알림을 받지 못하는 경우 로그기반 메시지 브로커를 사용하는 소비자가 접속이 실패하거나 끊긴 이후 어떻게 재접속하고 접속이 끊겼을 동안 도착한 메시지를 빠짐없이 받을 수 있음
=> 개별 사용자에 대해서도 동일한 기법이 작동함 (각 장치는 작은 이벤트 스트림을 구독하는 작은 구독자임)
- 종단 간 이벤트 스트림
=> 상태변경이 트리거된 한 장치의 상호작용으로부터 이벤트로그를 거쳐 여러 파생 데이터 시스템과 스트림 처리자를 통해 다른 장 치의 상태를 보고 있는 사람의 사용자 인터페이스까지 이어짐
=> 이런 상태변경이 전파되는 지연시간은 상당히 낮은데 종단 간에는 대개 1초 이하로 끝남
=> 모든 애플리케이션이 이런 방식으로 구축하지 않는 이유는 상태 비저장 클라이언트와 요청/응답방식의 상호작용이 데이터베이스, 라이브러리, 프레임 워크, 프로토콜에 뿌리 깊게 배어있기 때문
=> 많은 데이터스토어가 요청 하나에 응답 하나를 하는 읽기 쓰기 연산을 지원하지만 변경사항 구독 기능을 지원하는 데이터스토어는 드묾
- 읽기도 이벤트다
=> 지속성 있는 저장소에 읽기 이벤트를 기록하면 인과적 의존성을 추적하기가 더 용이
=> 하지만 이 방법은 추가적인 저장소가 필요하고 I/0 비용이 더 발생
- 다중 파티션 데이터 처리
=> 단일 파티션에만 접근하는 질의를 처리하기 위해 스트림을 통해 질의를 보내고 응답 스트림을 수집하는 노력은 과잉작업일 수 있음
=> 그러나 스트림 처리자가 이미 제공하는 메시지 라우팅과 파티셔닝, 그리고 조인용 인프라를 이용하면 이 개념이 여러 파티션의 데이터 통합이 필요한 복잡한 질의를 분산실행할 수 있는가능성을 열어줌
3. 정확성을 목표로
3.1 데이터베이스에 관한 종단 간 논증
- 데이터베이 스에 관한 종단 간 논증
=> 단지 애플리케이션이 직렬성 트랜잭션 같은 비교적 강력한 안전성 속성을 지원하는 데이터시스템을 사용한다고 해서 애플리케이션에 데이터 유실과 손상이 없을 것이라는 보장은 없음
- 연산자의 정확히 한번 실행
=> 연산이 멱등이라는 것은 연산 횟수 상관없이 같은 효과가 나타남을 보장함
=> 그러나 본질적으로 멱등이 아닌 연산을 먹등으로 만드는 데는 노력과 신중함이 필요
=> 값을 갱신한 연산의 ID 집합 같은 메타데이터를 추가로 유지해야 할 수도 있고 한 노드에서 다른 노드로 장애복구될 때 펜싱을 보장할 필요도 있음
- 연산 식별자
=> 여러 네트워크 통신 홉을 통과하는 연산을 멱등적으로 만들기 위해 데이터베이스가 제공하는 트랜잭션 메커니즘에 의존하는 것은 충분하지 않고 해당요청의 종단 간 흐름을 생각할 필요가 있음
- 종단 간 논증
=> 문제기능은 통신시스템의 종단점에 위치한 애플리케이션의 지식과 도움이 있어야만 완벽하고 정확하게 구현 가능
=> 따라서 문제기능을 통신시스템 자체 기능으로 제공하는 것은 불가능
=> 때로는 통신 시스템에서 제공하는 불완전한 버전의 기능은 성능 향상 차원에서 유용할 수 있음
- 종단 간 사고를 데이터 시스템에 적용하기
=> 동시성과 부분실패에 관한 추론은 어렵고 직관적이지 않기 때문에 결과적으로 데이터를 잃거나 데이터가 손상될 수 있음
=> 이런 이유로 내결함성 추상화를 적용하는 것이 필요
3.2 제약 조건 강제하기
- 유일성 제약조건은 합의가 필요하다
=> 유일성검사는 유일성이 필요한 값을 기준으로 파티셔닝하면 확장 가능함
=> 그러나 비동기 다중 마스터 복제는 쓸 수 없음. 다른 마스터에서 동시에, 충돌되는 쓰기를 받아들여서 값이 더이상 유일하지 않을 수 있기 때문임
=> 제약조건을 위반하면 어떤 쓰기도 즉시 거부하기를 원한다면 동기식 코디네이션을 피할 수 없음
- 로그기반 메시징의 유일성
=> 로그는 모든 소비자가 동일한 순서로 메시지를 보도록 보장함 (전체 순서 브로드캐스트)
=> 스트림 처리자는 단일 스레드 상에서 한 로그 파티션의 모든 메시지를 순차적으로 소비함
=> 따라서 유일성이 필요한 값을 기준으로 로그를 파티셔닝하면 스트림 처리자는 충돌이 발생한 연산 중 어떤 것이 처음 들어 온 연산인지 분명하면서도 결정적으로 판결할 수 있음
- 다중 파티션 요청 처리
=> 다중 파티션 트랜잭션을 서로 다르게 파티셔닝된 2단계로 나누고 종단 간 요청ID를 사용하면 결함 존재여부와 상관없이 원자적 커밋 프로토콜을 쓰지 않고도 동일한 정확성 속성을 달성할 수 있음
3.3 적시성과 무결성
- 적시성과 무결성
=> 적시성(Timeliness): 적시성은 사용자가 시스템을 항상 최신상태로 관측 가능하다는 의미
=> 무결성(Integrity): 무결성은 손상이 없다는 의미(누락된 데이터도 없고 모순된 데이터도 잘못된 데이터도 없다는 의미)
- 데이터플로 시스템의 정확성
=> 무결성은 메커니즘의 결합을 통해 달성할 수 있음
1) 쓰기연산 내용을 단일 메시지로표현하기
2) 결정적 파생함수를 사용해 해당 단일 메시지에서 모든 상태 갱신을 파생하기
3) 클라이언트가 생성한 요청ID를 모든 처리단계를 통해 전달하기
3) 메시지를 불변으로 만들고 필요 시 파생데이터 재처리하기
- 느슨하게 해석되는 제약조건
=> 유일성 제약조건을 강제하려면 합의가 필요
=> 합의는 일반적으로 모든 이벤트를 단일노드를 통해 특정 파티션으로 보내 처리하는 방식으로 구현
=> 유일성 제약조건의 전통적인 형태가 필요하다면 이 제한은 피할 수 없음
=> 스트림처리도 마찬가지로 피할 수 없는 제한사항임
=> 그러나 실제로 많은 애플리케이션이 훨씬 완화된 유일성 개념을 사용해 이 제한을 피할 수 있음
- 코디네이션 회피 데이터 시스템
=>데이터플로 시스템은 코디네이션 없이도 많은 애플리케이션용 데이터 관리 서비스를 제공할 수 있을 뿐 아니라 여전히 무결성을 강력하게 보장한다는 점임 (코디네이션 회피)
=> 동기식 코디네이션이 필요한 시스템보다 성능이 더 좋고 더 나은 내결함성을 지님
=> 직렬성 트랜잭션은 파생상태를 유지하는 데 부분적으로만 유용함
4. 옳은 일 하기
4.1 예측 분석
- 편견과 차별
=> 예측분석 시스템은 오직 과거로부터 추정함
=> 과거가 차별적이라면 예측분석 시스템은 차별을 성문화함
- 책임과 의무
=> 의사결정에 데이터를 최우선으로 하는 맹목적 믿음은 망상일뿐 아니라 절대적으로 위험
=> 데이터 주도 의사결정이 보편화될수록 알고리즘을 설명 가능하고 투명하게 만드는 방법을 찾아야 함
=> 존재하는 편견이 강화되는 것을 막는 방법과 반드시 발생하는 실수를 수정하는 방법도 찾아야 함
=> 데이터가 사람들을 해치지 않게 하고 대신 긍정적 잠재력을 실현하는 방법을 찾아야 함
- 피드백 루프
=> 예측 분석이 자기 강화 피드백 루프 때문에 치명적인 문제가 발생할 수 있음
=> 피드백 루프는 전체시스템을 생각하면 많은 결과를 예측할 수 있음 (이러한 접근법을 시스템 사고라고 함)
4.2 사생활과 추적
- 동의와 선택의 자유
=> 사용자가 데이터 제공을 자발적으로 동의했다고 주장할 수 있지만 사용자는 사용자가 제공하는 데이터가 무엇이고 어떻게 유지하며 처리하는지에 대한 지식이 거의 없기 때문에 문제가 될 수 있음
- 자산과 권력으로서의 데이터
=> 행동데이터는 사용자가 서비스와 상호작용하면서 나오는 부산물이기 때문에 '데이터 배출'이라고 하기도 하지만 서비스의 핵심자산이 됨
=> 기업이 축적한 데이터와 지식은 공공의 감시를 벗어나 기업에게 암암리에 시민의 삶 전반에 걸쳐 많은 권력을 부여함
- 법률과 자기 규제
=> 데이터 보호법으로 개인의 권리를 보호할 수 있지만 이 법률이 오늘날 인터넷 맥락에 효과적인지는 의심
=> 각 개인은 스스로 자신의 사생활을 보호할 수 있어야 함. 스스로 사생활 데이터의 통제권을 가져야 하고 감시를 통해 통제권을 훔쳐서는 안됨