데일리 스크럼
PM 교체. 그전에 정리.
우리는 dkt 오래, 많이 했다. 그러나 지식이 편중되어 있다. 라이트닝과 wandb를 잘 쓰고 있으나, 한번 정리하는 시간을 필요할 것으로 보인다. 각자 쓰는 방법 정도 공유하면 좋을 것. 아침 스크럼이 지나치게 길어져서 시간에 제한을 거는 것이 필요할 것으로 보인다.
코테 리뷰는 매주 돌아가면서 하는 게 좋을 것으로 보인다.
부스팅 베이스라인이 잘 완성됨. userid가 자동화되어 추가되도록, 하면 gcn에서도 바로 사용이 가능할 것이다. gcn은 수요일부터 나가기. 시간에 쫓기지 말고 천천히 따라가도 좋으니 시작을 잘하자.
cs 공부 상당히 잘하고 있다.
화요일 말고도 따로 모여서 공부하기.
PM의 업무. 깃헙에서 머지하는 역할. 깃헙을 조금 더 체계적으로 써볼 필요가 있다. 모델 별로 분류하고, base와 모드를 나눈다. 그리고 각 브랜치를 올린 이후에 메인으로 머지하는 방식으로 한다. pm이 코드 양식을 최대한 비슷하게 맞춰줄 필요가 있다.
팀장과 pm의 분리. pm을 기술적인 영역에서만 가져갈 것인가? pm과 팀장을 합쳐서 하는 것으로. 개인의 경험의 영역에서 도움이 될 것이고, 어차피 모든 팀원이 적극적으로 참여할 것이기 때문에 책임감을 지는 연습을 해보자는 것. pm==팀장!
이후 코테 리뷰
면접을 위한 CS
4.2 ERD와 정규화 과정
Entity Relationship Diagram란? 릴레이션 간의 관계들을 정의한 것. 데이터베스를 구축할 때 기초적인 뼈대 역할을 한다.
관계형 구조로 표현할 수 있는 정형 데이터를 표현하기에 매우 적합하며 디버깅이나 설계도의 역할이 되어주기도 한다.
이러한 관계도를 ERD라고 부른다. [DataBase] ERD란?
데이터베이스 속 릴레이션들의 관계를 따지는 데에 있어 잘못된 종속 관계로 인한 이상 현상을 해결하거나 메모리의 효율을 위해 릴레이션들을 분리하는 과정을 정규화 과정이라고 부른다.
이상 현상이란? 하나의 회원에 하나의 등급이 있어야 하는데 3개가 있다던가, 데이터를 삽입해야 하는데 해당 필드가 비어있다던가 하는 의도하지 않은 현상을 말한다.
이를 해결하기 위해 정규화 과정을 통해 간단하고 효율적으로 표현을 정리하는 것. 이는 정규형 원칙을 기반으로 정규형을 만들어가는 과정이다. 정규형의 종류는 다양하다. 그래도 기본적으로는 더 좋은 구조, 중복성 감소, 독립적 관계 표현 등을 추구한다.
제1 정규형: 릴레이션의 모든 도메인이 분해될 수 없는 원자 값으로만 구성되어야 한다(집합 형태면 더 나눌 수 있을 것). 중복된 값을 가지는 집합이 있으면 안 된다는 것. 반복 집합이 있으면 제거되어야만 한다.
왼쪽을 오른쪽으로 바꾸는 것. 오른쪽이 제1 정규형이다. 이것에도 쉽게 이상현상이 나타난다고 한다. 삽입 이상, 삭제 이상, 갱신 이상. 자세한 것은 [DB] 8. 정규형 참조.
제2 정규형: 릴레이션이 제1 정규형이면서 부분 함수의 종속성을 제거한 형태. 위 예시에서는 학번에 지도교수가 종속되어 있다. 이런 것을 분리시켜주는 것.
주의할 점은 동등한 릴레이션으로 분리해야 한다는 것, 그리고 정보 손실이 발생하지 않는 무손실 분해를 해야한다는 것. 그러나 이것도 아직 이상현상이 발생할 수 있다. 그 이유는 바로 이행적 함수 종속성에 있다.
그게 뭐냐? 지도교수는 학번에 종속되고, 학과는 지도교수에 종속된다. 그렇다면 학과는 학번에 이행적으로 종속되어 있다는 것.
제3 정규형: 제2 정규형이면서 모든 속성이 이행적 함수 종속을 만족하지 않는 상태.
이렇게 만들어주자는 것!
결과적으로 이렇게 모양이 바뀌게 된다.
보이스/코드 정규형: Boyce and Codd Normal Form이라 하여 BCNF라고도 부른다. 이것은 기본적으로 제3 정규형이고, 함수 종속 관계를 제거하면서 릴레이션의 모든 것들을 후보키로? 만든 상태를 말한다고.
후보키란? 슈퍼키 중에서 최소성을 만족하는 키. -- 최소성을 만족하려면 두 필드의 묶음으로 되면 안 되는 것 아닌가?
여튼 이런 식으로 제3 정규형과 모양이 같은데, 그러면서 이러한 조건까지 만족할 때 BCNF라고 부른다는 모양.
혼자 공부하는 SQL 1-2
책에 나온대로 일단 설치해보자고. 원래 책에서 제시하는 버전은 8.0.21인데, 현재 나온 버전도 크게 바뀌지 않았기에 버전 명이 저럴 것이라고 판단하여 그냥 최신 버전으로 다운받았다. 나중에 문제 발생하고 울게 될 일이 없었으면 좋겠구만..
그래도 나머지는 책에 충실하기. 왜 저 3개만 골라서 다운을 받는 것일까? 나머지는 언어나, vscode랑 연결을 용이하게 해주는 장치들인 것 같아 보이는데, 일단 까라니 깐다..
추가 설정이 필요한 부분. 포트는 반드시 3306이어야한다고 하는데, 이거 어디서 많이 본 포트 번호다. 내가 42에서 봤던 번호인 건지, 부캠에서 하면서 맞닥뜨린 번호인 건지 기억에 혼동이 온다..
비밀번호 인증은 이전 버전에서 사용되던 방식으로. 이후에 번호는 책에 나온대로 설정한 후 이름도 단순하게 MySQL로 바꿔준다.
기본 mysql 설정은 끝이났고, 이후 samples-and-examples도 설정을 마친 모습.
성공적으로 mysql 설치가 완료됐다.
오호! 책에서 나온대로 잘 작동하고 있다. 서버 구축하는 과제를 할 때 mysql를 정말 겉핥기 식으로 공부했었는데 이렇게 아예 직접 만지는 날이 오게되니 또 새삼 신기하다. 그때는 다시는 안 만지게 될 것이라고 막연하게 생각했었다. 하지만 결국 다양하게 경험하고 내가 갈 길을 찾아나가야 한다. 최대한 내가 손 대는 것은 다 내 걸로 만들어보자고.
xgboost or lgbm
고양이는 다른 사람들이 손을 많이 대고 있어서 내가 한 것보다 훨씬 더 좋은 방식으로 수정을 해주는 사람이 있을 것 같고 당장 넣을 데이터 eda를 해주는 사람도 있는 상황. 아무래도 나는 다른 부스팅 모델이 가능하도록 만들어주는 것이 좋을 것 같다. 일단 저번 대회에서 스페셜 미션에서 있었던 자료들을 뒤져보자고.
앙상블을 하는 방법은 다양하다. 심지어 피쳐로 다른 모델의 예측값을.. 넣는 것도 가능하다!
당장 테스트를 할 때에 있어서는 wandb에 계속 업데이트되는 것도 거추장스럽다. 아예 인자로 넣어서 wandb를 쓸지 말지도 정하자.
나는 대충 알았을 때는 xgboost가 더 상위 모델이라고 생각했는데, 알아보니 오히려 lgbm이 2년 후에 나온 모델로 비슷하게 동작하면서 속도는 빠르고 성능 차이는 거의 나지 않는다고 해서 lgbm을 일단 적용해보기로 마음 먹었다.
스페셜 미션에 있는 것을 따라치는 중인데, lgbm은 데이터셋을 따로 만들어서 하는 방식을 취하는 모양이다.
일단 그대로 따라치니 잘 나와주고 있다. 그러나 내가 봤을 때는 조금 이상하게 값이 들어가는 것도 있는 것 같아 조금 더 공부가 필요해보인다.
피어세션
부스팅 모델 사용 이전에, 조금 더 dkt에서 볼 만한 사항들.
FE에서 라벨 인코딩을 하지 말고 dkt 딴에서 전처리하는 것으로 고려해보자. 어차피 캣부스트는 알아서 라벨 인코딩이 되기 때문에 그다지 필요하지 않다. 또한 FE가 잘 됐는지 확인하기 위해서는 인코딩된 값이 아니라 그냥 값을 확인해야 잘 됐는지 확인할 수 있다.
유저 id는 여태 행번호로 사용했으나, 부스팅에서는 이것도 피쳐로 사용해야 한다. 그냥 단순하게 하드코딩하면 되는 문제이니 EDA에서 수정될 사항은 없다.
seq2seq. 인코더와 디코더를 사용한다. 그러나 현재 베이스라인은 인코더만을 활용하는 방식이다. 그렇다면 디코더까지 활용한다면 어떻게 되는가? 이것은 일종의 층을 늘리는 것과 같은 효과일 것 같다.
그러나 여태의 결과에서는 층을 깊게 하는 것이 좋은 결과를 이끌어내지 못했다. 그러니 의미가 조금 덜할 수도 있다.
부스팅 관련.
부스팅 모델에서는 zscore을 쓰지 않는 게 더 좋을 수도 있고, 애초에 상관이 없을 수도 있다.
수도라벨링과 cascade.
수도 라벨링은 테스트 데이터에 임의 정답을 넣어 학습시키는 방식.
부스팅 모델들 단일로. 파라미터 튜닝이 가능하도록 하기.
캣부스트 관련 이야기.
혼자 공부하는 SQL 2
당장 내일 공부해가야 하는 것들을 끝내보자.
2-1. 건물을 짓기 위한 설계도 : 데이터베이스 모델링
데이터베이스 모델링을 통해 데이터베이스 속 테이블 구조를 미리 설계해야 한다.
소프트웨어 프로젝트(현실 업무를 컴퓨터로 옮기는 과정) 절차를 흔히 폭포수 모델이라 부른다. 순차적으로 단계를 넘어갈 때 급격히 진행되기에 이름 붙은 명칭.
- 프로젝트 계획 - 말 그대로 계획. 수요 파악!
- 업무 분석 - 현업 상황 파악. 파고들 요소를 분석한다.
- 시스템 설계 - 앞에서 진행한 분석을 토대로 코드 구상을 하고 형태를 다듬는다.
- 프로그램 구현 - 시스템 설계된 것을 실제 코드로 구현한다.
- 테스트 - 테스트
- 유지보수 - 서빙 중 보완할 점들을 보수하고 기능을 추가한다.
이러한 단계 중에서 데이터베이스 모델링은 업무 분석 및 시스템 설계 단계에 해당한다. 현실의 장부나 거래 내역을 데이터베이스로 어떤 구조로 만들지 고민하는 것.
데이터베이스 모델링에 관해 간단하게 워크벤치에서도 기능을 제공한다. 위의 diagram이 바로 그것.
뭔가 만들어지기는 하는데.. 어떻게 만져야 하는지 잘 모르겠다. 안 속에 타이핑을 해보고 싶은데..!
2-2. 데이터베이스 시작부터 끝까지
모델링을 토대로 우리는 데이터베이스를 구축해나가면 된다. 데이터베이스를 만들고, 테이블을 만들고, 데이터를 입력 및 삭제, 이후 데이터 활용을 하는 방식.
스키마 = 데이터베이스. 기본적으로 mysql에는 세 개의 데이터베이스가 주어져있다.
데이터베이스 추가하기. 물론 코드로도 작성할 수 있다.
CREATE SCHEMA `shop_db` ;
코드로 치면 이런 식으로! 이제 이 속에 들어갈 테이블을 만들어보자. 먼저 들어갈 자료형을 정의해줘야 하고, null을 허용해야할 지 정해야 한다.
테이블을 만들고 안 속 컬럼을 만드는 모습. 데이터 타입을 지정하고, 기본키(PK)와 널값 허용여부(NN)을 지정해준다. 이름은 어떻게 써도 알아서 소문자로 들어간다고 한다.
열심히 손으로 연습해본 것은 사실 코드로 구현하면 더 간단해보인다. 그냥 코드 구현을 익히는 게 더 나을 것 같은 건 내 착각인걸까?
이후 실습으로 product 테이블 만들기! 옵션 지정마다 옆 아이콘 모양이 바뀌는 것을 확인할 수 있다.
이후에는 데이터를 넣어보자. 참고로 기본키로 설정된 컬럼을 기준으로 데이터가 정렬된다. 수정이나 추가도 간단하게 할 수 있다. 입력은 INSERT, 수정일 경우 코드로는 UPDATE, 삭제는 DELETE를 사용한다.
이제 보니까 표시도 되어주고 있었다.
데이터를 사용할 때는 SELECT를 통해서 한다. 보통 가장 많이 쓰는 명령어이기에 이것만 잘해도 절반은 한다고 한다.
딱히 대문자로 쓰지 않아도 상관 없는 모습! 참고로 좌측에서 정확하게 데이터베이스를 더블 클릭해서 볼드체로 만들어놔야 오른쪽 쿼리창이 해당 데이터베이스에 대해서 결과를 도출한다고 한다.
where라는 명령어가 혹시 이쪽이 원산지인 것일까?! 판다스나 넘파이에서 흔히 쓰는 방식의 그 where인 듯하다. 아무튼 이렇게 두 요청에 대해서는 member 5,6으로 분리해 따로 실행한 것을 확인할 수 있다. 이게 싫다면 한 행을 선택한 상태에서 실행하도록 하자.
2-3. 데이터베이스 개체
데이터베이스에는 테이블이라는 핵심 개체가 있지만, 이밖에도 다른 개체들도 존재한다.
인덱스 - 데이터 조회 시 결과를 빠르게 나올 수 있도록 도와주는 개체
뷰 - 테이블의 일부를 제한적으로 표현할 때 사용
스토어드 프로시저 - SQL에서 프로그래밍이 가능하도록
트리거 - 잘못된 데이터가 들어가는 것을 미연에 방지
이 각각을 한번 실습해보자.
해당 코드를 통해 아이유의 정보를 뽑을 때의 속도. full table scan은 전체 테이블을 탐색했다는 뜻으로, 테이블 속 모든 행을 뒤지게 되기 때문에 오랜 시간이 걸린다고 한다. 만약에 인덱싱이 이뤄졌다면 그런 불상사를 대비할 수 있을 것이다.
create index idx_member_name on member(member_name);
이런 코드를 치면 멤버 이름을 기준으로 인덱스가 지정된다.
해당 코드 이후에 치니까 이렇게 방식이 조금 달라진 것을 확인할 수 있다. 대충 봐도 두 배의 시간 단축이 있었다!
뷰는 테이블의 이미지를 보여주는 녀석이다. 가상의 테이블로서 실제 테이블을 링크해서 보여주는 것.
create view member_view
as
select * from member;
이렇게 코드를 쳐서 뷰를 만들 수 있는데, 괜히 더 보기 어렵게 줄바꿈과 들여쓰기를 하는 것이 아닌가 싶다.. 이 이후부터는 select를 쓸 때 member에 바로 접근하지 않고 member_view를 통해 접근하는 것이 가능해진다. 뷰를 쓰는 이유는 일단 보안에 도움이 되고, 긴 sql문을 간략하게 만들 수 있기 때문!
stored procedure는 프로그래밍 기능! sql문을 묶어서 관리할 수 있도록 해준다.
구분문자라는 의미로 delimiter가 들어간다. 이후 myProc()이라는 저장된 절차(stored procedure)를 만들고, 원하는 명령어를 넣어준 모습.
call myProc()
이 이후에는 이 절차를 부르면 된다.
뷰와 저장된 절차가 들어가있는 모습을 확인할 수 있다.
회고 및 다짐
부캠을 수료한 이력이 채용에 고려되는 요소인가? 부캠에서 어떤 역량을 가지고 가면 좋을까? 이건 어느 회사에 대해서도 물을 수 있는 질문인 듯. 최대한 컴퍼니 데이는 전부 다 들을 생각이다. 아는 게 부족한 이상 귀동냥을 열심히 다녀야 한다고 생각한다. 따지자면 나는 내 진로에 있어서 뚜렷한 직관을 갖고 있지 않기 때문에 이를 보완하기 위해서는 정보를 수집하는 것이 필수다. 처음에는 잘 몰라도 귀에 박히게 듣다보면 언젠가 적응하겠지.
그나저나 오늘은 lgbm을 적용시키려는 시도만 하고 거의 대회 관련 기여를 못했다. lgbm을 쓰기는 썼지만, 아직 알아봐야 할 게 많다. 잠시 집중이 풀려서 능률 떨어지게 공부한 것이 컸던 것 같다. 코드를 짤 때 막힐 때마다 조금 멍해지는 순간이 있는데 이때 간혹 그대로 딴짓을 잠시 하거나 다른 쪽으로 생각을 트는 경우가 생겨서 그런 것 같다. 이는 조금 고칠 필요가 있을 것 같다. 멍해져서 졸려지는 게 가장 큰 문제인데(특히 근래 잠도 부족한지라) 이건 커피를 마셔서라도 해결을 해보자고.
'일지 > 네부캠 AI 4기(22.09.19~23.02.14)' 카테고리의 다른 글
20221130수-dkt13 (0) | 2022.12.01 |
---|---|
20221129화-dkt12, 오프라인 (0) | 2022.11.30 |
20221127일-라이트닝1~2, 밑러닝14~19, 리트코드 (2) | 2022.11.27 |
20221125금-dkt10,스미5 (0) | 2022.11.26 |
20221124목-dkt9 (9) | 2022.11.25 |