Sber.DS는 코드 없이도 모델을 생성하고 구현할 수 있는 플랫폼입니다.

어떤 다른 프로세스를 자동화할 수 있는지에 대한 아이디어와 회의가 매일 다양한 규모의 기업에서 발생합니다. 그러나 모델을 만드는 데 많은 시간이 소요될 수 있다는 사실 외에도 모델을 평가하고 얻은 결과가 무작위가 아닌지 확인하는 데 시간을 투자해야 합니다. 구현 후에는 모든 모델을 모니터링하고 정기적으로 확인해야 합니다.

그리고 이는 규모에 관계없이 모든 회사에서 완료해야 하는 모든 단계입니다. Sberbank의 규모와 유산에 관해 이야기하면 미세 조정 횟수가 크게 늘어납니다. 2019년 말까지 Sber는 이미 2000개 이상의 모델을 사용했습니다. 단순히 모델을 개발하는 것만으로는 충분하지 않고, 산업 시스템과 통합하고, 모델 구축을 위한 데이터 마트를 개발하고, 클러스터에서의 작동을 제어할 수 있어야 합니다.

우리 팀은 Sber.DS 플랫폼을 개발하고 있습니다. 이를 통해 기계 학습 문제를 해결하고 가설 테스트 프로세스의 속도를 높이며 원칙적으로 모델 개발 및 검증 프로세스를 단순화하고 PROM에서 모델 결과를 제어할 수도 있습니다.

여러분의 기대를 속이지 않기 위해 이 게시물은 소개용 게시물이라는 점을 미리 말씀드리고 싶습니다. 우선, 원칙적으로 Sber.DS 플랫폼의 내부에 무엇이 있는지에 대해 이야기하겠습니다. 모델의 생성부터 구현까지의 라이프사이클에 대한 이야기를 별도로 전해드리겠습니다.

Sber.DS는 여러 구성 요소로 구성되며, 핵심 구성 요소는 라이브러리, 개발 시스템 및 모델 실행 시스템입니다.

라이브러리는 모델 개발 아이디어가 나타나는 순간부터 PROM 구현, 모니터링 및 폐기까지 모델의 수명 주기를 제어합니다. 많은 라이브러리 기능은 교육 및 검증 샘플의 보고 및 저장과 같은 규제 기관 규칙에 따라 결정됩니다. 사실, 이것은 우리의 모든 모델의 등록입니다.

개발 시스템은 모델 및 검증 기술의 시각적 개발을 위해 설계되었습니다. 개발된 모델은 초기 검증을 거쳐 실행 시스템에 공급되어 비즈니스 기능을 수행합니다. 또한 런타임 시스템에서는 모델의 작동을 모니터링하기 위한 검증 기술을 주기적으로 실행하기 위해 모델을 모니터에 배치할 수 있습니다.

시스템에는 여러 유형의 노드가 있습니다. 일부는 다양한 데이터 소스에 연결하도록 설계되었고, 다른 일부는 소스 데이터를 변환하고 강화(마크업)하도록 설계되었습니다. 다양한 모델을 구축하기 위한 많은 노드와 이를 검증하기 위한 노드가 있습니다. 개발자는 모든 소스에서 데이터를 로드하고 중간 데이터를 변환, 필터링, 시각화하고 여러 부분으로 나눌 수 있습니다.

플랫폼에는 설계 영역으로 끌어다 놓을 수 있는 기성 모듈도 포함되어 있습니다. 모든 작업은 시각화된 인터페이스를 사용하여 수행됩니다. 실제로 한 줄의 코드 없이도 문제를 해결할 수 있습니다.

내장된 기능이 충분하지 않은 경우 시스템은 자신만의 모듈을 신속하게 생성할 수 있는 기능을 제공합니다. 우리는 다음을 기반으로 통합 개발 모드를 만들었습니다. Jupyter 커널 게이트웨이 처음부터 새로운 모듈을 만드는 사람들을 위한 것입니다.

Sber.DS의 아키텍처는 마이크로서비스를 기반으로 구축되었습니다. 마이크로서비스가 무엇인지에 대해서는 많은 의견이 있습니다. 어떤 사람들은 모놀리식 코드를 여러 부분으로 나누는 것만으로도 충분하다고 생각하지만 동시에 여전히 동일한 데이터베이스로 이동합니다. 우리의 마이크로서비스는 REST API를 통해서만 다른 마이크로서비스와 통신해야 합니다. 데이터베이스에 직접 액세스할 수 있는 해결 방법은 없습니다.

우리는 서비스가 너무 커지고 서투르게 되지 않도록 노력합니다. 하나의 인스턴스는 4~8GB 이상의 RAM을 소비해서는 안 되며, 새 인스턴스를 시작하여 요청을 수평적으로 확장할 수 있는 기능을 제공해야 합니다. 각 서비스는 REST API(공개 API). 서비스를 담당하는 팀은 API를 사용하는 마지막 클라이언트까지 API를 이전 버전과 호환되도록 유지해야 합니다.

애플리케이션의 핵심은 Spring Framework를 사용하여 Java로 작성됩니다. 솔루션은 처음에 클라우드 인프라에 신속하게 배포하도록 설계되었으므로 애플리케이션은 컨테이너화 시스템을 사용하여 구축되었습니다. Red Hat OpenShift (Kubernetes). 플랫폼은 비즈니스 기능 향상(새로운 커넥터, AutoML이 추가됨)과 기술 효율성 측면에서 지속적으로 발전하고 있습니다.

우리 플랫폼의 기능 중 하나는 모든 Sberbank 모델 실행 시스템에서 시각적 인터페이스로 개발된 코드를 실행할 수 있다는 것입니다. 이제 이미 두 개가 있습니다. 하나는 Hadoop에, 다른 하나는 OpenShift(Docker)에 있습니다. 우리는 거기서 멈추지 않고 온프레미스와 클라우드를 포함한 모든 인프라에서 코드를 실행하기 위한 통합 모듈을 만듭니다. Sberbank 생태계에 효과적으로 통합할 수 있는 가능성과 관련하여 기존 실행 환경과의 작업도 지원할 계획입니다. 앞으로 이 솔루션은 모든 조직의 모든 환경에 "즉시 사용 가능"하게 유연하게 통합될 수 있습니다.

PROM의 Hadoop에서 Python을 실행하는 솔루션을 지원하려고 시도한 사람들은 각 데이터 노드에 Python 사용자 환경을 준비하고 제공하는 것만으로는 충분하지 않다는 것을 알고 있습니다. Python 모듈을 사용하는 수많은 기계 학습용 C/C++ 라이브러리는 여러분을 편히 쉬게 하지 않을 것입니다. 새 라이브러리나 서버를 추가할 때 이미 구현된 모델 코드와의 하위 호환성을 유지하면서 패키지를 업데이트해야 한다는 점을 기억해야 합니다.

이를 수행하는 방법에는 여러 가지 접근 방식이 있습니다. 예를 들어, 자주 사용하는 라이브러리를 미리 준비하여 PROM에 구현해 보세요. Cloudera의 Hadoop 배포판에서는 일반적으로 다음을 사용합니다. 꾸러미. 또한 이제 Hadoop에서는 다음을 실행할 수 있습니다. 도커-컨테이너. 일부 간단한 경우에는 패키지와 함께 코드를 전달하는 것이 가능합니다. python.eggs.

은행은 제XNUMX자 코드 실행의 보안을 매우 중요하게 생각하므로 프로세스가 격리된 환경에서 실행되는 Linux 커널의 새로운 기능을 최대한 활용합니다. 리눅스 네임스페이스를 사용하면 네트워크 및 로컬 디스크에 대한 액세스 등을 제한할 수 있으며 이로 인해 악성 코드의 기능이 크게 저하됩니다. 각 부서의 데이터 영역은 해당 데이터의 소유자만 보호하고 액세스할 수 있습니다. 플랫폼은 소스에 대한 액세스부터 대상 매장에 데이터가 도착하는 것까지 모든 단계에서 제어되는 데이터 게시 프로세스를 통해서만 한 영역의 데이터가 다른 영역에 도달할 수 있도록 보장합니다.

올해 우리는 Hadoop에서 Python/R/Java로 작성된 모델 출시의 MVP를 완료할 계획입니다. 우리는 플랫폼 사용자를 어떤 식으로든 제한하지 않기 위해 Hadoop에서 사용자 정의 환경을 실행하는 방법을 배우는 야심 찬 작업을 스스로 설정했습니다.

또한 많은 DS 전문가는 수학과 통계에 뛰어나고 멋진 모델을 만들지만 빅 데이터 변환에 대해서는 잘 알지 못하며 교육 샘플을 준비하려면 데이터 엔지니어의 도움이 필요합니다. 우리는 동료들을 도와 Spark 엔진 모델의 표준 변환 및 기능 준비를 위한 편리한 모듈을 만들기로 결정했습니다. 이렇게 하면 데이터 엔지니어가 새 데이터 세트를 준비할 때까지 기다리지 않고 모델 개발에 더 많은 시간을 투자할 수 있습니다.

우리는 Linux 및 DevOps, Hadoop 및 Spark, Java 및 Spring, Scala 및 Akka, OpenShift 및 Kubernetes 등 다양한 분야에 대한 지식을 갖춘 인력을 채용합니다. 다음 시간에는 모델 라이브러리, 모델이 회사 내 라이프사이클을 통과하는 방법, 검증 및 구현 방법에 대해 이야기하겠습니다.

출처 : habr.com