데이터 후처리(?)를 위한 scripted field

Share
데이터 후처리(?)를 위한 scripted field

키바나 기능 중에 'scripted field'라는 게 있다. 무엇에 쓰는 물건인가 싶어 찾아보니 '중요한 값을 스키마에서 별도 필드로 정의하지 못하였거나 또는 두 개 필드를 결합하여 단일 필드로 처리하고자 하는 경우'에 유용한 기능이라고.

1
Management > Index Patterns > scripted filelds

로그스태시 연동할 때 깜박하고 로그 필드 정의 빼먹었다가 처음부터 다시 하는 불상사를 막을 수 있다는 얘기. 로그스태시 연동 중 필터 과정이 데이터 전처리라면, scripted field는 데이터 후처리라고 할 수 있다 다음은 웹로그 중 요청 메소드와 응답코드 발생 현황. 두 필드를 합치고 싶다면?

2

다음은 scripted filed 생성 과정. 이름 주고, 데이터 타입 정하고, 스크립트 작성하면 끝.

3

지정된 필드값을 가져오는 'doc['필드명'].value'가 기본 구문인데, 사칙연산을 포함해서 다양한 데이터 가공이 가능하다.

4

참고로 scripted field를 만들 때 사용하는 스크립트 언어 이름이 'painless(고통 없음?)'. 그만큼 쉽다는 뜻이겠지. 백인들 작명 센스는 참 자유분방한 듯. 중딩 때 록 밴드 'Michael learns to rock'의 이름을 처음 듣고, 마이클이 록을 배워? 이놈들 이름 막 짓는구나 싶어 신기했었는데(..) 노래는 좋다. 한적한 도로 달릴 때 frostbite 추천.

글이 산으로 가네 다음은 scripted field 기능을 이용해서 요청 메소드와 응답코드 필드를 합친 'method - status' 필드 조회 결과.

5

다음처럼 통계 분석도 할 수 있고, 위에 링크 걸린 사이트 가보면 알 수 있지만 꽤 다양한 데이터 가공이 가능하다.

6

이번엔 검색 테스트. '메서드-응답코드'가 매칭된 scripted field에서 get 메소드와 매칭된 200 응답코드를 검색해봤다. 응? 못찾네?

8

scripted field는 불러오는 시점에 데이터를 가공해서 보여주는 형식. 엘라스틱서치에 저장된 데이터가 아니라는 얘기. 없는 데이터를 검색하니 못찾는 게 당연한 건가?

다른 scripted field를 만들어 보자. 다음은 URI 변수 데이터를 필드 추출에서 멈추지 않고, Logstash 필터 ruby를 이용해서 데이터 길이까지 측정한 결과. asp 파일별 변수 길이의 변화 추적이 가능해진다. (변수 길이가 급증한 이유는 무엇일까?)

9

그런데 데이터 전처리 과정에서 필터 사용을 깜박하거나, 처음엔 데이터 길이 측정의 필요성을 느끼지 못하다가, 분석 과정에서 필요해졌다면? 그럴 땐 별 수 없이 지겨운 데이터 전처리 과정을 다시 진행해야 한다. 이럴 때 scripted field가 도움이 될까?

10

다음은 'var.keyword' 필드에 저장된 문자열 데이터의 길이를 잰 후, 숫자로 저장한 scripted field 생성 결과. 전처리 과정에서 생성한 var_len 필드와 후처리 과정에서 생성한 var_len2 필드가 같은 값을 보여준다.

11

이제 var_len2 필드로 asp 파일별 변수 길이의 변화 추이를 살펴볼 수 있는 시계열 그래프를 그려보자. 그런데 안 됨.

12

에러 메시지가 뜨지만 뭔소린지 모르겠다. 이것도 엘라스틱서치에 저장되지 않은 데이터라서 발생하는 문제인가? 'method-status' 필드의 시계열 그래프는 잘 그렸는데, 얘는 왜 못그리지? 차이가 있다면 'method-status' 필드는 문자형, 'var_len2' 필드는 숫자형 데이터라는 건데, scripted field는 숫자형 데이터의 aggregation을 지원하지 않나? 날도 더운데 괜히 시작했다 싶다.-_-

scripted field는 실시간으로 데이터를 가공해서 보여주는 기능이라 그런지, 활용에 제약이 좀 있는 듯하다. 데이터 후처리 가능한 기능이라고 좋아했는데(..) 흥, 그냥 데이터 전처리 잘 하면 되지 뭐. 말은 이렇게 했지만 아시는 분 조언 좀

Read more

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로 TypeSafe AI가 2026년 9월 15일에 Jev를 내놨습니다. 텍스트를 쓰지 않고 타입이 정해진 판정과 확률을 바로 내는 모델입니다. 유추카 검색에서 가장 느린 단계가 마침 텍스트가 필요 없는 판정이었습니다. 그 구간만 Jev로 갈아끼우고 일주일간 측정했습니다. 콜드

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

스위스 아미 나이프. 도구가 몇 개인지는 보면 알지만, 지금 어느 도구를 펴야 하는지는 안 적혀 있습니다. 요즘 AI 활용법을 다루는 글은 스킬 만드는 법부터 가르칩니다. 얼마 전까지는 MCP였고요. 저희 기록을 열어봤습니다. 석 달 동안 스킬 60회, 서브에이전트 42회, 브라우저 자동화 988회를 썼습니다. 안 쓴 게 아닙니다. 다만 붙인 MCP 서버는

By 김형준