Amazon Redshift: 저렴한 가격, 더 높은 성능 | 아마존 웹 서비스

플라톤에 의해 재발행

팔로워 : 0

사실상 모든 고객과 마찬가지로 귀하도 가능한 한 최고의 성능을 얻으면서 지출을 최소화하기를 원합니다. 이는 가격 대비 성능에주의를 기울여야 함을 의미합니다. 와 함께 아마존 레드 시프트, 케이크를 갖고 먹을 수도 있습니다! Amazon Redshift는 수백 명의 동시 사용자를 지원하기 위한 동시성 확장, 더 빠른 쿼리 성능을 위한 향상된 문자열 인코딩과 같은 고급 기술을 사용하여 실제 워크로드에서 다른 클라우드 데이터 웨어하우스보다 사용자당 최대 4.9배 더 낮은 비용, 최대 7.9배 더 나은 가격 대비 성능을 제공합니다. , 그리고 Amazon Redshift 서버리스 성능 향상. 가격 대비 성능이 중요한 이유와 Amazon Redshift의 가격 대비 성능이 특정 수준의 워크로드 성능, 즉 성능 ROI(투자 수익)를 얻는 데 드는 비용을 측정하는 방법을 알아보려면 계속 읽어보세요.

가격과 성능 모두 가격 대비 성능 계산에 포함되기 때문에 가격 대비 성능을 생각하는 방법에는 두 가지가 있습니다. 첫 번째 방법은 가격을 일정하게 유지하는 것입니다. 지출할 금액이 1달러인 경우 데이터 웨어하우스에서 얼마나 많은 성능을 얻을 수 있습니까? 가격 대비 성능이 더 나은 데이터베이스는 1달러를 지출할 때마다 더 나은 성능을 제공합니다. 따라서 가격이 동일한 두 데이터 웨어하우스를 비교할 때 가격을 일정하게 유지하면 가격 대비 성능이 더 나은 데이터베이스가 쿼리를 더 빠르게 실행합니다.. 가격 대비 성능을 살펴보는 두 번째 방법은 성능을 일정하게 유지하는 것입니다. 작업 부하를 10분 안에 완료해야 하는 경우 비용은 얼마입니까? 가격 대비 성능이 더 뛰어난 데이터베이스는 더 저렴한 비용으로 10분 안에 워크로드를 실행합니다. 따라서 동일한 성능을 제공하도록 크기가 조정된 두 데이터 웨어하우스를 비교할 때 성능을 일정하게 유지하면 가격 대비 성능이 더 나은 데이터베이스가 비용이 더 적게 들고 비용을 절약할 수 있습니다.

마지막으로 가격 대비 성능의 또 다른 중요한 측면은 예측 가능성입니다. 데이터 웨어하우스 사용자 수가 증가함에 따라 데이터 웨어하우스에 드는 비용이 얼마나 되는지 아는 것은 계획을 세우는 데 중요합니다. 현재 최고의 가격 대비 성능을 제공할 뿐만 아니라 더 많은 사용자와 워크로드가 추가됨에 따라 예측 가능하게 확장하고 최고의 가격 대비 성능을 제공해야 합니다. 이상적인 데이터 웨어하우스는 다음과 같아야 합니다. 선형 스케일— 두 배의 쿼리 처리량을 제공하기 위해 데이터 웨어하우스를 확장하면 이상적으로는 비용이 두 배(또는 그 이하)가 됩니다.

이 게시물에서는 성능 결과를 공유하여 Amazon Redshift가 선도적인 대체 클라우드 데이터 웨어하우스에 비해 어떻게 훨씬 더 나은 가격 대비 성능을 제공하는지 보여줍니다. 즉, 다른 데이터 웨어하우스 중 하나에 지출하는 것과 동일한 금액을 Amazon Redshift에 지출하면 Amazon Redshift를 통해 더 나은 성능을 얻을 수 있다는 의미입니다. 또는 동일한 성능을 제공하도록 Redshift 클러스터 크기를 조정하면 이러한 대안에 비해 비용이 더 저렴해집니다.

실제 워크로드를 위한 가격 대비 성능

Amazon Redshift를 사용하면 복잡한 ETL(추출, 변환 및 로드) 기반 보고서의 일괄 처리와 실시간 스트리밍 분석부터 지연 시간이 짧은 BI(비즈니스 인텔리전스) 대시보드에 이르기까지 매우 다양한 워크로드를 지원할 수 있습니다. XNUMX초 미만의 응답 시간으로 수백 또는 수천 명의 사용자에게 동시에 서비스를 제공해야 합니다. 고객을 위해 가격 대비 성능을 지속적으로 개선하는 방법 중 하나는 Redshift 제품군의 소프트웨어 및 하드웨어 성능 원격 측정을 지속적으로 검토하여 Amazon Redshift 성능을 더욱 향상시킬 수 있는 기회와 고객 사용 사례를 찾는 것입니다.

차량 원격 측정을 통한 성능 최적화의 최근 사례는 다음과 같습니다.

문자열 쿼리 최적화 – Amazon Redshift가 Redshift 집합에서 다양한 데이터 유형을 처리하는 방법을 분석함으로써 문자열이 많은 쿼리를 최적화하면 고객의 워크로드에 상당한 이점을 가져올 수 있다는 사실을 발견했습니다. (이에 대해서는 이 게시물의 뒷부분에서 자세히 설명합니다.)
자동화된 구체화된 뷰 – Amazon Redshift 고객은 공통 하위 쿼리 패턴을 가진 많은 쿼리를 실행하는 경우가 많다는 사실을 발견했습니다. 예를 들어, 여러 다른 쿼리가 동일한 조인 조건을 사용하여 동일한 세 개의 테이블을 조인할 수 있습니다. Amazon Redshift는 이제 구체화된 뷰를 자동으로 생성 및 유지 관리한 다음 기계 학습을 통해 구체화된 뷰를 사용하도록 쿼리를 투명하게 다시 작성할 수 있습니다. 자동화된 구체화된 뷰 Amazon Redshift의 자율 기능. 활성화되면 자동화된 구체화된 뷰는 사용자 개입 없이 반복 쿼리에 대한 쿼리 성능을 투명하게 향상시킬 수 있습니다. (이 게시물에서 논의된 벤치마크 결과에서는 자동화된 구체화된 뷰가 사용되지 않았습니다.)
동시성이 높은 워크로드 – Amazon Redshift를 사용하여 대시보드와 같은 워크로드를 제공하는 사용 사례가 늘어나고 있습니다. 이러한 워크로드는 원하는 쿼리 응답 시간이 한 자릿수 초 이하라는 특징이 있으며, 수십 또는 수백 명의 동시 사용자가 급증하고 종종 예측할 수 없는 사용 패턴으로 동시에 쿼리를 실행하고 있습니다. 이에 대한 전형적인 예는 많은 수의 사용자가 한 주를 시작하는 월요일 아침에 트래픽이 급증하는 Amazon Redshift 지원 BI 대시보드입니다.

특히 동시성이 높은 워크로드는 적용 가능성이 매우 넓습니다. 대부분의 데이터 웨어하우스 워크로드는 동시성으로 작동하며, 수백 또는 수천 명의 사용자가 Amazon Redshift에서 동시에 쿼리를 실행하는 것은 드문 일이 아닙니다. Amazon Redshift는 쿼리 응답 시간을 예측 가능하고 빠르게 유지하도록 설계되었습니다. Redshift Serverless는 쿼리 응답 시간을 빠르고 예측 가능하게 유지하기 위해 필요에 따라 컴퓨팅을 추가 및 제거하여 이를 자동으로 수행합니다. 이는 한두 명의 사용자가 액세스할 때 빠르게 로드되는 Redshift Serverless 지원 대시보드가 많은 사용자가 동시에 로드하는 경우에도 계속해서 빠르게 로드된다는 의미입니다.

이러한 유형의 워크로드를 시뮬레이션하기 위해 우리는 100GB 데이터 세트가 있는 TPC-DS에서 파생된 벤치마크를 사용했습니다. TPC-DS는 다양한 일반적인 데이터 웨어하우스 쿼리를 포함하는 업계 표준 벤치마크입니다. 100GB라는 상대적으로 작은 규모에서 이 벤치마크의 쿼리는 Redshift Serverless에서 평균 몇 초 만에 실행됩니다. 이는 대화형 BI 대시보드를 로드하는 사용자가 기대하는 것을 나타냅니다. 우리는 이 벤치마크에 대해 1~200개의 동시 테스트를 실행하여 동시에 대시보드를 로드하려는 1~200명의 사용자를 시뮬레이션했습니다. 또한 자동 확장을 지원하는 널리 사용되는 여러 대체 클라우드 데이터 웨어하우스에 대해서도 테스트를 반복했습니다. Amazon Redshift는 가격 대비 성능 리더십을 이어갑니다., 경쟁사 A는 자동 확장을 지원하지 않기 때문에 포함하지 않았습니다. 우리는 평균 쿼리 응답 시간을 측정했는데, 이는 사용자가 쿼리가 완료되거나 대시보드가 로드될 때까지 기다리는 시간을 의미합니다. 결과는 다음 차트에 나와 있습니다.

경쟁사 B는 약 64개의 동시 쿼리까지 잘 확장됩니다. 이 시점에서는 추가 컴퓨팅을 제공할 수 없고 쿼리가 대기열에 들어가기 시작하여 쿼리 응답 시간이 늘어납니다. 경쟁사 C는 자동으로 확장할 수 있지만 Amazon Redshift 및 경쟁사 B보다 낮은 쿼리 처리량으로 확장되며 쿼리 런타임을 낮게 유지할 수 없습니다. 또한 컴퓨팅이 부족할 때 대기열 쿼리를 지원하지 않으므로 약 128명의 동시 사용자를 초과하여 확장할 수 없습니다. 이 이상의 추가 쿼리 제출은 시스템에서 거부됩니다.

여기서 Redshift Serverless는 수백 명의 사용자가 동시에 쿼리를 실행하는 경우에도 쿼리 응답 시간을 약 5초로 비교적 일관되게 유지할 수 있습니다. 경쟁업체 B와 C의 평균 쿼리 응답 시간은 웨어하우스의 로드가 증가함에 따라 꾸준히 증가합니다. 이로 인해 데이터 웨어하우스가 사용량이 많을 때 사용자는 쿼리가 반환될 때까지 더 오래(최대 16초) 기다려야 합니다. 즉, 사용자가 대시보드를 새로 고치려고 하면(다시 로드할 때 여러 개의 동시 쿼리를 제출할 수도 있음) Amazon Redshift는 대시보드가 수십 또는 수백 개의 다른 쿼리에 의해 로드되는 경우에도 대시보드 로드 시간을 훨씬 더 일관되게 유지할 수 있습니다. 동시에 사용자.

Amazon Redshift는 짧은 쿼리에 대해 매우 높은 쿼리 처리량을 제공할 수 있기 때문입니다. Amazon Redshift는 가격 대비 성능 리더십을 이어갑니다.), 또한 더 효율적으로 확장할 때 더 높은 동시성을 처리할 수 있으므로 훨씬 더 저렴한 비용으로 처리할 수 있습니다. 이를 정량화하기 위해 우리는 게시된 가격 대비 성능을 살펴봅니다. 주문형 가격 이전 테스트의 각 창고에 대해 다음 차트에 표시됩니다. 사용한다는 점은 주목할 가치가 있습니다. 예약 인스턴스(RI)특히 전체 선불 옵션으로 구매한 3년 RI는 프로비저닝된 클러스터에서 Amazon Redshift를 실행하는 데 드는 비용이 가장 낮으므로 온디맨드 또는 기타 RI 옵션에 비해 가격 대비 성능이 가장 좋습니다.

따라서 Amazon Redshift는 더 높은 동시성으로 더 나은 성능을 제공할 수 있을 뿐만 아니라 훨씬 더 저렴한 비용으로 이를 수행할 수 있습니다. 가격 대비 성능 차트의 각 데이터 포인트는 지정된 동시성에서 벤치마크를 실행하는 데 드는 비용과 동일합니다. 가격 대비 성능은 선형이기 때문에 모든 동시성에서 벤치마크를 실행하는 데 드는 비용을 동시성(이 차트의 동시 사용자 수)으로 나누어 이 특정 벤치마크에 대한 각 신규 사용자 추가 비용을 알 수 있습니다.

앞의 결과는 간단하게 복제할 수 있습니다. 벤치마크에 사용된 모든 쿼리는 다음에서 사용할 수 있습니다. GitHub 저장소 성능은 데이터 웨어하우스를 시작하고, Amazon Redshift에서 동시성 확장(또는 다른 웨어하우스의 해당 자동 확장 기능)을 활성화하고, 즉시 데이터를 로드한 다음(수동 튜닝이나 데이터베이스별 설정 없음) 실행하여 측정됩니다. 각 데이터 웨어하우스에서 1단계로 200~32개의 동시 쿼리 스트림을 제공합니다. 동일한 GitHub 저장소는 사전 생성된(수정되지 않은) TPC-DS 데이터를 참조합니다. 아마존 단순 스토리지 서비스 (Amazon S3) 공식 TPC-DS 데이터 생성 키트를 사용하여 다양한 규모로 확장합니다.

문자열이 많은 워크로드 최적화

앞서 언급했듯이 Amazon Redshift 팀은 고객에게 더 나은 가격 대비 성능을 제공할 수 있는 새로운 기회를 지속적으로 찾고 있습니다. 성능을 크게 향상시키기 위해 최근 출시한 개선 사항 중 하나는 문자열 데이터에 대한 쿼리 성능을 가속화하는 최적화입니다. 예를 들어 다음과 같은 쿼리를 사용하여 뉴욕시에 위치한 소매점에서 발생한 총 수익을 찾을 수 있습니다. SELECT sum(price) FROM sales WHERE city = ‘New York’. 이 쿼리는 문자열 데이터(city = ‘New York’). 상상할 수 있듯이 문자열 데이터 처리는 데이터 웨어하우스 애플리케이션 어디에나 존재합니다.

고객의 워크로드가 문자열에 액세스하는 빈도를 정량화하기 위해 Amazon Redshift에서 관리하는 수만 개의 고객 클러스터에 대한 플릿 원격 측정을 사용하여 문자열 데이터 유형 사용에 대한 자세한 분석을 수행했습니다. 분석에 따르면 클러스터의 90%에서 문자열 열이 모든 열의 30% 이상을 구성하고, 클러스터의 50%에서 문자열 열이 모든 열의 50% 이상을 구성하는 것으로 나타났습니다. 또한 Amazon Redshift 클라우드 데이터 웨어하우스 플랫폼에서 실행되는 모든 쿼리의 대부분은 하나 이상의 문자열 열에 액세스합니다. 또 다른 중요한 요소는 문자열 데이터가 카디널리티가 매우 낮은 경우가 많다는 것입니다. 즉, 열에 상대적으로 작은 고유 값 집합이 포함되어 있다는 의미입니다. 예를 들어, 비록 orders 판매 데이터를 나타내는 테이블에는 수십억 개의 행이 포함될 수 있습니다. order_status 해당 테이블 내의 열에는 다음과 같이 수십억 개의 행에 걸쳐 몇 가지 고유한 값만 포함될 수 있습니다. pending, in process및 completed.

이 글을 쓰는 시점에서 Amazon Redshift의 대부분의 문자열 열은 다음과 같이 압축됩니다. LZO or ZSTD 알고리즘. 이는 우수한 범용 압축 알고리즘이지만 카디널리티가 낮은 문자열 데이터를 활용하도록 설계되지 않았습니다. 특히, 작업을 수행하기 전에 데이터의 압축을 풀어야 하며 하드웨어 메모리 대역폭 사용 효율성이 떨어집니다. 카디널리티가 낮은 데이터의 경우 더 최적일 수 있는 또 다른 인코딩 유형이 있습니다. 바이트딕트. 이 인코딩은 데이터베이스 엔진이 먼저 압축을 풀 필요 없이 압축된 데이터에 대해 직접 작동할 수 있도록 하는 사전 인코딩 체계를 사용합니다.

문자열이 많은 워크로드의 가격 대비 성능을 더욱 향상시키기 위해 Amazon Redshift는 이제 BYTEDICT로 인코딩된 낮은 카디널리티 문자열 열에 대해 5~63배 더 빠른 스캔 및 조건자 평가 속도를 높이는 추가 성능 향상 기능을 도입하고 있습니다. 다음 섹션) LZO 또는 ZSTD와 같은 대체 압축 인코딩과 비교됩니다. Amazon Redshift는 가볍고 CPU 효율이 높으며 BYTEDICT로 인코딩된 낮은 카디널리티 문자열 열에 대한 스캔을 벡터화하여 이러한 성능 향상을 달성합니다. 이러한 문자열 처리 최적화는 최신 하드웨어가 제공하는 메모리 대역폭을 효과적으로 활용하여 문자열 데이터에 대한 실시간 분석을 가능하게 합니다. 새로 도입된 이러한 성능 기능은 카디널리티가 낮은 문자열 열(최대 수백 개의 고유 문자열 값)에 최적입니다.

활성화하면 이 새로운 고성능 문자열 향상 기능을 자동으로 활용할 수 있습니다. 자동 테이블 최적화 Amazon Redshift 데이터 웨어하우스에서. 테이블에 자동 테이블 최적화가 활성화되어 있지 않은 경우 다음에서 권장 사항을 받을 수 있습니다. 아마존 레드시프트 어드바이저 Amazon Redshift 콘솔에서 문자열 열의 BYTEDICT 인코딩 적합성에 대해 알아보세요. BYTEDICT 인코딩을 사용하여 카디널리티가 낮은 문자열 열이 있는 새 테이블을 정의할 수도 있습니다. Amazon Redshift의 문자열 향상 기능은 이제 모든 AWS 리전에서 사용할 수 있습니다. 아마존 레드시프트를 사용할 수 있습니다.

실적 결과

문자열 개선이 성능에 미치는 영향을 측정하기 위해 우리는 낮은 카디널리티 문자열 데이터로 구성된 10TB(Tera Byte) 데이터 세트를 생성했습니다. 우리는 Amazon Redshift 플릿 원격 측정에서 문자열 길이의 25번째, 50번째, 75번째 백분위수에 해당하는 짧은, 중간, 긴 문자열을 사용하여 세 가지 버전의 데이터를 생성했습니다. 이 데이터를 Amazon Redshift에 두 번 로드하여 한 경우에는 LZO 압축을 사용하고 다른 경우에는 BYTEDICT 압축을 사용하여 인코딩했습니다. 마지막으로, 이러한 낮은 쿼리에 대해 많은 행(테이블의 90%), 중간 개수의 행(테이블의 50%), 몇 개의 행(테이블의 1%)을 반환하는 스캔 중심 쿼리의 성능을 측정했습니다. -카디널리티 문자열 데이터세트. 성능 결과는 다음 차트에 요약되어 있습니다.

높은 비율의 행과 일치하는 조건자가 있는 쿼리는 LZO에 비해 새로운 벡터화된 BYTEDICT 인코딩을 사용하여 5~30배 개선된 반면, 낮은 비율의 행과 일치하는 조건자가 있는 쿼리는 이 내부 벤치마크에서 10~63배 개선되었습니다.

Redshift 서버리스 가격 대비 성능

이 게시물에 제시된 높은 동시성 성능 결과 외에도 TPC-DS에서 파생된 클라우드 데이터 웨어하우스 벤치마크를 사용하여 Redshift Serverless의 가격 대비 성능을 더 큰 3TB 데이터 세트를 사용하는 다른 데이터 웨어하우스와 비교했습니다. 우리는 가격이 비슷한 데이터 웨어하우스를 선택했습니다. 이 경우에는 공개된 주문형 가격을 사용하여 시간당 10달러의 32% 이내였습니다. 이러한 결과는 Amazon Redshift RA3 인스턴스와 마찬가지로 Redshift Serverless가 다른 주요 클라우드 데이터 웨어하우스에 비해 더 나은 가격 대비 성능을 제공한다는 것을 보여줍니다. 항상 그렇듯이 이러한 결과는 SQL 스크립트를 사용하여 복제할 수 있습니다. GitHub 저장소.

자신만의 Amazon Redshift를 사용해 보시기 바랍니다. 개념 증명 Amazon Redshift가 데이터 분석 요구 사항을 어떻게 충족할 수 있는지 확인하는 가장 좋은 방법입니다.

귀하의 워크로드에 가장 적합한 가격 대비 성능을 찾으세요

본 게시물에 사용된 벤치마크는 업계 표준인 TPC-DS 벤치마크에서 파생되었으며 다음과 같은 특징을 가지고 있습니다.

스키마와 데이터는 TPC-DS에서 수정되지 않은 상태로 사용됩니다.
쿼리는 TPC-DS 키트의 기본 무작위 시드를 사용하여 생성된 쿼리 매개변수와 함께 공식 TPC-DS 키트를 사용하여 생성됩니다. 웨어하우스가 기본 TPC-DS 쿼리의 SQL 언어를 지원하지 않는 경우 TPC 승인 쿼리 변형이 웨어하우스에 사용됩니다.
테스트에는 99개의 TPC-DS SELECT 쿼리가 포함됩니다. 유지 관리 및 처리량 단계는 포함되지 않습니다.
단일 3TB 동시성 테스트의 경우 XNUMX번의 전원 실행이 실행되었으며 각 데이터 웨어하우스에 대해 최상의 실행이 수행되었습니다.
TPC-DS 쿼리의 가격 대비 성능은 시간당 비용(USD)에 벤치마크 런타임(시간)을 곱한 값으로 계산됩니다. 이는 벤치마크 실행 비용과 동일합니다. 앞서 언급한 예약 인스턴스 가격이 아닌 최신 게시된 온디맨드 가격이 모든 데이터 웨어하우스에 사용됩니다.

우리는 이를 클라우드 데이터 웨어하우스 벤치마크라고 부르며, 우리가 제공하는 스크립트, 쿼리, 데이터를 사용하여 이전 벤치마크 결과를 쉽게 재현할 수 있습니다. GitHub 저장소. 이는 이 게시물에 설명된 TPC-DS 벤치마크에서 파생되었으며, 테스트 결과가 공식 사양을 따르지 않기 때문에 게시된 TPC-DS 결과와 비교할 수 없습니다.

결론

Amazon Redshift는 가장 다양한 워크로드에 대해 업계 최고의 가격 대비 성능을 제공하기 위해 최선을 다하고 있습니다. Redshift Serverless는 최고의(최저) 가격 대비 성능으로 선형적으로 확장되어 일관된 쿼리 응답 시간을 유지하면서 수백 명의 동시 사용자를 지원합니다. 이 게시물에서 논의한 테스트 결과에 따르면 Amazon Redshift는 가장 가까운 경쟁사(경쟁사 B)에 비해 동일한 동시성 수준에서 최대 2.6배 더 나은 가격 대비 성능을 제공합니다. 앞서 언급했듯이 3년 전체 선결제 옵션이 포함된 예약 인스턴스를 사용하면 Amazon Redshift를 실행하는 데 가장 저렴한 비용이 제공되므로 이 게시물에서 사용한 온디맨드 인스턴스 가격에 비해 상대적인 가격 대비 성능이 훨씬 더 좋습니다. 지속적인 성능 개선에 대한 우리의 접근 방식에는 고객 사용 사례와 관련 확장성 병목 현상을 이해하려는 고객의 집착과 지속적인 차량 데이터 분석을 결합하여 상당한 성능 최적화를 위한 기회를 식별하는 고유한 조합이 포함됩니다.

각 워크로드에는 고유한 특성이 있으므로 이제 막 시작하는 경우 개념 증명 Amazon Redshift가 더 나은 성능을 제공하면서 비용을 절감할 수 있는 방법을 이해하는 가장 좋은 방법입니다. 자체 개념 증명을 실행할 때는 쿼리 처리량(시간당 쿼리 수), 응답 시간, 가격 대비 성능 등 올바른 지표에 초점을 맞추는 것이 중요합니다. 스스로 개념 증명을 실행하여 데이터 기반 결정을 내릴 수 있습니다. 도움을 받아 AWS 또는 시스템 통합 및 컨설팅 파트너.

Amazon Redshift의 최신 개발 상황을 최신 상태로 유지하려면 다음을 따르십시오. Amazon Redshift의 새로운 기능 피드.

저자 소개

스테판 그로몰 그는 Amazon Redshift 팀의 수석 성능 엔지니어로 Redshift 성능 측정 및 개선을 담당하고 있습니다. 여가 시간에는 요리하기, 세 아들과 놀기, 장작 패기 등을 즐깁니다.

라비 아니미 Amazon Redshift 팀의 수석 제품 관리 리더이며 성능, 공간 분석, 스트리밍 수집 및 마이그레이션 전략을 포함하여 Amazon Redshift 클라우드 데이터 웨어하우스 서비스의 여러 기능 영역을 관리합니다. 그는 관계형 데이터베이스, 다차원 데이터베이스, IoT 기술, 스토리지 및 컴퓨팅 인프라 서비스에 대한 경험을 갖고 있으며 최근에는 AI/딥 러닝, 컴퓨터 비전 및 로봇공학을 사용하는 스타트업 창업자이기도 합니다.