개요인텔리제이와 LLM을 연동하려면 Proxy AI라는 플러그인을 사용한다. 이 플러그인은 대화형을 지원하기 때문에 AI 모델도 대화형이 지원되는 걸 다운로드해야 한다. 모델 이름에 Instruct 가 붙어 있는 게 대화형을 지원하는 모델이다. 대화형을 지원 안 하는 모델도 사용 가능하지만 벽에다 대고 말하는 것 같은 기분이 드니까 처음부터 Instruct 가 붙어 있는 모델을 다운로드 하자. 허깅페이스에서 CodeLlama-34B-Instruct-GGUF 모델을 다운로드 받았다.CodeLlama: 모델명34B: 모델 파라미터 수 (340 억)Instruct: 대화형 지원GGUF: 경량 파일 포맷 (로컬 환경에서도 빠르게 실행할 수 있음)https://huggingface.co/TheBloke/CodeL..

🔶 Config 파일을 수정해야겠다데이터 ETL 코드를 전체적으로 리팩토링 하고 있다. 환경도 다양하고, 데이터 타입도 다양하다 보니 ETL 환경 설정이 여러개인데, 전역 변수로 나와 있는 것들을 config로 다 정리해야겠다고 마음먹었다. 전역 변수로 적게 되면 오염될 가능성이 있고, 휴먼 에러가 발생할 확률이 높다. 그러나 이걸 config 파일에 한번에 정리해 두고, 검토만 한다면 휴먼 에러는 확실히 줄어들 것이다. 그리고 필요힌 변수를 받고, 만들어내는 과정도 config 파일에 잘 정의만 헤둔다면 줄일 수 있을 것이다. ❓그렇다고 config 파일이 없었냐?그건 아니다. 암호화 정보나 DB 접속 정보 등 기본적인 것은 다 Config 파일로 관리하고 있다. 그러나 파일 경로와 접속 정보들이 파..

FAILED: SemanticException [Error 10034]: Duplicate column name column_name in the table definition.Hive 테이블의 format을 orc로 변경 후에 데이터를 적재할 때 발생했던 오류이다. DB 에 있는 데이터가 아닌 파일 데이터라, 스키마 structure 를 저장해 두고 그에 맞게 저장하고 있는데, 컬럼 값들이 대문자여서 에러가 났다. 데이터를 전부 삭제하고 적재해도 데이터가 전부 NULL로 들어가는 이슈 발생 txt 포맷일 때는 한 번도 본 적 없던 에러가 왜 orc로 변경 후에 나타날까 원인1. txt 포맷은 스키마 매칭이 유연하다.2. orc 포맷은 스키마 매칭에 엄격하다.Hive는 내부적으로 스키마 정보를 소문자로 ..

[Hive] 하이브 테이블의 Format을 ORC로 변경하기 [Hive] 하이브 테이블의 Format을 ORC로 변경하기하이브 테이블의 포맷을 ORC 로 포맷을 변경하게 된 이유주기적으로 데이터를 삭제해야 하는 트랜잭션이 발생일정 범위의 데이터를 삭제해야 하는데, 이 작업이 txt 포맷에서는 되지 않음새로운m8o9.tistory.com첫 번째 과정은 위 글에 작성해 두었다 코드 수정과 설정 추가에 초점을 맞춘 포스팅이번에는 이미 적재해 둔 하이브 테이블의 format을 어떻게 변경했는지 적어 보겠다 하이브 테이블의 format을 바꾸는 데에는 총 두 가지 방법이 있다.1️⃣ 테이블을 새로 생성한 뒤 데이터를 옮기는 방법2️⃣ 테이블을 변경(ALTER)하는 방법2 번 방법이 훨씬 편하지만 안전성을 생각한다..

하이브 테이블의 포맷을 ORC 로 포맷을 변경하게 된 이유주기적으로 데이터를 삭제해야 하는 트랜잭션이 발생일정 범위의 데이터를 삭제해야 하는데, 이 작업이 txt 포맷에서는 되지 않음새로운 컬럼 추가 시, 추가되었다는 문자열을 프린트하는데, 업데이트가 되지 않아 새로운 컬럼이 추가되지 않았음에도 계속 문자열이 추가됨하이브에 최적화된 파일 형식이 ORC라고 한다즉 ACID를 위해서는 파일 포맷을 ORC로 변경하는 게 최선기존 저장 방식df.write.format('hive')최초 저장과 데이터 추가 전부 포맷을 hive로 지정하여 저장하고 있었다.최초 저장 시에는 기본 값인 txt 포맷으로 테이블이 저장되고, 데이터 추가 시에는 기존 테이블의 포맷을 따라 저장된다Hive에 저장된 테이블은 모두 txt 포맷..

1. DISK FULL 1차 발생개발 서버에서 HDFS DATA NODE로 쓰던 서버들 DISK FULL이 발생했다. 업무 시간에 일어난 일이라 용량을 가장 많이 차지하고 있는 디렉토리를 찾고, 단순 로그 데이터임을 확인한 뒤 삭제했다. 전체 디스크 용량 확인df -h용량이 가장 큰 상위 10개의 디렉토리 찾기du -ah /경로 | sort -rh | head -n 10 2. 주말에 DISK FULL 2차 발생확인해 보니 1차와 같은 경로에 로그가 계속 쌓여 있었다. 주말이라 완벽하게 대처는 못했다. 1차와 똑같이 로그 데이터를 삭제했다. YARN WEB 으로 들어가 실행되고 있는 프로세스를 확인했다. 같은 이름의 SPARK JOB이 수분, 수초마다 실행되고 있었다. SPARK SESSION 생성 시 A..