서버 분석 시스템

이것은 분석 시스템에 관한 일련의 기사 중 두 번째 부분입니다(1부 링크).

오늘날에는 신중한 데이터 처리와 결과 해석이 거의 모든 유형의 비즈니스에 도움이 될 수 있다는 데 더 이상 의심의 여지가 없습니다. 이와 관련하여 분석 시스템에는 점점 더 많은 매개변수가 로드되고 있으며 애플리케이션의 트리거 및 사용자 이벤트 수가 늘어나고 있습니다.
이로 인해 기업은 분석가에게 분석하고 건전한 결정을 내릴 수 있도록 점점 더 많은 원시 정보를 제공하고 있습니다. 기업에 있어 분석 시스템의 중요성은 과소평가되어서는 안 되며, 시스템 자체가 신뢰할 수 있고 안정적이어야 합니다.

클라이언트 분석가

고객 분석은 기업이 공식 SDK를 통해 자사 웹사이트나 애플리케이션에 연결하고 자체 코드베이스에 통합하고 이벤트 트리거를 선택하는 서비스입니다. 이 접근 방식에는 분명한 단점이 있습니다. 수집된 모든 데이터는 선택한 서비스의 제한으로 인해 원하는 대로 정확하게 처리되지 않을 수 있습니다. 예를 들어, 한 시스템에서는 MapReduce 작업을 실행하기가 쉽지 않고, 다른 시스템에서는 모델을 실행할 수 없습니다. 또 다른 단점은 서비스에 대한 일반적인 (인상적인) 청구서입니다.
시장에는 수많은 고객 분석 솔루션이 있지만 조만간 분석가들은 모든 작업에 적합한 단일 범용 서비스가 없다는 사실에 직면하게 됩니다(이러한 모든 서비스의 가격은 항상 상승하고 있습니다). 이러한 상황에서 기업은 필요한 모든 사용자 정의 설정과 기능을 갖춘 자체 분석 시스템을 만들기로 결정하는 경우가 많습니다.

서버 분석가

서버 측 분석은 회사 내 자체 서버에 (일반적으로) 자체 노력으로 배포할 수 있는 서비스입니다. 이 모델에서는 모든 사용자 이벤트가 내부 서버에 저장되므로 개발자는 다양한 스토리지 데이터베이스를 시도하고 가장 편리한 아키텍처를 선택할 수 있습니다. 일부 작업에 타사 클라이언트 분석을 사용하려는 경우에도 여전히 가능합니다.
서버 측 분석은 두 가지 방법으로 배포할 수 있습니다. 첫째, 일부 오픈 소스 유틸리티를 선택하여 컴퓨터에 배포하고 비즈니스 논리를 개발합니다.

프로
죄수 팀은

원하는 것은 무엇이든 맞춤 설정할 수 있습니다.
이는 종종 매우 어려우며 별도의 개발자가 필요합니다.

둘째: 직접 배포하는 대신 SaaS 서비스(Amazon, Google, Azure)를 사용하세요. SaaS에 대해서는 세 번째 부분에서 자세히 설명하겠습니다.

프로
죄수 팀은

중간 규모에서는 더 저렴할 수 있지만 규모가 커지면 여전히 너무 비쌉니다.
모든 매개변수를 제어하는 ​​것은 불가능합니다.

관리는 전적으로 서비스 제공업체의 책임으로 이전됩니다.
서비스 내부에 무엇이 있는지 항상 알 수 있는 것은 아닙니다(필요하지 않을 수도 있음).

서버 분석 수집 방법

클라이언트 분석을 사용하는 것에서 벗어나 자체 분석을 구축하려면 먼저 새 시스템의 아키텍처를 전체적으로 생각해야 합니다. 아래에서는 고려해야 할 사항, 각 단계가 필요한 이유 및 사용할 수 있는 도구를 단계별로 설명하겠습니다.

1. 데이터 수신

고객 분석의 경우와 마찬가지로, 우선 기업 분석가들은 향후 연구하고 싶은 이벤트 유형을 선택하여 목록으로 수집합니다. 일반적으로 이러한 이벤트는 "이벤트 패턴"이라는 특정 순서로 발생합니다.
다음으로, 모바일 애플리케이션(웹사이트)에 일반 사용자(장치)와 많은 서버가 있다고 상상해 보세요. 장치에서 서버로 이벤트를 안전하게 전송하려면 중간 계층이 필요합니다. 아키텍처에 따라 여러 가지 이벤트 큐가 있을 수 있습니다.
아파치 카프카 -가요 게시/구독 대기열, 이벤트 수집을 위한 큐로 사용됩니다.

에 따르면 Quora에 게시 2014년 아파치 카프카(Apache Kafka)의 창시자는 “글쓰기에 최적화된 시스템”이고 카프카의 작품을 좋아했기 때문에 프란츠 카프카(Franz Kafka)의 이름을 따서 소프트웨어 이름을 짓기로 결정했습니다. — 위키 백과

이 예에는 많은 데이터 생산자와 데이터 소비자(장치 및 서버)가 있으며 Kafka는 이들을 서로 연결하는 데 도움을 줍니다. 소비자는 주요 주제가 되는 다음 단계에서 더 자세히 설명됩니다. 이제 데이터 생산자(이벤트)만 고려하겠습니다.
Kafka는 큐와 파티션의 개념을 캡슐화합니다. 이에 대해서는 다른 곳에서 더 구체적으로 읽는 것이 좋습니다(예: 선적 서류 비치). 자세히 설명하지 않고 모바일 애플리케이션이 두 가지 다른 OS용으로 실행된다고 가정해 보겠습니다. 그런 다음 각 버전은 자체 별도의 이벤트 스트림을 생성합니다. 생산자는 Kafka에 이벤트를 보내고 적절한 대기열에 기록됩니다.

(그림 따라서)

동시에 Kafka를 사용하면 청크 단위로 읽고 이벤트 스트림을 미니 배치로 처리할 수 있습니다. Kafka는 증가하는 요구 사항(예: 이벤트의 지리적 위치)에 따라 확장되는 매우 편리한 도구입니다.
일반적으로 샤드 하나면 충분하지만 확장할 때는 상황이 더 복잡해집니다(늘 그렇듯이). 아키텍처는 내결함성이 있어야 하므로 프로덕션에서 하나의 물리적 샤드만 사용하고 싶어하는 사람은 아마 아무도 없을 것입니다. Kafka 외에도 또 다른 잘 알려진 솔루션인 RabbitMQ가 있습니다. 우리는 이를 프로덕션에서 이벤트 분석을 위한 대기열로 사용하지 않았습니다(그런 경험이 있다면 댓글로 알려주세요!). 그러나 우리는 AWS Kinesis를 사용했습니다.

다음 단계로 넘어가기 전에 시스템의 또 다른 추가 계층인 원시 로그 저장소에 대해 언급해야 합니다. 이는 필수 레이어는 아니지만 문제가 발생하여 Kafka의 이벤트 큐가 재설정되는 경우 유용합니다. 원시 로그를 저장하는 데는 복잡하고 비용이 많이 드는 솔루션이 필요하지 않으며, 올바른 순서로 어딘가에(하드 드라이브에도) 간단하게 기록할 수 있습니다.

2. 이벤트 스트림 처리

모든 이벤트를 준비하고 적절한 대기열에 배치한 후 처리 단계로 넘어갑니다. 여기서는 가장 일반적인 두 가지 처리 옵션에 대해 설명하겠습니다.
첫 번째 옵션은 Apache 시스템에서 Spark Streaming을 활성화하는 것입니다. 모든 Apache 제품은 파일 복제본이 있는 보안 파일 시스템인 HDFS에 있습니다. Spark Streaming은 스트리밍 데이터를 처리하고 확장성이 뛰어난 사용하기 쉬운 도구입니다. 그러나 유지 관리가 어려울 수 있습니다.
또 다른 옵션은 자신만의 이벤트 핸들러를 만드는 것입니다. 이를 위해서는 예를 들어 Python 애플리케이션을 작성하고 Docker에서 빌드한 후 Kafka 대기열을 구독해야 합니다. 트리거가 Docker 핸들러에 도착하면 처리가 시작됩니다. 이 방법을 사용하면 애플리케이션을 항상 실행 상태로 유지해야 합니다.
위에서 설명한 옵션 중 하나를 선택하고 처리 자체로 넘어간다고 가정해 보겠습니다. 프로세서는 데이터의 유효성을 확인하고 가비지 및 "깨진" 이벤트를 필터링하는 것부터 시작해야 합니다. 검증을 위해 우리는 일반적으로 켈베로스. 그런 다음 데이터 매핑을 수행할 수 있습니다. 서로 다른 소스의 데이터가 공통 테이블에 추가되기 위해 정규화되고 표준화됩니다.

3. 데이터베이스

세 번째 단계는 정규화된 이벤트를 유지하는 것입니다. 기성 분석 시스템으로 작업할 때는 자주 액세스해야 하므로 편리한 데이터베이스를 선택하는 것이 중요합니다.
데이터가 고정된 구성표에 잘 맞는 경우 다음을 선택할 수 있습니다. 클릭하우스 또는 다른 컬럼형 데이터베이스. 이렇게 하면 집계가 매우 빠르게 작동합니다. 단점은 체계가 엄격하게 고정되어 있으므로 수정 없이 임의의 개체를 추가하는 것이 불가능하다는 것입니다(예: 비표준 이벤트가 발생할 때). 하지만 정말 매우 빠르게 셀 수 있습니다.
구조화되지 않은 데이터의 경우 NoSQL을 사용할 수 있습니다. 예를 들면 다음과 같습니다. 아파치 카산드라. HDFS에서 실행되고, 잘 복제되며, 많은 인스턴스를 생성할 수 있고, 내결함성이 있습니다.
예를 들어, 더 간단한 것을 올릴 수도 있습니다. MongoDB의. 매우 느리고 볼륨이 작습니다. 그러나 장점은 매우 간단하므로 시작하기에 적합하다는 것입니다.

4. 집계

모든 이벤트를 주의 깊게 저장한 후 도착한 배치에서 모든 중요한 정보를 수집하고 데이터베이스를 업데이트하려고 합니다. 전 세계적으로 관련 대시보드와 지표를 얻고 싶습니다. 예를 들어, 이벤트에서 사용자 프로필을 수집하고 어떻게든 행동을 측정합니다. 이벤트는 집계, 수집 및 다시 저장됩니다(사용자 테이블에). 동시에 집계자-코디네이터에 필터를 연결할 수 있도록 시스템을 구축할 수 있습니다. 특정 유형의 이벤트에서만 사용자를 수집합니다.
그 후 팀 구성원 중 누군가가 높은 수준의 분석만 필요하다면 외부 분석 시스템을 연결할 수 있습니다. Mixpanel을 다시 수강하실 수 있습니다. 그러나 비용이 많이 들기 때문에 모든 사용자 이벤트가 그곳으로 전송되는 것이 아니라 필요한 것만 전송됩니다. 이를 위해서는 일부 원시 이벤트나 이전에 우리가 직접 집계한 내용을 외부 시스템, API 또는 광고 플랫폼으로 전송할 코디네이터를 만들어야 합니다.

5. 프론트엔드

생성된 시스템에 프런트엔드를 연결해야 합니다. 좋은 예가 서비스다. 다시 대시하다는 대시보드 구축을 돕는 데이터베이스 GUI입니다. 상호작용 작동 방식:

1. 사용자가 SQL 쿼리를 만듭니다.
2. 이에 대한 응답으로 그는 사인을 받습니다.
3. 이를 위한 '새로운 시각화'가 생성되고 사용자가 직접 저장할 수 있는 아름다운 그래프가 생성됩니다.

서비스의 시각화는 자동으로 업데이트되므로 모니터링을 사용자 정의하고 추적할 수 있습니다. Redash는 자체 호스팅의 경우 무료이지만 SaaS의 경우 월 50달러의 비용이 듭니다.

결론

위의 모든 단계를 완료한 후에는 서버 분석을 생성하게 됩니다. 모든 것을 직접 구성해야 하기 때문에 이는 단순히 고객 분석을 연결하는 것만큼 간단하지 않습니다. 따라서 자신만의 시스템을 만들기 전에 심각한 분석 시스템의 필요성과 이에 할당하려는 리소스를 비교하는 것이 좋습니다.
계산을 해보고 비용이 너무 높다는 사실을 알게 되었다면 다음 부분에서는 서버 측 분석의 저렴한 버전을 만드는 방법에 대해 설명하겠습니다.

읽어 주셔서 감사합니다! 댓글로 질문주시면 감사하겠습니다.

출처 : habr.com