실리콘밸리 리더가 알려주는 빅데이터 처리 (Spark)
₩108,900
초급 / Apache Spark, pyspark, Pandas, 빅데이터, SQL
빅데이터를 처리한다는 것은 Pandas로 데이터를 처리하는 것과 무엇이 다를까요? 빅데이터 처리의 필수 프레임워크인 Spark에 대해서 배워볼까요?
초급
Apache Spark, pyspark, Pandas
컴퓨터 공학 석사 후 삼성전자에서 시작된 커리어가 친구덕에 실리콘밸리로 이어져 지난 29년간 13개의 다양한 스테이지의 회사를 다녔습니다 (창업, 대기업들, 다수의 스타트업들).
야후: 엔지니어링 디렉터로 검색엔진 개발.
유데미. 데이터팀을 처음 만들어 30명까지 성장. 2021년 10월에 나스닥 상장
삼성전자
...
중간에 11개월 쉬어보기도 했고 본의 아니게 엔젤투자자(Chartmetric, Goodtime.io, Select Star, EO, 비지니스 캔버스, ...), 어드바이저(몰로코, 블라인드, 월급쟁이부자들, ...), 컨설팅(SK텔레콤, 현대카드, 이마트 등등) 등의 역할을 하면서 나만의 브랜드를 만들었습니다. 실패를 실패가 아닌 교훈으로 보는 긍정의 힘과 꾸준함이라는 복리의 힘을 믿습니다.
● 멘토 소개
컴퓨터 공학 석사 후 삼성전자에서 시작된 커리어가 친구덕에 실리콘밸리로 이어져 지난 29년간 13개의 다양한 스테이지의 회사를 다녔습니다 (창업, 대기업들, 다수의 스타트업들). 중간에 11개월 쉬어보기도 했고 본의 아니게 엔젤투자, 어드바이저, 컨설팅 등의 역할을 하면서 나만의 브랜드를 만들었습니다. 실패를 실패가 아닌 교훈으로 보는 긍정의 힘과 꾸준함이라는 복리의 힘을 믿습니다.
이 멘토링을 통해 원하는 방향으로 발전하신 분들이 많이 계십니다. 커리어는 결국 자신감이고 전략을 바탕으로 행동으로 옮겼을 때 더 좋은 방향으로 변화하게 되며 생각을 바꾸는 것이 시작입니다.
● 멘토링 대상
● 진행방식
● 준비물
커리어 관점에서 제일 중요한 포인트는 주기적으로 회고해보고 행동으로 옮기는 것입니다. 여기서 두 가지 생각해볼 포인트는 다음과 같습니다.
감사합니다.
실리콘밸리 리더가 알려주는 빅데이터 처리 (Spark)
₩108,900
초급 / Apache Spark, pyspark, Pandas, 빅데이터, SQL
빅데이터를 처리한다는 것은 Pandas로 데이터를 처리하는 것과 무엇이 다를까요? 빅데이터 처리의 필수 프레임워크인 Spark에 대해서 배워볼까요?
초급
Apache Spark, pyspark, Pandas
실리콘밸리 데이터 리더가 알려주는 Airflow 기초
₩132,000
3일만
25%
₩99,000
초급 / airflow, snowflake, SQL, Python
5.0
(4)
AI 시대가 도래하면서, 데이터 파이프라인 구성은 기업 경쟁력을 좌우하는 핵심 역량으로 자리 잡았습니다. 가장 널리 사용되는 Airflow를 활용해 효율적인 데이터 파이프라인을 구축하는 노하우를, 실전 경험과 풍부한 강의 경력을 지닌 실리콘밸리 전문가(前 유데미 데이터팀 헤드, 現 산호세 주립대 데이터 석사 과정 교수)에게 직접 배워보세요.
초급
airflow, snowflake, SQL
실리콘밸리 데이터 리더가 알려주는 기초 SQL
₩71,500
초급 / SQL, 데이터 리터러시, 데이터 엔지니어링, 빅데이터, DBMS/RDBMS, duckdb
5.0
(2)
데이터를 하는 사람이라면 꼭 알아야하는 기본 기술은 SQL입니다. 이번 강의에서는 SQL을 데이터 분석이란 관점에서 실습 위주로 학습해보겠습니다. 실습은 DuckDB를 가지고 Google Colab에서 진행합니다.
초급
SQL, 데이터 리터러시, 데이터 엔지니어링
실리콘밸리에서 인정받는 개발자의 특징 (w. 한기용)
무료
입문 / career-advice, career-development, 커뮤니케이션
4.8
(21)
본 영상은 <판교 퇴근길 밋업 with 인프런 - 개발자 커리어> 에서 진행한 발표 세션의 녹화본입니다.
입문
career-advice, career-development, 커뮤니케이션
[멘토링] 데이터로 미래를 그리다: 모두를 위한 데이터 리터러시
₩264,000
입문 / 데이터 리터러시, 데이터 엔지니어링, 데이터 트랜스포메이션, EDA
4.8
(10)
데이터에 관심있는 개인이나 리더를 대상으로 데이터 팀이 하는 일을 소개하고 조직의 데이터 활용 능력을 나타내는 데이터 문해력이 어떤 것인지 소개합니다.
입문
데이터 리터러시, 데이터 엔지니어링, 데이터 트랜스포메이션
질문&답변
이전 강의에서도 그랬지만 소리가 너무 작아요
Airflow 말고 다른 강의에서도 소리가 작았나요? 제 컴퓨터에서만 확인해보고 폰에서는 확인해본 적이 없었네요. 오늘 중으로 챕터 하나를 골라서 소리를 키워보고 업로드해 볼테니 소리의 크기가 어떤지 확인부탁드리겠습니다.
질문&답변
실습 code 강의자료 문의
강의 소개에 보면 GitHub 링크가 있습니다. 아래를 참고하세요:https://github.com/keeyong/spark-bootcamp
질문&답변
강의자료 다운로드 문의
제가 업로드하는 걸 잊어버리고 있었습니다. 알려주셔서 감사드립니다. 처음 "과정소개" 섹션 밑에 "강의 자료"라는 챕터를 만들고 거기 압축 파일을 하나 올렸습니다.(사진)
질문&답변
nps.csv 파일 위치
질문 감사드립니다. "Snowflake 환경 익히기 실습" 강의에서 다운로드 받으시면 nps.csv 파일이 다운로드됩니다(사진).계속 문제가 있다면 알려주세요!
질문&답변
강의가 잘못 올라온것이 있네요. => 48강
48, 49장에 수업 노트 내용에 중복이 있군요. 원래 하나의 챕터로 만들었다가 내용이 너무 길어 두 개로 분리하면서 그 부분을 정리하지 못했네요. 수정했습니다. 또 비슷한 이슈 보면 알려주세요!
질문&답변
Airflow 웹 UI에서 파일 디렉토리 구조 확인이 가능한가요?
필요하다면 그 구조를 노출해주는 DAG나 Plugin을 만들어볼 수 있습니다만 Airflow Web UI 자체에 그런 기능은 없는 걸로 알고 있습니다.보통 내용을 확인하려면 Airflow가 동작하는 서버로 로그인해서 살펴보는 것이 일반적이라 할 수 있습니다. Docker Container를 쓰는 환경이라면 해당 Docker Container 안으로 로그인해보는 것이구요. 클라우드 기반의 Airflow 서비스를 쓰는 경우라면 서버 안으로 들어가서 체크하는 걸 허용하지 않지만 대신 Airflow 서버내 dags 폴더로 맵핑되는 폴더를 클라우드 스토리지 등에 구성하고 그걸 미러링하는 것이 일반적입니다. 질문 감사드립니다. 혹시 위 답변에 추가 질문이 있다면 알려주세요
질문&답변
본문과 같은 메시지가 뜨면서, 어느 순간부터 계속 안되는데, 어떤 이유일까요 ㅠㅠ
말씀하신 것처럼 마지막에 보면 아래와 같은 에러 메시지가 있습니다.This session does not have a current database. Call 'USE DATABASE', or use a qualified name.Snowflake Connection을 Airflow UI에서 설정할 때 database 항목을 설정했는지 한번 확인해보실래요? 거기에 dev라고 설정이 되어야 하는데 그게 빠지면서 현재 연결에 데이터베이스 설정이 안되는 것이 아닌가 싶습니다.
질문&답변
yfinance 주식 읽어 오기 처음 중, no module named helpers 에러
질문 감사드립니다. helpers는 외부 모듈이 아니구요. 제가 제공한 GitHub Repo에 있는 모듈입니다. 이전 실습에서 자주 사용되던 몇 개의 함수를 재사용하기 위해서 util.py라는 파일을 만들었고 그걸 helpers라는 폴더안에 저장했습니다. 그러면 util.py에 정의된 함수들을 사용하기 위해서 아래와 같은 util을 임포트할 수 있습니다.from helpers import util이걸 앞 섹션의 "앞서 Airflow 예제를 개선해보자 (v6)" 챕터에서 설명했었는데 그 부분 다시 한번 보시는 걸 추천드립니다. https://inf.run/YqWFjairflow-bootcamp repo가 존재하는 폴더에서 아래 복사 명령을 실행하고 나면 해결되리라 믿습니다.mkdir dags/helpers cp dags_to_move/helpers/util.py dags/helpers혹시라도 해결이 안되면 알려주세요!
질문&답변
Data Drift 발생시 머신러닝 모델이 동작하지 않는 것의 의미
좋은 질문 감사드립니다. 1. Data Drift 발생 시에 머신러닝 모델이 동작하지 않게 될 것이라는 것은 서비스는 돌아가지만, 머신러닝의 모델이 원래 기대했던 성능을 내지 못할 것을 의미하는 것일까요?맞습니다. 예를 들어 모든 머신 러닝 서비스에는 중요 성능 지표가 있게 되는데 예를 들면 추천한 내용에 대한 클릭 비율 등등 이런 지표가 하락하게 됩니다. 2. 주기적으로 데이터의 분포를 점검하는 필요가 있다면 어느 정도 주기여야 할까요?ML 모델이 어떤 일을 하느냐에 따라 민감도가 다를 듯 한데 일반적으로 추천/검색 등이라면 일주일이나 한달에 한번 정도가 적당하지 않을까 싶습니다. 보통은 ML 모델을 구동하는 API 레이어에서 들어오는 데이터를 전수조사를 하거나 데이터가 너무 많다면 샘플링을 해서 랜덤하게 로그를 남기는 것이 일반적입니다. 사실은 이런 데이터 분포의 점검 보다 선행되어야 하는 것은 모델의 성능 지표의 트렌드를 주기적으로 확인해보는 겁니다. 떨어진다 싶으면 분명히 data drift 같은 이슈가 이유일 확률이 높습니다.3. 데이터의 분포가 어느 정도로 변하게 되면 이상 신호로 받아 들이게 되는 것인가요? 평균의 변화가 아닌 분산의 변화만으로도 이상 신호로 보아야 하는 것인지요? (뭔가 더 복잡하면 데이터의 성격에 따라 이러한 분포의 변화에 대해 반응해야 하는 수준이 다 다를 것으로도 느껴지기도 합니다.)ML 모델의 입력이 되는 모든 피쳐에 대해 체크할 필요는 없구요. 기본적으로는 중요 피쳐들에 대해서만 보면 충분할 텐데 평균과 분산 모두 봐야할테고 상황마다 조금씩 다 다를꺼라 처음에는 앞서 이야기했던 것처럼 중요 성능 지표의 변화를 모니터링하다가 나빠지는게 보일 때 중요 피쳐의 변화를 살펴보는 걸 추천드립니다.요즘 ML 프레임워크들 (예를 들면 AWS의 SageMaker)은 ML 모델의 배포와 모니터링을 지원하는 경우가 많습니다. 이쪽을 최근에는 본 적이 없어서 어떤 제품들이 많이 사용되는지는 모르겠습니다만 data drift 분석을 쉽게 해주는 서비스도 분명히 있으리라 믿습니다. 도움이 되었으면 좋겠고 추가 질문이 있다면 알려주세요!
질문&답변
docker 에러
에러 메시지를 보면 이렇게 되어 있습니다. (사진)이게 아마도 Docker 동작 방식에 있어 Windows와 Mac의 차이점이 아닐까 싶은데 재실행되면서 logs 폴더가 사라지는 것 같네요. airflow-bootcamp가 있는 폴더에서 logs 라는 서브 폴더를 만드세요. 그리고나서 아래 명령을 다시 실행해보세요:docker compose -f docker-compose.yaml up해결 여부 꼭 알려주세요.
2024. 01. 25.
7
비전공 개발자가 흔히 하는 고민
지난 주에 30대 초반에 부트 캠프를 통해 엔지니어로 전직한 분과 이야기해보는 시간이 있었다. 30대 중반이 되어 주니어 개발자로 일하고 있는데 대학을 졸업한지 2-3년차 동료들과 비교하며 힘들어 하고 있었다. 부트캠프부터 치면 3년이 되어가는데 아직도 잘 모르겠다고 하면서 어떻게 살아야할지 길을 잃은 것 같다고 고민을 털어놓았다. 30-40대 경력 전환 주니어 개발자들과 이야기하다보면 항상 나오는 패턴이다.20대로 돌아가면 어떻게 살것 같냐고 했더니 조금 생각하더니 술술 잘 이야기하길래 지금부터 그렇게 살면 된다고 조언해주었다. 앞에 시간이 많기에 (이분은 앞으로 적어도 40년은 일해야한다 ^^) 늦은 것 같지만 늦은 게 아니다. 나이가 주는 강박관념과 과거에 보낸 시간이 물경력이 아닐까 하는 후회, 그러다보니 나보다 어리지만 사실은 그 분야에서 더 오랜 시간을 보낸 사람들과 비교하기 쉽다.개발에 들어온지 3년만에 잘 할 수 있다면 그건 천재다. 오랜 시간이 걸리며 디버깅은 다들 아주 사소한 걸로 몇 시간부터 며칠 보내는 일이 허다하다. 마음이 조급하다보면 회사 일을 열심히 해서 실력을 늘리기 보다는 회사 일은 회사 일이고 업무 시간 밖에서 아직은 너무 어려운 다른 공부를 하며 스트레스 받기 쉽다 (방정식을 배우는 단계에서 미분을 배우려고 하는 듯 한 느낌). 처음은 기본기다.길게 바라보며 나만의 길을 찾고 내가 있는 곳에서 잘 하려고 최선을 다 해보는 것이 커리어를 발전시키는 가장 쉬운 길이다. "나"와 "현재"에 집중해보자.커리어 멘토링에 관심있다면 https://www.inflearn.com/mentors?mentor_id=1823 :)
개발 · 프로그래밍 기타
・
커리어고민
・
비전공개발자
・
물경력
2024. 01. 23.
9
성장하는 조직의 기술 부채는 언제 갚을까?
작은 회사에서 속도에 초점을 맞추고 주니어 중심으로 개발을 하면 당연히 기술 부채가 쌓인다. 워낙 숨 가쁜 일정으로 돌아가다 보니 유닛 테스트를 만드는 건 꿈도 꿀 수 없고 최종 QA(Quality Assurance)도 대충 하고 프로덕션에서 실제 고객들이 테스트 아닌 테스트를 하는 일도 다반사다. 자잘한 버그가 자주 보고되는 것은 물론 가끔 사고도 터지며, 이런 기술 부채로 인해 생긴 누더기 같은 코드로 인해 새로운 기능 개발도 지연되기 시작한다. 그렇다고 내일도 살아있을지 아무도 모르는 작은 회사에서 항상 깔끔하고 완벽하게 테스트된 코드만 지향하거나 무모하게 새로운 프레임워크를 사용해 볼 수도 없는 노릇이다. 시작하는 단계의 스타트업이 빠른 속도와 무결점 중 꼭 하나만 선택해야 한다면 속도를 선택하는 편이 유리하다는 게 내 생각이다. 그 대신 아래의 내용을 참고하면 돈이 더 생기고 더 경험 있는 사람을 뽑기 전까지 리스크를 최소화할 수 있을 것이다. 어느 시점부터는 슬슬 사고의 빈도가 늘며 정도도 심해지기 시작할 때 그 때부터는 아래를 고민해보는 것이 좋은 듯 하다.서비스 모니터링 프로세스를 만든다. 서비스에 문제가 생기면 빨리 인지하고 해결하는데 초점을 맞추는 것이다. 이 것도 상당한 노력과 시간을 필요로 할 수 있는데 기술 부채를 많이 안고 가는 상황에서 모니터링에 대한 노력을 먼저 기울이는 것이 맞다고 본다. 어떤 지표를 바탕으로 서비스의 안정성을 측정할 것인지 그리고 서비스에 문제가 생겼을 경우 어떻게 escalate하고 문제해결을 할지 점진적으로 개선해가며 프로세스를 만드는 것이다. 또한 사고의 심각성에 따라 재발을 막을 방법을 찾아봐야 하는데 이건 뒤 문단에서 이어서 더 이야기해보겠다. 2. 매주 엔지니어링 미팅 등에서 지난 한 주간의 버그와 사고를 리뷰하고 이유를 파악한다. 유닛 테스트 코드를 붙이지는 못하고 QA를 충분히 하지 못하더라도, 이미 발견된 버그와 사고가 재발하는 것을 방지하기 위한 테스트는 붙이는 것이 필요하다고 본다. 서비스 모니터링 프로세스가 어느 정도 자리잡혀있다면 사고 리뷰는 상대적으로는 쉬워진다. 만일 버그와 사고의 빈도가 점점 높아진다면 새로운 기능 개발뿐 아니라 기존 코드의 리팩토링에도 시간을 써야 한다. 유데미 시절 데이터 엔지니어링 팀은 이슈가 늘어나면서 그러다가 대형 사고를 한번 겪고 난 뒤 최대 40%의 시간을 리팩토링에 할애했다. 3. 훌륭한 개발자는 자신이 만든 결과물이 실제 사용자들에 의해 어떻게 사용되는지 관심이 많고 실제 사용자의 피드백에 귀를 기울이는 사람이다. ‘개발 다 했으니 내 업무는 끝!’이 아니라 어떻게 쓰이는지 보고 개선하려는 의지가 있다는 말이다. 인정받는 개발자 혹은 좋은 개발 팀의 매니저가 되고 싶다면, CS/CX 팀과의 협업 채널을 만들고 주기적인 미팅을 통해 고객의 소리를 들어보고 사람이 되자. SDD(Support Driven Development)라는 말을 들어봤는가? Y Combinator 스타트업 스쿨에서 강조하는 원칙 중의 하나이다. 몇 가지 상대적으로 쉽게 붙여볼 수 있는 중요한 성능 모니터링이 있는데 첫 번째는 백엔드 데이터베이스의 오래 걸리는 쿼리를 모니터링하고 문제 되는 부분을 찾아 미리 최적화하는 것이고 두 번째는 서비스 홈페이지나 중요 API의 실행시간 (latency) 모니터링을 해보는 것이다. 이를 기술 부채를 해결하기 위해 단기적 관점에서 해볼 수 있는 일이다. 물론 위와 같은 방법을 동원해도 사고는 터진다. 그중 몇 건은 대형 사고일지도 모른다. 그럴 때 중요한 것은 사고를 바라보는 경영진의 관점인데, 특정인이나 팀을 향해 손가락질하기보다는 사고 경위서를 작성해서 사고의 원인을 이해하고 재발 방지 대책을 세운 뒤 사내에 공유하는 과정에 집중해야 한다. 여기서 포인트는 경위서 작성 자체가 아니라, 밝혀진 문제의 재발을 막기 위한 조치들이 경위서의 내용에 포함되고 이런 조치들이 실제로 구현되어야 한다는 점이다. 온라인 서비스에서 사고는 언제 일어나느냐의 문제지 피해갈 수는 없다. 회사가 망할 정도의 사고만 아니라면 조직 구성원 모두가 기술 부채 등의 다양한 이슈를 체감하고 이를 줄이기 위해 노력할 수 있는 기회가 된다는 사실을 잊지 말자. 모든 위기는 기회가 될 수 있다. 모든 사람들이 기술 부채 문제를 체감하는 회사가 망할지 않을 정도의 대형 사고를 내가 사랑하는 이유다 🙂 What doesn’t kill you makes you stronger!
개발 · 프로그래밍 기타
・
기술부채
・
사고경위서
・
SDD