데이터 계통

Data lineage

데이터 계통에는 데이터 출처, 데이터 발생 상황, 데이터 이동 장소가 포함된다.[1] 데이터 계통은 가시성을 제공하는 동시에 데이터 분석 프로세스에서 오류를 근본 원인으로 추적하는 기능을 크게 단순화한다.[2]

또한 단계별 디버깅이나 손실된 출력을 재생하기 위해 데이터 흐름의 특정 부분 또는 입력을 재생할 수 있다. 데이터베이스 시스템은 유사한 검증 및 디버깅 과제를 해결하기 위해 데이터 검증이라고 불리는 그러한 정보를 사용한다.[3] 데이터 증명(data provenance)은 관심 있는 데이터에 영향을 미치는 입력, 실체, 시스템 및 프로세스의 기록을 말하며, 데이터와 그 출처에 대한 과거 기록을 제공한다. 생성된 증거는 데이터 의존성 분석, 오류/보상 탐지 및 복구, 감사, 컴플라이언스 분석과 같은 법의학적 활동을 지원한다. "리니지는 왜 증명되었는지를 보여주는 단순한 유형이다."[3]

데이터 계통은 기업 환경에서 다양한 변화와 홉을 통해 소스에서 목적지로의 데이터 흐름/이동, 그 과정에서 데이터가 어떻게 변환되는지, 표현과 매개변수가 어떻게 변화하는지, 그리고 각 홉 후에 데이터가 어떻게 분리 또는 수렴되는지를 발견하기 위해 시각적으로 표현될 수 있다. 데이터 리니지의 단순한 표현은 점과 선으로 나타낼 수 있으며, 여기서 점은 데이터 포인트의 데이터 컨테이너를 나타내고, 이를 연결하는 선은 데이터 컨테이너 사이에서 데이터 포인트가 겪는 변환을 나타낸다.

표현은 대체로 메타데이터 관리 범위와 관심 기준점에 따라 달라진다. 데이터 계통은 역행하는 데이터 계통을 가진 참조점으로부터 데이터 출처와 중간 데이터 흐름 홉을 제공하며, 최종 목적지의 데이터 지점과 전방 데이터 계통을 가진 중간 데이터 흐름으로 이어진다. 이러한 견해는 소스에서 최종 목적지까지 관심 있는 데이터 지점에 대한 완전한 감사 추적을 제공하는 기준점에 대해 엔드엔드 계통과 결합될 수 있다. 데이터가 가리키거나 홉이 증가함에 따라, 그러한 표현의 복잡성은 이해할 수 없게 된다. 따라서 데이터 계통 보기의 가장 좋은 기능은 원하지 않는 주변 데이터 지점을 일시적으로 마스킹하여 보기를 단순화할 수 있는 것이다. 마스킹 기능을 갖춘 툴은 뷰의 확장성을 지원하며, 기술 및 비즈니스 사용자 모두를 위한 최상의 사용자 경험으로 분석을 강화한다. 또한 데이터 계통을 통해 기업은 오류 추적, 프로세스 변경 구현, 시스템 마이그레이션 구현 등의 목적으로 특정 비즈니스 데이터의 소스를 추적하여 상당한 시간과 리소스를 절약함으로써 BI 효율성을 크게 향상시킬 수 있다.[4]

데이터 계통의 범위는 그 데이터 계통을 나타내기 위해 필요한 메타데이터의 볼륨을 결정한다. 일반적으로 데이터 거버넌스데이터 관리는 조직의 규정, 기업 데이터 관리 전략, 데이터 영향, 보고 속성, 중요 데이터 요소에 따라 데이터 계통의 범위를 결정한다.

데이터 계통에서는 최고 세분화된 수준에서 데이터 포인트의 감사 추적을 제공하지만, 계통의 표시는 분석 웹 맵과 유사하게 방대한 정보를 단순화하기 위해 다양한 줌 수준에서 이루어질 수 있다. 데이터 리니지는 뷰의 세분화에 따라 다양한 수준에서 시각화할 수 있다. 매우 높은 수준의 데이터 계통에서는 데이터가 대상에 도달하기 전에 어떤 시스템이 상호작용하는지 제공한다. 세분성이 증가함에 따라 데이터 포인트 레벨까지 올라가 데이터 포인트의 상세 내용과 데이터 계통의 특정 데이터 포인트를 통과하는 데이터의 과거 동작, 속성, 추세 및 데이터 품질을 제공할 수 있다.

데이터 거버넌스는 지침, 전략, 정책, 구현을 위한 메타데이터 관리에서 핵심적인 역할을 한다. 데이터 품질마스터 데이터 관리를 통해 데이터 계통을 더욱 비즈니스 가치로 강화 데이터 계통의 최종 표현이 하나의 인터페이스로 제공되더라도 메타데이터를 수집하고 데이터 계통 그래픽 사용자 인터페이스에 노출하는 방식은 완전히 다를 수 있다. 따라서 데이터 계통은 메타데이터의 수집 방식에 따라 크게 세 가지 범주로 나눌 수 있는데, 구조화된 데이터, 프로그래밍 언어, 빅데이터를 위한 소프트웨어 패키지를 포함하는 데이터 계통이다.

데이터 계통 정보에는 데이터 변환과 관련된 기술 메타데이터가 포함된다. 풍부한 데이터 계통 정보는 데이터 품질 시험 결과, 참조 데이터 값, 데이터 모델, 비즈니스 어휘, 데이터 스테어워드, 프로그램 관리 정보 및 데이터 포인트 및 변환에 연결된 기업 정보 시스템을 포함할 수 있다. 데이터 계통 시각화에서 마스킹 기능을 사용하면 도구는 특정 사용 사례에 중요한 모든 풍부함을 통합할 수 있다. 상이한 시스템을 하나의 공통 관점으로 나타내기 위해서는 "메타데이터 표준화" 또는 표준화가 필요할 수 있다.

이론적 근거

구글 맵 축소,[5] 마이크로소프트 드라이어드,[6] 아파치 하둡[7](오픈소스 프로젝트), 구글 프레겔과[8] 같은 분산형 시스템은 기업과 사용자를 위한 플랫폼을 제공한다. 그러나 이러한 시스템에서도 빅 데이터 분석은 단순히 관련 데이터 볼륨 때문에 몇 시간, 며칠 또는 몇 주가 걸릴 수 있다. 예를 들어 넷플릭스상 도전에 대한 등급 예측 알고리즘은 50개 코어에 대해 실행하는데 20시간 가까이 걸렸고, 지리정보를 추정하는 대규모 이미지 처리 작업은 400개 코어를 사용하여 완료하는 데 3일이 걸렸다.[9] 대형 시놉틱 조사 망원경은 매일 밤 테라바이트의 데이터를 생성해 결국 50페타바이트 이상 저장될 것으로 예상되며, 생물정보학 분야에서는 현재 세계 최대 규모의 게놈 12 염기서열 집단이 페타바이트 단위의 데이터를 저장한다.[10] 데이터 과학자가 미지의 결과나 예상치 못한 결과를 추적하는 것은 매우 어렵다.

빅데이터 디버깅

빅데이터 분석은 대용량 데이터 세트를 검토하여 숨겨진 패턴, 알 수 없는 상관관계, 시장 동향, 고객 선호도 및 기타 유용한 비즈니스 정보를 파악하는 과정이다. 그들은 데이터를 변환하는 데이터에 머신러닝 알고리즘 등을 적용한다. 방대한 데이터 크기 때문에 데이터에 알 수 없는 특징이 있을 수 있으며, 특이치가 있을 수도 있다. 데이터 과학자가 예상치 못한 결과를 실제로 디버깅하기는 꽤 어렵다.

데이터의 대규모 확장 및 비정형화 특성, 이러한 분석 파이프라인의 복잡성, 긴 런타임은 상당한 관리성 및 디버깅 문제를 야기한다. 이러한 분석에서 단 한 번의 오류도 식별하고 제거하기가 매우 어려울 수 있다. 단계별 디버깅을 위해 디버거를 통해 전체 분석을 다시 실행하여 디버깅할 수 있지만, 필요한 시간과 리소스의 양 때문에 비용이 많이 들 수 있다. 감사와 데이터 검증은 실험에 사용할 관련 데이터 소스에 대한 접근 용이성 증가, 과학 커뮤니티 간 데이터 공유 및 비즈니스 기업에서 제3자 데이터 사용으로 인한 또 다른 주요 문제점이다.[11][12][13][14] 이러한 시스템과 데이터가 계속 증가함에 따라 이러한 문제들은 더 커지고 더 심각해질 것이다. 이와 같이, 데이터 집약적인 확장 가능 컴퓨팅(DISC)을 분석하는 보다 비용 효율적인 방법은 이들의 지속적인 유효 사용에 매우 중요하다.

빅데이터 디버깅 관련 당면 과제

대규모

EMC/IDC 연구에 따르면:[15]

  • 2012년에 2.8ZB의 데이터가 생성 및 복제되었다.
  • 디지털 우주는 현재와 2020년 사이에 매 2년마다 두 배로 증가할 것이다.
  • 대략 5.2명 정도가 될 것이다.2020년에 모든 사람을 위한 TB의 데이터.

이러한 규모의 데이터로 작업하는 것은 매우 어려운 일이 되었다.

비정형 데이터

구조화되지 않은 데이터는 일반적으로 전통적인 행-열 데이터베이스에 존재하지 않는 정보를 가리킨다. 비정형 데이터 파일에는 텍스트와 멀티미디어 콘텐츠가 포함되는 경우가 많다. 예를 들어 이메일 메시지, 워드 프로세싱 문서, 비디오, 사진, 오디오 파일, 프리젠테이션, 웹 페이지 및 기타 많은 종류의 업무 문서를 들 수 있다. 이러한 종류의 파일은 내부 구조를 가질 수 있지만, 파일에 포함된 데이터가 데이터베이스에 깔끔하게 맞지 않기 때문에 여전히 "구조화되지 않은" 파일로 간주된다는 점에 유의하십시오. 전문가들은 어떤 조직에서든 80~90%의 데이터가 구조화되지 않은 것으로 추정하고 있다. 그리고 기업의 비정형 데이터 양은 정형화된 데이터베이스가 증가하는 것보다 훨씬 더 빠르게 증가하는 경우가 많다. "빅데이터에는 정형 데이터와 비정형 데이터가 모두 포함될 수 있지만 IDC는 빅데이터의 90%가 비정형 데이터인 것으로 추정하고 있다."[16]

비정형 데이터 소스의 근본적인 문제는 비기술적 비즈니스 사용자와 데이터 분석가 모두가 분석적 사용을 위한 복스를 풀고 이해하고 준비하기 어렵다는 것이다. 구조상의 문제를 넘어서는, 이러한 유형의 데이터의 순전히 부피다. 이 때문에, 현재의 데이터 마이닝 기술은 종종 귀중한 정보를 배제하고 비정형 데이터 분석을 힘들고 비싸게 만든다.[17]

롱 런타임

오늘날의 경쟁적인 비즈니스 환경에서 기업은 필요한 관련 데이터를 신속하게 찾아 분석해야 한다. 문제는 데이터 볼륨과 필요한 세부 정보 수준에 모두 고속으로 접근하는 것이다. 도전은 세분화 정도가 높아질수록 커진다. 한 가지 가능한 해결책은 하드웨어다. 일부 공급업체는 대량의 데이터를 신속하게 처리하기 위해 늘어난 메모리와 병렬 프로세싱을 사용하고 있다. 또 다른 방법은 데이터를 메모리에 넣는 것이지만 문제를 해결하기 위해 많은 기계를 사용하는 그리드 컴퓨팅 접근법을 사용하는 것이다. 두 가지 접근 방식을 통해 조직은 막대한 데이터 볼륨을 탐색할 수 있다. 이 정도 수준의 정교한 하드웨어와 소프트웨어라 하더라도 며칠에서 몇 주가 걸리는 대규모 이미지 처리 작업은 거의 없다.[18] 데이터 처리 디버깅은 실행 시간이 길기 때문에 매우 어렵다.

고급 데이터 검색 솔루션의 세 번째 접근 방식은 셀프 서비스 데이터 사전 준비와 시각적 데이터 검색을 결합하여 분석가가 새로운 회사인 트라이팩타, 알테릭스 등이 제공하는 대화형 분석 환경에서 동시에 데이터를 나란히 준비하고 시각화할 수 있게 한다.[19]

데이터 계통을 추적하는 또 다른 방법은 사용자들에게 세포 수준의 계통을 제공하는 엑셀과 같은 스프레드시트 프로그램이나 어떤 세포가 다른 세포에 의존하는지 볼 수 있는 능력이다. 그러나 변환의 구조는 사라진다. 마찬가지로 ETL이나 매핑 소프트웨어는 변환 수준의 계통을 제공하지만, 이 견해는 일반적으로 데이터를 표시하지 않으며 논리적으로 독립적이거나 종속적인 변환(예: 구별되는 열에서 작동하는 변환)을 구별하기에 너무 조잡하다.[20]

복합 플랫폼

빅데이터 플랫폼은 구조가 매우 복잡하다. 데이터는 여러 기계에 분산되어 있다. 일반적으로 작업은 여러 기계에 매핑되며, 결과는 나중에 작업 감소에 의해 결합된다. 빅 데이터 파이프라인의 디버깅은 시스템의 특성 때문에 매우 어려워진다. 데이터 과학자가 어떤 기계의 데이터에 특이치와 알 수 없는 특징이 있는지 파악하여 특정 알고리즘이 예상치 못한 결과를 내도록 하는 것은 쉬운 일이 아닐 것이다.

제안 솔루션

빅데이터 파이프라인의 디버깅을 더 쉽게 하기 위해 데이터 검증 또는 데이터 계통을 사용할 수 있다. 따라서 데이터 변환에 대한 데이터 수집이 필요하다. 아래 절에서는 데이터 입증에 대해 더 자세히 설명한다.

데이터 증명

데이터 입증은 데이터와 그 기원에 대한 과거 기록을 제공한다. 워크플로우와 같은 복잡한 변환에 의해 생성되는 데이터의 입증은 과학자들에게 상당한 가치가 있다.[21] 이를 통해 조상 데이터와 출처를 바탕으로 데이터의 품질을 확인할 수 있고, 오류의 출처를 추적할 수 있으며, 데이터를 업데이트하기 위해 파생의 자동 재현을 허용하며, 데이터 출처의 귀속성을 제공할 수 있다. 또한 데이터 웨어하우스의 데이터 출처를 드릴다운하고, 지적 재산의 생성을 추적하며, 규제 목적을 위한 감사 추적을 제공하는 데 사용할 수 있는 비즈니스 영역에도 입증은 필수적이다.

데이터 흐름을 통해 레코드를 추적하고 원본 입력의 하위 집합과 디버그 데이터 흐름에서 데이터 흐름을 재생하기 위해 분산 시스템에서 데이터 검증의 사용을 제안한다. 그러기 위해서는 각각의 출력물을 도출하는 데 사용된 각 연산자에 대한 입력 세트를 추적할 필요가 있다. 비록 카피 증명서, 어떻게 증명되었는가 등 여러 형태의 증명서가 있지만,[14][22] 우리에게 필요한 정보는 큐이 외 연구원이 정의한 왜 증명서,혈통의 단순한 형태다.[23]

리니지 캡처

직관적으로 출력 o를 생산하는 연산자 T의 경우 계통은 {I, T, o} 형식의 세 쌍으로 구성되며 여기서 나는 o를 도출하는 데 사용되는 T의 입력 집합이다. 각 이동 통신사 T에 대한 dataflow에 혈통 포착하면 사용 중 하나는 출력은 입력에 의해 생산된 것 c. 있고“어떤 입력 사업자 T생산은 0를?”[3],“어느 출력 사업자 T에 대한 입력 나는에 의해 제작되었습니다?”등을 집중 추궁한 출력이라고 불리는 헤드가 뒤를 추적 쿼리를 파생시키는 입력을 발견한 쿼리 요청할 수 있는알전방 추적 질의를 주도했다.[24] 역추적은 디버깅에 유용한 반면, 전진추적은 오류 전파를 추적하는데 유용하다.[24] 또한 추적 쿼리는 원본 데이터 흐름을 재생하기 위한 기초를 형성한다.[12][23][24] 그러나, DISC 시스템에서 계통을 효율적으로 이용하기 위해서는, 우리는 여러 레벨(또는 세분화)의 연산자와 데이터에서 계통을 포착하고, DISC 처리구조에 대한 정확한 계통을 포착할 수 있어야 하며, 여러 데이터 흐름 단계를 효율적으로 추적할 수 있어야 한다.

DISC 시스템은 여러 단계의 연산자와 데이터로 구성되며, 계통의 다른 사용 사례가 계통을 포착해야 하는 수준을 좌우할 수 있다. 리니지는 {IF i, M RJob, OF i} 형식의 리니지 튜플과 파일을 사용하여 작업 수준에서 캡처할 수 있으며, 리니지는 {(k rr, v rr), 맵(k m, v m )의 리니지 튜플과 기록을 사용하여 각 작업의 레벨에서도 캡처할 수 있다. 첫 번째 형태의 혈통을 거친 혈통이라고 하고, 두 번째 형태는 고운 혈통이라고 부른다. 서로 다른 세분류에 걸쳐 계통을 통합하면 사용자는 "MapReduce 작업에서 읽은 파일이 이 특정 출력 레코드를 생성했는가?"와 같은 질문을 할 수 있으며, 다른 운영자와 데이터 흐름 내에서 데이터 세분화를 디버깅하는 데 유용할 수 있다.[3]

제약 관계를 표시하는 지도 작업 감소

DISC 시스템에서 엔드투엔드 계통을 포착하기 위해,[25] 우리는 운영자와 데이터에 대한 격납 계층의 개념을 도입하는 Ibis 모델을 사용한다. 구체적으로, Ibis는 운영자가 다른 운영자 내에 포함될 수 있다고 제안하며, 두 운영자 사이의 그러한 관계를 운영자 봉쇄라고 한다. "운영자 격납은 포함된(또는 자식) 운영자가 포함하는(또는 상위) 운영자의 논리적 운영의 일부를 수행한다는 것을 의미한다."[3] 예를 들어, MapReduce 태스크는 작업에 포함되어 있다. 데이터 격납이라고 불리는 데이터에도 유사한 격납 관계가 존재한다. 데이터 격납은 포함된 데이터가 포함된 데이터(서퍼셋)의 하위 집합임을 의미한다.

격납 계층

규범 데이터 계통

규범적 데이터 계통 개념은 해당 데이터가 어떻게 흘러야 하는지에 대한 논리적 모델(entity)과 그 예에 대한 실제 계통 모두를 결합한다.[26]

데이터 계통 및 검증은 일반적으로 데이터 집합이 현재의 데이터 계통인 데이터 계통에 도달한 방식 또는 단계뿐만 아니라 모든 복사본 또는 파생 모델을 가리킨다. 그러나 법의학적 관점에서 혈통을 판별하기 위해 감사나 로그 상관관계만 되돌아보는 것은 특정 데이터 관리 사례에 흠이 있다. 예를 들어, 데이터 워크플로우가 취했던 경로가 정확했는지 논리 모델 없이는 준수 상태인지를 확실하게 판단할 수 없다.

논리 모델을 원자 법의학적 사건과 결합해야만 적절한 활동을 검증할 수 있다.

  1. 인증된 복사본, 조인 또는 CTAS 작업
  2. 해당 프로세스가 실행되는 시스템에 대한 처리 매핑
  3. Ad-Hoc 대 설정된 처리 순서

많은 인증된 컴플라이언스 보고서에는 특정 인스턴스에 대한 최종 상태 데이터뿐만 아니라 데이터 흐름의 입증도 필요하다. 이러한 유형의 상황에서 규정된 경로로부터의 편차를 설명하고 잠재적으로 교정할 필요가 있다.[27] 이는 순전히 되돌아보는 모델에서 규정 준수 워크플로우를 포착하는 데 더 적합한 프레임워크로 사고의 전환을 나타낸다.

활동적 혈통 대 게으른 혈통

게으른 혈통 수집은 일반적으로 런타임에 거친 혈통만을 포착한다. 이러한 시스템은 적은 양의 혈통으로 인해 캡처 오버헤드가 낮다. 그러나 미세한 추적 쿼리에 응답하려면 입력의 모든(또는 큰 부분)에서 데이터 흐름을 재생하고 재생 중에 미세한 계통을 수집해야 한다. 이 접근방식은 사용자가 관찰된 불량 출력을 디버깅하고자 하는 법의학 시스템에 적합하다.

활성 수집 시스템은 런타임에 데이터 흐름의 전체 계통을 캡처한다. 그들이 포착하는 계통의 종류는 거친 회색 또는 미세한 회색일 수 있지만, 그들은 실행 후 데이터 흐름에 대한 더 이상의 연산을 요구하지 않는다. 활성 미세한 혈통 수집 시스템은 게으른 수집 시스템보다 캡처 오버헤드가 더 높다. 그러나, 그것들은 정교한 재생과 디버깅을 가능하게 한다.[3]

배우들

행위자는 데이터를 변환하는 실체다; 그것은 Dryad 꼭지점, 개별 지도 및 축소 연산자, MapReduce 작업 또는 전체 데이터 흐름 파이프라인일 수 있다. 배우들은 블랙박스 역할을 하며 배우의 입력과 출력은 연관성의 형태로 혈통을 포착하기 위해 두드려진다. 여기서 연결은 배우 T에 대한 출력 o와 입력 i를 연관시키는 트리플트 {i, T, o}이다. 따라서 계측기는 한 번에 한 배우의 데이터 흐름에서 혈통을 포착하여 각 배우의 연결 집합으로 만든다. 배우. 시스템 개발자는 배우가 읽는 데이터(다른 배우로부터)와 배우가 쓰는 데이터(다른 배우에게)를 캡처할 필요가 있다. 예를 들어, 개발자는 각 작업에서 읽고 쓰는 파일 세트를 기록함으로써 Hadoop Job Tracker를 배우로 취급할 수 있다. [28]

연관성

연결은 입력, 출력 및 작동 자체를 조합한 것이다. 이 수술은 배우로도 알려진 블랙박스로 표현된다. 연관성은 데이터에 적용되는 변환을 설명한다. 연결은 연결 테이블에 저장된다. 각각의 독특한 배우들은 그들만의 연결 테이블로 대표된다. 연관 자체는 {i, T, o}처럼 보이는데, 여기서 나는 배우 T에 대한 입력 집합이고 o는 배우에 의해 생산된 출력 집합이다. 연결은 데이터 리니지의 기본 단위다. 개별 연결은 나중에 데이터에 적용된 변환의 전체 이력을 구성하기 위해 함께 결합된다.[3]

건축

빅데이터 시스템은 수평적으로 확장된다. 즉, 분산형 시스템에 새로운 하드웨어 또는 소프트웨어 엔터티를 추가하여 용량을 증가시킨다. 분산형 시스템은 여러 하드웨어 및 소프트웨어 엔터티로 구성되더라도 논리적 수준에서 단일 엔터티로 작용한다. 시스템은 수평 스케일링 후에도 이 속성을 계속 유지해야 한다. 수평적 확장성의 중요한 장점은 즉석에서 용량을 늘릴 수 있는 능력을 제공할 수 있다는 점이다. 가장 큰 장점은 상품 하드웨어를 이용해 수평적 확장이 가능하다는 점이다.

리니지 스토어의 아키텍처를 만들면서 빅 데이터 시스템의 수평적 확장 기능을 고려해야 한다. 이는 리니지 스토어 자체도 빅데이터 시스템과 병행하여 확장할 수 있어야 하기 때문에 필수적이다. 계통을 저장하는 데 필요한 연결 수와 저장 용량은 시스템의 크기와 용량이 증가함에 따라 증가할 것이다. 빅 데이터 시스템의 아키텍처는 단일 계통 저장소를 사용하는 것이 적절하지 않고 확장 불가능하게 만든다. 이 문제에 대한 즉각적인 해결책은 혈통 매장 자체를 유통시키는 것이다.[3]

최상의 시나리오는 분산 시스템 네트워크의 모든 기계에 대해 로컬 계통 저장소를 사용하는 것이다. 이를 통해 계통매장도 수평으로 스케일링할 수 있다. 이 설계에서 특정 기계의 데이터에 적용되는 데이터 변환 계통은 특정 기계의 로컬 계통 저장소에 저장된다. 계통 상점은 일반적으로 연관 테이블을 저장한다. 각 배우들은 각자의 연상표들로 대표된다. 행은 연결 자체로, 열은 입력과 출력을 나타낸다. 이 디자인은 두 가지 문제를 해결한다. 리니지 스토어의 수평적 스케일링이 가능하다. 하나의 중앙집중화된 계통 저장소를 사용하는 경우, 이 정보는 네트워크를 통해 전달되어야 했고, 이는 추가적인 네트워크 지연을 야기할 것이다. 네트워크 지연은 분산된 계통 저장소를 사용함으로써도 방지된다.[28]

계통제도의 구조

데이터 흐름 재구성

연관성의 관점에서 저장된 정보는 특정 업무의 데이터 흐름을 얻기 위해 어떤 수단에 의해 결합될 필요가 있다. 분산형 시스템에서 작업은 여러 태스크로 나뉜다. 하나 이상의 인스턴스가 특정 태스크를 실행하십시오. 이러한 개별 기계에서 생산된 결과는 나중에 함께 결합하여 작업을 완료한다. 서로 다른 시스템에서 실행되는 태스크는 기계의 데이터에 대해 여러 변환을 수행한다. 기계의 데이터에 적용되는 모든 변환은 그 기계의 로컬 계통 저장소에 저장된다. 이 정보를 종합해 전체 직업의 혈통을 얻을 필요가 있다. 전체 업무의 계통은 데이터 과학자가 업무의 데이터 흐름을 이해하는 데 도움이 되어야 하며 빅데이터 파이프라인을 디버깅하는 데 데이터 흐름을 활용할 수 있다. 데이터 흐름은 3단계로 재구성된다.

연관 테이블

데이터 흐름 재구성의 첫 번째 단계는 연결 표의 계산이다. 각 지역 계통 매장의 각 배우에 대한 연관 테이블이 존재한다. 배우의 전체 연관표는 이러한 개별 연관표를 조합하여 계산할 수 있다. 이것은 일반적으로 배우들 자체에 기초하여 일련의 평등 결합을 이용한다. 몇 가지 시나리오에서는 입력을 키로 사용하여 표를 결합할 수도 있다. 또한 인덱스는 조인의 효율성을 향상시키는 데 사용될 수 있다. 조인된 테이블은 단일 인스턴스 또는 기계에 저장해야 추가로 처리할 수 있다. 조인을 계산할 기계를 선택하는 데 사용되는 여러 가지 방법이 있다. CPU 로드가 최소인 가장 쉬운 것. 결합이 발생할 경우를 선택하는 동안 공간 제약도 염두에 두어야 한다.

연관 그래프

데이터 흐름 재구성의 두 번째 단계는 혈통 정보로부터 연관 그래프를 계산하는 것이다. 그래프는 데이터 흐름의 단계를 나타낸다. 배우들은 정점 역할을 하고 연관성은 가장자리 역할을 한다. 각각의 배우 T는 데이터 흐름에서 그것의 업스트림과 다운스트림 배우들과 연결된다. T의 업스트림 배우는 T의 입력을 생산한 배우인 반면 다운스트림 배우는 T의 출력을 소비하는 배우인 것이다. 격납관계는 링크를 만들면서 항상 고려된다. 그래프는 세 가지 유형의 링크 또는 가장자리로 구성된다.

명시적으로 지정된 링크

가장 간단한 링크는 두 배우 사이에 명시적으로 지정된 링크다. 이러한 링크는 기계 학습 알고리즘의 코드에 명시되어 있다. 배우가 정확한 업스트림이나 다운스트림 배우를 인지하고 있을 때, 이 정보를 계통 API에 전달할 수 있다. 이 정보는 나중에 추적 질의 중에 이러한 행위자들을 연결하는데 사용된다. 예를 들어, MapReduce 아키텍처에서, 각 지도 인스턴스는 출력이 소비되는 정확한 레코드 판독기 인스턴스를 알고 있다.[3]

논리적으로 추론된 링크

개발자들은 각 논리적 행위자에 데이터 흐름 원형을 첨부할 수 있다. 데이터 흐름 원형은 배우 유형의 자녀 유형이 데이터 흐름에서 어떻게 스스로를 배열하는지 설명한다. 이 정보의 도움으로 소스 유형의 각 배우와 목적지 유형의 연결을 유추할 수 있다. 예를 들어, MapReduce 아키텍처에서, 지도 행위자 유형은 감소의 원천이며, 그 반대의 경우도 마찬가지다. 시스템은 이를 데이터 흐름 원형으로부터 주입하고 지도 인스턴스를 축소 인스턴스와 적절히 연결한다. 그러나 데이터 흐름에는 여러 MapReduce 작업이 있을 수 있으며, 모든 맵 인스턴스를 모든 축소 인스턴스와 연결하면 잘못된 링크가 생성될 수 있다. 이를 방지하기 위해 이러한 링크는 포함(또는 상위) 배우 유형의 일반적인 배우 인스턴스 내에 포함된 배우 인스턴스로 제한된다. 따라서 지도와 축소 인스턴스는 동일한 직무에 속하는 경우에만 서로 연결된다.[3]

데이터 세트 공유를 통한 암시적 링크

분산형 시스템에서는 실행 중에 지정되지 않는 암묵적 링크가 있는 경우도 있다. 예를 들어, 파일에 글을 쓴 배우와 파일에서 읽은 다른 배우 사이에 암묵적인 연결이 존재한다. 그러한 링크는 실행을 위해 공통 데이터 세트를 사용하는 행위자를 연결한다. 데이터 집합은 첫 번째 배우의 출력물이며, 그것을 따르는 배우의 입력물이다.[3]

위상 분류

데이터 흐름 재구성의 마지막 단계는 연관 그래프의 위상학적 정렬이다. 이전 단계에서 생성된 방향 그래프는 배우들이 데이터를 수정한 순서를 얻기 위해 위상적으로 정렬된다. 이는 행위자의 상속 순서가 빅데이터 파이프라인이나 업무의 데이터 흐름을 규정하는 것이다.

추적 및 재생

이는 빅데이터 디버깅에서 가장 중요한 단계다. 포획된 혈통을 결합하여 처리하여 송유관의 데이터 흐름을 얻는다. 데이터 흐름은 데이터 과학자 또는 개발자가 행위자와 그 변형을 깊이 들여다 볼 수 있도록 돕는다. 이 단계를 통해 데이터 과학자는 예기치 않은 출력을 생성하는 알고리즘의 부분을 파악할 수 있다. 빅데이터 파이프라인은 크게 두 가지 면에서 잘못될 수 있다. 첫 번째는 데이터 흐름 속에 수상한 배우가 등장하는 것이다. 두 번째는 데이터에 특이치가 있다는 것이다.

첫 번째 사례는 데이터 흐름을 추적하여 디버깅할 수 있다. 데이터 과학자는 계통 정보와 데이터 흐름 정보를 함께 사용함으로써 입력이 어떻게 출력으로 변환되는지 파악할 수 있다. 그 과정에서 예상치 못한 행동을 하는 행위자들이 잡힐 수 있다. 이러한 행위자들은 데이터 흐름에서 제거되거나 새로운 행위자들에 의해 증강되어 데이터 흐름을 바꿀 수 있다. 개선된 데이터 흐름은 그것의 유효성을 시험하기 위해 재생될 수 있다. 결함이 있는 행위자를 디버깅하는 것은 데이터 흐름에서 행위자에 대해 거친 곡선을 재귀적으로 재생하는 것을 포함하는데,[29] 이는 긴 데이터 흐름에서 자원이 비쌀 수 있다. 또 다른 접근방법은 이상 징후를 찾기 위해 혈통 로그를 수동으로 검사하는 것인데,[13][30] 이는 데이터 흐름의 여러 단계에 걸쳐 지루하고 시간이 오래 걸릴 수 있다. 게다가, 이러한 접근법은 데이터 과학자가 나쁜 결과를 발견할 수 있을 때만 효과가 있다. 알려진 나쁜 결과물이 없는 분석을 디버깅하려면 데이터 흐름을 분석하여 일반적으로 의심스러운 행동을 해야 한다. 그러나 사용자는 예상된 정상 동작을 모를 수 있고 술어를 지정할 수 없는 경우가 많다. 이 절에서는 다단계 데이터 흐름에서 불량 행위자를 식별하기 위해 혈통을 소급 분석하는 디버깅 방법을 설명한다. 우리는 배우의 평균 선택성, 처리 속도 또는 출력 크기 같은 갑작스러운 행동 변화가 변칙적인 특징이라고 믿는다. 리니지는 시간 경과에 따른 배우 행동과 다른 배우 사례에 걸친 배우 행동의 변화를 반영할 수 있다. 따라서 그러한 변화를 식별하기 위한 채굴 혈통은 데이터 흐름에서 결함 있는 행위자를 디버깅하는 데 유용할 수 있다.

비정상적인 배우 추적

두 번째 문제, 즉 특이치의 존재는 데이터 흐름 단계를 현명하게 실행하고 변환된 출력을 살펴봄으로써도 식별할 수 있다. 데이터 과학자는 나머지 산출물에 부합하지 않는 산출물의 하위 집합을 찾는다. 이러한 나쁜 출력을 유발하는 입력은 데이터의 특이치다. 이 문제는 데이터에서 특이치 집합을 제거하고 전체 데이터 흐름을 재생함으로써 해결할 수 있다. 또한 데이터 흐름에서 행위자를 추가, 제거 또는 이동시켜 머신러닝 알고리즘을 수정함으로써 해결할 수 있다. 재생된 데이터 흐름이 나쁜 출력을 생성하지 않으면 데이터 흐름의 변경이 성공한다.

데이터에서 특이치 추적

과제들

데이터 계통 접근법의 사용이 빅데이터 파이프라인의 새로운 디버깅 방식이라고 해도 과정이 간단치 않다. 계통매장의 확장성, 계통매장의 내결함성, 블랙박스 사업자의 정확한 계통 포착 등 여러 과제가 있다. 이러한 과제는 신중하게 고려해야 하며 데이터 계통 캡처를 위한 현실적인 설계를 위해 이들 간의 절충을 평가할 필요가 있다.

확장성

DISC 시스템은 주로 높은 처리량을 위해 설계된 배치 처리 시스템이다. 분석당 여러 개의 작업을 실행하며, 작업당 여러 개의 태스크를 실행한다. 클러스터에서 언제든지 실행되는 전체 운영자 수는 클러스터 크기에 따라 수백에서 수천까지 다양할 수 있다. 이러한 시스템에 대한 계통 캡처는 DISC 분석의 병목 현상을 방지하기 위해 대량의 데이터와 수많은 운영자 모두에게 확장될 수 있어야 한다.

내결함성

리니지 캡처 시스템도 리니지를 캡처하기 위해 데이터 흐름이 재실행되지 않도록 내결함성을 갖춰야 한다. 동시에, 그들은 또한 DISC 시스템의 고장을 수용해야 한다. 그렇게 하려면 실패한 DISC 작업을 식별할 수 있어야 하며 실패한 작업에 의해 생성된 부분 계통과 재시작된 계통에 의해 생성된 중복 계통 사이의 계통 복사본을 저장하지 않아야 한다. 또한 혈통 시스템은 현지의 혈통 시스템이 다운되는 여러 경우를 우아하게 처리할 수 있어야 한다. 이것은 여러 기계에 혈통 연관성의 복제본을 저장함으로써 달성할 수 있다. 복제본은 실제 복사본이 유실될 경우 백업과 같은 역할을 할 수 있다.

블랙박스 연산자

DISC 데이터 흐름을 위한 리니지 시스템은 블랙박스 운영자에 걸쳐 정확한 리니지를 캡처할 수 있어야 미세한 디버깅이 가능하다. 이에의 접근법 Prober, 즉 장(알에 의해 사용되는 몇번이나 그 최소한의 set,[31일]고 역동적인 slicing을 추론하는 data-flow 재연해 정비 운전자에게 지정된 출력을 입력의 최소 집합을 찾기 위한 것을 포함한다.[32]NoSQL 운영자에 대한 이진을 다시 작성을 통해 동적 sli를 계산하기 위해 혈통 포착할 수 있다.ces. 비록 매우 정확한 혈통을 생산하지만, 그러한 기법은 포획이나 추적을 위해 상당한 시간 오버헤드를 초래할 수 있으며, 대신 더 나은 성능을 위해 약간의 정확성을 거래하는 것이 더 나을 수 있다. 따라서, 캡처나 추적에 상당한 오버헤드가 없이 합리적인 정확도로 임의의 운영자로부터 계통을 포착할 수 있는 DISC 데이터 흐름의 계통 수집 시스템이 필요하다.

효율적인 추적

디버깅에는 추적이 필수적이며, 이 과정에서 사용자는 여러 추적 쿼리를 실행할 수 있다. 따라서 추적이 빠른 턴 타임을 갖는 것이 중요하다. 이케다 외.[24]는 MapReduce 데이터 흐름에 대해 효율적인 역추적 쿼리를 수행할 수 있지만 다른 DISC 시스템에 일반적이지 않으며 효율적인 전방 쿼리를 수행하지 않는다. 피그용 계통 [33]시스템인 립스틱은 역추적과 전진추적이 모두 가능하면서도 피그와 SQL 연산자 전용으로 블랙박스 연산자 전용으로 거친 곡물추적이 가능하다.[34] 따라서 블랙박스 운영자를 통한 일반적인 DISC 시스템 및 데이터 흐름의 효율적인 전후추적이 가능한 계통 시스템이 필요하다.

정교한 재생

데이터 흐름의 특정 입력 또는 일부만 재생하는 것은 효율적인 디버깅 및 What-if 시나리오 시뮬레이션에 필수적이다. 이케다 외에서는 업데이트된 입력을 선택적으로 재생하여 영향을 받는 출력을 재평가하는 계통 기반 업데이트/교체 방법론을 제시한다.[35] 이것은 잘못된 입력이 고정되었을 때 출력을 다시 계산하기 위해 디버깅할 때 유용하다. 그러나 때때로 사용자는 오류로 인해 이전에 영향을 받은 출력물의 계통을 재생하여 오류 없는 출력을 생성하고자 할 수 있다. 우리는 이것을 독점 재생이라고 부른다. 디버깅에서 재생의 또 다른 용도는 단계적 디버깅(선택적 재생이라고 함)을 위해 잘못된 입력을 재생하는 것을 포함한다. 현재 DISC 시스템에서 계통을 사용하는 접근방식은 이러한 문제를 다루지 않는다. 따라서 서로 다른 디버깅 요구를 해결하기 위해 배타적 재생과 선택적 재생 모두를 수행할 수 있는 계통 시스템이 필요하다.

이상 탐지

DISC 시스템의 주요 디버깅 관심사 중 하나는 결함이 있는 운영자를 식별하는 것이다. 수백 개의 연산자 또는 작업이 있는 긴 데이터 흐름에서 수동 검사는 지루하고 불가능할 수 있다. 검사할 연산자의 서브셋을 좁히기 위해 계통을 사용한다고 해도, 단일 출력의 계통은 여전히 여러 연산자에 걸쳐 있을 수 있다. 합리적인 정확도로 고장 가능성이 있는 연산자 세트를 실질적으로 좁혀 필요한 수동 검사량을 최소화할 수 있는 저렴한 자동 디버깅 시스템이 필요하다.

참고 항목

참조

  1. ^ "What is Data Lineage? - Definition from Techopedia".
  2. ^ Hoang, Natalie (2017-03-16). "Data Lineage Helps Drives Business Value Trifacta". Trifacta. Retrieved 2017-09-20.
  3. ^ a b c d e f g h i j k 드, 수야루파 (2012). Newt : DISC 시스템에서 계통 기반 재생 및 디버깅을 위한 아키텍처. UC 샌디에이고: b7355202. 검색 대상: https://escholarship.org/uc/item/3170p7zn
  4. ^ Drori, Amanon (2020-05-18). "What is Data Lineage? Octopai". Octopai. Retrieved 2020-08-25.
  5. ^ 제프리 딘과 산제이 헤마왓. Mapreduce: 대규모 클러스터에서 간소화된 데이터 처리. 코뮌. ACM, 51(1):107–113, 2008년 1월.
  6. ^ 마이클 이사드, 미하이 부디우, 위안유, 앤드류 비렐리, 데니스 페테르리. Dryad: 순차적 빌딩 블록에서 데이터 병렬 프로그램을 배포한다. 제2회 ACM SIGOPS/EuroSys 유럽 컨퍼런스 2007의 Procedures onComputer Systems 2007에서 EuroSys '07, 페이지 59–72, 뉴욕, 뉴욕, 미국, 2007. ACM
  7. ^ Apache Hadoop. http://hadoop.apache.org.
  8. ^ 그르제고르츠 말레위츠, 매튜 H. 오스테른, 아아트 J.C 바이크, 제임스 C. 데네르트, 일란 혼, 나티 레저, 그리고 그르제고르츠 크자이코프스키. Pregel: 대규모 그래프 처리를 위한 시스템이다. 2010년 데이터 관리에 관한 국제 회의의 절차에서, SGIMOD '10, 135–146페이지, 뉴욕, 뉴욕, 미국, 2010. ACM
  9. ^ 시민 첸과 스티븐 W. 슐로저. 지도 감축은 더 다양한 어플리케이션들을 충족시킨다. 기술 보고서, 인텔리서치, 2008.
  10. ^ 유전체학에서 데이터가 쇄도한다. https://www-304.ibm.com/connections/blogs/ibmhealthcare/entry/data genomics3?de=de, 2010년 과부하.
  11. ^ 요게시 L. 심만, 베스 플레일, 데니스 개넌. 전자 과학에서의 데이터 입증에 대한 조사. SGIMOD Rec, 34(3):31–36, 2005년 9월.
  12. ^ a b 이언 포스터, 옌스 보클러, 마이클 와일드, 용자오. Chimera: 데이터 파생의 표현, 쿼리 및 자동화를 위한 가상 데이터 시스템. 2002년 7월, 제14회 과학 및 통계 데이터베이스 관리에 관한 국제 회의에서.
  13. ^ a b 벤자민 H. 시겔만, 루이스 안드르 바로소, 마이크 버로우스, 팻 스티븐슨, 마노즈 플라칼, 도널드 비버, 사울 재스판, 찬단 샨바그. 인프라를 추적하는 대규모 분산 시스템인 Dapper. 기술 보고서, Google Inc., 2010.
  14. ^ a b 피터 버네만, 산제프 칸나, 왕치우 탄. 데이터 증명: 몇 가지 기본적인 문제. 소프트웨어 기반에 관한 제20차 회의의 진행 중기술 및 이론 컴퓨터 과학, FST TCS 2000, 87–93페이지, 영국 런던, 2000페이지. 스프링거-베를라그
  15. ^ "New Digital Universe Study Reveals Big Data Gap Less Than 1 of World s Data is Analyzed Less Than 20 is Protected".
  16. ^ 웹미디어 http://www.webopedia.com/TERM/U/unstructured_data.html
  17. ^ Schaefer, Paige (2016-08-24). "Differences Between Structured & Unstructured Data". Trifacta. Retrieved 2017-09-20.
  18. ^ SAS. http://www.sas.com/resources/asset/five-big-data-challenges-article.pdf 웨이백 머신에 2014-12-20 아카이브
  19. ^ "5 Requirements for Effective Self-Service Data Preparation". www.itbusinessedge.com. 18 February 2016. Retrieved 2017-09-20.
  20. ^ Kandel, Sean (2016-11-04). "Tracking Data Lineage in Financial Services Trifacta". Trifacta. Retrieved 2017-09-20.
  21. ^ Pasquier, Thomas; Lau, Matthew K.; Trisovic, Ana; Boose, Emery R.; Couturier, Ben; Crosas, Mercè; Ellison, Aaron M.; Gibson, Valerie; Jones, Chris R.; Seltzer, Margo (5 September 2017). "If these data could talk". Scientific Data. 4: 170114. doi:10.1038/sdata.2017.114. PMC 5584398. PMID 28872630.
  22. ^ 로버트 이케다와 제니퍼 위덤. 데이터 계통: 설문 조사. Stanford University, 2009년 기술 보고서.
  23. ^ a b Y. Cui와 J. Widom. 일반 데이터 웨어하우스 변환을 위한 계통 추적. VLDB 저널, 12(1), 2003.
  24. ^ a b c d 로버트 이케다, 박현정, 제니퍼 위덤. 일반화된 맵 및 워크플로우 감소에 대한 입증. 2011년 1월 CIDR의 Proc.에서.
  25. ^ C. 올스턴과 A. 다스 사르마. Ibis: 다중 계층 시스템의 입증 관리자. 2011년 1월 CIDR의 Proc.에서.
  26. ^ http://info.hortonworks.com/rs/549-QAL-086/images/Hadoop-Governance-White-Paper.pdf
  27. ^ SEC 소기업 컴플라이언스 가이드
  28. ^ a b 디오니시오스 로고테티스, 수야루파 데, 케네스 요쿰. DISC 분석을 디버깅하기 위한 확장 가능한 계통 캡처 제4회 클라우드 컴퓨팅 관련 심포지엄(SOCC '13)을 개최하는 과정 ACM, 뉴욕, 뉴욕, 미국, 17조, 15페이지.
  29. ^ Zhou, Wenchao; Fei, Qiong; Narayan, Arjun; Haeberlen, Andreas; Thau Loo, Boon; Sherr, Micah (December 2011). Secure network provenance. Proceedings of 23rd ACM Symposium on Operating System Principles (SOSP).
  30. ^ Fonseca, Rodrigo; Porter, George; Katz, Randy H.; Shenker, Scott; Stoica, Ion (2007). X-trace: A pervasive network tracing framework. Proceedings of NSDI’07.
  31. ^ 아니쉬 다스 사마, 알파 자인, 필립 보하논. PROBER: 추출 및 통합 파이프라인의 Ad-Hoc 디버깅. 기술 보고서 야후, 2010년 4월
  32. ^ 명우장, 샹유장, 샹장, 수닐 프라바하카르. 관계 운영자 이상의 혈통 추적. Proc. 2007년 9월 VLDB(Very Large Data Base) 컨퍼런스.
  33. ^ 야엘 암스테르담어, 수잔 B. 데이비드슨, 다니엘 더치, 토바 밀로, 줄리아 스토야노비치. Pig에 립스틱 바르기: 데이터베이스 스타일의 워크플로우 증명 가능. 2011년 8월 VLDB의 Proc.에서.
  34. ^ 크리스토퍼 올스턴, 벤자민 리드, 우카르시 스리바스타바, 라비 쿠마르, 앤드류 톰킨스. 돼지 라틴어: 데이터 처리를 위한 외국어가 아닌 언어. 2008년 6월 캐나다 밴쿠버 ACM SGIMOD의 Proc.
  35. ^ 로버트 이케다, 세미 살리호글루, 제니퍼 위덤. 데이터 지향 워크플로우의 입증 기반 업데이트/교체. 정보 및 지식 관리에 관한 제20회 ACM 국제 회의의 절차에서, CIKM '11, 페이지 1659–1668, 뉴욕, 뉴욕, 뉴욕, 미국, 2011. ACM