SME 사의 고객사인 미국의 한 유틸리티 회사는 200만 계량기로 구성된 새로운 계량기 네트워크를 설치하여 이전 계량기 네트워크보다 훨씬 더 많은 데이터를 생성하고 있었습니다. 인입되는 데이터의 양과 리포팅 요구가 기존 하둡 기반의 복잡한 솔루션으로 수용이 어려웠습니다. 10개의 서로 다른 데이터 처리 구성 요소를 단일 SingleStore 클러스터로 교체하였고, 그 결과 뛰어난 성능, 향후 요구 사항에 맞는 확장성, SQL을 통한 표준 BI 툴 사용과 비용 효율성을 경험하였습니다.
SME의 솔루션 엔지니어인 조지 배럿(George Barrett)은 “SingleStore는 스위스 군용 칼(Swiss Army Knife)과 같습니다. 단일 데이터베이스에서 운영 분석, 데이터웨어하우스(DW)와 데이터 레이크(Data Lake) 요구 사항을 처리할 수 있습니다”라고 말합니다. 이 블로그에서 서로 어떻게 협력하는지에 대해 더 많이 배울 수 있을 것입니다.
소개
이 유틸리티 회사는 복잡한 데이터 인프라를 구축했습니다. 전자 상거래, 재무, 고객 관계 관리, 물류 등 회사의 모든 운영 시스템에서 데이터를 가져왔습니다.
새로운 계량기 네트워크는 향후 확장 계획에 따라 수집 요구 사항을 초당 100,000 행으로 증가시킬 것인데 기존 아키텍처는 이것을 수용이 어려웠고, 추가 수집 요구에 대해 빠르게 확장할 수가 없었습니다. 기존에는 아래와 같이 10가지 구성 요소가 있었습니다.
· HDFS, Hive & Druid
핵심 데이터베이스는 하둡 분산 파일시스템(HDFS), ETL과 데이터 웨어하우징을 위한 Hive와 온라인 분석 처리(OLAP)를 위한 Druid로 구성되어 있습니다. 모두 빅데이터/데이터 레이크(Data Lake)구현을 위해 함께 자주 사용되는 구성입니다.
· ODS, EDW & Spark
ODS와 EDW로부터 분석과 머신러링 모델을 실행하는 Spark에 데이터를 제공합니다.
· Key-value 저장소, MongoDB(문서 기반), Cassandra(칼럼 저장소 데이터), ElasticSearch(반 정형 데이터)
4가지 유형의 NoSQL 데이터베이스는 서로 다른 종류의 리포팅과 쿼리를 위해 데이터를 저장하고 있습니다.
새로운 요구 사항을 충족하지 못하는 기존 솔루션들
서로 다른 요소들의 혼합은 구성이 복잡하고 관리하기 매우 어려우며 확장 또한 쉽지 않았습니다. 비록 이것들이 효과를 발휘하게 하기 위해 많은 노력과 투자를 했음에도 불구하고, 예상되는 수집 처리 요구 사항을 수용하는 것도 간단하지 않습니다.
핵심 요구 사항들은 이 복잡한 시스템의 다른 부분에까지 영향을 미칠 수 있었습니다.
1. 스트리밍되는 속도만큼 빠른 데이터 수집
HDFS는 배치 처리에 가장 적합합니다. 그것이 마이크로 배치를 처리할 수 있지만, 새로운 계량기에 필요한 실제 스트리밍에는 적합하지 않았습니다.
2. 3단계 데이터 집계(Aggregation)
이 유틸리티 기업은 앞으로 집계를 추가할 수 있는 기능으로 사용량(미터)당 5초 간격으로, 매일, 매월 데이터를 지속적으로 집계해야 했습니다. HDFS와 Hive 간의 상호 연결을 통해서는 응답 시간에 의존하지 않고 필요한 집계를 제공할 만큼 충분히 빠르게 실행될 수 없었습니다.
3. 선택된 Read를 높은 경보와 낮은 경보로 버킷화(Bucket)
이 유틸리티 기업에서 필요에 따라 알람 레벨을 변경하여 값이 너무 높거나 너무 낮아서 일부 Read 값을 경보(Alram)로 표시해야 했습니다(SingleStore의 신규 시계열 기능이 여기에 도움이 될 수 있음). HDFS와 Druid의 페어 구성은 이 요구 사항을 유연하고 필요한 성능으로 처리할 수 없었습니다.
4. 프로세스 전반에 걸친 데이터 쿼리
이 유틸리티 기업은 운영 담당자, 분석가와 관리자가 프로세스 전반에서 대화식으로 데이터를 쿼리하고 향후 응용 프로그램에 기계 학습 모델을 추가할 수 있도록 해야 했습니다. 10개 구성 요소의 스택에는 다른 수준의 응답성을 가진 다양한 인터페이스가 있으며 비즈니스의 쿼리 요구를 지원하기에는 너무 제한적이고 매우 복잡했습니다.
5. 성능 유지
시스템 전체에 걸쳐 엄격한 SLA를 충족하거나 초과할 수 있는 성능이 필요했습니다. 다양한 인터페이스와 낮은 성능 수준의 여러 구성 요소는 처음부터 성능이 부적절할 것이고 확장될 수 없다는 것은 자명했습니다.
요구 사항을 충족하고 심지어 초과하는 SingleStore
이 유틸리티 회사는 Kafka를 사용하여 데이터를 실시간으로 SingleStore에 적재하는 새로운 솔루션을 구축하고 테스트했습니다. SingleStore를 핵심으로 해서 기존의 10개의 다른 구성요소의 모든 기능을 단일 데이터베이스로 통합했습니다. 이것을 통해 모든 요구 조건을 충족시켰습니다.
1. 스트리밍되는 속도만큼 빠른 데이터 수집
SingleStore가 월별 집계와 같이 가장 복잡한 작업을 수행할 때 Kafka가 데이터를 잠시 보관하게 함으로 Kafka와 SingleStore의 조합은 원활한 데이터 수집 처리를 가능하게 합니다.
2. 3단계 데이터 집계(Aggregation)
SingleStore는 “사용량, 일별 사용량, 월별 사용량” 별로 필요에 따라 3단계의 집계를 처리합니다.
3. 선택된 Read를 높은 경보와 낮은 경보로 버킷화(Bucket)
실시간 데이터에 대한 SingleStore의 빠른 비교 기능을 통해 필요에 따라 경보와 비 경보 카테고리로 Read를 버킷화하는 것을 쉽게 할 수 있습니다.
4. 프로세스 전반에 걸친 데이터 쿼리
SingleStore는 MySQL과 100% 호환될 뿐만 아니라 모든 단계에서 SQL을 지원하므로 필요한 툴이나 애플리케이션이 SingleStore를 쉽게 접속할 수 있습니다.
5. 성능 유지
작은 클러스터가 전체 작업을 처리할 정도로 SingleStore는 매우 빠른 속도를 보장합니다. 데이터/쿼리 볼륨이나 기타 비즈니스 요구 사항에 따라 증가되는 수요를 처리할 수 있도록 SingleStore는 선형적으로 확장이 됩니다.
또한 10개의 서로 다른 구성 요소를 사용하는 것보다 표준 SQL을 지원하는 단일 데이터베이스를 사용하는 것은 명백한 운영상의 이점이 있습니다.
머신러닝과 AI도 훨씬 쉽게 구현할 수 있습니다. 모든 종류의 데이터를 위해 단일 데이터 저장소(Single Data Store)를 사용하면 실시간 데이터와 과거 데이터를 동일한 데이터베이스 내에 분리된 테이블로 보관할 수 있습니다. JOIN과 같은 표준 SQL 작업은 최대 효율성으로 비교 작업, 쿼리 수행 그리고 보다 복잡한 작업을 위해 데이터를 통합할 수 있습니다.
SingleStore와 함께 하는 미래
이 고객은 SingleStore를 핵심으로 하여 다양한 툴과 임시(ad-hoc) 프로세스를 사용하여 전체 데이터 셋에서 분석과 리포팅을 실행할 수 있게 되었습니다. 원래의 사용 사례는 1.4억 행의 과거 사용량(Meter) 읽기 데이터이었지만 데이터가 수십억 행, 심지어 수조 행으로 증가함에 따라 그들의 환경을 쉽게 확장할 수 있게 되었습니다.
조지 배럿와 다른 이들은 SingleStore 7.0에서 신규 출시된 SingleStore 기능에 대해 매우 흥분하고 있습니다. 이 SingleStore를 통해 로우스토어(rowstore) 테이블을 압축하고, 컬럼스토어(columnstore) 테이블을 더욱 빠르게 검색할 수 있게 되었습니다. 이 테이블들은 더 비슷해졌고 문제를 해결하기 위해 다른 2가지 유형의 여러 테이블을 사용해야 할 필요성이 크게 줄어들었습니다. 시간이 지남에 따라 더 많은 문제들이 하나의 테이블 유형으로 해결되어 이미 많이 개선된 운영 워크로드를 더욱 단순화시킬 것입니다.
December 18, 2019
출처: https://www.singlestore.com/blog/case-study-memsql-replaces-hadoop-for-2-million-meters/
Case Study: SingleStore Replaces Hadoop for Managing 2 Million New-Style Utility Meters
SingleStore is a database partner to SME Solutions Group, who crafted a solution for a utility company installing 2M new-style meters. Kafka and SingleStore replaced Hadoop, meeting all requirements and delivering room to grow.
www.singlestore.com
※ www.a-platform.biz | info@a-platform.biz
'SingleStoreDB > 사례연구' 카테고리의 다른 글
| [사례 연구, SME_Fanatics_Thorn_BofA] 다양한 NoSQL의 데이터 인프라를 SingleStore로 단순화하는 방법 (0) | 2020.02.27 |
|---|---|
| [사례 연구, Pinterest] Spark로 실시간 사용자 참여를 측정하는 방법 (0) | 2020.02.18 |
| [사례 연구, PandoraTV] 수 천억 행의 쿼리를 위한 실시간 대쉬보드 구축 (0) | 2020.01.08 |
| [사례 연구, Dzone] 시계열, 실시간 및 그 이상을 위한 SingleStore (0) | 2019.12.06 |
| 대용량 및 다차원 이미지 데이터를 SingleStore의 고성능 벡터 연산 함수로 처리하기 (0) | 2019.11.18 |
