[특강] 데이터 파이프라인 트렌드

김종욱·2023년 6월 5일
0

학습주제

학습내용

데이터 파이프라인 트렌드에 대해 알아본다.

그룹 프로젝트를 하다보면 작은 충돌이 발생할 수 있음.
앞으로 현업에서 업무를 하게 되면 더 중요해짐.

충돌을 어떤 관점에서 바라봐야 하는지?
건전한 충돌이 무엇인지?


1. 실리콘벨리 지역이 많았음. 남편따라 왔음. 비자가 없어 일을 못하다가 애가 생기면서 집에 눌러앉는 케이스. 생각보다 많고, 아쉬운 인재가 많음.
2. 경력이 공백인 경우. 버클리에서 바이오쪽으로 졸업한 친구가 있는데 작년 5월에 졸업했는데 아직도 놀고 있음. 오른쪽 집 아들은 컴퓨터 사이언스 전공했는데 작년 여름 아마존 오퍼 받았다가 10월에서 오퍼를 취소, 아직 잡을 찾지 못함. 이런 케이스가 많음.
3. 나이가 있는 사람들. 갖고 있는 기술, 경험이 시장에서 불필요한 기술이 됨. 자신있게 있으면 좋을 텐데, 한 회사에 20~30년 다닌사람들이 많음. 졸지에 40대 후반에 직업을 잃고 집에 있게됨. 요새 100살까지 살게됨.

  • 자신감이 없다. 자신감이 없으니 혼자 있고 바깥으로 안나감.
  • 서포트 네트워크, 커뮤티니로 서로 배우고 밀어주고 끌어주면서, 성공하는 모습을 앞의 몇 사람이 보여주면 잘 따라가는 구나.


미국엔 인턴십 외에 리턴십이 있음. 지난 2년이상 풀타임으로 일을 해본 경험이 없는 사람이 없는 사람들을 위한 프로그램. 미국에서 일할수 있는 영주권, 시민권만 있으면 지원 가능. 큰 IT 회사들은 거진 운영하고 있음. 보통 16주 정도 함. 잘 하면 풀타임으로 바꿔줌. 삼전에서 10년 이상 일했다가 미국와서 10년 가정주부로 있다가 이 프로그램 듣고 meta로 입사.

  • 왜 이런걸 하는가? 숨어있는 진주들이 많이 있다는 것. 회사들은 손해보는 행동 안함.

이러한 모임을 주선하는 비영리 단체도 있음.
한쪽에 경력을 재개하고 싶은 사람들 모으고, 한쪽은 그러한 사람들을 뽑고 싶어하는 회사를 모아둠.
유데미도 주최했었음. 경력의 단절이라는게 본의아니게 많이 생김. 남자의 비율도 적지 않음.

두번째 경력단절

유데미 초창기 멤버 2명이 있었음. 피터: 23살, 스탠포트 경제학 전공. 데이비드: 버클리 공연학 전공 나이 비슷. 흔히 문송함. 유데미가 아주 작을 때 별볼일 없는 포지션으로 들어옴. 데이비드: 강사 마케팅 팀 주니어. 둘이 업무시간 끝나면 SQL 공부해서 유데미에 관련 강의 올렸음. 유데미엔 업무 전환 제도가 있었음. 1년 일하고 업무 퍼포먼스가 높으면 새로가는 팀의 매니저가 OK 하면 갈 수 있었음. 이런 제도는 대부분 실리콘밸리에 있음. 피터는 마케팅 팀에 있다가 데이터 분석, 이후 분석가로 팀으로 조인. 이후 데이터 사이언티스트, 매니저까지 하다가 다른 회사로 이동. 주니어 강사 마케팅하다가 프로덕트 매니저로 같이 일함. 지금 투자회사로 옮김. 초창기 멤버라 주식을 많이 받고 경제적으로 안정적임.
시작은 본인들이 생각했던 것보다 안 좋았을 수 있음. 그래도 열심히 하다보면 길이 생긴 케이스.


실리콘벨리는 개발자가 갑인 세상. 온갖 종류의 사람들이 개발자가 되고 싶어함.
파이썬, 여자만 뽑는 프로그램. 12주, 2만 5천불 받음. 이정도의 돈을 낼 사람은 많이 않음. 미국은 다원성을 따지다보니 성비를 맞추려고 하는 경향 있음. 이력서 파이프라인 보면 성비 8:2, 많아야 7:3. 이런 부트캠프에서 발표 잘하는 사람들. 샌프란시스코 IT 지역 회사에서 많이 옴. 인턴으로 뽑거나 인터뷰 하자고 함. 기용님도 보고 3달 인턴 시켜보고 괜찮아서 풀타임으로 전환. 그 전엔 코딩을 어렸을 때부터 배우면 좋다고 생각했었음. 그러나 고정관념을 깨게 된 계기가 됨. 열심히 하고 논리적으로 생각했고, 이해가 안되어도 천천히 차분하게 붙들고 늘어지는 끈기도 있었음. 데이터 엔지니어링 팀에서 두번째로 뽑았던 사람. 1년 반 정도 배우고 갑자기 얘기하자고 함 (안좋은 느낌임. 다른데 오퍼받았다는 얘기). 에어비엔비에서 오퍼를 받음. 32살에 코딩 처음 배워서 1년 반 동안 일하고 에어비엔비로 조인함. 보통 막을 수 없음. 1년 반 있다가 다시 유데미로 돌아옴. 재밌긴 했는데, 자기가 재밌게 일하기엔 힘든 환경이었다고 함. 너무 일을 잘하는 사람들이 많아, 자기가 기회를 발휘하기 힘들었다고 함.

문열고 나가면 끝이라고 생각할 수 있지만, 다시 원상복귀 할 수 도 있음 (다만 원래 있던 조직에서 평판이 좋았어야 함. 사고치지 않고).
야후에서 팀원 하나가 스타트업에 조인한다고 해서, 송별회를 함. 미국은 팀 회식은 거진 점심이었으나 오래 일한 사람이라 저녁에 밥 먹고 헤어짐. 그 다음주에 연락와서 회사가 생각했던 것 보다 너무 안좋았다 돌아올 수 있는가? 한달 안에 돌아온다면 원래 있던 베네핏을 다 복구를 시켜줌. 아 결정했다고 끝이 아니구나, 마무리를 잘 했고 평판이 좋으면 돌아올 수 있음. 꽤 놀리기도 함. 1년 있다 다른 회사로 가는 송별회 함.

  • 뭔가 내가 하나의 결정을 하면 다시 돌아올 수 없다고 생각할 수 있지만, 돌아올 수 있음

다원성

  • 다양한 백그라운드가 있는 사람들이 있는게 좋음

    의견 교환을 할 때도, 비슷한 사람들끼리 있으면 다른 의견을 잘 못받아 들임


다양한 의견.
젊은 남자들만 있을 경우 - 브로그래머스라고 함.다른 백그라운드가 들어오면 배척할 수 있음.


남편따라 미국에 유학왔다가, 가정주부로 경력단절 된 케이스.
이러한 직업교육을 지원하는 비영리 단체.
기용님. 코딩 멘토링 제안.
5분, 한인 학생 5명. 총 10명을 코딩을 가르침.
10주동안 1주일 2시간씩 숙제도 줌.
젊은 사람들이 더 빠릿하지 않을까?
10주가 끝나서 보니 아니었음. 젊은 사람들은 노느라 바쁨. 오히려 집중을 못함.
가정주부 분들은 절박함이 있음. - 다시 일하고 싶다는 욕망이 상당함. 훨씬 더 열심히 하심.
나중에 다 직업을 가지심.
그 중 한사람이 취직을 하니, 남아있는 사람도 아 나도 하면 할 수 있구나 하고 롤모델이 생김.
엄마가 남게 되는 이유가 경제적인 이유. 초반엔 애를 봐주는 사람을 구하는게 돈도 많이 들고, 믿기 어려운 이슈가 있음. 본의아니게 시작했다가 오래가는 경우임. 젊은 부부에게 해줄 수 있는 말은 꼭 맞벌이를 해라. 각자 커리어를 가지고 가는게 건강한 관계. 꼭 돈을 생각해서가 아님. 엄마, 아빠가 바쁜게 좋은 교육. 오히려 간섭하는경우 있었음.
2000~3000명정도 코딩, SQL, 등 데이터 스터디그룹이 자발적으로 돌아감.


40대 중반. 미국에 온지 4~5년 됨. 데이터 분석가 신입으로 처음 들어옴. 미국은 나이를 덜 따짐.

이렇게 성공 사례들을 보며, 의미있는 일이었다는 것을 깨닫게 됨.


실리콘벨리 데이터엔지니어링, 블로그
파일도 나중에 공유할 예정.
취업 준비를 굉장히 체계적으로 함.


공부좀 그만하고 일을 해라.
공부를 한다는게 좋은거 같지만, 현실도피적인 측면도 있음.
공부는 한도 끝도 없음. 몸으로 부딪히고, 면접 많이 해보는게 좋음.


야후에서 근무할 때
매니저를 하려고 보니 문화도 다르고 부족한 부분이 많음. 책도 굉장히 많이 읽으심. 주변에 이런 경험이 있는 사람들을 찾아다니며 배우심. 강의로 만들기도 함. 라인플러스 매니저들을 대상으로 강의도 하심.
이 중 피드백 부분만 발췌.


피드백? 매니저가 팀원에게 줄 수도 있지만,
내 모든 인간관계에 적용됨.

  • 신뢰가 제일 중요. 믿음이 있어야 주기도 편하고, 받아들이는 사람도 아 이사람이 나를 해하려고 하는게 아니구나
  • 내가 별로 인터렉션이 없는 사람이라면 할 얘기가 없음.
  • 내 관찰을 바탕으로. 나쁜건 남의 의견을 가져다가 말함. 도움이 안됨.
  • 내가 관찰, 나의 생각 피드백, 돌려 말하지 않고, 그렇다고 감정적으로 얘기하는게 아님. 나의 기대, 관찰 사이의 갭을 말하기.


책의 내용을 기반함.
망해가는 팀의 5개의 역기능.
1. 신뢰가 없음.
2. 아무도 말을 안함. (질문, 얘기하면 책잡힐 것 같아 얘기를 안함.)
3. 결정이 내려저도 헌신을 안하게 됨. (저건 내가 내린결정도 아닌데)
4. 책임지지 않음.
5. 결과가 안좋음.

잘되는 회사는?
1. 서로 믿음이 있음.
2. 자기의 생각을 더 드러냄. 질문이 많이 나옴. (질문하기 편한 환경, 질문을 갖고 사람을 판단해선 안됨. 서로 다른 의견을 공유하고 결정이 내려지면. 100% 일치하지 않더라도 내 생각과 조금 다른 방향으로 가더라도 괜찮음. 사람들은 내 의견을 들어주길 바라지 꼭 의견대로 가는걸 원하지 않음.)
3. 헌신을 하게 됨.
4. 책임을 지려고 함.
5. 결과를 내게 됨.

어떻게 신뢰를 쌓을 수 있는가?

인간적인 모습을 보여야 함.

  • 실수했을 때 실수했다고 말해야함. 그자리에서 말을 못했더라도, 돌아와서 이야기 하기. (특히 리더한테 중요. 팀원: 아 실수할 수 있구나. 반복 실수 주의)
  • 리더라고해서 다 아는 것은 아님. 모두의 의견을 물어보기.
  • 항상 되물어보기. 너 생각은 어때?. 내가 아는것보다 팀원이 더 잘알 수 있음. 자기검열을 하는 팀원은 질문을 하고 되묻고 싶어함.
  • 리더는 말을 좀 덜하고, 주변 사람이 말을 많이하게 하고, 결정을 잘 내리는 것.
  • 잘못을 쪽팔려하지 않기.


남자보다 여자의 만족도가 낮음.
지금 회사에서 당신이 하는 일에 비에 보상을 제대로 받는가? (0-5점)

여자 팀원들만 모아서 미팅을 함.
뭔가 큰게 있는건 아님.
작은게 모여 불만이 생겼음.
꼭 여자라고 해서 생기는 건 아님. 소수인 경우, 덜 적극적인 경우 생길 수 있는 문제.

그 중 미팅이 문제였음.
말이 많은 백인남자 몇명이 있었음. 미팅에서 말할 기회를 찾다가 미팅이 끝난다.

그다음 미팅할 때, 매니저들에게 언질함. 말 너무 많이하면 제제, 꼭 집어서 발표 시키기.

그자리에 조용히 있는 사람들에게 말을 시켜야함. 성격의 문제이지 덜 적극적인건 아닐 수도 있음.

주기적으로 1:1로 만나서 맨날 하는 업무얘기 하는게 아니라, 이 사람이 어떤 일을 하는지는 다른 루트로 알아내야함. 팀 미팅에서 프로젝트 상황 얘기. 스탠드업이라고 매일 각자 무슨일 하는지 공유됨. 1:1 미팅에서 정말 해야할 얘기는, 이사람이 어려운 문제가 무엇인지. 신뢰가 생기고 내가 얘기를 하다보면, 더 오픈을 하게 됨.
맥스님은 월, 화 미팅 때는 주말에 뭐했는지, 목, 금 때는 주말에 뭐할건지. 그리고 마지막으로 내가 무엇을 도와줄 수 있는지.
1:1로 얘기하는 것의 중요성.

가끔을 1:1로 얘기 해보기. 상대에 대해 더 이해할 수 있음.
얘기를 하다보면 더 생김.

어떤 사람들은 말이 짧은 사람도 있음. 맥스님은 30분 하려고 하지만 5분이면 끝나는 경우가 있음. 그럼 조급해하지 말고 점차 6,7,8분 씩 의도적으로 늘리기.

베스트 프렌드가 되라는 것이 아님.


기술적인 피드벡은 사람들이 잘 받아들임.
행동양식 피드백은 상대적으로 덜 긍정적. 이건 내 장점인데 무슨소리지?

행동양식, 건설적인 피드백은 어려움. 어느정도 올라왔을 때 받게됨.

  • 내가 꼭 옳다고 생각하지 않기
  • 선의를 바탕으로 해야함.
  • 내가 못마땅한게 있는데, 건설적 피드백 관점에서 내가 아쉬운게 뭔지, 하고싶은게 뭔지. 너무 많이 생각하지 말고 하나만 생각해야함. 핵심도 불분명해지고, 여러개를 동시에 얘기하면 혼란스러워짐.
  • 문제의 크기를 생각해보고, 이걸 지금 얘기하는게 맞나?
  • 작은거라도 패턴이 보이면 얘기해주는게 맞음 (미팅 때 매일 5분씩 늦음.)
  • 나와 같이 일하는 동료

  • 장단점 명확한 사람이라면 장점을 최대화.
  • 레벨이 오르고 상황이 바뀌다보면 그사람이 생각하는 장점이 어느순간 단점이 되기도 함.
  • 행동양식 피드백에 많음. 본인이 생각하는 장점이, 매니저나 주변사람이 볼 때는 단점.
  • 처음에는 못받아들임. 무슨소리냐. 내 장점인데. 그런거 말고 진짜 피드백을 줘.
  • 긍정적인 피드백을 줄 때도 구체적이어야 강화학습이 됨. 그냥 잘했다 고맙다보다 왜 잘했는지, 왜 고마운지 얘기를 해줘야 함.
  • 신뢰가 없으면 건설적 피드백 안먹힘.
  • 선한의도를 갖는다는 건, 상대방이 좀 싫어하는 사람. 상대가 내가 믿고 일을 시킬수 있는 사람이 아니라도 선의를 가져야 함.
  • 내가 기대했던걸 얘기, 내가 관찰했던걸 얘기, 그 차이에 대해 이야기하고 줄일 수 있는 방법을 찾아보는 것.
  • 어떤 사람이 프로젝트를 하고 있는데, 이번주 금요일까지 끝내기로 함. 이 사람이 일하는 모습을 보니, 절대 못 끝낼 것 같음. 이걸 잘못 접근하면, 이 사람이 날 무시하네? 내가 만만한가? 감정적이게 됨. 뭔가 내가 오해, 모르는게 있을 수 있겠지로 시작해 빨리 터트려야함. 가볍게 얘기 시작. 지금 당신이 하는 이 일 진행이 다음주에도 안끝날꺼 같다 얘기해보자.
  • 내가 한번 얘기했다고 해서 상대가 바로 이해하지 않음.
  • 중요한건 반복해서 얘기해야 함. (경험)
  • 문제를 마음 속에서 키우다보면 감정적으로 터지게 됨. 작을 때 어떻게 터뜨릴 수 있을까. 감정적이지 않고 객관적으로 다룰 수 있을까?
  • 하다보면 상대가 느끼기에 건설적 피드백이라기 보다, 일을 더 잘하기 위한 방법으로 인식.

  • 결국 다 간접적인 비난
  • 아쉬운 얘기를 하기 겁나니까. 장점, 단점, 끝날 때 장점. 듣는사람에선 뭔소리 하는거야?
  • 가작 최악: 바디랭귀지로 불만
  • 남의 얘기하면서 돌려까기. 내 의견만 얘기할 것.


주니어일 땐 아주 좋았음. 레벨이 올라 시니어가 되면, 중요한 일을 열심히 하는게 중요. 자잘한 것도 열심히 하면 일의 경중이 없음.
완벽주의.
좋게 얘기하면 장점이지만, 많게 보면 민폐.
자기가 갖고 있는 루틴임. 상황에 적응하는 사람은 아님.
과거의 성공방정식에 머무름. 더 이상 장점이 아님. 그렇게 하면 성공할 것이라는 잘못된 믿음을 갖고 있음.
본인만의 comfort zone에서 나가야함.

5년 같이 일했음.
엔비디아에서 일 잘하고 있음.

주니어의 경우

일을 왜 해야되는지, 어떤 임팩트가 있는지 생각 안하고 완료하는데 집중.
스프린트 처리하는 티켓 수를 보면 제일 많은데, 어떤 가치를 만들어내는지 보면 별 의미가 없음.

우리가 일을 하는 건 가치를 만들어내가 위해서임.
내가 맡은 일을 그냥 완료만하고.

맡은 일을 끝내고나서 뭔가 더 해볼수 있는지 생각해보기
Extra mile을 가기.
5~10분 더 생각해보기. 더 좋게 만들 방법이 뭐가 있을까. (중요한 일이 있을 때)

일을 잘 하는 것에 대한 의미를 모르고 있던 엔지니어

슬픈 얘기지만 해피엔딩

개발자인데, 코딩을 못함. - 큰 문제임.
좀 로지컬하게 생각하고 코드를 짠다기 보단,
그냥 코드 막 짬.

피드백 받고 2주쯤 지나면 원래대로 돌아감.
거기게 맞게 점진적으로 변화하는 모습을 보고 싶었는데, 시간이 지나면 원상복귀.

풀타임 전환 실패.

정말도 니 인생에서 하고싶은게 뭐냐.
동기부여가 되고 있는거 같지 않았음.

세일즈 엔지니어링
서포트 엔지니어링

오피스에 앉아서 개발하는게 아니라, 영업팀 따라다니거나, 서포트 콜 응대해 기술적으로 해결해주는 사람. 말도 잘해야되고,

석달 있다가 연락옴. 세일즈 엔지니어로 일하고 있음. 얼마 전에도 만나서 점심 먹음.
경험이 많이 쌓인 후에 이렇게 말을 할 수 있었음

피드백을 너무 두려워 말기. 실수했을 때는 미안하다고 하기.

네번째 케이스
카네기 컴퓨터사이언스 전공. 인턴
백그라운드 특이함.
잡을 바로 가진게 아니라 로스쿨 갔다가 2년 다니고 졸업 못하고 그만 두고 다시 개발자로 돌아온 특이 케이스.
인턴 때는 잘하더니 풀타임 컨버트 되니 본색이 나옴.
11시 ~ 12시 지각 출근함.
맥스님 앞에 앉아있었기에 물어봄.
중간 매니저가 얘기를 잘 못하길래 직접 물어봄.
게임하느라 늦었다고 함.
피드백을 주면 2주정도는 출근 시간이 괜찮아짐.
11시 전에만 오면 뭐라 안함. 중요 미팅은 11시 부터 있다보니 이걸 늦는게 문제.
시간이 지나면 원상복귀함.
결국 해고함.
마지막에 물어봄.
인생에서 정말 하고싶은게 뭐냐. 능력도 있는 사람인거 같은데, 자기는 컴퓨터 사이언스가 딱히 좋지 않았는데, 부모님이 가래서 갔고, 아버지가 변호사가 되라고 했고. 자기가 생각해서 결정해본적이 없음. 게임 개발을 해보고 싶다. 그거 보고 아는 게임 개발사 소개해주기로 함.
지금 게임 개발자로 일하고 있음. 잘 지내고 있음.

  • 상대를 위해 선의를 기반으로 얘기해주면, 처음 관계가 불편할 수 있어도 관계가 망가지진 않았음.

  • 처음 매니저 때 해고한 2명의 직원은 원수관계가 되었음. 불만족스러운 관계가 이어졌고 참다가 터지는 모습으로 해고하게 됨.

  • 터지기 전에 작게 줘야하는 구나. 여러 책을 읽고 공부를 하심.

  • 기대, 관찰, 갭은 책에 있는 내용.

맥스님도 공부, 적용, 실패, 좀 더 나아지는 과정을 겪으심.
모든 일을 처음부터 잘할 수 는 없음.

그룹으로 일하다보면 알게 모르게 CONFLICT가 있을 수 있음.
1:1 대화 많이 하기.
회사에 가서 업무를 해도 크게 달라지진 않음.


skt 데이터 엔지니어에게 했던 얘기


가장 전문자로 여겨짐.

블로그로 굉장히 잘 작성함.

데이터 엔지니어의 역할

  • 데이터 웨어하우스 관리
  • ETL 작성하고
  • 그것과 관련된 튜닝, 최적화
  • 관련 서비스들: 데이터 이상감지, 데이터의 데이터, AB테스트, 사용자 행동테이터 잘 로깅, 분석


메타 데이터 관리 중요해짐
ETL이 많아지면 데이터 엔지니어가 관리, 운영해야하는 그 중 하나라도 잘못되면 뒤에 서비스가 영향받음.

누가 ETL 요청했는지 기록해놔야함. 처음엔 몇개 안되기에 다 기억. 그러나 퇴직, 점차 많아지면 누가 요청했는지 모름. 파이프라인 실패했을 때 이걸 누구한테 물어봐야지? 하는 경우가 생김.
-> 데이터 엔지니어들이 신경써야할 부분
-> DataOps 라고 불림. 데이터 퀄리티, 누가 소비하는지 이해하고 운영하자.

AB테스트, 추천엔진 만드려면
사용자 행동 분석 잘 하기
이상 데이터 감지


SQL 잘해야함.
그 SQL을 가지고 데이터 모델링. raw_data만 가지고 쓸 순 없음.
ELT를 데이터 분석가가 하기도 하지만, 엔지니어가 만들기도 함.
ETL을 어떻게 디자인하고 구현할 것인가가 중요해짐.
백필이 중요해짐. 데이터 엔지니어의 삶을 불행하게 함.
AI 기술이 워낙 발전하고 있기에 거부하지 않고 더 잘하기 위해 활용하는 방법.
코드 코딩도 프롬프트 줘서 만들어봄.
테스트 케이스는 내가 만들고.
프로젝트 아이디어도 GPT랑 대화하면서 조금 더 구체적인 아이디어 생성.
항상 정답을 얘기하진 않음.


Spark 나중에 배움
데이터 레이크의 활용. 나중에 Data Mesh.
중앙 데이터 팀이 인프라 만들고 머신러닝 했지만, 데이터 활용 요구가 현업부서에서 생김. 현업부서들이 직접 데이터 분석, 데이터 인프라도 갖기를 원함. 보통 중앙 엔지니어들이 마케팅팀 전용 데이터 웨어하우스 셋업. 중앙 팀이 모든걸 하는게 아니라, 약간 플랫폼화 되어 DW ETL 같은걸 각 팀에 론치할 수 있게 함.

배치 -> 스트리밍으로 넘어감.
에어플로우는 배치 프로세싱.

카프카라는 스트리밍 큐, 실시간 데이터들을 어떻게 처리하느냐.
중간에 메세지 큐를 둬서 데이터를 기록, 반대쪽에서 기록을 읽음


SaaS가 완전히 대체는 어려움. 데이터 엔지니어 수가 부족해, 힘들고 덜 중요한 파이프라인을 SaaS를 씀.
데이터 중앙 집중 -> 탈중앙화, 민주화. 현업부서가 직접 데이터 분석
데이터 분석가들은 분산되는 형태.
현업에서 일도 하며 데이터 분석도 겸

세이지 메이커 등을 써서 모델링부터 배포 모니터링을 자동화하려는 노력이 생김.(MlOps)

개인정보 보호법이 딱히 없었음. GDPR, CCPA를 보고 세계 모든 나라들이 개인정보보호법을 만듦. 개망신위.

인공지능 엄청나게 발전 중. 이런 툴을 사용해서 내가 하는 일을 효율적으로 만드는 것은 중요함. 옆에 친한 친구, 비서처럼 계속 대화해볼 것.


많이 데이터 소스, DW을 연동.
많은 경우 패턴이 있음.
mysql 테이블 읽어다 redshift에 적재.
많이 쓰이는 것들이 있기 때문에, 코딩 없이 configuration만 있으면

결정적인 문제가 있음.
가격이 절대 싸지 않음.
소스 데이터 특성을 모르니 incremental 업데이트를 하지못함.
full 로 읽어다 적재하는건 잘함.
그 전날 바뀐것만 읽어오는건 잘 못함. 불필요하게 비효율적으로 하며, 레코드들을 다읽어옴.
ETL로 받아온걸 또 ELT화 해야되다보니 에어플로우 작업이 필요함.

데이터 엔지니어가 하는 일을 보조해주는 정도.

직접 구현하려고 보니 API가 너무 복잡한 경우.
나중에 저 파이프 라인 구현해본 엔지니어가 조인 했을 때 고침.

데이터 엔지니어 고용이 어려울 때 써볼 수 있음.


좀 더 플랫폼 적인 일을 하게 될것임. (여러 부서 전용)
데이터 품질 어떻게 올릴 것인지?

굉장히 많은 데이터가 생기면 메타데이터를 위한 데이터 카탈로그 -> 데이터 디스커버리 서비스


데브옵스 - 개발자 만든 코드를 테스트, 문제없음 확인 후 배포, 모니터링
mlops - 머신러닝 모델에 대해, 빌드, 테스트, 배포, 모니터링
데이터옵스 - 파이프라인 타고 오는 데이터 품질을 관리


순간 순간 데이터 품질 이슈가 생길 수 있음.
모르면 그대로 데이터 카피
최종적으로 쓰는 데이터에도 문제가 생김.

레코드 수
중복
PK 유효성 보장여부
필드가 카테고리 값이면, 내가 예상한 카테코리 값 있는지
최근 데이터가 있는지
시간이 지나면서 사고생기면 체크를 붙여야 하는 구나 알게됨.


코드를 체킹하면


요 체크를 별로 안하게 됨.
데이터 사용 인력이 늘어나게 됨에 따라 점점 중요.
내가 처리하는 데이터 품질을 어떻게 처리하느냐 중요.
코드는 한번 작성하면 바뀌기 전까지 안바뀜.
외부 데이터는 데이터가 바뀔 수 있음.
테스트를 많이 붙여놔야 함.


품질 이상 체크도 있지만
인프라 수준 체크도 있음
redhift, spark 잘 돌아가는지
etl, dag가 성공적으로 끝났는지

레코드 수 확인
통계 내봐서 이상한지
mod 가장 많이 발생한 값.

이렇게 스냅샷을 주기적으로 만들어 확인하면.
일일히 코딩을 할 수 도 있고, 모니터링 툴을 사서 임베드하면 자동으로 알려주기도 함.


실패시 누구에게 어디에서, 왜 실패했는지 알려주는게 중요해짐


데이터 파이프라인 ops
미국은 점점 생겨나는 중
한국은 아직


데이터 파이프라인 작성, 관리 표준 프레임워크가 됨

Prefect, Dagster 까지가 대안이 될 수 있음.

profile
반갑습니다 햄스터 좋아합니다

0개의 댓글