안녕하세요 Data Platform Engineer 조광진입니다.저희 Platform Technology 팀은 지난 수년간 On-premise Hadoop 기반의 빅데이터 플랫폼인 'Baikal' 이란 서비스를 사내에 제공하여 전사에서 활용되는 데이터의 수집, 적재, 분석에 대해 편의성을 제공하고 있습니다.빅데이터 플랫폼 Baikal은 On-premise 에서 Cloud Lakehouse Platform으로 전환을 앞두고 있습니다.Cloud Lakehouse Platform으로 전환하기 앞서 On-premise Hadoop 기반인 Baikal에 대해 소개하고자 합니다.Gmarket BaikalBaikal 이란 이름은 잘 아시다시피 러시아 시베리아 남쪽의 있는 세계에서 가장 오래되고 깊은 담수호 이름입니다. 대용량 데이터 분석을 위한 Data Lake 이름으로 Baikal 이란 네이밍은 적절하다고 생각됩니다. Gmarket 의 Transaction, Traffic 등의 다양한 데이터를 통합 분석하며 비즈니스 인사이트를 얻을 수 있는 플랫폼의 역할을 하고 있습니다.Baikal ArchitectureArchitecture데이터 처리 흐름에 따라 6개의 Step으로 작성된 Gmarket Baikal Architecture입니다.크게 Data Source, Message Broker, Data Processing, OLAP, Data Storage, Data Analytic으로 구분했습니다.ClusterBaikal Architecture 안에 있는 Cluster의 종류는 총 4개 이며, 각 Cluster의 역할은 아래와 같습니다.Hadoop Cluster: Spark 을 제외한 일반적인 Hadoop ecosystemSpark Cluser: Spark, Spark Streaming JobDruid Cluster: OLAP 서비스를 제공Isilon Cluster: HDFS의 Warm/Cold 데이터 백업DataSource 종류와 특징Baikal 플랫폼에서 처리하는 데이터 종류에 대해 알아보겠습니다.Traffic DataTraffic 데이터는 지마켓에 방문한 고객들의 행동을 기록한 행위 데이터입니다. 웹 페이지 혹은 애플리케이션에서 수집된 데이터는 실시간으로 Kafka로 적재되며 데이터 처리는 Spark Streaming, Gobblin 등 별도의 Consumer를 통해서 데이터를 처리합니다. 실시간 분석이 필요한 데이터 경우 Spark Streaming에서 Druid로 전달하여 Superset에서 Realtime 분석을 할 수 있도록 제공합니다.Transaction DataTransaction 데이터는 지마켓의 고객들이 제공된 서비스를 이용하면서 발생한 데이터이며 MSSQL, Oracle과 같은 관계형 데이터베이스에 저장되어 있습니다. Transaction 데이터의 종류는 구매, 배송, 상품,할인, 고객의 정보가 저장되어 있으며 데이터 처리는 RDB 에서 HDFS 로 데이터를 전달할 때 Sqoop을 활용합니다.Cache DataRedis로 저장된 캐

메트릭의 최종 저장소로 Apache Druid(이하 드루이드)를 선정했습니다. 드루이드는 확장성과 고가용성을 확보한 데이터 저장소입니다. 카카오에서는 카카오 내 모든 크루를 대상으로 공용 드루이드 클러스터를 운영하고 있어서, 축적된 기술 노하우를 활용할 수 있는 장점도 있습니다. 그뿐만 아니라 드루이드는 시계열 수치 데이터의 처리와 연산에 큰 강점이 있기에, 메트릭 질의 시 훌륭한 성능을 기대할 수 있다는 장점도 있습니다.클러스터 관리자가 수집해야 하는 메트릭의 출처와 포맷은 매우 다양합니다. 그래서 이를 일괄적으로 수집하고 정제하는 역할이 필요합니다. KHP 모니터링 체계에서는 KHP Agent라는 메트릭 수집기를 자체 구현해 각 서버에 설치했습니다. KHP Agent는 클러스터 관리자가 지정한 이름의 메트릭을 지정한 방식으로 수집하고, 수집한 메트릭을 지정한 포맷으로 재구성한 뒤, 관리자가 지정한 목적지로 전송합니다. 메트릭 처리에 핵심인 KHP Agent는 아래에서 자세히 설명하겠습니다.이렇게 데이터 수집 과정에서 산출되는 시계열 데이터 처리에 지연이 발생할 경우 동시성 확보를 통해 문제를 해결할 수 있습니다. KHP 모니터링 체계는 이 중에서도 분산 큐인 Kafka(이하 카프카)를 도입해 트래픽이 높은 상황에서도 동시성을 확보하고 시간 지연 없이 즉시 데이터를 처리하도록 구현되었습니다. 드루이드에서 주목할 만한 기능은 실시간 처리 파이프라인을 손쉽게 구성하고 관리할 수 있는 kafka indexing service라는 기능입니다. KHP 모니터링 체계에 카프카를 도입해 드루이드의 maintainer가 기능과 성능을 보장하는 이 실시간 처리 기술도 활용할 수 있도록 했습니다.KHP Agent: KHP 클러스터의 메트릭 수집기KHP 모니터링 체계에서 사용할 메트릭 수집기는 두 가지 요구사항을 모두 만족해야 합니다.수집기에서 원시 데이터를 보정하거나 후처리해야 함수집한 데이터를 드루이드에서 처리할 수 있는 포맷으로 가공해 카프카에 적재해야 함수집기가 수집하는 원천 데이터는 데이터 값의 종류를 기준으로 크게 두 가지로 나눌 수 있습니다. 바로 절댓값과 누적값입니다. CPU 사용량, Disk 사용량과 같은 대부분의 메트릭은 측정 당시의 절댓값을 바로 수집할 수 있습니다. 그러나 HDFS의 FSNamesystem numOps, HBase의 Replication shippedBatches와 같은 메트릭은 프로세스 실행 후부터 누적된 누적값만을 수집할 수 있습니다. 누적값은 절댓값과 다르게 프로세스가 재시작하면 0으로 초기화됩니다. 메트릭 수집기가 위의 두 가지 요구사항을 만족해야 하는 이유는, 다양한 종류의 메트릭을 관리자가 정의한 명세에 따라 일관성 있게 메트릭을 보정하고, 저장소에 보정한 메트릭을 적재할 수 있어야 하기 때문입니다.메트릭이 최종적으로 저장되는 저장소는 드루이드입니다. 그러므로, 수집된 원천 데이터는 드루이드에서 사용할 수 있는 형태여야 합니다. 수집기가 원천 데이터를 수집한 후 드루이드에서 처리할 수 있는 형태로 바로 가공

MRT Public Data Service 개발 — 2안녕하세요. 마이리얼트립 데이터플랫폼팀 서재권입니다. 지난 포스팅에 이어 CDC를 이용해 가져온 서비스 DB의 데이터를 Druid에 색인 및 Api로 제공하는 Public Data Service에 대해 공유해 드리겠습니다.Public Data Service (PDS)마이리얼트립에서 생성되고 있는 여러 출처의 데이터를 재가공해 서비스에서 필요한 다양한 실시간 및 배치성 지표를 제공하는 서비스입니다. 이러한 서비스를 제공하기 위해서는 먼저 실시간으로 생성되는 데이터를 수집(CDC)해야 하며, 이러한 데이터를 실시간으로 집계할 수 있어야 합니다. 이러한 요구 사항을 만족하기 위해 Kafka Stream, Druid를 이용하고 있습니다.Kafka StreamsKafka Streams는 Kafka에서 공식적으로 제공하는 스트리밍 데이터 처리용 Java 라이브러리입니다. CDC로 들어오는 데이터를 Druid에 색인 데이터 생성을 위해 사용하고 있으며, 아래와 같은 특징이 있습니다.단순 Java 라이브러리로 매우 가볍습니다. 또한 다른 스트리밍 처리 프레임워크인 spark와 다르게, Kafka 이외의 외부 의존성이 없어 도입 장벽을 크게 낮출 수 있습니다. 이로 인해 특정 프레임워크(spring)에 탑재하여 추가 기능으로 사용할 수도 있고, 또는 단순 Java 프로그램으로 실행할 수도 있어 개발자의 자유도가 높습니다.Kafka 공식 커뮤니티에서 주도하여 개발하고 있기 때문에 Kafka 와 버전 호환성 문제가 없고, 제공하는 모든 기능을 쉽게 사용할 수 있습니다.Streams DSL을 지원해 간단하게 스트리밍 데이터에 transform, filter, join과 같은 연산을 적용할 수 있습니다. 아래는 마이리얼트립 PDS 서비스에 left join을 적용한 예 입니다.https://medium.com/media/25ff13b2fe2b1e6a95d74ca17601d96e/href4. 로컬 디버깅 환경 및 exactly once 제공TopologyTestDriver를 이용해 배포 전 로직 검증을 할 수 있습니다.다른 라이브러리나 프레임워크와는 다르게, kafka 데이터 처리 시 exactly once를 제공해 데이터 유실 및 중복 전송 이슈로부터 자유로울 수 있습니다. 이는 현재로써 거의 유일합니다.아래는 confluent에서 가이드하는 kafka의 데이터 처리 방식으로, kafka connect를 이용해 kafka로 데이터를 전송 및 저장하며, kafka streams를 이용해 저장된 데이터를 변경하는 프로세스를 보여주고 있습니다. 마이리얼트립 또한 동일한 방식으로 스트리밍 데이터를 처리하고 있습니다.https://www.confluent.io/blog/hello-world-kafka-connect-kafka-streams/Druid대규모 데이터에 대한 실시간 탐색 및 분석을 위해 설계된 Column Oriented, Distributed Data Storage로써 대용량의 이벤트 데이터를 빠르게 색

Apache Druid를 활용한 실시간 MAB 정렬 시스템 구축안녕하세요. 무신사 전시개발팀에서 데이터 기반의 MAB 정렬과 이벤트 버스(Event Bus) 개발을 담당하고 있는 홍승표입니다.무신사는 콘텐츠 기반의 커뮤니티로 스토어를 운영하면서 고객이 쇼핑하는데 필요한 다양한 정보를 제공하고 있습니다. 실시간 이벤트를 확인 할 수 있는 배너, 원활한 검색을 돕는 태그, 상품의 정보와 아이덴티티를 확인할 수 있는 브랜드 등 페이지마다 수많은 정보가 배치되어 있는 것을 확인할 수 있습니다. 문제는 무신사 스토어가 제공할 수 있는 정보의 양 대비 노출할 수 있는 웹/앱의 공간은 제한적이라는 것입니다.무신사 전시개발팀은 공간 제약이 있는 상황에서, 고객이 최대한 유의미한 결과를 얻을 수 있도록 정보를 노출하고 정렬하는 방식을 지속 개선하고 있습니다. 이번 글에서는 실시간 인기 브랜드를 확인할 수 있는 브랜드숍 페이지를 기준으로, 무신사가 어떻게 정렬 방식을 고도화하고 있는지 소개해 드리겠습니다.과거에는 인기 브랜드의 정렬을 수동으로 관리했습니다. 브랜드 수가 적을 땐 관리가 용이했으나, 브랜드 수가 많아질수록 관리의 효율성이 떨어집니다. 또한 수동 관리시 노출 순서가 하위로 내려간 브랜드는 다시 상위로 올라오는 것이 어렵다는 문제점도 있습니다. 브랜드가 하위에 있을수록 고객에게 노출되는 횟수는 줄어들고, 클릭까지 이어질 확률도 낮아지기 때문입니다.이에 무신사는 브랜드 정렬을 고착화하지 않으면서도 고객이 유의미한 정보를 찾을 수 있는 정렬 방식을 찾게 됩니다. 바로 클릭률(CTR)이 높은 브랜드를 상위로 노출시키는 것입니다. 클릭률은 실시간으로 사용자들의 트렌드를 반영할 수 있고, 사용자들의 성별/연령에 따라 분류가 가능하다는 장점이 있습니다.클릭률 기반의 정렬을 개발하기에 앞서, 자동화 개발 기준을 다음과 같이 설정하였습니다.고객이 관심있어 할 정보를 실시간으로 상위 노출시킨다.특정 순서로 고착되지 않게 한다.성별/연령에 따라 다른 순서가 부여 될수 있게 한다.위 목표로 자동화를 진행한다면 관리자의 상위 노출에 대한 불필요한 에너지 소모를 줄이고 고객에게 더 집중 할 수 있게 될 것입니다.처음 클릭률 통계를 기준으로 순서 정렬을 테스트 하였더니 관심있는 정보가 상위로 노출됐으나 순서의 변화가 적고 하위 정보는 상위로 올라올수가 없었습니다. 이후 판매순 통계를 기준으로 순서 정렬을 테스트 한 것 역시 클릭률과 비슷하게 순서의 변화가 적고 할인 이벤트에 따라서 순서가 급격하게 변경되었습니다.이를 해결하기 위해 MAB(Multi-Armed Bandit) 알고리즘을 적용하여 정렬에 리프레쉬(Refresh) 성을 추가하였습니다. 구체적인 적용 방법을 설명하기에 앞서, MAB의 개념을 간단히 소개해 드리겠습니다.MAB란 카지노의 여러개(Multi)의 레버(Arm)를 가진 슬롯머신(Bandit)에서 유래되었습니다. 각 슬롯머신마다 승률이 다르기에 어떤 머신을 당겨야 최대한 많은 수익을 낼 수 있는지를 파악하기 위해 만들어진 알고리즘입니다.MAB의 핵심 개념