차례:
Hadoop은 분석 처리를 위해 데이터를 오프로드하거나 기존 시스템으로는 불가능한 대량의 단일 데이터 소스를 모델링하기에 좋은 장소입니다. 그러나 회사가 많은 소스에서 Hadoop으로 데이터를 가져 오면서 여러 소스에서 데이터 분석에 대한 요구가 증가하고 있으며이를 달성하기가 매우 어려울 수 있습니다. 이 게시물은 조직이 Hadoop 내에서 다양한 데이터 소스 및 유형을 분석하려고 시도하면서 이러한 문제를 해결하는 방법을 설명하는 3 부로 구성된 시리즈 중 첫 번째 기사입니다. 오늘 포스트는 여러 내부 소스를 결합 할 때 발생하는 문제에 중점을 둡니다. 다음 두 게시물은 외부 데이터 소스가 추가 될 때 이러한 문제가 복잡 해지는 이유와이를 해결하는 데 새로운 접근 방식이 어떻게 도움이되는지 설명합니다.
서로 다른 소스의 데이터를 연결 및 매핑하기 어려움
다양한 소스의 데이터는 구조가 다르기 때문에 내부 소스의 데이터를 포함하여 데이터 유형을 서로 연결하고 매핑하기가 어렵습니다. 고객이 여러 개의 계정 번호를 가지고 있거나 조직이 다른 회사를 인수하거나 합병 한 경우 데이터 결합이 특히 어려울 수 있습니다. 지난 몇 년 동안 일부 조직에서는 데이터 검색 또는 데이터 과학 응용 프로그램을 사용하여 Hadoop에 저장된 여러 소스의 데이터를 분석하려고 시도했습니다. 이 접근 방식은 많은 추측이 필요하기 때문에 문제가됩니다. 사용자는 다양한 데이터 소스를 연결하고 데이터 모델 오버레이를 만들 때 어떤 외래 키를 사용할지 결정해야합니다. 이러한 추측은 테스트하기 어렵고 규모에 적용될 때 종종 잘못되어 데이터 분석에 결함이 있고 소스의 불신을 초래합니다.
하둡 전문가들이 데이터를 병합하려고 시도
따라서 여러 데이터 소스에서 데이터를 분석하려는 조직은 Hadoop 전문가를 고용하여 데이터 세트를 병합하는 사용자 지정 소스 별 스크립트를 작성했습니다. 이러한 하둡 전문가는 일반적으로 데이터 통합 또는 엔터티 확인 전문가가 아니지만 조직의 즉각적인 요구를 해결하기 위해 최선을 다합니다. 이러한 전문가는 일반적으로 Pig 또는 Java를 사용하여 특정 소스의 구조화 된 데이터를 결합하는 방법 (예 : 계정 번호를 기준으로 레코드 일치)을 결정하는 강력하고 빠른 규칙을 작성합니다. 두 개의 소스에 대한 스크립트가 작성되면 세 번째 소스를 추가해야하는 경우 첫 번째 스크립트를 버리고 세 개의 특정 소스를 결합하도록 설계된 새 스크립트가 필요합니다. 다른 소스가 추가되는 경우에도 마찬가지입니다. 이 방법은 비효율적 일뿐만 아니라 규모에 따라 적용 할 때 실패하고, 엣지 케이스를 제대로 처리하지 못하고, 중복 레코드가 많이 생성 될 수 있으며, 종종 결합하지 않아야하는 많은 레코드를 병합합니다.
