Apache Flink 애플리케이션을 실행할 때 Apache Flink용 Amazon 관리형 서비스, 서버리스 특성을 활용하는 고유한 이점이 있습니다. 즉, 비용 최적화 작업은 언제든지 수행할 수 있으며 더 이상 계획 단계에서 수행할 필요가 없습니다. Apache Flink용 관리형 서비스를 사용하면 버튼 클릭만으로 컴퓨팅을 추가 및 제거할 수 있습니다.

Apache Flink는 중요한 비즈니스 애플리케이션을 담당하는 수백 개의 회사와 워크로드에 대한 스트림 처리가 필요한 수천 명의 개발자가 사용하는 오픈 소스 스트림 처리 프레임워크입니다. 가용성과 확장성이 뛰어나 가장 까다로운 스트림 처리 애플리케이션에 높은 처리량과 낮은 대기 시간을 제공합니다. Apache Flink의 이러한 확장 가능한 속성은 클라우드에서 비용을 최적화하는 데 핵심이 될 수 있습니다.

Apache Flink용 관리형 서비스는 Apache Flink 애플리케이션 구축 및 관리의 복잡성을 줄여주는 완전 관리형 서비스입니다. Apache Flink용 관리형 서비스는 내구성 있는 애플리케이션 상태, 지표, 로그 등을 제공하는 기본 인프라와 Apache Flink 구성 요소를 관리합니다.

이 게시물에서는 Apache Flink용 관리형 서비스 비용 모델, Apache Flink 애플리케이션에서 비용을 절감할 수 있는 영역에 대해 알아보고 데이터 처리 파이프라인에 대한 전반적인 이해를 높일 수 있습니다. 비용을 이해하고, 애플리케이션이 초과 프로비저닝되었는지 여부를 이해하고, 자동 확장에 대해 생각하는 방법, 비용 절감을 위해 Apache Flink 애플리케이션을 최적화하는 방법에 대해 자세히 알아봅니다. 마지막으로 Apache Flink가 귀하의 사용 사례에 적합한 기술인지 판단하기 위해 귀하의 워크로드에 대한 중요한 질문을 합니다.

Apache Flink용 관리형 서비스에서 비용이 계산되는 방식

Apache Flink용 관리형 서비스 애플리케이션과 관련된 비용을 최적화하려면 관리형 서비스 가격 책정에 어떤 영향을 미치는지 파악하는 것이 도움이 될 수 있습니다.

Apache Flink용 관리형 서비스 애플리케이션은 가상 CPU 1개와 4GB 메모리로 구성된 컴퓨팅 인스턴스인 Kinesis 처리 장치(KPU)로 구성됩니다. 애플리케이션에 할당된 총 KPU 수는 직접 제어하는 ​​두 매개변수를 곱하여 결정됩니다.

• 병행 – Apache Flink 애플리케이션의 병렬 처리 수준
• KPU당 병렬성 – 각 병렬 처리에 할당된 리소스 수

KPU 수는 간단한 공식인 KPU = Parallelism / ParallelismPerKPU에 의해 결정되며 다음 정수로 반올림됩니다.

애플리케이션당 추가 KPU도 오케스트레이션을 위해 요금이 부과되며 데이터 처리에 직접 사용되지 않습니다.

총 KPU 수는 애플리케이션에 할당된 리소스, CPU, 메모리 및 애플리케이션 스토리지 수를 결정합니다. 각 KPU에 대해 애플리케이션은 1개의 vCPU와 4GB의 메모리를 수신하며, 이 중 3GB는 기본적으로 실행 중인 애플리케이션에 할당되고 나머지 1GB는 애플리케이션 상태 저장소 관리에 사용됩니다. 각 KPU에는 애플리케이션에 연결된 50GB의 스토리지도 함께 제공됩니다. Apache Flink는 구성 가능한 한도까지 메모리 내 애플리케이션 상태를 유지하고 연결된 스토리지로 스필오버합니다.

세 번째 비용 구성 요소는 내구성 있는 애플리케이션 백업입니다. 스냅 샷. 이는 전적으로 선택 사항이며 매우 많은 수의 스냅샷을 유지하지 않는 한 전체 비용에 미치는 영향은 작습니다.

이 글을 쓰는 시점을 기준으로 미국 동부(오하이오) AWS 리전의 각 KPU 비용은 시간당 0.11달러이고, 연결된 애플리케이션 스토리지 비용은 GB당 월 0.10달러입니다. 내구성 있는 애플리케이션 백업(스냅샷) 비용은 매월 GB당 $0.023입니다. 인용하다 Apache Flink용 Amazon Managed Service 가격 최신 가격 및 다양한 지역을 확인하세요.

다음 다이어그램은 Apache Flink용 관리형 서비스에서 실행 중인 애플리케이션에 대한 비용 구성 요소의 상대적 비율을 보여줍니다. 병렬성 및 KPU당 병렬성 매개변수를 통해 KPU 수를 제어합니다. 내구성 있는 애플리케이션 백업 스토리지는 표시되지 않습니다.

다음 섹션에서는 비용을 모니터링하고, 애플리케이션 리소스 사용을 최적화하고, 처리량 프로필을 처리하는 데 필요한 KPU 수를 찾는 방법을 살펴봅니다.

AWS Cost Explorer 및 청구서 이해

현재 Apache Flink용 관리형 서비스 지출이 얼마인지 확인하려면 다음을 사용하세요. AWS 비용 탐색기.

Cost Explorer 콘솔에서는 날짜 범위, 사용 유형, 서비스별로 필터링하여 Apache Flink용 관리형 서비스 애플리케이션에 대한 지출을 분리할 수 있습니다. 다음 스크린샷은 이전 섹션에서 설명한 가격 범주로 분류된 지난 12개월 간의 비용을 보여줍니다. 이 기간 중 대부분의 지출은 대화형 KPU에서 이루어졌습니다. Apache Flink Studio용 Amazon 관리형 서비스.

Cost Explorer를 사용하면 청구서를 이해하는 데 도움이 될 뿐만 아니라 자동으로 또는 처리량 요구 사항으로 인해 기대 이상으로 확장될 수 있는 특정 애플리케이션을 더욱 최적화하는 데도 도움이 됩니다. 적절한 애플리케이션 태깅을 사용하면 이 지출을 애플리케이션별로 분류하여 어떤 애플리케이션이 비용을 차지하는지 확인할 수도 있습니다.

과잉 프로비저닝 또는 리소스의 비효율적인 사용 징후

Apache Flink용 관리형 서비스 애플리케이션과 관련된 비용을 최소화하기 위한 간단한 접근 방식은 애플리케이션에서 사용하는 KPU 수를 줄이는 것입니다. 그러나 철저하게 평가하고 테스트하지 않으면 이러한 감소가 성능에 부정적인 영향을 미칠 수 있다는 점을 인식하는 것이 중요합니다. 애플리케이션이 초과 프로비저닝되었는지 여부를 빠르게 측정하려면 CPU 및 메모리 사용량, 애플리케이션 기능, 데이터 배포와 같은 주요 지표를 검사하세요. 그러나 이러한 지표는 잠재적인 과잉 프로비저닝을 암시할 수 있지만 KPU 수를 조정하기 전에 성능 테스트를 수행하고 조정 패턴을 검증하는 것이 중요합니다.

통계

분석 애플리케이션에 대한 측정항목 on 아마존 클라우드 워치 과잉 프로비저닝의 명확한 신호를 밝힐 수 있습니다. 만약 containerCPUUtilization 과 containerMemoryUtilization 지표가 애플리케이션의 트래픽 패턴에 대해 통계적으로 중요한 기간 동안 지속적으로 20% 미만으로 유지되는 경우, 규모를 축소하고 더 ​​적은 수의 시스템에 더 많은 데이터를 할당하는 것이 가능할 수 있습니다. 일반적으로 우리는 다음과 같은 경우 애플리케이션의 적절한 크기를 고려합니다. containerCPUUtilization 50~75% 사이를 맴돈다. 하지만 containerMemoryUtilization 하루 종일 변동될 수 있고 코드 최적화의 영향을 받을 수 있습니다. 상당한 기간 동안 지속적으로 낮은 값은 잠재적인 과잉 프로비저닝을 나타낼 수 있습니다.

KPU당 병렬 처리가 충분히 활용되지 않음

애플리케이션이 과도하게 프로비저닝되었다는 또 다른 미묘한 징후는 애플리케이션이 순수하게 I/O 바인딩되어 있거나 데이터베이스 및 CPU를 많이 사용하지 않는 작업에 대한 간단한 호출만 수행하는 경우입니다. 이 경우 Apache Flink용 관리형 서비스 내에서 KPU당 병렬 처리 매개변수를 사용하여 단일 처리 장치에 더 많은 작업을 로드할 수 있습니다.

KPU 매개변수당 병렬 처리수는 컴퓨팅 및 메모리 리소스(KPU) 단위당 워크로드 밀도의 측정값으로 볼 수 있습니다. KPU당 병렬 처리를 기본값인 1보다 높게 늘리면 처리 밀도가 높아져 단일 KPU에 더 많은 병렬 프로세스가 할당됩니다.

다음 다이어그램은 애플리케이션 병렬 처리를 일정하게 유지(예: 4)하고 KPU당 병렬 처리를 늘려(예: 1에서 2로) 애플리케이션이 동일한 병렬 실행 수준에서 더 적은 리소스를 사용하는 방법을 보여줍니다.

이 게시물의 모든 권장 사항과 마찬가지로 KPU당 병렬 처리를 늘리는 결정은 매우 신중하게 이루어져야 합니다. KPU당 병렬 처리 값을 늘리면 단일 KPU에 더 많은 로드가 발생할 수 있으며 해당 로드를 기꺼이 견딜 수 있어야 합니다. I/O 바인딩된 작업은 의미 있는 방식으로 CPU 또는 메모리 사용률을 증가시키지 않지만, 데이터에 대해 많은 복잡한 작업을 계산하는 프로세스 기능은 리소스를 압도할 수 있으므로 단일 KPU에 대조하는 이상적인 작업이 아닙니다. 성능을 테스트하고 이것이 귀하의 애플리케이션에 적합한 옵션인지 평가하십시오.

크기 조정에 접근하는 방법

Apache Flink용 관리형 서비스 애플리케이션을 시작하기 전에 애플리케이션에 할당해야 하는 KPU 수를 예측하기 어려울 수 있습니다. 일반적으로 추정하기 전에 트래픽 패턴을 잘 이해하고 있어야 합니다. 초당 메가바이트 수집 속도 기준으로 트래픽 패턴을 이해하면 대략적인 시작점을 찾는 데 도움이 될 수 있습니다.

일반적으로 애플리케이션이 처리할 1MB/s당 하나의 KPU로 시작할 수 있습니다. 예를 들어 애플리케이션이 평균 10MB/s를 처리하는 경우 애플리케이션의 시작점으로 10개의 KPU를 할당합니다. 이는 일반적인 추정에 효과적인 매우 높은 수준의 근사치라는 점을 명심하세요. 그러나 성능 테스트도 수행하고 장기간에 걸쳐 지표(CPU, 메모리, 대기 시간, 전체 작업 성능)를 기반으로 이것이 장기적으로 적절한 크기인지 여부를 평가해야 합니다.

애플리케이션에 적합한 크기를 찾으려면 Apache Flink 애플리케이션을 확장 및 축소해야 합니다. 앞서 언급한 것처럼 Apache Flink용 관리형 서비스에는 병렬 처리와 KPU당 병렬 처리라는 두 가지 별도의 제어 기능이 있습니다. 이러한 매개변수는 함께 애플리케이션 내 병렬 처리 수준과 사용 가능한 전체 컴퓨팅, 메모리 및 스토리지 리소스를 결정합니다.

권장되는 테스트 방법은 KPU별로 병렬성 또는 병렬성을 개별적으로 변경하면서 실험을 통해 올바른 크기를 찾는 것입니다. 일반적으로 전체 리소스를 늘리지 않고 병렬 I/O 바인딩 작업 수를 늘리려면 KPU당 병렬 처리만 변경합니다. 다른 모든 경우에는 병렬 처리만 변경하면 됩니다. 즉, KPU는 결과적으로 변경되므로 워크로드에 적합한 크기를 찾습니다.

당신은 또한 수 운영자 수준에서 병렬성 설정 제한하고 확장 메커니즘과 독립적이어야 할 수 있는 소스, 싱크 또는 기타 연산자를 제한합니다. 10개의 파티션이 있는 Apache Kafka 주제에서 읽는 Apache Flink 애플리케이션에 이를 사용할 수 있습니다. 와 더불어 setParallelism() 방법을 사용하면 KafkaSource를 10으로 제한할 수 있지만 Kafka 소스에 대한 유휴 작업을 생성하지 않고 Apache Flink용 관리형 서비스 애플리케이션을 10보다 높은 병렬 처리로 확장할 수 있습니다. 다른 데이터 처리 사례에서는 연산자 병렬성을 정적 값으로 정적으로 설정하지 않고 전체 애플리케이션이 확장될 때 확장되도록 애플리케이션 병렬성의 기능을 설정하는 것이 좋습니다.

크기 조정 및 자동 크기 조정

Apache Flink용 관리형 서비스에서 병렬 처리 또는 KPU당 병렬 처리를 수정하는 것은 애플리케이션 구성을 업데이트하는 것입니다. 그러면 응용프로그램이 자동으로 스냅 사진 (비활성화되지 않은 경우) 애플리케이션을 중지하고 새 크기로 다시 시작하여 스냅샷에서 상태를 복원합니다. 확장 작업은 데이터 손실이나 불일치를 일으키지 않지만 인프라가 추가되거나 제거되는 동안 짧은 기간 동안 데이터 처리를 일시 중지합니다. 이는 프로덕션 환경에서 크기를 조정할 때 고려해야 할 사항입니다.

테스트 및 최적화 과정에서는 비활성화하는 것이 좋습니다. 자동 스케일링 최적의 값을 찾기 위해 KPU별 병렬성과 병렬성을 수정합니다. 앞서 언급했듯이 수동 확장은 애플리케이션 구성을 업데이트하는 것일 뿐이며 다음을 통해 실행할 수 있습니다. AWS 관리 콘솔 또는 API를 사용하여 업데이트애플리케이션 작업.

최적의 크기 조정을 찾았을 때 수집된 처리량이 크게 달라질 것으로 예상되면 자동 크기 조정을 활성화하기로 결정할 수 있습니다.

Apache Flink용 관리형 서비스에서는 여러 유형의 자동 크기 조정을 사용할 수 있습니다.

• 즉시 사용 가능한 자동 확장 – 이를 활성화하여 애플리케이션 병렬성을 자동으로 조정할 수 있습니다. containerCPUUtilization 미터법. 새 애플리케이션에서는 자동 크기 조정이 기본적으로 활성화됩니다. 자동 스케일링 알고리즘에 대한 자세한 내용은 다음을 참조하세요. 자동 스케일링.
• 세분화된 측정항목 기반 자동 확장 – 구현하기가 간단합니다. 자동화는 다음을 포함한 거의 모든 측정항목을 기반으로 할 수 있습니다. 맞춤 측정항목 귀하의 응용 프로그램이 노출됩니다.
• 예약된 확장 – 이는 하루 중 특정 시간이나 요일에 최대 작업 부하가 예상되는 경우 유용할 수 있습니다.

기본으로 제공되는 자동 조정과 세분화된 지표 기반 조정은 상호 배타적입니다. 세분화된 지표 기반 자동 크기 조정 및 예약된 크기 조정과 완전히 작동하는 코드 예제에 대한 자세한 내용은 다음을 참조하세요. Apache Flink용 Amazon Managed Service에 대한 지표 기반 및 예약된 확장 활성화.

코드 최적화

Apache Flink용 관리형 서비스 애플리케이션의 비용 절감에 접근하는 또 다른 방법은 코드 최적화를 이용하는 것입니다. 최적화되지 않은 코드는 동일한 계산을 수행하기 위해 더 많은 머신이 필요합니다. 코드를 최적화하면 전체 리소스 활용도를 낮출 수 있으며 그에 따라 규모를 축소하고 비용을 절감할 수 있습니다.

코드 성능을 이해하는 첫 번째 단계는 Apache Flink에 내장된 유틸리티인 Flame 그래프.

Apache Flink 대시보드를 통해 액세스할 수 있는 Flame 그래프는 스택 추적을 시각적으로 보여줍니다. 메서드가 호출될 때마다 스택 추적에서 해당 메서드 호출을 나타내는 막대는 총 샘플 수에 비례하여 커집니다. 이는 Flame 그래프에 매우 긴 막대가 있는 비효율적인 코드 조각이 있는 경우 이 코드를 보다 효율적으로 만드는 방법에 대한 조사의 원인이 될 수 있음을 의미합니다. 또한 다음을 사용할 수 있습니다. 아마존 코드 구루 프로파일 러 에 Apache Flink용 관리 서비스에서 실행되는 Apache Flink 애플리케이션 모니터링 및 최적화.

애플리케이션을 설계할 때 특정 시점에 특정 작업에 필요한 최고 수준의 API를 사용하는 것이 좋습니다. Apache Flink는 Flink SQL, Table API, 네 가지 수준의 API 지원을 제공합니다. Datastream API 및 ProcessFunction 복잡성과 책임 수준이 증가하는 API. 애플리케이션을 Flink SQL 또는 Table API로 완전히 작성할 수 있는 경우 이를 사용하면 상태 및 계산을 수동으로 관리하는 대신 Apache Flink 프레임워크를 활용하는 데 도움이 될 수 있습니다.

데이터 왜곡

Apache Flink 대시보드에서는 Apache Flink용 관리형 서비스 작업에 대한 기타 유용한 정보를 수집할 수 있습니다.

대시보드에서는 직무 지원 그래프 내의 개별 작업을 검사할 수 있습니다. 각 파란색 상자는 작업을 나타내며, 각 작업은 하위 작업, 즉 해당 작업에 대한 분산 작업 단위로 구성됩니다. 이런 방식으로 하위 작업 간의 데이터 편향을 식별할 수 있습니다.

데이터 왜곡은 한 하위 작업이 다른 하위 작업보다 더 많은 데이터가 전송되고 있으며, 더 많은 데이터를 받는 하위 작업이 다른 하위 작업보다 더 많은 작업을 수행하고 있음을 나타내는 지표입니다. 이러한 데이터 왜곡 증상이 있는 경우 소스를 식별하여 이를 제거할 수 있습니다. 예를 들어, GroupBy or KeyedStream 키에 왜곡이 있을 수 있습니다. 이는 데이터가 키 간에 고르게 분산되지 않아 Apache Flink 컴퓨팅 인스턴스 전체에 작업이 고르지 않게 분산된다는 것을 의미합니다. 다음을 기준으로 그룹화하는 시나리오를 상상해 보세요. userId, 그러나 애플리케이션은 한 사용자로부터 나머지 사용자보다 훨씬 더 많은 데이터를 받습니다. 이로 인해 데이터 왜곡이 발생할 수 있습니다. 이를 제거하려면 다른 그룹화 키를 선택하여 하위 작업 전체에 데이터를 균등하게 배포할 수 있습니다. 다른 키를 선택하려면 코드 수정이 필요하다는 점을 명심하세요.

데이터 왜곡이 제거되면 다음으로 돌아갈 수 있습니다. containerCPUUtilization 과 containerMemoryUtilization KPU 수를 줄이기 위한 측정항목입니다.

코드 최적화를 위한 다른 영역에는 다음을 통해 외부 시스템에 액세스하고 있는지 확인하는 것이 포함됩니다. 비동기 I/O API 또는 데이터 저장소에 대한 동기식 쿼리로 인해 속도가 느려지고 검사점에 문제가 발생할 수 있기 때문에 데이터 스트림 조인을 통해 가능합니다. 추가로 다음을 참조하세요. 성능 문제 해결 느린 체크포인트나 로깅으로 인해 발생할 수 있는 문제로 인해 애플리케이션 역압이 발생할 수 있습니다.

Apache Flink가 적합한 기술인지 확인하는 방법

애플리케이션이 Apache Flink 프레임워크와 Apache Flink용 관리형 서비스의 강력한 기능을 사용하지 않는 경우 더 간단한 방법을 사용하면 잠재적으로 비용을 절감할 수 있습니다.

Apache Flink의 태그라인은 "데이터 스트림을 통한 상태 기반 계산"입니다. 이 맥락에서 상태 저장은 Apache Flink 상태 구성을 사용하고 있음을 의미합니다. Apache Flink의 State를 사용하면 과거에 본 메시지를 장기간 기억할 수 있으므로 스트리밍 조인, 중복 제거, 정확히 한 번 처리, 창 설정, 지연 데이터 처리 등이 가능해집니다. 이는 메모리 내 상태 저장소를 사용하여 수행됩니다. Apache Flink용 관리형 서비스에서는 다음을 사용합니다. RocksDB 그 상태를 유지하기 위해.

애플리케이션에 상태 저장 작업이 포함되지 않은 경우 다음과 같은 대안을 고려할 수 있습니다. AWS 람다, 컨테이너화된 애플리케이션 또는 아마존 엘라스틱 컴퓨트 클라우드 (Amazon EC2) 애플리케이션을 실행하는 인스턴스입니다. 이러한 경우에는 Apache Flink의 복잡성이 필요하지 않을 수 있습니다. 독립적인 스트림 위치 메모리가 필요한 캐시된 데이터 또는 강화 절차를 포함한 상태 저장 계산은 Apache Flink의 상태 저장 기능을 보장할 수 있습니다. 장기간의 데이터 보존이나 기타 상태 저장 요구 사항을 통해 향후 애플리케이션이 상태 저장이 될 가능성이 있는 경우 Apache Flink를 계속 사용하는 것이 더 간단할 수 있습니다. 스트림 처리 기능을 위해 Apache Flink를 강조하는 조직에서는 상태 저장 및 상태 비저장 애플리케이션에 Apache Flink를 사용하여 모든 애플리케이션이 동일한 방식으로 데이터를 처리하는 것을 선호할 수 있습니다. 또한 Apache Flink에서 대안으로 전환하기 전에 정확히 XNUMX회 처리, 팬아웃 기능, 분산 계산과 같은 오케스트레이션 기능을 고려해야 합니다.

또 다른 고려 사항은 대기 시간 요구 사항입니다. Apache Flink는 실시간 데이터 처리에 탁월하기 때문에 6시간 또는 1일의 대기 시간 요구 사항이 있는 애플리케이션에 이를 사용하는 것은 의미가 없습니다. 임시 배치 프로세스로 전환하여 비용 절감 아마존 단순 스토리지 서비스 (Amazon S3)은 예를 들어 중요할 것입니다.

결론

이번 게시물에서는 Managed Service for Apache Flink에 대한 비용 절감 조치를 시도할 때 고려해야 할 몇 가지 측면을 다루었습니다. 관리형 서비스에 대한 전체 지출을 식별하는 방법, KPU를 축소할 때 모니터링하는 몇 가지 유용한 지표, 축소를 위해 코드를 최적화하는 방법, Apache Flink가 사용 사례에 적합한지 확인하는 방법에 대해 논의했습니다.

이러한 비용 절감 전략을 구현하면 비용 효율성이 향상될 뿐만 아니라 간소화되고 최적화된 Apache Flink 배포가 제공됩니다. 전체 지출을 염두에 두고, 주요 지표를 사용하고, 리소스 축소에 대해 정보에 입각한 결정을 내리면 성능 저하 없이 비용 효율적인 운영을 달성할 수 있습니다. Apache Flink 환경을 탐색하면서 특정 사용 사례에 부합하는지 지속적으로 평가하는 것이 중요하므로 데이터 처리 요구 사항에 맞는 효율적인 맞춤형 솔루션을 얻을 수 있습니다.

이 게시물에서 논의된 권장 사항이 귀하의 워크로드에 공감한다면 시도해 보시기 바랍니다. 지정된 지표와 워크로드를 더 잘 이해하는 방법에 대한 팁을 사용하면 이제 Managed Service for Apache Flink에서 Apache Flink 워크로드를 효율적으로 최적화하는 데 필요한 정보를 얻을 수 있습니다. 다음은 이 게시물을 보완하는 데 사용할 수 있는 몇 가지 유용한 리소스입니다.

저자에 관하여

제레미 베르 지난 10년 동안 소프트웨어 엔지니어, 기계 학습 엔지니어, 그리고 가장 최근에는 데이터 엔지니어로 원격 측정 데이터 공간에서 일해 왔습니다. AWS에서 그는 스트리밍 전문가 솔루션 아키텍트로서 Apache Kafka용 Amazon Managed Streaming(Amazon MSK)과 Apache Flink용 Amazon Managed Service를 모두 지원합니다.

로렌조 니코라 AWS에서 수석 스트리밍 솔루션 아키텍트로 일하며 EMEA 전역의 고객을 지원합니다. 그는 25년 넘게 클라우드 기반의 데이터 집약적 시스템을 구축해 왔으며 컨설팅 및 FinTech 제품 회사를 통해 금융 업계에서 일했습니다. 그는 오픈 소스 기술을 광범위하게 활용했으며 Apache Flink를 포함한 여러 프로젝트에 기여했습니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/big-data/real-time-cost-savings-for-amazon-managed-service-for-apache-flink/