데이터는 차트가 아니라 돈이 되어야 한다.
•
502 j'aime•56,746 vues
데이터 분석에 대해 이야기는 많이 나오지만, 실제로 변화를 주는데 굉장히 힘이 듭니다. 데이터를 액션으로 옮기는데 어떠한 어려움이 있고, 어떻게 타개해야 하는지에 대한 팁들을 정리해보았습니다. 넘버웍스 만세
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (13)
Similaire à 데이터는 차트가 아니라 돈이 되어야 한다.
Similaire à 데이터는 차트가 아니라 돈이 되어야 한다. (20)
데이터는 차트가 아니라 돈이 되어야 한다.
- 1. 데이터는 차트가 아니라 돈이 되야 한다. NUMBERWORKS 대표 하용호 yongho.ha@numberworks.io
- 2. 하용호 용 호
- 5. 수십페타바이트를 원없이 만져본 행복한 시간이었지만 동료 데이터 과학자들이랑 같이 졸업을 하고 넘버웍스를 만들었습니다.
- 6. 넘버웍스 = 데이터사이언티스트 + 데이터사이언티스트 + 데이터사이언티스트 + 데이터사이언티스트 그 귀하다는 경험많은 데이터 사이언티스트가
- 7. 오늘은 데이터 필드에서의 지난 경험들을 나누는 자리
- 8. Data Science는 공학과 마케팅 사이 Engineering Marketing DataScience 무게중심이 마케팅쪽으로 옮겨지고 있다.
- 9. 여러분은 점점 사장님과 가까워집니다. DataScience 무서운 일이죠. =_= CTO CEO
- 10. 사장님은 왜 무서운가? 사장님이 궁금한 것은 단 한가지 “그거 돈이 되냐?”
- 11. 돈으로 이야기 해줘야 한다. • 고객이 얼마나 늘었고 • 한사람당 얼마를 더 썼고 • 그래서 우리는 얼마를 더 벌게 될 예정입니다. 그런데 우리는 이 질문 앞에 작아집니다.
- 12. 왜 작아지는 걸까? ‘액션’을 하지 않기 때문에 ‘분석’은 많이 하는데 비해서
- 13. ‘액션’ 하지 않으면 아무일도 안생긴다
- 14. 애초에 Data Science 라는 말을 생각해보면 왜 Data Science 이지?
- 15. 관측 가설실험 과학의 방법론에 따라 일하기 때문 (Action) 그 중 실험 부분이 바로 ‘Action’
- 16. 관측 가설실험 그런데 대부분의 회사들은 (Action) 실험(Action)을 잘 하지 않는다.
- 17. 마음속의 거리 멀다고 느껴지면 안가게 된다. 관측 가설 실험
- 18. 이것 때문에 발생하는 느린 이터레이션은 매우매우 큰일!!
- 19. 좋은 비유 대상이 있다. 테테테. 테니스!
- 21. 테니스 연습을 하는데 공이 돌아오는데 30분이라면? 실력이 늘지 않아!
- 22. 오늘의 주제는 저 두 산을 허무는 법 관측 가설 실험 빠르게 iteration하기위해
- 24. 현업의 로그는 어떤 양상인가?
- 25. 현업의 로그는 어떤 양상? 없거나 쓸 수 없거나 (그런거 없ㅋ엉ㅋ) (현재 상태 DB만 있는뎅)
- 26. 로그를 남기려면 고민이 필요 “뭘 남기지?” “어떤 형식으로 남기지?” “어떻게 전송하지?” “어디에 저장하지?” 몰라@.@ 정하기 어려워 안남기면 해결된다. 의식의 흐름 1) 왜 없나?
- 27. 로그를 기록하는 과정부터 중앙 repository에 붓는 작업을 한정식에서 라면화 시켜야 한다. 고민없이 가져다 쓸 수 있는 로그 레시피의 제작 및 보급 그래야 남는다
- 28. • “우리도 데이터 있어요” • 막상 가보면 DB에 현재의 state만 남아있음 • 예를 들어 같은 통장 잔고 100만원도 • 1000만원 벌고 900만원 탕진한 100만원인 사람과 • 110만원 벌고 10만원 아껴써서 100만원인 사람 다름 • 이력이 필요합니다. state가 아니라 history 2) 왜 쓸 수가 없나?
- 29. 자. 이제 로그가 분석가에게 쓰여지려면 어떤 가공을 해야 할까?
- 30. 분석가들은 어떤 사람인가? 통계 지식 R 같은 데이터 언어 비지니스 유관 지식 이들이 자료를 보기 위해 MR짜고 있으면 망함
- 31. 몇가지 이유에서 망함 • 분석가가 MR을 짜고 있으면 작업속도가 느려져, 하루에 몇 번 밖에 iteration을 돌 수 없다. • 그렇게 짠 코드가 버그가 없을 쏘냐? • MR을 작성할 줄 아는 분석가는 매우 소수다. • 뽑기 어렵다. 사람이 있어야 일을 하지.
- 32. 바로 R, ipython 등에서 쓸 수 있게 데이터를 Ready 시켜야 한다. 이들이 편한 언어 SQL 결국 테이블화 되어야 함
- 33. 분석가 SQL SQL SQL
- 34. 추천하는 방법은 자료들을 모두 Hive테이블화 시켜버리세요
- 35. 왜 hive table와 시키나요? • 생짜 로그 파일은 그 자체로 자기 기술적이지 못함 • 몇번째 필드는 이름은 뭐고, 어떤 속성인지 등 메타와 바인드 필요 • 이거 분석가가 자꾸 직접 해야 하면 화낸다. • 꼭 hive를 query엔진으로 쓰지 않는다 하더라도 • Impala, Tajo, SparkSQL 다른 멋진 query엔진들 • 저들이 native로 읽어갈 수 있는 표준 자료 저장소로 좋은 포맷 • 보유 프로세스 비용이 없음. 안돌릴 땐 메타서버만 살아있음 • 평소에 CPU, RAM등을 차지하고 있지 않음
- 36. Hive Table 만드시고 쓰는 것은 Impala, Tajo, SparkSQL 원하는대로 쓰세요 + Hue (web ui)는 꼭 열어줄 것 -접하기 쉬워야 많이들 쓴다-
- 38. 분석가들이 일을 잘할수록 엔지니어들은 힘들다. 왜?
- 40. 이 일은 참 고되다. • 많은 MR, Spark, Hive job들이 얼기 설기 섞여 돌아간다. • 각 작업은 다른 여러 작업들에 dependent할 때가 많다. • 자료의 입수가 때로는 지연된다. • 머신 Fail로 뭔가가 안만들어지는 경우도 많다. • 안되요. 어 앞의 것이 안되었네. 어 그 앞의 것이. 또 앞의..
- 41. 요 테이블, 우량고객 계산할 때 기준값을 바꾸었어요 (방긋) 이 와중에
- 42. 새로 다 다시 돌려! 자주발생한다. 이것의 절차적, 심리적 부담감을 줄여야 작업이 쉬워진다. (안그러면 분석가를 압박하게 됨. 좋게좋게 삽시다하고. ‘안되요’남발)
- 43. 우리의 선택
- 44. 루이지 from
- 45. 마리오 형제는 원래 배관공 이게 사실 파이프
- 46. 우리가 하는 일도 pipe의 연장과 연장 • 이거 되고 나서, 이거 되야 하고 • 저기서 물길이 들어오면 • 요 물길과 합쳐서 섞어 다음으로 보내고
- 47. luigi : 각 자료마다 자신이 만들어지기 위한 의존성을 정의해 놓고 모아놓으면 뭐 어떻게든 다 잘될거야. D C C A B A 0 1 2
- 48. D C C A B A 0 1 2 D C A B 0 1 2 D를 주세요! 있으면 가져오고 없으면 자동으로 만든다.
- 50. luigi를 도입하고 • 앞에 어떠한 데이터가 망가졌어도 • 최종적으로 가지고 싶은 데이터 테이블만 지정 실행하면 • 그것을 위한 모든 dependency가 계산되어 자동으로 만들어진다. • reprocessing? = 코드 수정 + 과거 날리고 + luigi run
- 51. 루이지를 만나고 제 삶이 달라졌어요
- 52. 데이터 엔지니어링은 자료의 순환 속도를 고속화하고 처리의 심리적 부담을 줄이는 방향으로 진행되야 한다.
- 54. 분석가들의 어려움 2) 분석했더니 현업이 이미 아는 것들이래요 1) 어떤 문제부터 분석해야할지 모르겠어요 정상입니다.
- 55. 1) 어떤 문제부터 분석해야할지 모르겠어요 분석만큼 중요한 것이 현업의 협조 그렇다면 어느 현업 부서와 일해야 하나?
- 56. 원피스의 명대사
- 57. 회사는 언제 데이터를 본다고 생각하나? 일이 안되어 갈 때
- 58. 현재 어려움이 있는 부서로 가세요 • 잘나가는 부서는 인사이트를 드려도 심드렁 합니다. • 잘하고 있거든요! • 힘들어하는 부서는 데이터 조직에게 아이디어를 줍니다 • 그리고 잘 도와줍니다. Action을 함께 할 수 있습니다. • Small Win을 쌓으세요. 이걸로 큰 부서에 영업하세요
- 59. 2) 분석했더니 현업이 이미 아는 것들이래요 다시말하지만 정상입니다.
- 60. 분석의 목적은 기적의 창조가 아님 • 대부분의 경향성은 현업도 알고 있습니다. • 분석의 힘은 정량화 - 양과 크기를 안다 - 에 있음 • 돌을 던지면 날아간다는 초딩도 알지만 • 힘, 각도, 날아간 거리를 재면 사람이 달도 간다. • “양을 정확히 안다.” -> “예상과 액션을 가능케 한다”
- 61. 그리고 현업이 빠지기 쉬운 함정이 있다. 심슨 패러독스 (이 심슨 아님) (Simpson’s paradox)
- 62. B병원이 진료를 잘합니다? 환자수 생존자수 치료율 A병원 500 290 58% B병원 500 320 64% 환자수 생존자수 치료율 A병원 400 200 50% B병원 200 80 40% 간질환 위질환 환자수 생존자수 치료율 A병원 100 90 90% B병원 300 240 80% A병원이 진료를 잘합니다!
- 63. 나누어 뜯어 보면 전체를 볼 때 몰랐던 숨은 진실을 발견할 수 있다!
- 64. Robert Capa.
- 65. "만약 당신의 사진이 만족스럽지 않다면 그것은 충분히 가까이 가지 않았기 때문이다." "만약 당신의 분석이 만족스럽지 않다면 그것은 충분히 나누지 않았기 때문이다."
- 66. 기존의 상식이라 받아들여지는 것도 나누어 보고, A/B test 실험으로 재검증 해보는 것이 필요하다. 거기서 기회!
- 67. 역시 예제로 살펴봐야 재밌다.
- 68. 이메일은 정말 구린가? 심슨패러독스 케이스
- 69. 언제나 중요한 것은 채널! 고객이 우리를 떠나 있을 때 그들에게 접촉할 수 있는 채널! 이메일, SMS, PUSH
- 70. “에이 요새 누가 이메일 읽어요. 보내도 오픈 안해요” 0.0% 6.3% 12.5% 18.8% 25.0% 5.2% 전체유저 0.0% 6.3% 12.5% 18.8% 25.0% 15.4% 지난달 1번이라도 방문한 유저 한 쇼핑몰의 케이스 나누어보자 심슨패러독스!
- 71. 전체를 보면 죽은 채널 같아 보여도 최근 사용 유저들에겐 매우 유효한 채널 그래서 넘버웍스는 뭘했나? 고객마다 개인화하여 다른 메일내용으로 기계가 자동 뉴스 레터를 보내게 했다. (사람이 언제 다 만드나) 오픈 후 클릭율은 21%증가 클릭후 장바구니율 25%증가 베스트 상품 vs 개인화 메일
- 72. 배너는 정말 좋은건가? A/B test로 상식을 확인해보는 케이스
- 73. 우린 다들 믿고 있죠 “크고 아름다운 배너님은 고객의 마음을 둑흔둑흔하게 해줄거야” “정말일까?” 실험해 보았다. A/B test
- 74. 원안 대안1 대안2VS VS 9000명의 모든손님 900명의 손님(10%의 샘플링) 300명 300명 300명 A/B test
- 75. 크고 아름다운 배너 간소한 배너 배너 없음 121% 100% 125%
- 76. 상식을 믿지말고 실험으로 검증하라 • 당연히? 당연한거 없음 • 크고 아름다운 배너 < 배너 없음 < 얇은 배너 • ‘배너 없음’에게도 지다니!? • 진리는 그곳에 따라 다름. • 이곳은 단골 비중이 높은 회사. • 단골은 다음방문부터 배너 때문에 폰 스크롤이 지겹다. • 상품에 쓸 지면을 낭비하고 있었던 것
- 77. 항상 A/B test로 증명해야 한다. • A/B test로 증명하지 않으면 • 상식에 반하는 결과를 만날때나 • 논공행상에 문제가 생긴다. • 특히 외부가 크게 변하는 시기에는 더욱 두드러진다. • (이건 너희가 잘해서가 아니라, 원래 그런 흐름이야?) • 무조건 A/B test는 쓰라. 안 쓸 생각을 마라.
- 78. 좀 더 진보된 A/B test Multi-Armed Bandit
- 79. 사장님은 역시 다르다. “사장님 A/B테스트를 통해 양쪽에 50명씩 보내서 좋은 쪽을 알아보겠습니다!” “그러면 50명은 안좋은 쪽에 보내는 건가요?” (과연 사장님..)
- 80. 충분한 사람이 테스트될 때까지 오래 걸린다. 테스트되는 동안 나쁜 안에 사람이 많이가면 아깝다. A/B 테스트의 단점
- 81. 이를 보완하기 위해 MAB (Multi-Armed Bandit) 알고리즘이 등장!
- 82. MAB 쉬운 설명 다음중 숫자가 크게 나오는 주사위를 찾아라!
- 83. 방법1) 1번 주사위 100번, 2번 주사위 100번, 3번 주사위 100번... 방법2) 주사위를 돌아가며 한번씩 던져본다. 뭔가 조짐이 좋은 녀석을 더 자주 던져본다.
- 84. 더 빨리 찾는다. 찾는 과정중에 이득도 극대화 한다. MAB
- 85. 정리
- 86. Data Engineering 로그 레시피를 보급해서 데이터를 쉽게 남기도록 테이블 + SQL을 제공해서 분석가들이 편해지게 워크플로우로 도입으로, 변화에 부담없어져라
- 87. Data Analytics 지금 힘든 현업을 찾아서 도와줄 것 늘 나누어보며 심슨패러독스를 경계할 것 A/B test를 통해 모두 다 검증할 것 MAB를 써서 회사의 효용도 극대화 할것
- 88. 관측 가설 실험
- 89. 관측 가설실험 산이 없는 부담없는 세상 빠른 이터레이션!
- 90. 실험은 분석의 끝이 아니라 시작 실험이 부담없어지면 실험을 가볍게 진행하고 이를 통해 발견한 결과가 생각의 확장을 불러일으키는 경지 모든 고민을 끝내고 확인하기 위해 실험하는게 아니라 할 수 없던 생각을 할 수 있게 된다.
- 91. 내가 태어나서 한번도 치킨을 먹어보지 않았다면 내가 치킨을 원한다는 사실을 모른다. 회사도 고객도 일단 치킨을 먹어보자 진지합니다. 궁서체
- 92. 실험하자!!
- 93. 사실 데이터를 돈을 만드는 일의 끝판 대장은 자동화 신경쓰지않아도계속벌어다준다.
- 94. 데이터 인사이트 액션 자동화 넘을 수 없는 사차원의 벽 넘을 수 없는 사차원의 벽
- 95. 넘버웍스는 데이터 분석과 머신러닝 베이스로 액션과 자동화를 전문으로 하는 Data Science firm입니다 라끄베르, 아니 넘버웍스랑 상의하세요 (발표에서 말못한 깜짝놀랄 케이스들이 많아요)