강 명훈(mhkang)http://kangmyounghun.blogspot.com

하나의 로그스태시 파이프라인에서 서로 다른 데이터를 수집, 서로 다른 인덱스에 저장하는 구성에 대한 질문을 받았다. 방법은 input 구간에서 출처별로 수집 플러그인을 분리한 후, output 구간에서 조건에 따라 저장명을 달리하는 것. 데이터 전처리를 잘 하면 분석이 쉬워진다가 강의 주제인지라 filter 구간 활용에 집중한다. 자연스럽게 input이나 output 멀티 구성에 대한 필요성을 느낀 적이 없음. 개인의 경험은 한계가 있다. 그래서 타인의 경험이 공유될 때 강의가 재밌어진다. 당연히 질문에 대한 답을 처음부터 알지 못했다. 하지만 답을 찾는 게 어렵진 않았다. 모르면 물어보면 되니까....

로그스태시는 에러 발생 시 상당히 고약한 트러블슈팅 환경을 제공한다. 물론 원인 파악이 쉬울 때도 있음. remove_field 오타 발생. 에러 원인을 정확히 찝어준다. 문제는 안 그럴 때가 많다는 거. ssl_certificate_authorities 오타 발생. 남다른 가독성을 뽐내는 한 줄 에러 메시지. [caption id="attachment_29442" align="aligncenter" width="600"] 엔터 좀 치라고[/caption] 엔터 좀 쳐주면 낫지 않을까? 저 상황에서도 읽기 좋으라고 사용된 문장 기호 중 쉼표를 줄바꿈 문자로 치환. 몇 번째 라인(항상 정확하진 않음), 어느 지점에 문제가 있는지 보이기 시작한다. 적당한 엔터 삽입만으로도 정보 처리 수준이 달라진다. 정보가 잘 보이지 않던 구조를 잘 보이는 구조로 바꾸는 데이터 시각화 사례. [caption id="attachment_29446" align="aligncenter" width="600"]...

로그스태시를 이용한 데이터 연동 시 문자열 데이터는 형태소 단위로 인덱싱하는 text 타입과 집계 정렬 목적으로 인덱싱을 하지 않는 keyword 타입, 2개의 필드에 저장된다. 이때 keyword 타입 필드는 ignore_above 값 (기본값은 256) 보다 길이가 긴 데이터를 저장하지 않는다고 한다. 실제 text와 keyword 필드를 비교해보니 저장 결과가 다른 상황 발생. ­ ignore_above 수정. 재인덱싱 후 다시 비교해봤다. 필드 유실 없음. ­ agent 길이를 재보니 ignore_above 수정 전 유실된 데이터 개수와 256보다 길이가 긴 데이터 개수가 같다....

두 명의 심리학자 헨리 뢰디거, 마크 맥다니얼과 작가 피터 브라운이 같이 쓴 2014년작. 공부를 잘하고 싶다면? 주기적으로 복습 하면 그 주제를 더 잘 기억할 수 있다 - 5페이지 머릿말에서 비법 예습, 복습 철저 을 다 알려주는 책. 결국 알고만 있어서는 소용 없고 실천이 중요하다 (..) [목차] 1. 우리는 잘못된 방식으로 배우고 있다 2. 배우려면 먼저 인출하라 3. 뒤섞어서 연습하라 4. 어렵게 배워야 오래 남는다 5. 안다는 착각에서 벗어나라 6. 학습 유형이라는 신화...

검색엔진은 잘 모르지만 엘라스틱을 데이터 분석툴로 사용할 때 데이터 전처리가 차지하는 비중은 생각보다 크다. [caption id="attachment_29096" align="aligncenter" width="600"] youtube [/caption] 그렇다 보니 자연스럽게 로그스태시 필터 기능을 소개하는 데 많은 시간을 할애한다. 그때 종종 받는 (툴을 잘 쓰면 데이터 분석이 쉬워질거라는 기대가 담긴) 질문. 저 기능들을 언제 다 익혔나요? 그러게? 난 언제 저 기능들을 익혔지? 사실은 익힌 적이 없다. 엘라스틱을 만나기 전부터 이미 사용해왔으니까. 도끼 쓰다가 전기톱으로 바꾼다고 나무 잘리는 원리가 달라질 리 없는 것과 마찬가지....

빅데이터가 대세 키워드였던 몇 년 전까지만 해도 하둡 등의 인프라가 모든 것을 해결해줄 듯한 분위기였다면, 알파고 이후엔 수학 및 통계학, 그리고 그런 지식에 기반한 모델링 능력이 필수 자질로 꼽히는 세상이 되었다. 광고, 추천, 번역, 금융 등 많은 분야에서 그런 자질을 요구한다. 열거한 분야들의 공통점은 최종 목적이 결국 돈이라는 것. 돈을 벌기 위해서는 사람의 심리나 행동을 예측해야 한다. 절대 쉽지 않은 작업. 아마 작두 타는 수준의 분석 능력이 필요할 것이다. 복잡한 수학/통계 지식의 필요성에 수긍이 가는 대목....

5일 중 3일을 정규표현식에 할애한 과정을 진행하다가 아차 (?) 싶었던 첫 강의가 생각난다. 그렇게 정규표현식 비중을 줄이고 줄여서 현재 정규표현식 과정은 반나절 정도 (..) 그럼에도 빠지지 않는 질문이 쉬운 정규표현식? 대체 방법? 정규표현식이 쉬워지는 방법은 많이 써보는 수밖에 없다 보니 정규표현식을 사용하지 않고 원하는 테이블 구조를 만드는 방법에 대한 고민을 자주 한다. 일단 엘라스틱 예제 데이터 생성. url 데이터에서 file 정보를 추출해보자. 다음은 읽기 스키마 기반의 런타임 필드 생성 쿼리....

다음은 root 사용자의 IP별 접속 현황. 5월 14~16일 및 6월 12일의 IP 변화가 눈에 띈다. 그런데 사용자가 많다면 사용자별 접속 IP의 변화 확인이 꽤 까다로울 것이다. 더 직관적인, 한 눈에 IP 변화를 알아차릴 수 있는 차트를 그릴 수는 없을까? 다음은 root 사용자의 IP 고유 개수 변화. 6월 12일의 변화는 뚜렷한데, 5월 14~16일의 변화는 보이지 않는다. 해당 시점의 접속 IP가 평소와 다른 건 맞지만 유형은 하나뿐이니 당연한 결과. IP 변화를 숫자 변화로 이상징후 분석은 통계 분석의 다른 말이고, 결국 특정 상태의 숫자 변화를 추적하는 과정. 마침 IP는 숫자로도 표현할 수 있다. 8bit 단위로 나눈 IP를 순서대로 256...

엘라스틱이 sql을 지원하기 시작한지 꽤 됐는데 조인은 아직이다. 그런데 아마존이 배포하는 opendistro 는 조인을 지원한다. 물론 아직 조인 내부적으로 집계도 안 되고, 서브 쿼리도 안 먹고 등등 많이 부족함. [caption id="attachment_28234" align="aligncenter" width="600"] 중복 제거 좀..[/caption] 하지만 외부 조인까지 지원하는 걸 보면, 빠르게 기능 개선이 이루어지지 않을까 싶다. 아마존이 이렇게 발 빠르게 움직인다면 엘라스틱도 가만 있지 않겠지? 그나저나 엘라스틱이 아마존을 겨냥한 라이센스를 발표하고, 아마존은 직접 엘라스틱을 배포하면서 서로 완전히 등을 돌린 모양새던데, 둘의 대립이 어떻게 결론 날지 궁금하다....

단순 카운트 변화 추이는 로그의 상태를 정확히 표현하지 못한다. 다양한 상태 정보가 섞여 있는 상태에서 개수의 변화가 어떤 상태를 특정하는지 알기 힘들다는 얘기. count 추이(12~25일) 그래서 강조하는 게 상태별 고유성 확보를 통한 데이터 해상도 변경 및 다양한 Metric 활용. 카운트 추이로는 알 수 없었던 19일의 상태 변화가 해상도 및 Metric 변경을 통해 드러난다. URL 고유 개수 백분위 90% 의 변수 길이 이런 결과를 얻기 위해 데이터를 분류하고, 고유성을 확보하고, 효과적인 지표를 개발하는 데 많은 시간을 투자한다. 그러나 그런 노력을 들이고도 정작 쌓인 데이터를 분석하지 않는다면 모든 노력은 물거품이 되고 만다. 반면 정말 단순하게 로그 개수만 센다 해도 매일, 매 시간, 매 분 데이터의 변화를 궁금해한다면 그 데이터에서 의미를 찾아낼 수 있다....