주요 기술 서비스 기업은 디지털 시대에 경쟁하기 위해 어떻게 준비하고 있습니까? 그리고, 고객의 비즈니스 전망을 크게 향상시킬 수 있는 탁월한 서비스를 제공합니까? 동시에, 복잡성을 줄이고 비용을 절감하며, 경우에 따라 SLA를 10배 이상 강화할 수 있습니까?
이러한 기업의 경우 해결책은 Kafka 및 SingleStore를 사용하여 실시간 운영 분석을 제공하는 것입니다.
이 기업에서는 데이터가 여러 데이터 저장소를 통과하고 관계형 SQL 데이터베이스에서 배치 쿼리 처리를 위해 NoSQL 데이터 저장소로 이동하고, BI, 앱 및 애드혹 쿼리를 위해 다시 SQL로 이동되었습니다. 이제 데이터는 Kafka를 통해 바로 SingleStore로 흐릅니다. Airflow는 오케스트레이션을 제공합니다.
Before SingleStore : 사용자 정의 코드, PostgreSQL, HDFS, Hive, Impala 및 SQL Server
이 기술 서비스 기업에서 분석은 비즈니스에 매우 중요합니다. 기업은 서비스를 제공하고 비즈니스를 운영하기 위해 분석 통찰력이 필요합니다. 또한 플랫폼을 사용하여 고객에게 보고서 및 데이터 시각화를 제공합니다. (우리는 고객의 프로세스나 그들이 프로세스와 기술상의 결정에 대해 보다 자유롭게 이야기할 수 있도록 기업의 이름을 익명으로 하였습니다.)
기업의 기존 데이터 처리 플랫폼은 몇 년 전에 개발되었으며 현재도 사용되고 있습니다. 곧 Kafka와 SingleStore로 대체될 예정입니다. 당시 많은 기업과 마찬가지로 분석 인프라의 핵심에서 NoSQL 접근 방식을 선택했습니다.
데이터는 다음 단계에 따라 분석 코어를 통과했습니다.
- 사용자 정의 워크플로 엔진은 데이터를 가져오고 작업 예약
- 엔진은 데이터 수집 및 데이터 파이프라인 스케줄링의 유연성을 극대화하기 위해 Python으로 작성
- 주요 관계형 데이터베이스 중 하나인 PostgreSQL에 정규화되어 저장
- Hadoop용 데이터 저장소인 HBase로 이동 (HBase: 원자적 columna 수준에서 데이터 버전 지정 기능을 제공하는 NoSQL)
- Hadoop용 데이터 웨어하우징 솔루션인 Apache Hive로 이동
- Cloudera버전의 Apache Impala Hadoop-to-SQL 쿼리엔진에 업데이트된 새로운 Parquet 테이블 생성
- 또 다른 주요 관계형 데이터베이스인 SQL Server로 이동, 여기서 기존의 SQL기반 BI(비즈니스 인텔리전스) 툴을 통해 데이터에 액세스
이 시스템은 배치(batch) 형태의 분석 및 기타 배치(batch) 기반의 사례에 잘 작동했으며, 그것은 여전히 기업에서 수행하는 대부분의 데이터 활용 사례입니다. 또한 다양한 단계에서 기존 SQL 인터페이스나 Hadoop/HDFS(즉, Impala)를 중심으로 개발된 에코시스템을 통해 데이터를 사용할 수 있었습니다.
비용은 사내, 오픈 소스 및 라이센스 소프트웨어를 함께 사용했기 때문에 합리적이었습니다. 그리고 HDFS에 저장하기 전후에 데이터가 관계형 형식이기 때문에 NoSQL 시스템에 저장되는 대부분의 데이터에 비해 이해도가 높고 정돈되어 있었습니다.
그러나, 기업은 실시간 운영 분석, 머신 러닝(ML) 및 AI로 이동하고 있습니다. ML과 AI는 회사의 분석 처리 코어와 관련된 많은 문제를 강조했습니다.
- 시간이 지난 데이터. 데이터는 시스템을 통해 이동할 때 여러 번 배치 처리됩니다. 각 단계에서 이전 데이터에 대해 분석이 실행됩니다. 그러나 AI의 구현 전망이 보였준것 처럼 가장 가치 있는 것은 최신 데이터입니다.
- 정보 손실. 데이터가 관계형 데이터베이스(PostgreSQL)로 이동한 다음, NoSQL 스토리지 엔진(HDFS)으로 이동한 다음, 캐시와 같은 쿼리 시스템(Cloudera Impala)으로 이동하고, 마지막으로 다른 관계형 데이터베이스(Microsoft SQL Server)로 이동함에 따라 세부 수준 각 단계에서 가져올 수 있는 데이터가 손상됩니다.
- 어설픈 프로세스. 모든 단계는 상당한 운영 오버헤드가 발생하며, 특정 단계에는 어설픈 측면이 있습니다. 예를 들어 Cloudera Impala는 Hive에서 전체 데이터 파일을 가져와 빠른 쿼리에 사용할 수 있도록 하는 방식으로 작동합니다. 즉, 데이터 업데이트는 전체 새 파일을 생성하여 Impala로 보내는 것을 의미합니다.
- 운영 복잡성. 기업은 이 시스템을 유지보수 하는데 전념하는 상당한 기술 전문 지식을 개발하고 유지해야 했습니다. 이것은 새로운 솔루션을 구축할 수 있는 사람들을 속박시킵니다.
- 미래에 대비할 수 없음. 기업이 ML 및 AI로 이동하려고 할 때 발견했듯이 복잡한 인프라로 인해 새로운 기술을 수용할 수 없었습니다.
Kafka 및 SingleStore로의 이동
기술 서비스 기업이 사용하던 이전 아키텍처는 미래로 가는 길을 막고 있었습니다. 따라서 이들은 ML 및 AI를 지원하는 SingleStore를 통한 스트리밍 데이터 및 프로세싱을 특징으로 하는 새롭고 단순한 아키텍처로 이동하고 있습니다. 기업은 데이터의 변경 사항을 추적하고 기록하며 로봇 프로세스를 주도할 것입니다. 이것은 그들이 언급하는 일종의 "시간 여행"을 할 수 있게 해줄 것입니다.
기업은 새 플랫폼에 필요한 사항을 다음과 같이 설명했습니다.
- 단순성. Hadoop을 제거하여 복잡성과 지연을 줄이고, Impala를 제거하여 업데이트 시 큰 테이블을 로드하기 위해 40~50분의 대기 시간을 줄여야 합니다.
- 데이터 소스. Oracle, Salesforce, Sharepoint, SQL Server, Postres 등으로 부터100개 이상의 소스를 수집해야 합니다.
- 동시 처리. 20-25개의 동시 작업에서 최대 200개 이상으로 확장되어야 합니다.
- 쿼리 유형. 단순, 복잡, 계층적(분석), 집계, 시계열 및 애드혹 쿼리를 잘 처리할 수 있어야 합니다.
- 쿼리 속도. ETL을 12시간에서 1시간 이하로 줄여야 합니다.
- SQL 지원. 기업의 엔지니어 대부분이 뛰어난 SQL개발자들입니다, 하지만, 기존의 단일 프로세스 데이터베이스가 아닌 다른 확장 가능한 플랫폼이 필요합니다.
- 비즈니스 혜택. 현재 이미 임계값을 초과하여 처리하므로, 작업자 대기 시간을 줄여야 합니다.(일 작업 수 증가, 일 데이터량 증가, 분산 컨테이너 지원)
어떤 플랫폼이 이러한 작업을 수행할 수 있습니까? 프로젝트 책임자 중 한 명은 다음과 같이 말합니다. “SingleStore를 보고 매우 기뻤습니다. 우리는 SQL 쿼리를 입력하고 즉시 결과를 얻을 수 있습니다. 우리는 이것이 많은 문제를 해결할 수 있다고 생각했습니다.”
기업은 Kafka가 대용량 데이터 스트리밍을 수집할 수 있는 가장 좋은 방법이라는 것을 알게 되었습니다. 그래서, SingleStore를 조사할 때 Kafka 와 일치하는 exactly-once updating 를 포함하여 Kafka 파이프라인 기능 을 발견하게 되어 기뻤습니다. 이를 통해 Kafka는 AI 공급에만 사용되는 것에서 모든 분석 데이터를 위한 스트리밍 파이프라인에 이르기까지 더 큰 역할을 수행하게 되었습니다.
기업은 아직 설계 단계에 있습니다. Kafka와 SingleStore는 지금까지 기업에서 던진 모든 사용 사례를 처리했습니다. 클라우드와 온프레미스에서 동일한 환경을 복제만 하면, 비용 효율적이고 편리한 곳이면 어디든지 워크로드를 이동할 수 있습니다.
기업은 또한 rowstore 및 columnstore 테이블을 서로 조인할 수 있습니다. 예를 들어 데이터는 rowstore 테이블로 유입시키면 동시에 변환을 수행할 수 있습니다. 그런 다음 새로운 데이터와 기존 데이터를 columnstore 테이블에 집계하여 최종적으로 총 페타바이트(PB)의 정보를 수집할 수 있습니다.
Impala 솔루션 및 Parquet 파일과 같은 대부분의 데이터베이스와 달리 현재 솔루션에서 SingleStore는 다시 빌드하고 다시 로드할 필요 없이 columnstore 테이블을 업데이트할 수 있습니다. (이 기능은 이미 출시된 SingleStore DB 7.0 에서 향상되어 더 빠른 검색과 더 빠른 업데이트가 가능해졌습니다.)
이는 기업의 가장 큰 사용 사례 중 하나인 랩 쿼리에 대한 지원과 일치합니다. 랩은 지속적인 데이터 저장을 위해 거의 무한대에 가까운 디스크 공간이 필요합니다. 수백 개의 열이 있는 columnstore 테이블이 있으며 이전 솔루션에서는 Hive 메타스토어를 통해 가져오는 데 문제가 있었습니다. SingleStore는 수천 개의 개별 열을 지원할 수 있는 기능을 제공합니다. 또한 SingleStore에는 JSON에 대한 지원을 내장하고 있기 때문에 프로젝트 책임자의 표현대로 "제한이 없습니다." 그런 다음 선택한 데이터를 rowstore 저장소 테이블로 이동하여 집중적인 처리 및 분석을 할 수 있습니다.
기업은 SingleStore를 발견한 후 대안을 찾는 것을 중단했습니다. 예를 들어, Postgres용 Citus는 매우 성숙한 데이터베이스인 PostgreSQL 위에 분산 쿼리 엔진인 Citus를 제공합니다. 프로젝트 리더는 "하지만 한계가 있고 작동하려면 많은 사전 계획이 필요합니다."라고 말했습니다.
설계 및 구현: Airflow, Kafka, SingleStore, Spark
파일럿 프로젝트에서는 제한된 데이터 양, 특히 제한된 사용자 수로 이러한 작업중 일부를 수행할 수 있는 데이터베이스는 많이 있습니다. 그러나 프로젝트 리더가 말했듯이 "SingleStore의 장점은 더 많은 사용자를 확보하면 더 많은 노드를 추가할 수 있다는 것입니다."
이 기업은 Airflow를 스케줄러로 사용할 것입니다. Airflow는 원격 시스템에 명령을 보내 데이터를 보냅니다. Create Pipeline과 같은 명령은 데이터 흐름을 가져옵니다. Airflow는 수집할 데이터를 Kafka 토픽(topic)으로 보낸 다음 원격 시스템에 대한 연결을 끊습니다. Airflow는 데이터 자체를 저장하는 것이 아니라 단순히 오케스트레이션을 위해 존재하는 것입니다.
MySQL 인터페이스(SingleStore는 MySQL 와이어드 프로토콜과 호환됨)를 사용하여 데이터를 SingleStore로 수집합니다. SingleStore의 데이터에는 거의 무제한의 옵션이 있습니다. 그들은 SingleStore 변환 및 스토어드 프로시저에 대한 파이프라인을 사용하여 데이터베이스 데이터에 대해 Python 코드를 실행할 수 있습니다 .
팀 리더는 다음과 같이 말했습니다. "우리의 유일한 비용은 팀 구성원이 개발하는 데 드는 시간입니다. 이것은 1인 디자인 팀이 있는 경우에도 우리에게 효과적입니다. 데이터 엔지니어는 우리가 구축한 프레임워크를 활용하여 비용을 절감할수 있습니다.”
이전의 분석 처리 프레임워크는 복잡했지만 오픈 소스 코드만 포함했습니다. 프로젝트 책임자에 따르면 분석 코어에 "구독 기반(subscription-based) 라이선스를 도입한 것은 이번이 처음입니다."이라고 말합니다. “우리는 가치를 보여주고 싶습니다. 장기적으로 보면 돈을 절약할 수 있습니다.”
그들은 많은 사용자가 개척한 솔루션인 SingleStore와 함께 Spark를 사용하는 최선의 방법을 탐구할 것입니다. 예를 들어, 그들은 SingleStore의 공동 CEO인 Nikita Shamgunov가 Spark Summit에서 시연한 풍력 터빈 사용 사례에 흥미를 느꼈습니다. 이것은 기업의 실제 사용 사례입니다.
현재 페타바이트(PB) 규모의 스토리지를 갖춘 고성능 클러스터를 보유하고 있습니다. 그들은 실시간으로 최신 상태로 유지되는 거대한 데이터 세트에 대해 실행되는 SingleStore와 Spark의 조합으로 솔루션을 확장할 것입니다.
그들은 현재 페타바이트(PB) 규모의 스토리지를 갖춘 고성능 클러스터를 보유하고 있으며, 대규모 데이터셋에서 실행되는 SingleStore와 Spark의 조합으로 솔루션을 실시간으로 최신 상태를 확장할 예정입니다.
프로젝트 리더는 "핵심 데이터베이스는 그 자체로 우리에게 가장 가치 있는 부분입니다."라고 말합니다. “그리고 기본 Kafka 통합은 훌륭합니다. Spark와의 통합도 최적화되면 지금까지 살펴본 것과 비교할 수 있는 것이 없습니다.
기업은 거의 모든 작업에 대해 Docker 컨테이너를 운영하고 있으며, Kubernetes을 사용하고 있습니다. 그들은 SingleStore의 새로운 탄력적 클라우드 데이터베이스인 SingleStore Managed Service도 Kubernetes를 기반으로 구축되었다는 사실을 알게 되어 기뻤습니다. 이를 통해 프로젝트 리더는 앞으로 SingleStore 와 Kubernetes로 무엇을 할 수 있는지 다음과 같이 말합니다. "1~2분 안에 전체 클러스터가 생성됩니다. 이것이 컨테이너화의 요점입니다."
프로젝트 리더는 "로고로 가득 찬 이전 아키텍쳐에서 Airflow, Kafka 및 SingleStore의 세 가지 로고로 바뀌었습니다. 우리는 단 하나의 데이터베이스만 다루기를 원합니다.” 그리고 SingleStore는 그 이상의 일을 할 것입니다.
November 16th, 2019
Case Study: Moving to Kafka and AI at a Major Technology Services Company
This major technology services company moved from a complex setup, with custom code, Postgres, Hadoop, HDFS, Hive, Impala, and SQL Server, to a simple one: Airflow for orchestration, Kafka for streaming, and NGINX. They achieved speed and concurrency on up
www.singlestore.com
※ www.a-platform.biz | info@a-platform.biz
'SingleStoreDB > 사례연구' 카테고리의 다른 글
| Infosys and SingleStore: Working Together (0) | 2021.10.18 |
|---|---|
| [사례 연구, Handytec] SingleStore로 빠른 Geoanalytics 제공 (0) | 2021.08.31 |
| [사례 연구, DailyVest] 401(k) 구축 및 애플리케이션 성능 30% 향상 (0) | 2021.08.24 |
| [사례 연구, CME] 시카고 상업거래소를 역설계한 방법 (0) | 2021.08.24 |
| [사례 연구, IEX Cloud] 일 25억건의 API 요청을 평균 8ms로 응답 (0) | 2021.08.23 |
