Full Stack
& AI▲ 만들다 막힌 지점과 풀어낸 방법의 기록
한 건씩 즉시 읽고 쓰는 HBase, 실시간으로 흘러드는 데이터를 받는 Kafka. HDFS 가 못 하는 자리를 누가 맡는지 살펴봅니다.
데이터가 커질 때 가장 먼저 무너지는 건 저장 공간이 아니라 읽어내는 속도입니다. 하둡이 왜 만들어졌는지, 그 세 가지 벽부터 살펴봅니다.
상품 상세는 잘라서 조각으로 만들었다. 그러면 고객은? 후기를 전부 이어 붙이면 서비스가 오래 돌수록 무한히 길어진다. 네 가지 방법을 재 보면 하나는 확실히 나쁘고 셋은 못 가른다 — 그때 무엇을 근거로 고를 것인가.
하던 작업을 급히 치우기, 잘못 올린 파일 빼내기, 커밋 되돌리기, 그리고 권한 없는 남의 프로젝트에 기여하기. 마지막 강입니다.
벡터 3,260개를 만들었는데 확인은 안 했다. 만드는 파일과 재는 파일을 갈라 두고, 재는 파일도 다시 「순서」와 「몸통」으로 가른다. 개수 · 차원 · 정규화 · 토큰을 세고, 문자로 저장한 대가를 잰다.
클라우드 저장소와 쿠버네티스가 하둡의 자리를 상당 부분 가져갔습니다. 무엇이 밀려나고 무엇이 남았는지, 마지막으로 정리합니다.
step0 까지는 벡터를 파이프라인 안에서만 썼다. 04_verify.py 가 numpy 로 직접 곱했다. 1단계에서 그 계산이 앱으로 넘어오고, 밖으로 나갈 글에서 개인정보가 사라진다. 새로 생기는 파일을 하나씩 끝낸다.
3교시에 정한 설계를 코드로 옮긴다. 조각 1,560 · 상품 200 · 고객 300 · 후기 1,200 개를 for 하나로 처리하는데, 열쇠 타입을 손으로 적으면 조인이 오류 없이 0건이 된다. 그래서 부모 표에서 베껴 온다.
같은 줄을 두 곳에서 다르게 고치면 깃은 못 정합니다. 일부러 충돌을 내고, 마커를 읽고, 손으로 골라서 끝냅니다. 겁먹을 일이 아닙니다.
벡터스토어는 딕셔너리다. 만들어 둔 벡터를 그대로 올리는 데 13초 중 대부분이 모델 로딩이다. 그리고 「환불하고 싶은데요」를 물으면 1위가 「이런 분께 권합니다」로 온다 — 어제 한 약속을 오늘 못 지켰다.
Spark 가 MapReduce 의 자리를 가져간 이유는 단순히 빨라서가 아닙니다. 무엇을 덜 하기로 했는지가 핵심이에요.
파일이 늘어나기 전에 자리를 잡는다. app 을 core 와 features 로 가르고, 옮긴 파일 셋의 import 를 한 줄씩 맞춘 다음, 어제와 똑같이 도는지 확인한다.
벡터 좌표로 같은 의미를 추론
가지를 깃허브에 올리고 '이거 넣어도 될까요' 하고 결재를 올립니다. 21강에서 미뤄둔 질문의 답이고, 실무에서 매일 하는 일입니다.
오후에 후기를 그대로 벡터로 만들었다. 그 안에 전화번호 152건 · 메일 46건 · 카톡 49건 · 주소 100건이 있다. 지우기 전에 먼저 세고, 그다음에 「안 꺼내는 것」부터 한다.
이 시리즈를 수업용 슬라이드 8벌로 다시 묶었습니다. 설치 없이 브라우저 안에서 가짜 터미널에 명령을 치고, 서버를 고장 내 보고, MapReduce 를 단계별로 따라가며 볼 수 있어요.
1교시에 app 을 나눴다. pipeline 만 그 기준 밖에 있다. 어제 친 240줄짜리 02_prepare.py 를 재 보면 자르는 일 자체는 0.6초고 나머지는 전부 준비 시간이다. 같은 기준으로 파일 넷으로 가른다.
옆자리와 짝을 지어 서로를 협업자로 초대하고, 남의 저장소에 PR 을 올립니다. 16강에서 만난 403 이 왜 났는지가 오늘 풀립니다.
「환불」과 「반품」은 글자가 하나도 안 겹친다. 문장 네 개를 384개짜리 숫자로 바꿔서, 글자 겹침과 벡터 거리를 나란히 재 본다. 순서는 맞다 — 그런데 차이가 0.015 다.
구분자를 선택으로 바꾼 조각 하나가 42건을 152건으로 만든다. 카톡 아이디는 모양을 못 정해서 문장째 버린다. 그리고 이름 앞에서 정규식을 포기하고 고객 표에서 사전 213개를 만든다 — 184건을 오탐 0으로 잡고, 최소 31건을 놓친다.