Acquisition: 사람들을 끌어모으는 것, 최종적으로 install하게 하는 것이 목표 ex) Temu에서 룰렛 돌려서 무료 쿠폰 주고 해서 유입시키게 함 ex) Mobile: Download, New User, Demographic info(나이,성별,디바이스 타입), install tracking(어느 광고를 보고 다운로드를 하게 되었는지, 페북 광고? 유튜브 광고? 그래야 비용 효율적인 마케팅 전략이 세워짐)
Retention: 계속 들어오게 만드는 것 ex) 게임에서 신규 가입하면 30일 동안 매일 출석 시 아이템 주고 30일 다 채우면 엄청 좋은 아이템 주고, 이런 것들 ex) 보통 금요일에 Retention Rate가 높고 월요일에 낮음. 설치했다가 주말에 할 거 없으니 금욜에 하는 것임. 그래서 금욜 저녁에 광고 단가가 비쌈
Engagement: 매일 접속만 하면 끝? 상품을 검색도 해보고 상호 작용을 해야 함 ex) 쿠팡 같은 경우를 생각해보면 트래픽이 처음 어디로 랜더링될까 생각해보면 메인 페이지가 아니라 상품 상세 페이지가 가장 트래픽이 많이 발생한다. 왜냐하면 우리가 보통 인터넷을 돌아다니다가 원하는 유사 상품 상세 페이지 링크를 타고 쿠팡으로 들어가게 되기 때문이다. 그렇기 때문에 유저가 어디에서 들어오고 어디로 나가는지를 확인해야 한다. 예를 들어 보통 결제하는 부분에서 이탈이 많이 발생한다. 공인인증서하다가 빡쳐서ㅋ. 그래서 이러한 부분을 확인하고 이탈을 줄이기 위해 보강을 하는 식으로 해야 최종 Monetize까지 이어질 수 있다 ex) 유저가 들어와서 어디서 빠지는지를 시각화해서 보여줌
Monetize: 사용자가 돈 쓰는 것
이런 분석 기법들은 물론 데이터 사이언티스트들이 하겠지만, 아키텍쳐를 설계할 때 이런 insight를 가지고 접근할 수 있어야 한다
빅데이터 시스템 전략 수립
최근 빅 데이터 시스템의 목표는 필요한 사람이, 필요한 데이터를, 필요한 시점에 Access할 수 있도록 하는 것이 키포인트이다.
어떻게 돈을 벌 것인지를 정하기. 3~4개의 major indicator면 충분 (대시보드의 지표는 언제든 바뀔 수 있다)
구현: 분석이 첫번째이다. data lake를 만들던지 data warehouse 이런거 다 좋은데 요즘 오픈소스나 써드파티들 중에 좋은 것들이 너무 많이 나와있다. 그니까 거창한거 하려고 하지말고 일단 구글 looker studio 같은거 써서 일단 시스템 올리고 분석부터 해보자. 그러고 나서 사내에 적용이 될 수 있는 환경이 갖춰지면 그 때 고급진 시스템을 만들자 https://lookerstudio.google.com/navigation/reporting
그리고 빅데이터 아키텍쳐는 유연성이 있어야 한다. 지표가 언제든지 바뀔 수 있기 때문이다. 예를 들어 처음 시스템을 런칭하면 사람이 얼마나 가입했는지가 궁금하고, 그 후에는 retention이 중요하고, 그 다음에는 매출, 그 다음은 원가... 이렇게 비즈니스는 단계별로 변하기 때문에 유연성과 민첩성이 중요하다.
예측: 이렇게 잘 수집된 데이터로 비즈니스 결정하는데 도움을 줄 수 있음
그리고 요즘은 데이터 사이언티스트들의 입지가 계속 줄어들고 있는게 생성형 AI를 통해 text to SQL이 얼마든지 가능하기 때문이다
모든 데이터를 Data Lake에 넣고 다 분석하자!!! 가 예전 트렌드였다면 지금은 Data Mesh 아키텍쳐로 변화하고 있다
Data Mesh 아키텍쳐는 빅데이터 시스템의 MSA라고 생각하면 쉽다
예전에는 하나의 빅데이터에 모든 데이터가 들어가고 데이터 사이언티스트가 있었다
예전 구조
하지만 데이터 사이언티스트는 데이터는 잘 볼지 몰라도 마케팅이 어떻게 돌아가고 영업이 어떻게 돌아가는지 잘 모른다. 즉, 업무 도메인이 부족하다. 그러다 보니 여기서 문제가 발생한다. 영업 쪽은 이런걸 원하는데 말은 안 통하고 그렇다고 데이터 분석 결과도 바로 알려주는 것도 아니고~ 병목 현상+업무 도메인 지식의 부족으로 인해 커뮤니케이션 문제가 발생하는 것이다.
그러면 그냥 내가 할래~ 하면서 Data Mesh가 나온 것이다.
요즘 트렌드 - Data Mesh
팀 별로 데이터 분석팀을 만들어주는 것! → 이것이 Data Mesh 아키텍쳐의 컨셉이다
근데 여기서 문제점은 각 팀별로 소수 정예의 데이터 분석팀들이 하둡이니 카프카니 텐서플로우니 어떻게 다 하냐... 그래서 여기에 SRE 팀이 합류하게 된다
요즘은 퍼포먼스를 얘기할 수준은 이미 지났다. 160코어로 3시간 걸리는 데이터 분석 작업이 빅쿼리에서는 7초면 끝난다.
그렇다면 요즘은? 데이터의 search, 접근 제어가 중요해졌다. 데이터 접근 제어가 column이나 row 레벨까지 가능한 수준까지 왔다. 예를 들어 PII와 같은 민감한 정보가 있을 때 해당 부분만 access를 못하게 막을 수도 있다. 아니면 서울 팀에게는 서울 관련된 데이터만 보여지게 할 수도 있고 여러가지 응용이 가능하다.
또한 IP 주소, 시간대, 접속 디바이스에 따라서도 접근 제어가 가능하다. 회사에서만 접근이 가능하게 만들 수 있음
Data eye tracking이란 것도 중요하다. 데이터를 누가 사용했고 어디로 들어가서 사용되는지를 추적 가능 해야한다. 하지만 이 부분은 아직 조금 어려운게 단일 툴을 사용하는게 아니라 여러 툴을 혼합해서 사용하다 보니...
요즘 데이터 포맷 변환은 ETL이 아니라 ELT를 많이 사용하고 있다. ELT 방식은 데이터를 데이터베이스에 로딩한 후에 데이터베이스 안에서 변환을 진행하는 것을 말한다. 이 것이 가능한 이유는 데이터베이스의 성능이 좋아졌기 때문 (Snowflake나 Google BigQuery 같은 managed service 기준) / 하지만 아직 온프렘에서는 ETL을 많이 사용 중 (비용 때문에)
Data Analye - Streaming Analytics
보통 DB로 진행되는 것은 배치로 하는 것이다 → 실시간 X
카프카나 큐를 사용하거나 로그에서 바로 보내거나 하는 식으로 구현 가능하다
Real time streaming analytics에서는 실시간으로 들어오는 데이터를 윈도우라는 단위로 자른다. 완전한 실시간은 불가능하다. 현재 시점을 기준으로 동접자 수를 측정한다고 하면 정확히 현재 시점이 아니라 현재 시간 기준으로 ± 5초 이런식이다.
이런 리얼타임이 가능한 오픈소스 중 대표적인 것이 Apache Spark이다 (Apache Flink도 가능)
Fixed Windows 기법은 일정 시간 단위로 단순히 자르는 기법. 그러다보니 데이터 변화율을 측정할 때 계단식으로 측정이 되는 단점이 있다.
Sliding Windows 기법은 일부를 중첩시켜서 측정. 그렇게 되면 변화율이 계단식이 아니라 곡선 형태를 띄게 됨. 그래서 보통 Sliding Windows 기법을 많이 사용한다
User Sessions는 유저 별로 이벤트를 보고 싶을 때 사용 가능. 유저가 접속되고 idle 타임까지의 데이터를 윈도우 크기로 설정. Streaming 분석 sdk 성능이 좋아야 사용 가능하다. Spark v2는 가능 v1은 불가능. Flink는 가능
=============================
데이터를 보냈을 때 전송 시간과 도착 시간이 차이가 난다. 나는 1234를 보내도 서버에서는 3421로 받을 수 있다는 것이다. 심지어 342---1로 받아서 윈도우 크기가 안 맞다면 342로 데이터가 잘려버리는 경우도 발생할 수 있다. 그래서 리얼타임 분석에서는 순차 보장이 안된다는 문제가 있다. 그렇기 때문에 리얼타임 분석은 근사값을 보는 것이지 정확한 값을 보는 것이 아니다. 그래서 매출 정보를 리얼타임 분석으로 정산을 하겠다? 적절치 못하다. 이런 상황에서는 월 말마다 배치를 통해서 다 들어온 데이터들을 기준으로 진행해야 한다.
그래서 리얼타임, 배치 두가지 모두 적절하게 사용해야 한다
그리고 위에서 말했듯이 342---1로 들어와서 윈도우 크기에 맞지 않을 경우에 데이터가 손실이 될 수 있다고 했는데 이 부분을 복원해주는 메카니즘을 만들어주면 좋다. Apache Beam에서 다음처럼 하면 구현할 수 있다
// Apache Beam 코드
PCollection<String> pc = ...;
pc.apply(Window.<String>into(FixedWindows.of(1, TimeUnit.MINUTES))
.triggering(AfterProcessingTime.pastFirstElementInPane()
.plusDelayOf(Duration.standardMinutes(1)))
.withAllowedLateness(Duration.standardMinutes(30));
// withAllowedLateness()에서 늦게 들어온 30분에 대한 것을 나중에 후처리(Duration.standardMinutes(30))
이렇게 하면 늦게 도착한 데이터를 반영시켜줄 수 있다.
하지만 필요한 경우에만 적용할 것. 불필요하게 시스템 복잡도를 높일 필요는 없다. 1~2% 차이나면 그냥 무시, 어차피 근사값이니까. 나중에 배치할 때 정확히 보면 됨
GCP Big Data System Architecture (Data Ingest+Data Analyze)
Realtime은 필요에 따라 사용. 아니면 실시간까진 필요 없고 준 실시간 정도로 충분할 경우에는 Warehouse 배치를 15분 20분 단위로 돌리면 됨 (컴퓨팅 성능이 많이 좋아졌기 때문에 가능)
Dataflow Example with GCP
여기서 중요한 점은 요즘 좋은 서비스들이 많이 있기 때문에 간단하게 조합하기만 하면 4~5시간 만에 만들어낼 수 있다
즉, 어떻게 아키텍쳐를 짤지 머를 쓸지 이런걸 고민하기보다는 먼저 빠르게 데이터 분석을 해서 비즈니스에 도움을 주는 것이 중요하다. 나중에 좋은거 써서 만들어도 됨.
Visualization
대시보드 솔루션을 하나만 쓰지 말고 여러개를 써라
크게 3가지 정도 사용
아래와 같이 구글 시트는 백엔드에 빅데이터 시스템과 연동이 가능하다. (GCP 클라우드만 가능한지는 모르겠음, 아니면 오라클 커넥터 활용)
Looker: The Platform for Data Experiences
Jupyter 같은 경우에는 작게는 16vCPU에서 크게는 96vCPU까지도 사용하기 때문에 비용 절감을 위해 오토 idle time out을 걸어주면 좋다
데이터 분석을 잘하는 것도 중요하지만 필요한 사람에게 필요한 데이터만 보여주는 것도 굉장히 중요하다
GCP Big Data System Architecture (Data Ingest+Data Analyze+Visualization)
Workflow
Explore data: EDA 작업, 데이터에서 의미를 찾아내는 작업. 데이터들끼리의 상관 관계 파악
요즘은 이런 워크플로우를 Airflow를 많이 사용한다
Personal Information Handling
위에까지가 기본적인 빅데이터 분석 시스템이다
여기에 추가로 개인정보 보호를 추가하면 좋다
DLP (Data Loss Prevention)
개인정보 동의서를 쓴 데이터는 상관이 없지만 그렇지 않은 경우에는 처리를 해주어야 한다
구글 같은 경우에는 120가지 정도 종류의 PII를 인식하는 기능이 built-in 되어 있다 (한국 주민도 인식)
보통 비밀번호 같은 경우에는 MD5로 해시처리를 하는데 사용한지 꽤 되었기도 하고 비교적 간단한 편이기 때문에 Dictionary Attack이 가능하다
반응형