Oncrawl 외부에서 Oncrawl 데이터로 복잡한 데이터 질문에 답하는 방법

게시 됨: 2022-01-04

엔터프라이즈 SEO용 Oncrawl의 장점 중 하나는 원시 데이터에 대한 전체 액세스 권한이 있다는 것입니다. SEO 데이터를 BI 또는 데이터 과학 워크플로에 연결하든, 자체 분석을 수행하든, 조직의 데이터 보안 지침 내에서 작업하든, 원시 SEO 및 웹 사이트 감사 데이터는 다양한 용도로 사용될 수 있습니다.

오늘은 복잡한 데이터 질문에 답하기 위해 Oncrawl 데이터를 사용하는 방법을 살펴보겠습니다.

복잡한 데이터 질문이란 무엇입니까?

복잡한 데이터 질문은 단순한 데이터베이스 조회로는 답할 수 없지만 답을 얻기 위해서는 데이터 처리가 필요한 질문입니다.

다음은 SEO가 자주 갖는 "복잡한" 데이터 질문의 몇 가지 일반적인 예입니다.

404 상태의 다른 페이지로 리디렉션되는 페이지를 가리키는 모든 링크 목록 만들기
URL이 아닌 측정항목을 기반으로 하는 세분화의 페이지를 가리키는 모든 링크 및 해당 앵커 텍스트 목록 만들기

Oncrawl에서 복잡한 데이터 질문에 답하는 방법

Oncrawl의 데이터 구조는 거의 모든 사이트에서 거의 실시간으로 데이터를 조회할 수 있도록 구축되었습니다. 여기에는 인터페이스에서 조회 시간을 최소로 유지하기 위해 서로 다른 데이터 세트에 서로 다른 유형의 데이터를 저장하는 작업이 포함됩니다. 예를 들어 URL과 관련된 모든 데이터를 응답 코드, 나가는 링크 수, 존재하는 구조화된 데이터 유형, 단어 수, 유기적 방문 수와 같은 데이터 세트에 저장합니다. 그리고 링크와 관련된 모든 데이터를 별도의 데이터 세트에 저장합니다. 링크 대상, 링크 원점, 앵커 텍스트…

이러한 데이터 세트를 결합하는 것은 계산적으로 복잡하며 Oncrawl 애플리케이션의 인터페이스에서 항상 지원되는 것은 아닙니다. 다른 데이터세트에서 검색하기 위해 한 데이터세트를 필터링해야 하는 검색에 관심이 있는 경우 원시 데이터를 직접 조작하는 것이 좋습니다.

모든 Oncrawl 데이터를 사용할 수 있으므로 데이터 세트를 결합하고 복잡한 쿼리를 표현하는 방법이 많이 있습니다.

이 기사에서는 Google Cloud 및 BigQuery를 사용하여 그 중 하나를 살펴보겠습니다. 이는 많은 고객이 대용량 페이지가 있는 사이트의 데이터를 검사할 때 접하게 되는 매우 큰 데이터 세트에 적합합니다.

필요한 것

이 문서에서 논의할 방법을 따르려면 다음 도구에 액세스해야 합니다.

온크롤
빅 데이터 내보내기가 포함된 Oncrawl의 API
구글 클라우드 스토리지
빅쿼리
Oncrawl에서 BigQuery로 데이터를 전송하는 Python 스크립트(이 기사에서 이를 구축할 예정입니다.)

시작하기 전에 Oncrawl에서 완료된 크롤링 보고서에 액세스할 수 있어야 합니다.

Google BigQuery에서 Oncrawl 데이터를 활용하는 방법

오늘 기사의 계획은 다음과 같습니다.

먼저 Google Cloud Storage가 Oncrawl에서 데이터를 수신하도록 설정되어 있는지 확인합니다.
다음으로 Python 스크립트를 사용하여 Oncrawl의 빅 데이터 내보내기를 실행하여 주어진 크롤링에서 Google Cloud Storage 버킷으로 데이터를 내보냅니다. 페이지와 링크라는 두 개의 데이터세트를 내보냅니다.
이 작업이 완료되면 Google BigQuery에서 데이터세트를 생성합니다. 그런 다음 BigQuery 데이터세트 내의 두 내보내기 각각에서 테이블을 생성합니다.
마지막으로 개별 데이터세트를 쿼리한 다음 두 데이터세트를 함께 쿼리하여 복잡한 질문에 대한 답을 찾는 실험을 할 것입니다.

Oncrawl 데이터를 수신하도록 Google Cloud 내에서 설정

전용 샌드박스 환경에서 이 가이드를 실행하려면 새 GCP 프로젝트를 만들어 기존 진행 중인 프로젝트에서 격리하는 것이 좋습니다.

Google Cloud의 홈에서 시작해 보겠습니다.

Google Cloud 홈페이지에서 Cloud Storage 외에도 다양한 항목에 액세스할 수 있습니다. Google Cloud Platform의 클라우드 스토리지 계층 내에서 사용할 수 있는 Cloud Storage 버킷에 관심이 있습니다.

https://console.cloud.google.com/storage/browser에서 직접 Cloud Storage 브라우저에 연결할 수도 있습니다.

그런 다음 Cloud Storage 버킷을 만들고 선택한 접두사 아래에서 Oncrawl의 서비스 계정이 버킷에 쓸 수 있도록 올바른 권한을 부여해야 합니다.
Google Cloud Storage 버킷은 Google BigQuery에 로드하기 전에 Oncrawl에서 내보낸 빅 데이터를 보관하기 위한 임시 저장소 역할을 합니다.

이 버킷에는 "links"와 "pages"라는 두 개의 폴더도 만들었습니다.

Oncrawl에서 데이터 세트 내보내기

이제 데이터를 저장할 공간을 설정했으므로 Oncrawl에서 데이터를 내보내야 합니다. 데이터를 올바른 형식으로 내보내고 버킷에 직접 저장할 수 있기 때문에 Oncrawl을 사용하여 Google Cloud Storage 버킷으로 내보내는 것은 특히 쉽습니다. 이렇게 하면 추가 단계가 필요하지 않습니다.

API 키 생성

BigQuery용 Parquet 형식으로 Oncrawl에서 데이터를 내보내려면 API 키를 사용하여 Oncrawl 계정 소유자를 대신하여 프로그래밍 방식으로 API 작업을 수행해야 합니다. Oncrawl 애플리케이션을 사용하면 사용자가 명명된 API 키를 생성할 수 있으므로 계정이 항상 잘 정리되고 정리됩니다. API 키는 또한 키와 해당 목적을 관리할 수 있도록 다양한 권한(범위)과 연결됩니다.

새 키의 이름을 '지식 세션 키'로 지정하겠습니다. 빅 데이터 내보내기 기능은 데이터 내보내기를 생성하기 때문에 계정에 쓰기 권한이 필요합니다. 이를 수행하려면 프로젝트에 대한 읽기 액세스 권한과 계정에 대한 읽기 및 쓰기 액세스 권한이 있어야 합니다.

이제 클립보드에 복사할 새 API 키가 있습니다.

보안상의 이유로 키를 한 번만 복사 할 수 있습니다. 키 복사를 잊어버린 경우 키를 삭제하고 새 키를 만들어야 합니다.

Python 스크립트 만들기

이를 위해 Google Colab 노트북을 만들었지만 나만의 도구나 노트북을 만들 수 있도록 아래 코드를 공유하겠습니다.

1. API 키를 전역 변수에 저장
먼저 환경을 부트스트랩하고 "Oncrawl Token"이라는 전역 변수에 API 키를 선언합니다. 그런 다음 나머지 실험을 준비합니다.

 #@title Oncrawl API에 액세스
#@markdown 이 노트북이 Oncrawl 데이터에 액세스할 수 있도록 아래에 API 토큰을 제공하세요.
# ONCRAWL API용 토큰
ONCRAWL_TOKEN = "" #@param {유형:"문자열"}

! pip 설치 감옥

IPython.display 가져오기 clear_output에서
clear_output()

print('모두 로드되었습니다.')

2. 작업할 Oncrawl 프로젝트를 선택하는 드롭다운 목록을 만듭니다.
그런 다음 해당 키를 사용하여 프로젝트 목록을 가져오고 해당 목록에서 드롭다운 위젯을 만들어 재생하려는 프로젝트를 선택할 수 있기를 원합니다. 두 번째 코드 블록을 실행하여 다음 단계를 수행하십시오.

방금 제출한 API 키를 사용하여 계정의 프로젝트 목록을 가져오기 위해 Oncrawl API를 호출합니다.
API 응답에서 프로젝트 목록을 가져오면 프로젝트 이름과 프로젝트 시작 URL을 사용하여 목록 형식을 지정합니다.
응답에 제공된 프로젝트의 ID를 저장합니다.
드롭다운 메뉴를 만들고 코드 블록 아래에 표시합니다.

 #@title 해당 Oncrawl 프로젝트를 선택하여 분석할 웹사이트를 선택합니다.
가져오기 요청
수입 감옥
ipywidget을 위젯으로 가져오기
json 가져오기
 
# 프로젝트 목록 가져오기
응답 = requests.get("https://app.oncrawl.com/api/v2/projects?limit={limit}&sort={정렬}".format(
       제한=1000,
       정렬='이름:오름차순'
   ),
   headers={ '승인': '소유자 '+ONCRAWL_TOKEN }
)
 
json_res = 응답.json()
 
사용자가 프로젝트를 선택할 수 있도록 #prepare 드롭다운
프로젝트 = []
json_res['projects']의 항목:
   project.append(('{} - {}'.format(item['name'], item['start_url']), item['id']))
 
출력 = 위젯.출력()
 
dropdown_purpose = widgets.Dropdown(옵션 = 프로젝트, 설명="프로젝트: ")
 
def dropdown_project_eventhandler(변경):
   output.clear_output()   
   출력:
       디스플레이(프로젝트)
 
dropdown_purpose.observe(dropdown_project_eventhandler, 이름='값')
 
디스플레이(dropdown_purpose)

이렇게 하면 생성되는 드롭다운 메뉴에서 API 키가 액세스할 수 있는 프로젝트의 전체 목록을 볼 수 있습니다.

오늘 시연을 위해 우리는 Oncrawl 웹사이트를 기반으로 하는 데모 프로젝트를 사용하고 있습니다.

3. 작업하려는 프로젝트 내에서 크롤링 프로필을 선택하는 드롭다운 목록을 만듭니다.
다음으로 사용할 크롤링 프로필을 결정합니다. 이 프로젝트 내에서 크롤링 프로필을 선택하려고 합니다. 데모 프로젝트에는 다양한 크롤링 구성이 있습니다.

이 경우 Oncrawl 팀이 실험에 자주 사용하는 프로젝트를 살펴보고 있으므로 마케팅 팀에서 Oncrawl 웹 사이트의 성능을 모니터링하는 데 사용하는 크롤링 프로필을 선택하겠습니다. 이것은 가장 안정적인 크롤링 프로필이어야 하므로 오늘날 실험에 적합한 선택입니다.

크롤링 프로필을 가져오기 위해 Oncrawl API를 사용하여 프로젝트의 모든 단일 크롤링 프로필 내에서 마지막 크롤링을 요청합니다.

주어진 프로젝트에 대해 Oncrawl API를 쿼리할 준비를 합니다.
"만든 날짜"에 따라 내림차순으로 반환된 모든 크롤링을 요청합니다.

 가져오기 요청
json 가져오기
ipywidget을 위젯으로 가져오기
 
project_id = dropdown_purpose.value
 
# 프로젝트 세부 정보 가져오기(프로젝트의 모든 크롤링 포함)
프로젝트 = requests.get("https://app.oncrawl.com/api/v2/projects/{}".format(project_id),
                      params=dict(include_nested_resources=True, sort="created_at:desc"),
                      headers={ '승인': '베어러 '+ONCRAWL_TOKEN }).json()
 
# 크롤링 프로필(크롤링 이름)별로 그룹 크롤링
crawls_by_config = {}
노력하다:
 프로젝트['crawls']의 크롤링:
 
   크롤링['상태']이 ["완료"]인 경우:
 
     크롤링['crawl_config']['이름']이 crawls_by_config.keys()에 없는 경우:
       crawls_by_config[crawl['crawl_config']['이름']] = {'crawl_ids' : [], 'is_crawl_archived' : False}
 
     len(crawls_by_config[crawl['crawl_config']['이름']]['crawl_ids']) == 0인 경우:
       crawls_by_config[crawl['crawl_config']['이름']]['crawl_ids'].append(크롤링['id'])
 
     크롤링['상태'] == "보관됨"인 경우:
       crawls_by_config[crawl['crawl_config']['이름']]['is_crawl_archived'] = True
 
예외를 제외하고 e:
 예외 발생("오류 {}, {}".format(e, 프로젝트))
 
# 드롭다운 선택을 위한 목록 작성
목록 = [("{} ({})".format(k, len(v['crawl_ids'])), k) for k, v in crawls_by_config.items()]
 
dropdown_crawl_configs = widgets.Dropdown(옵션 = 목록, 설명="구성 크롤링: ")
 
def dropdown_cc_eventhandler(변경):
   output.clear_output()   
   출력:
       디스플레이(crawls_by_config)
 
len(crawls_by_config.values()) == 0인 경우:
 print('이 프로젝트에서 라이브 크롤링을 찾을 수 없습니다')
 dropdown_crawl_configs.observe(dropdown_cc_eventhandler, 이름='값')
 
디스플레이(dropdown_crawl_configs)

이 코드가 실행되면 Oncrawl API는 "created at" 속성을 내림차순으로 크롤링 목록으로 응답합니다.

그런 다음 완료된 크롤링에만 집중하기 때문에 크롤링 목록을 살펴보겠습니다. 상태가 "완료"인 모든 단일 크롤링에 대해 크롤링 프로필의 이름을 저장하고 크롤링 ID를 저장합니다.

너무 많은 크롤링을 노출하지 않도록 크롤링 프로필별로 최대 하나의 크롤링을 유지합니다.

결과는 프로젝트의 크롤링 프로필 목록에서 생성된 이 새로운 드롭다운 메뉴입니다. 우리는 우리가 원하는 것을 선택할 것입니다. 마케팅 팀에서 실행한 마지막 크롤링이 수행됩니다.

4. 사용하려는 프로필로 마지막 크롤링 식별
선택한 프로필의 마지막 크롤링과 연결된 크롤링 ID가 이미 있습니다. "crawl_by_config" 개체 사전에 숨겨져 있습니다.

인터페이스에서 이를 쉽게 확인할 수 있습니다. 이 프로필 분석에서 마지막으로 완료된 크롤링을 찾습니다.

분석을 보기 위해 클릭하면 크롤링 ID가 E617로 끝나는 것을 볼 수 있습니다.

오늘 데모를 위해 크롤링 ID를 기록해 두겠습니다.

물론 수행 중인 작업을 이미 알고 있는 경우 프로젝트 목록과 크롤링 프로필별 크롤링 목록을 가져오기 위해 Oncrawl API를 호출하는 단계를 건너뛸 수 있습니다. 인터페이스이며 이 ID만 있으면 내보내기를 실행하는 데 필요한 모든 것입니다.

지금까지 실행한 단계는 API 키가 액세스할 수 있는 항목이 주어지면 주어진 프로젝트의 지정된 크롤링 프로필의 마지막 크롤링을 얻는 프로세스를 쉽게 하기 위한 것입니다. 이 솔루션을 다른 사용자에게 제공하거나 자동화하려는 경우 유용할 수 있습니다.

5. 크롤링 결과 내보내기
이제 내보내기 명령을 살펴보겠습니다.

 #@title 빅데이터 내보내기 트리거
#@markdown GCS 버킷 및 접두사 gs://some-bucket/pages 제공
 
# GCS 버킷
gcs_bucket = #@param {유형:"문자열"}
gcs_prefix = #@param {유형:"문자열"}
 
 
# 주어진 프로젝트/크롤링 프로필에서 마지막 크롤링 ID를 가져옵니다.
list_crawl_ids = crawls_by_config[dropdown_crawl_configs.value]['crawl_ids']
last_crawl_id = list_crawl_ids[0]
 
# 데이터 내보내기 쿼리를 위한 템플릿 페이로드
페이로드 = {
   "data_export": {
   "data_type": '페이지',
   "resource_id": last_crawl_id,
   "출력 형식": '마루',
   "대상": 'gcs',
   "target_parameters": {
       "gcs_bucket": gcs_bucket,
       "gcs_prefix": gcs_prefix
   }
 }
}
 
# 내보내기 트리거
export = requests.post("https://app.oncrawl.com/api/v2/account/data_exports", json=payload, headers={ '승인': 'Bearer '+ONCRAWL_TOKEN }).json()
 
# API 응답 표시
디스플레이(수출)
 
# 향후 사용을 위해 내보내기 ID 저장
export_id = 내보내기['data_export']['id']

이전에 설정한 Cloud Storage 버킷으로 내보내려고 합니다.

그 안에서 마지막 크롤링 ID에 대한 페이지를 내보낼 것입니다.

마지막 크롤링 ID는 3단계에서 생성된 "crawls_by_config" 사전 어딘가에 저장된 크롤링 ID 목록에서 가져옵니다.
4단계의 드롭다운 메뉴에 해당하는 항목을 선택하고 싶으므로 드롭다운 메뉴의 값 속성을 사용합니다.
그런 다음, crawl_ID 속성을 추출합니다. 이것은 목록입니다. 목록의 상위 50개 항목을 유지합니다. 이 작업을 수행해야 하는 이유는 2단계에서 기억하듯이 crawls_by_config 사전을 만들 때 구성 이름당 하나의 크롤링 ID만 저장했기 때문입니다.

내보내기를 보낼 Google Cloud Storage 버킷과 접두사 또는 폴더를 쉽게 제공할 수 있도록 입력 필드를 설정했습니다.

데모를 위해 오늘은 이미 설정한 폴더 중 하나에 있는 "mixed dataset" 폴더에 쓸 것입니다. Google Cloud Storage에서 버킷을 설정할 때 '링크' 내보내기 및 '페이지' 내보내기용 폴더를 준비했음을 기억할 것입니다.

첫 번째 내보내기의 경우 Parquet 파일 형식을 사용하여 마지막 크롤링 ID의 "페이지" 폴더로 페이지를 내보내려고 합니다.

아래 결과에서 API 키를 사용하여 빅 데이터 내보내기를 요청하는 엔드포인트인 데이터 내보내기 엔드포인트로 전송될 페이로드를 볼 수 있습니다.

 # 데이터 내보내기 쿼리를 위한 템플릿 페이로드
페이로드 = {
   "data_export": {
   "data_type": '페이지',
   "resource_id": last_crawl_id,
   "출력 형식": '마루',
   "대상": 'gcs',
   "target_parameters": {
       "gcs_bucket": gcs_bucket,
       "gcs_prefix": gcs_prefix
   }
 }
}

여기에는 내보내려는 데이터 세트 유형을 비롯한 여러 요소가 포함됩니다. 페이지 데이터 세트, 링크 데이터 세트, 클러스터 데이터 세트 또는 구조화된 데이터 데이터 세트를 내보낼 수 있습니다. 무엇을 할 수 있는지 모르는 경우 여기에 오류를 입력할 수 있으며 API를 호출할 때 데이터 유형에 대한 선택은 페이지, 링크 또는 클러스터 또는 구조화된 데이터여야 한다는 메시지를 받게 됩니다. 메시지는 다음과 같습니다.

 {'fields': [{'message': '올바른 선택이 아닙니다. "페이지", "링크", "클러스터", "구조화된_데이터" 중 하나여야 합니다.',
	'이름': '데이터 유형',
	'유형': 'invalid_choice'}],
'유형': 'invalid_request_parameters'}

오늘 실험의 목적을 위해 페이지 데이터 세트와 링크 데이터 세트를 분리된 내보내기로 내보낼 것입니다.

페이지 데이터세트부터 시작하겠습니다. 이 코드 블록을 실행할 때 다음과 같은 API 호출의 출력을 인쇄했습니다.

 {'data_export': {'data_type': '페이지',
	'export_failure_reason': 없음,
	'아이디': 'XXXXXXXXXXXXXX',
	'출력 형식': '마루',
	'출력 형식_매개변수': 없음,
	'output_row_count': 없음,
	'출력_크기_인_바이트: 1634460016000,
	'resource_id': '60dd4c2b34d08a0f10a5e617',
	'상태': '요청됨',
	'대상': 'gcs',
	'대상_매개변수': {'gcs_bucket': '데이터 cms',
		'gcs_prefix': 'MIXDATASETS/페이지/'}}}

이렇게 하면 내보내기가 요청되었음을 확인할 수 있습니다.

내보내기 상태를 확인하려는 경우 매우 간단합니다. 이 코드 블록의 끝에서 저장한 내보내기 ID를 사용하여 다음 API 호출로 언제든지 내보내기 상태를 요청할 수 있습니다.

 # 수출현황
export_status = requests.get("https://app.oncrawl.com/api/v2/account/data_exports/{}".format(export_id), headers={ '승인': '베어러 '+ONCRAWL_TOKEN }).json ()

디스플레이(export_status)

이것은 반환된 JSON 객체의 일부로 상태를 나타냅니다.

 {'data_export': {'data_type': '페이지',
'export_failure_reason': 없음,
'아이디': 'XXXXXXXXXXXXXX',
'출력 형식': '마루',
'출력 형식_매개변수': 없음,
'output_row_count': 없음,
'output_size_in_bytes': 없음,
'요청된_at': 1638350549000,
'resource_id': '60dd4c2b34d08a0f10a5e617',
'상태': '내보내는 중',
'대상': 'gcs',
'대상_매개변수': {'gcs_bucket': '데이터-csm',
'gcs_prefix': 'MIXDATASETS/페이지/'}}}

내보내기가 완료되면( 'status': 'DONE' ) Google Cloud Storage로 돌아갈 수 있습니다.

버킷을 살펴보고 "링크" 폴더로 이동하면 페이지를 내보냈기 때문에 여기에는 아직 아무것도 없습니다.

그러나 "pages" 폴더를 보면 내보내기가 성공했음을 알 수 있습니다. Parquet 파일이 있습니다.

이 단계에서 페이지 데이터세트는 BigQuery에서 가져올 준비가 되었지만 먼저 위의 단계를 반복하여 링크에 대한 Parquet 파일을 얻습니다.

링크 접두사를 설정해야 합니다.
"링크" 데이터 유형을 선택합니다.
이 코드 블록을 다시 실행하여 두 번째 내보내기를 요청하십시오.

그러면 "links" 폴더에 Parquet 파일이 생성됩니다.

BigQuery 데이터세트 만들기

내보내기가 실행되는 동안 BigQuery에서 데이터세트 생성을 시작하고 Parquet 파일을 별도의 테이블로 가져올 수 있습니다. 그런 다음 테이블을 함께 결합합니다.

지금 우리가 하고자 하는 것은 Google Cloud Platform의 일부로 제공되는 Google Big Query를 사용하는 것입니다. 화면 상단의 검색창을 사용하거나 https://console.cloud.google.com/bigquery로 직접 이동할 수 있습니다.

작업용 데이터세트 만들기

Google BigQuery 내에서 데이터세트를 생성해야 합니다.

데이터 세트에 이름을 제공하고 데이터가 저장될 위치를 선택해야 합니다. 이는 데이터가 처리되는 위치를 결정하고 변경할 수 없기 때문에 중요합니다. 데이터에 GDPR 또는 기타 개인정보 보호법이 적용되는 정보가 포함된 경우 영향을 미칠 수 있습니다.

이 데이터세트는 처음에 비어 있습니다. 열면 테이블 생성, 데이터 세트 공유, 복사, 삭제 등을 할 수 있습니다.

데이터용 테이블 생성

이 데이터세트에 테이블을 생성하겠습니다.

빈 테이블을 생성한 다음 스키마를 제공할 수 있습니다. 스키마는 테이블의 열 정의입니다. 직접 정의하거나 Google Cloud Storage를 탐색하여 파일에서 스키마를 선택할 수 있습니다.

우리는 이 마지막 옵션을 사용할 것입니다. 버킷으로 이동한 다음 "페이지" 폴더로 이동합니다. 페이지 파일을 선택합시다. 파일이 하나뿐이므로 하나만 선택할 수 있지만 내보내기에서 여러 파일을 생성했다면 모두 선택할 수 있었습니다.

파일을 선택하면 자동으로 Parquet 파일 형식임을 감지합니다. "pages"라는 테이블을 만들고 싶고 스키마는 소스 파일에 의해 정의됩니다.

Parquet 파일을 로드하면 스키마가 포함됩니다. 즉, 생성 중인 테이블의 열 정의는 Parquet 파일 내에 이미 존재하는 스키마에서 유추됩니다. 이것은 실제로 마술의 일부가 일어나는 곳입니다.

앞으로 나아가 Parquet 파일에서 테이블을 생성해 보겠습니다.

왼쪽 사이드바에서 데이터 세트 내에 테이블이 나타난 것을 볼 수 있습니다. 이는 정확히 우리가 원하는 것입니다.

따라서 이제 Parquet 파일에서 자동으로 유추된 모든 필드가 있는 페이지 테이블의 스키마가 있습니다. 페이지가 리디렉션 등인 경우 페이지의 깊이인 Inrank가 있습니다.

이러한 필드의 대부분은 Oncrawl Data Studio 커넥터를 통해 Data Studio 내에서 사용할 수 있는 필드와 동일하며 Oncrawl 인터페이스의 데이터 탐색기에 표시되는 필드와 동일합니다.

그러나 몇 가지 차이점이 있습니다. 원시 빅 데이터 내보내기를 사용하면 모든 원시 데이터가 있습니다.

데이터 스튜디오에서 일부 필드의 이름이 바뀌고 일부 필드가 숨겨지며 상태와 같은 일부 필드가 추가됩니다.
데이터 탐색기에서 일부 필드는 "가상 필드"라고 하며, 이는 기본 필드에 대한 일종의 지름길일 수 있음을 의미합니다. 데이터 탐색기에서 사용할 수 있는 이러한 가상 필드는 스키마에 나열되지 않지만 Parquet 파일에서 사용할 수 있는 항목을 기반으로 다시 만들 수 있습니다.

이제 이 테이블을 닫고 링크에 대해 다시 수행해 보겠습니다.

링크 테이블의 경우 스키마가 약간 더 작습니다.

다음 필드만 포함합니다.

링크의 출처,
링크의 대상,
다음 속성,
내부 속성,
대상 상태,
대상 상태의 범위,
앵커 텍스트 및
링크에서 구매한 주스 또는 자산.

BigQuery의 모든 테이블에서 미리보기 탭을 클릭하면 데이터베이스를 쿼리하지 않고도 테이블을 미리 볼 수 있습니다.

이를 통해 사용 가능한 항목을 빠르게 볼 수 있습니다. 위의 링크 표에 대한 미리보기에서 모든 단일 행과 모든 열을 미리 볼 수 있습니다.

일부 Oncrawl 데이터 세트에서는 여러 행에 걸쳐 있는 일부 행을 볼 수 있습니다. 예시가 없지만 이 경우 일부 필드에 값 목록이 포함되어 있기 때문입니다. 예를 들어 페이지의 h2 제목 목록에서 단일 행은 Big Query의 여러 행에 걸쳐 있습니다. 나중에 예를 보면 알아보겠습니다.

쿼리 만들기

BigQuery에서 쿼리를 만든 적이 없다면 이제 쿼리를 사용하여 작동 방식에 익숙해질 시간입니다. BigQuery는 SQL을 사용하여 데이터를 조회합니다.

쿼리 작동 방식

예를 들어 모든 URL과 해당 순위를 살펴보겠습니다.

 SELECT url, inrank ...

페이지 데이터셋에서…

 SELECT url, inrank FROM `datascience-oncrawl.example_bigdata_exports.pages` ...

페이지의 상태 코드는 200…

 SELECT url, inrank FROM `datascience-oncrawl.example_bigdata_exports.pages` WHERE status_code = 200
...

처음 10개의 결과만 유지합니다.

 SELECT url, inrank FROM `datascience-oncrawl.example_bigdata_exports.pages` WHERE status_code = 200 LIMIT 10

이 쿼리를 실행하면 상태 코드가 200인 페이지 목록의 처음 10개 행을 가져옵니다.

이러한 속성은 수정할 수 있습니다. f 10개 대신 1000개 행을 원하고 1000개 행을 설정할 수 있습니다.

 SELECT URL, inrank FROM `datascience-oncrawl.example_bigdata_exports.pages` WHERE status_code = 200 LIMIT 1000

정렬을 원하면 "order-by"로 할 수 있습니다. 이렇게 하면 내림차순으로 정렬된 모든 행이 제공됩니다.

 SELECT URL, inrank FROM `datascience-oncrawl.example_bigdata_exports.links` ORDER BY inrank DESC LIMIT 1000

이것은 내 첫 번째 쿼리입니다. 원하는 경우 저장할 수 있습니다. 그러면 나중에 원할 경우 이 쿼리를 재사용할 수 있습니다.

쿼리를 사용하여 간단한 질문에 답하기: 301 상태의 페이지에 대한 모든 내부 링크 나열

이제 쿼리를 작성하는 방법을 알았으므로 원래 문제로 돌아가 보겠습니다.

우리는 단순하든 복잡하든 데이터 질문에 답하고 싶었습니다. "301(리디렉션) 상태의 페이지를 가리키는 모든 내부 링크는 무엇이며 어디에서 찾을 수 있습니까?"와 같은 간단한 질문부터 시작하겠습니다.

새 쿼리 만들기

이것이 어떻게 작동하는지 살펴보는 것으로 시작하겠습니다.

"링크" 데이터베이스에서 다음 요소에 대한 열을 원합니다.

기원
표적
대상 상태 코드

 SELECT origin, target, target_status FROM `datascience-oncrawl.example_bigdata_exports.links`

이를 내부 링크로만 제한하고 싶지만 열 이름이나 링크가 내부 또는 외부인지 여부를 나타내는 값이 기억나지 않는다고 가정해 보겠습니다. 스키마로 이동하여 조회하고 미리보기를 사용하여 값을 볼 수 있습니다.

이것은 열 이름이 "intern"이고 가능한 값 범위가 "external" 또는 "internal"임을 알려줍니다.

내 쿼리에서 "인턴이 내부인 위치"를 지정하고 현재로서는 결과를 처음 100개로 제한하고 싶습니다.

 SELECT origin, target, target_status FROM `datascience-oncrawl.example_bigdata_exports.links` WHERE intern LIKE 'internal' LIMIT 100

위의 결과는 대상 상태와 함께 링크 목록을 보여줍니다. 내부 링크만 있고 쿼리에 지정된 대로 100개가 있습니다.

리디렉션된 페이지에 대한 해당 지점에 대한 내부 링크만 갖고 싶다면 'intern like internal 및 target status is 301'이라고 말할 수 있습니다.

 SELECT origin, target, target_status FROM `datascience-oncrawl.example_bigdata_exports.links` WHERE intern LIKE 'internal' AND target_status = 301

존재하는 링크의 수를 모르는 경우 이 새 쿼리를 실행할 수 있으며 대상 상태가 301인 내부 링크가 3002개 있음을 알 수 있습니다.

테이블 조인: 리디렉션된 페이지를 가리키는 링크의 최종 상태 코드 찾기

웹 사이트에는 리디렉션되는 페이지에 대한 링크가 있는 경우가 많습니다. 리디렉션되는 페이지(또는 최종 대상 URL)의 상태 코드를 알고 싶습니다.

한 데이터세트에는 링크에 대한 정보가 있습니다. 원본 페이지, 대상 페이지 및 상태 코드(예: 301)는 리디렉션된 페이지가 가리키는 URL이 아닙니다. 그리고 다른 하나에는 리디렉션과 최종 타겟에 대한 정보가 있지만 링크가 있는 원본 페이지는 없습니다.

이것을 분해해보자:

먼저 리디렉션에 대한 링크가 필요합니다. 이것을 적어 봅시다. 우리는 다음을 원합니다:

원산지.
목표. 대상에는 301 상태 코드가 있어야 합니다.
리디렉션의 최종 대상입니다.

즉, 링크 데이터 세트에서 다음을 원합니다.

링크의 기원
링크의 대상

페이지 데이터 세트에서 다음을 원합니다.

리디렉션되는 모든 대상
리디렉션의 최종 대상

이것은 우리에게 다음과 같은 쿼리를 줄 것입니다:

 URL 선택, final_redirect_location, final_redirect_status FROM `datascience-oncrawl.example_bigdata_exports.pages` AS 페이지 WHERE status_code = 301 OR status_code = 302

이것은 나에게 방정식의 첫 번째 부분을 제공해야 합니다.

이제 방금 생성한 쿼리의 결과인 페이지로 연결되는 모든 링크가 필요하며, 내 데이터세트에 대한 별칭을 사용하고 링크 대상 URL과 페이지 URL에서 이들을 결합해야 합니다. 이것은 이 섹션의 시작 부분에 있는 다이어그램에서 두 데이터 세트의 겹치는 영역에 해당합니다.

 고르다
link.origin,
페이지.URL,
page.final_redirect_location,
page.final_redirect_status
에서
`datascience-oncrawl.example_bigdata_exports.pages` AS 페이지
가입하다
`datascience-oncrawl.example_bigdata_exports.links` AS 링크
켜짐
link.target = page.url
어디
page.status_code = 301
또는 page.status_code = 302
주문
원점 ASC

쿼리 결과에서 열 이름을 더 명확하게 할 수 있지만 이미 첫 번째 열의 페이지에서 두 번째 열의 페이지로 연결되는 링크가 있다는 것을 알 수 있습니다. 이 링크는 다시 다음으로 리디렉션됩니다. 세 번째 열의 페이지입니다. 네 번째 열에는 최종 대상의 상태 코드가 있습니다.

이제 200페이지로 해결되지 않는 리디렉션된 페이지를 가리키는 링크를 알 수 있습니다. 예를 들어 수정해야 할 링크의 우선 순위 목록을 제공하는 404일 수도 있습니다.

이전에 쿼리를 저장하는 방법을 보았습니다. 최대 16000줄의 결과에 대해 결과를 저장할 수도 있습니다.

그런 다음 이 결과를 다양한 방식으로 사용할 수 있습니다. 다음은 몇 가지 예입니다.

이것을 CSV 또는 JSON 파일로 로컬에 저장할 수 있습니다.
Google 스프레드시트로 저장하고 나머지 팀과 공유할 수 있습니다.
데이터 스튜디오로 직접 내보낼 수도 있습니다.

전략적 이점으로서의 데이터

이러한 모든 가능성을 통해 복잡한 질문에 대한 답변을 전략적으로 쉽게 사용할 수 있습니다. BigQuery 결과를 데이터 스튜디오 또는 기타 데이터 시각화 플랫폼에 연결한 경험이 있거나 정보를 엔지니어링 팀이나 비즈니스 인텔리전스 또는 데이터 분석 워크플로로 푸시하는 프로세스가 이미 있을 수 있습니다.

이 문서의 단계를 프로세스의 일부로 포함했다면 BigQuery의 모든 단계를 자동화할 수 있습니다. 이 문서에서 수행한 모든 작업은 BigQuery API를 통해서도 액세스할 수 있습니다. 즉, 스크립트 또는 사용자 지정 도구의 일부로 프로그래밍 방식으로 실행할 수 있습니다.

다음 단계가 무엇이든 첫 번째 단계는 항상 원시 SEO 및 웹사이트 데이터에 액세스하는 것입니다. 데이터에 대한 이러한 액세스는 기술 분석의 가장 중요한 부분 중 하나라고 믿습니다. Oncrawl을 사용하면 항상 원시 데이터에 대한 전체 액세스 권한을 가질 수 있습니다.

데이터에 대한 액세스는 또한 Oncrawl 인터페이스에서 가능한 것 이상으로 질문하는 것이 아무리 복잡하더라도 데이터 간의 모든 관계를 탐색할 수 있음을 의미합니다.