저는 최근에 사이버 보안 회사의 데이터 플랫폼 담당 선임 이사와 이야기를 나눴습니다. 그는 이렇게 말했습니다. "저는 끊임없이 변화하는 도구가 너무 엉망이기 때문에 기계 학습의 미래를 보장 할 수있는 방법을 이해할 수 없습니다." 이것은 일반적인 정서입니다. 기계 학습 (ML)은 거의 다른 최신 기술보다 빠르게 발전했습니다. 라이브러리는 종종 연구 실험실에서 새로 출시되었으며 도구 및 플랫폼을 광고하는 수많은 공급 업체가 있습니다 (Databricks 포함). 그러나 우리가 이야기 한 것처럼 플랫폼 디렉터는 회사의 데이터 과학 (DS) 및 ML 이니셔티브를 미래에 대비할 수있는 완벽한 위치에 있다는 것을 이해하게되었습니다. 그들의 회사 는 끊임없이 변화하는 기술을 지원할 수 있는 플랫폼 이 필요했습니다 .
Databricks에서 근무하는 동안 저는 많은 조직이 DS 및 ML 팀을 장기적으로 지원하기 위해 데이터 플랫폼을 구축하는 것을 보았습니다. 이러한 조직이 일반적으로 직면하는 초기 문제는 데이터 플랫폼과 ML 도구 간의 분리, 엔지니어링과 DS 및 ML 팀 간의 잘못된 커뮤니케이션 및 협업, 변화와 성장을 저해하는 과거의 기술 선택 등 몇 가지 영역으로 분류 할 수 있습니다. 이 블로그 게시물에서는 이러한 조직이 새로운 기술을 선택하고 DS 및 ML 플랫폼을 개선하는 데 도움이되는 높은 수준의 권장 사항을 수집했습니다. 이러한 일반적인 실수와 그 해결책은 세 가지 원칙으로 구성됩니다.
DS 및 ML은 데이터에 쉽게 액세스 할 수 있어야합니다. 일반적인 장벽에는 독점 데이터 형식, 데이터 대역폭 제약 및 거버넌스 불일치가 있습니다.
내가 함께 일한 한 회사가 대표적인 예를 제공합니다. 이 회사는 데이터 엔지니어링에 의해 관리되는 깨끗한 데이터가있는 데이터웨어 하우스를 보유하고 있습니다. XGBoost 및 TensorFlow와 같은 최신 도구를 사용하여 비즈니스 단위와 함께 작업하는 데이터 과학자도 있었지만웨어 하우스에서 DS 및 ML 도구로 데이터를 쉽게 가져올 수 없어 많은 프로젝트가 지연되었습니다. 더욱이 플랫폼 인프라 팀은 데이터 과학자가 데이터를 랩톱이나 워크 스테이션에 복사해야해서 보안 위험이 발생할 수 있다고 우려했습니다. ML에 대한 데이터웨어 하우스 중심 접근 방식으로 인한 이러한 마찰을 해결하기 위해 우리는 과제를 세 부분으로 나눴습니다.
이 예에서 첫 번째 문제는 독점 데이터 저장소의 사용이었습니다. 데이터웨어 하우스는 독점 형식을 사용 하며 DS 및 ML 용 데이터를 추출하려면 값 비싼 데이터 송신 프로세스가 필요합니다. 반면에 DS 및 ML 도구는 일반적으로 SQL이 아닌 Python 및 R을 기반으로하며 디스크의 Parquet, JSON, CSV 등, 메모리의 Pandas 또는 Apache Spark DataFrame과 같은 개방형 형식을 기대합니다. 이 문제는 데이터웨어 하우스에 자연스럽게 맞지 않고 처리를 위해 특수 라이브러리가 필요한 이미지 및 오디오와 같은 비정형 데이터의 경우 더욱 악화됩니다.
Data Lake 스토리지 (Azure ADLS, AWS S3, GCP GCS)를 중심으로 데이터 관리를 재구성 함으로써이 회사는 데이터 엔지니어링과 DS 및 ML 모두에 대한 데이터 관리를 통합하여 데이터 과학자가 데이터에 훨씬 쉽게 액세스 할 수있게되었습니다. 이제 데이터 과학자는 Python 및 R을 사용하여 기본 스토리지에서 DataFrame으로 데이터를 직접로드하여 모델 개발 및 반복 속도를 높일 수 있습니다. 또한 이미지 및 오디오와 같은 특수 형식으로 작업하여 새로운 ML 기반 제품 방향을 차단할 수 있습니다.
DS 및 ML 친화적 인 형식 외에도이 회사는 데이터 대역폭 및 확장 문제에 직면했습니다. ML 알고리즘에 데이터웨어 하우스의 데이터를 제공하면 소규모 데이터에 적합합니다. 그러나 애플리케이션 로그, 이미지, 텍스트, IoT 텔레 메 트리 및 기타 최신 데이터 소스는 데이터웨어 하우스를 쉽게 최대로 늘릴 수 있으므로 저장 비용이 매우 많이 들고 DS 및 ML 알고리즘의 추출 속도가 엄청나게 느려집니다.
이 회사는 데이터 레이크 스토리지를 기본 데이터 레이어 로 만들어 데이터 스토리지 및 이동 비용 을 줄이면서 10 배 크기의 데이터 세트로 작업 할 수있었습니다 . 더 많은 과거 데이터는 특히 드문 이상 값 이벤트를 처리 할 때 모델의 정확도를 높였습니다.
이 회사가 이전 데이터 관리 시스템에서 직면 한 문제 중 가장 복잡하고 위험한 것은 데이터 보안 및 거버넌스였습니다. 데이터 액세스를 관리하는 팀은 테이블 기반 액세스에 익숙한 데이터베이스 관리자였습니다. 그러나 데이터 과학자 는 데이터를 최신 ML 도구로 가져 오기 위해 이러한 관리되는 테이블에서 데이터 세트를 내 보내야 했습니다. 이러한 단절로 인한 보안 문제와 모호함으로 인해 데이터 과학자가 새로운 데이터 소스에 액세스해야 할 때마다 수개월의 지연이 발생했습니다.
이러한 문제점으로 인해 DS 및 ML 도구 가 데이터 엔지니어와 데이터베이스 관리자가 사용 하는 것과 동일한 거버넌스 모델 하에서 데이터에 액세스 할 수 있는보다 통합 된 플랫폼을 선택하게 되었습니다. 데이터 과학자는 대규모 데이터 세트를 Pandas 및 PySpark 데이터 프레임에 쉽게로드 할 수 있었고 데이터베이스 관리자는 사용자 ID를 기반으로 데이터 액세스를 제한하고 데이터 유출을 방지 할 수있었습니다.
이 고객은 DS 및 ML에 대한 데이터 액세스를 단순화하기 위해 두 가지 주요 기술 변경을 수행했습니다 . (1) 데이터 레이크 스토리지를 기본 데이터 저장소로 사용하고 (2) 데이터 레이크 스토리지가 지원하는 테이블 및 파일에 대한 공유 거버넌스 모델을 구현했습니다. 이러한 선택 은 델타 레이크 를 활용 하여 데이터 파이프 라인 안정성을 데이터 엔지니어링, ML에 필요한 개방형 데이터 형식으로 데이터 과학을 제공하고 보안에 필요한 거버넌스 모델을 관리자에게 제공하는 레이크 하우스 아키텍처로 이끌었습니다 . 이 현대화 된 데이터 아키텍처를 통해 데이터 과학자들은 새로운 사용 사례에 대한 가치를 절반도 안되는 시간에 보여줄 수있었습니다.
데이터 액세스 단순화에 대해 제가 가장 좋아하는 고객 성공 사례는 다음과 같습니다.
데이터 플랫폼은 이전 섹션에서 설명한 데이터 액세스 메커니즘을 넘어 데이터 엔지니어링과 DS 및 ML 팀 간의 협업을 단순화해야합니다. 일반적인 장벽은 컴퓨팅 및 배포, 데이터 처리 및 거버넌스를 위해 연결이 끊긴 플랫폼을 사용하는이 두 그룹으로 인해 발생합니다.
두 번째 고객은 성숙한 데이터 과학 팀이 있었지만 데이터 엔지니어링 팀과 너무 단절되어 있다는 사실을 인식했습니다. 데이터 과학에는 노트북, 온 디맨드 (클라우드) 워크 스테이션 및 ML 라이브러리 지원이 포함 된 DS 중심 플랫폼이있었습니다. 그들은 새롭고 가치있는 모델을 구축 할 수 있었고 데이터 엔지니어링은 배치 추론을 위해 모델을 Apache Spark 기반 프로덕션 시스템에 연결하는 프로세스를 가졌습니다. 그러나이 과정은 고통 스러웠습니다. 데이터 과학 팀은 워크 스테이션에서 Python 및 R을 사용하는 데 익숙했지만 데이터 엔지니어링에서 사용하는 Java 환경 및 클러스터 컴퓨팅에 익숙하지 않았습니다. 이러한 격차는 어색한 핸드 오프 프로세스로 이어졌습니다. Java로 Python 및 R 모델을 다시 작성하고 동일한 동작을 확인하고, 기능화 로직을 다시 작성하고 모델을 스프레드 시트에서 추적되는 파일로 수동 공유합니다. 이러한 관행으로 인해 수개월의 지연이 발생하고 생산에 오류가 발생했으며 관리 감독이 허용되지 않았습니다.
위의 예에서 첫 번째 과제는 환경 관리였습니다. ML 모델은 격리 된 개체가 아닙니다. 동작은 환경에 따라 다르며 모델 예측은 라이브러리 버전에 따라 변경 될 수 있습니다. 이 고객의 팀은 데이터 엔지니어링 프로덕션 시스템에서 ML 개발 환경을 복제하기 위해 뒤로 구부리고있었습니다. 현대 ML 세계에는 Python (때로는 R)이 필요하므로 virtualenv, conda 및 Docker 컨테이너와 같은 환경 복제 도구가 필요했습니다.
이 요구 사항을 인식하고 그들은 이러한 도구를 내부적으로 사용하지만 환경 관리의 복잡성으로부터 데이터 과학자를 보호 하는 MLflow 로 전환했습니다 . MLflow를 통해 데이터 과학자들은 생산 지연 시간을 한 달 이상 줄이고 최신 ML 라이브러리로 업그레이드하는 것에 대해 걱정하지 않았습니다.
DS 및 ML의 경우 좋은 데이터가 전부이며 ETL / ELT (종종 데이터 엔지니어 소유)와 기능화 (종종 데이터 과학자 소유) 사이의 경계는 임의적 입니다. 이 고객의 경우 데이터 과학자가 프로덕션에서 새롭거나 향상된 기능이 필요하면 데이터 엔지니어에게 파이프 라인 업데이트를 요청했습니다. 긴 지연으로 인해 대기 중에 비즈니스 우선 순위가 변경되어 작업 낭비가 발생하기도했습니다.
새로운 플랫폼을 선택할 때 그들은 데이터 처리 로직의 전달을 지원하는 도구를 찾았습니다. 결국 그들은 Databricks Jobs를 핸드 오프 지점으로 선택했습니다. 데이터 과학자는 Python 및 R 코드를 단위 (Jobs)로 래핑 할 수 있고 데이터 엔지니어링은 기존 오케 스트레이터 (Apache AirFlow) 및 CI / CD 시스템 ( Jenkins). 기능화 로직을 업데이트하는 새로운 프로세스는 거의 완전히 자동화되었습니다.
ML 모델은 기본적으로 방대한 양의 데이터와 비즈니스 목표가 간결한 비즈니스 로직으로 추출됩니다. 이 고객과 함께 일하면서 그러한 귀중한 자산이 적절한 거버넌스없이 저장되고 공유되고 있다는 사실이 제게 아이러니하고 두렵습니다 . 운영상 거버넌스의 부재로 인해 생산 (파일 및 스프레드 시트)을위한 힘들고 수동적 인 프로세스가 발생했을뿐만 아니라 팀 리더와 이사의 감독도 줄어 들었습니다.
ML 모델을 공유하고 프로덕션으로 이동하기위한 메커니즘을 제공하는 관리 형 MLflow 서비스로 이동하는 것이 판도를 바 꾸었습니다.이 서비스는 모두 단일 모델 레지스트리의 액세스 제어에 따라 보호되었습니다. 소프트웨어를 시행하고 이전에는 수동 프로세스를 자동화했으며 경영진은 모델이 생산으로 이동하면서이를 감독 할 수있었습니다.
협업을 촉진하기위한이 고객의 핵심 기술 선택은 공유 된 거버넌스 및 보안 모델을 통해 데이터 엔지니어링 및 데이터 과학 요구를 모두 지원하는 통합 플랫폼을 중심으로 선택되었습니다. Databricks를 사용하여 사용 사례를 활성화 한 핵심 기술 중 일부는 컴퓨팅 및 환경 요구 사항에 대한 Databricks 런타임 및 클러스터 관리, 작업 단위 정의 작업 ( AWS / Azure / GCP 문서), 조정을위한 개방형 API ( AWS / Azure / GCP 문서) 및 CI / CD 통합 ( AWS / Azure / GCP 문서) 및 관리 형 MLflow MLOps 및 거버넌스.
데이터 엔지니어링과 데이터 과학 간의 협업과 관련된 고객 성공 사례는 다음과 같습니다.
조직과 기술이 변할 것입니다. 데이터 크기는 증가 할 것입니다. 팀 기술 세트와 목표는 진화 할 것입니다. 그리고 기술은 시간이 지남에 따라 발전하고 대체 될 것입니다. 분명하지만 일반적인 전략적 오류는 규모를 계획하지 않는 것입니다. 일반적이지만 더 미묘한 또 다른 오류는 데이터, 논리 및 모델에 대해 휴대 불가능한 기술을 선택하는 것입니다.
이 마지막 원칙을 설명하기 위해 세 번째 고객 사례를 공유하겠습니다. 콘텐츠 분류를위한 ML 모델을 만들고자하는 초기 단계 고객과 함께 작업했습니다. 그들은 Databricks를 선택했지만 전문성이 부족하여 우리의 전문 서비스에 크게 의존했습니다. 1 년 후 비즈니스에 대한 초기 가치를 보여준 그들은 더 많은 전문 데이터 과학자를 고용 할 수 있었고 그 동안 거의 50 배 더 많은 데이터를 수집했습니다. 그들은 확장하고, 분산 된 ML 라이브러리로 전환하고, 다른 데이터 팀과 더 밀접하게 통합해야했습니다.
이 고객이 발견했듯이 데이터, 모델 및 조직은 시간이 지남에 따라 확장 될 것 입니다. 그들의 데이터는 원래 데이터웨어 하우스에 들어갈 수 있었지만 데이터 크기와 분석 요구가 증가함에 따라 다른 아키텍처로 마이그레이션해야했습니다. DS 및 ML 팀은 처음에는 랩톱에서 작업 할 수 있었지만 1 년 후 더 강력한 클러스터가 필요했습니다. Lakehouse 아키텍처와 단일 머신 및 분산 ML을 모두 지원하는 플랫폼을 미리 계획함으로써이 조직은 빠른 성장을위한 원활한 경로를 준비했습니다.
이식성은 더 미묘한 문제입니다. 기술 전략은 " 오픈 소스 기술을 사용하여 사내 플랫폼을 구축하면 사용자 정의를 허용하고 종속을 피할 수있는 반면 기성품의 독점 도구 세트를 구입하면 더 빠른 설정을 허용 할 수 있습니다. 그리고 진행.” 이 주장은 불행한 선택을 제시합니다. 사용자 지정 플랫폼에 막대한 선행 투자를하거나 독점 기술에 얽매이는 것입니다.
그러나이 주장은 데이터 플랫폼과 인프라와 프로젝트 수준 데이터 기술을 구분 하지 않기 때문에 잘못된 것 입니다. 데이터 스토리지 계층, 오케스트레이션 도구 및 메타 데이터 서비스는 일반적인 플랫폼 수준 기술 선택입니다. 데이터 형식, 언어 및 ML 라이브러리는 일반적인 프로젝트 수준 기술 선택입니다. 이 두 가지 유형의 선택은 변경을 계획 할 때 다르게 처리되어야합니다. 데이터 플랫폼과 인프라를 회사의 전문 데이터, 논리 및 모델을위한 일반 컨테이너 및 파이프 라인으로 생각하면 도움이됩니다.
프로젝트 수준 기술은 교체가 간단해야합니다 . 새로운 데이터 및 ML 기반 제품에는 새로운 데이터 소스, ML 라이브러리 또는 서비스 통합이 필요한 요구 사항이 다를 수 있습니다. 이러한 프로젝트 수준의 기술 선택을 유연하게 변경하면 비즈니스가 적응하고 경쟁력을 갖출 수 있습니다.
플랫폼은 이러한 유연성을 허용해야하며, 이상적으로는 팀이 데이터 및 모델에 대한 독점 도구 및 형식을 피하도록 장려해야합니다. 제 고객은 scikit-learn으로 시작했지만 플랫폼이나 MLOps 도구를 변경하지 않고도 Spark ML 및 분산 TensorFlow로 전환 할 수있었습니다.
플랫폼은 이식성을 허용해야합니다 . 플랫폼이 회사에 장기적으로 서비스를 제공하려면 플랫폼이 종속을 피해야합니다. 플랫폼간에 데이터, 논리 및 모델을 이동하는 것은 간단하고 저렴해야합니다. 데이터 플랫폼이 회사의 핵심 사명과 강점이 아닌 경우 조직이 더 빨리 이동할 수있는 플랫폼을 구입하는 것이 합리적입니다. 플랫폼이 회사가 민첩성을 유지하고 필요할 때 귀중한 자산을 다른 곳으로 옮길 수있는 한 말입니다.
제 고객은 scikit-learn, Spark ML 및 MLflow와 같은 개방형 도구 및 API를 사용할 수있는 플랫폼을 선택하는 것이 두 가지 방법으로 도움이되었습니다. 첫째, 결정을 되돌릴 수 있다는 확신을 주어 플랫폼 결정을 단순화했습니다. 둘째, 다른 플랫폼간에 코드와 모델을 이동하여 다른 데이터 팀과 통합 할 수있었습니다.
| 변경 유형 | 플랫폼 요구 | 프로젝트 수준의 기술 예 |
| 스케일링 | 작은 데이터와 큰 데이터를 모두 효율적으로 처리합니다.
단일 노드 및 분산 컴퓨팅을 제공합니다. |
팬더 스케일 → Apache Spark 또는 Koalas.
scikit-learn → Spark ML을 확장합니다. Keras → Horovod를 확장하십시오. |
| 새로운 데이터 유형 및 애플리케이션 도메인 | 임의 데이터 유형 및 개방형 데이터 형식을 지원합니다.
일괄 및 스트리밍을 모두 지원합니다. 다른 시스템과 쉽게 통합됩니다. |
Delta, Parquet, JSON, CSV, TXT, JPG, DICOM, MPEG 등을 사용하고 결합합니다.
웹 앱 백엔드에서 데이터를 스트리밍합니다. |
| 새로운 페르소나 및 조직 | 데이터 과학자, 데이터 엔지니어 및 비즈니스 분석가를 지원합니다.
확장 가능한 거버넌스 및 액세스 제어를 제공합니다. |
(a) 노트북의 플롯과 (b) 플러그인 가능한 BI 도구의 대시 보드 모두에서 데이터를 시각화합니다.
(a) 커스텀 코드와 (b) AutoML을 통해 ML을 실행합니다. |
| 플랫폼 변경 | 사용자는 자신의 데이터 및 ML 모델을 소유합니다. 출국세가 없습니다.
사용자는 자신의 코드를 소유합니다. 자식과 동기화하십시오. |
Keras 및 Spark ML과 같은 오픈 코드 API를 사용하여 프로젝트 수준 워크로드를 플랫폼과 독립적으로 유지합니다. |
고객이 변화에 적응할 수 있도록 허용 한이 고객의 주요 기술 선택은 레이크 하우스 아키텍처 , 단일 머신 및 분산 ML을 모두 지원 하는 플랫폼 , MLOps 용 라이브러리에 구애받지 않는 프레임 워크 인 MLflow였습니다. 이러한 선택은 데이터 확장 경로를 50 배 단순화하고 더 복잡한 ML 모델로 전환하며 팀과 기술 세트를 확장했습니다.
변경 계획 및 이식성에 대한 고객 성공 사례에 대한 필자가 선택한 몇 가지 사항은 다음과 같습니다.
큰 원칙을 나열하고 "가서 해!"라고 말하는 것은 쉽습니다. 그러나이를 구현하려면 기술 스택, 조직 및 비즈니스에 대한 솔직한 평가와 계획 및 실행이 필요합니다. Databricks는 DS 및 ML을 지원하는 데이터 플랫폼 구축에 대한 풍부한 경험을 제공합니다.
우리와 함께 일하는 가장 성공적인 조직은 몇 가지 모범 사례를 따릅니다 . 그들은 장기적인 아키텍처 계획이 영향과 가치의 단기 시연과 동시에 이루어져야한다는 것을 알고 있습니다. 이 가치는 데이터 과학 팀을 비즈니스 단위 및 우선 순위가 지정된 사용 사례에 맞춰 경영진에게 전달됩니다. 조직 간 조정은 프로세스 단순화에서 CoE (Centers of Excellence) 생성에 이르기까지 조직 개선을 안내하는 데 도움이됩니다.
이 블로그 게시물은 이러한 주제의 표면에 불과합니다. 다른 훌륭한 자료는 다음과 같습니다.
