Cách Logz.io tăng tốc các đề xuất ML và giải pháp phát hiện bất thường với Amazon SageMaker

Dấu thời gian: 26:2022 chiều ngày 1 tháng 18 năm XNUMX
Nút nguồn: 1594837

Logz.io là Đối tác công nghệ tiên tiến của Mạng đối tác AWS (APN) với Năng lực của AWS về DevOps, Bảo mật và Dữ liệu & Phân tích. Logz.io cung cấp nền tảng quan sát phần mềm dưới dạng dịch vụ (SaaS) dựa trên các giải pháp phần mềm nguồn mở tốt nhất trong ngành để phân tích nhật ký, số liệu và theo dõi. Khách hàng đang gửi lượng dữ liệu ngày càng tăng tới Logz.io từ nhiều nguồn dữ liệu khác nhau để quản lý tình trạng và hiệu suất của các ứng dụng và dịch vụ của họ. Việc này có thể gây choáng ngợp cho những người dùng mới đang tìm cách điều hướng trên các bảng thông tin khác nhau được xây dựng theo thời gian, xử lý các thông báo cảnh báo khác nhau và kết nối các điểm khi khắc phục sự cố sản xuất.

Thời gian trung bình để phát hiện (MTTD) và thời gian giải quyết trung bình (MTTR) là những số liệu chính dành cho khách hàng của chúng tôi. Chúng được tính toán bằng cách đo thời gian người dùng trong nền tảng của chúng tôi bắt đầu điều tra một vấn đề (chẳng hạn như dịch vụ sản xuất ngừng hoạt động) cho đến thời điểm họ ngừng thực hiện các hành động trong nền tảng có liên quan đến cuộc điều tra cụ thể.

Để giúp khách hàng giảm MTTD và MTTR, Logz.io đang chuyển sang học máy (ML) để cung cấp đề xuất cho các bảng thông tin và truy vấn có liên quan, đồng thời thực hiện phát hiện bất thường thông qua quá trình tự học. Kết quả là, người dùng bình thường được trang bị trải nghiệm tổng hợp của toàn bộ công ty họ, tận dụng trí tuệ của nhiều người. Chúng tôi nhận thấy rằng giải pháp của chúng tôi có thể giảm MTTR tới 20%.

Khi MTTD giảm, người dùng có thể xác định vấn đề và giải quyết nhanh hơn. Lớp ngữ nghĩa dữ liệu của chúng tôi chứa ngữ nghĩa để bắt đầu và dừng điều tra cũng như mức độ phổ biến của từng hành động mà người dùng đang thực hiện đối với một cảnh báo cụ thể.

Trong bài đăng này, chúng tôi chia sẻ cách Logz.io sử dụng Amazon SageMaker để giảm thời gian và công sức cho việc chứng minh khái niệm (POC), các thử nghiệm từ nghiên cứu đến đánh giá sản xuất cũng như cách chúng tôi giảm chi phí suy luận sản xuất.

Các thách thức

Cho đến khi Logz.io sử dụng SageMaker, khoảng thời gian từ nghiên cứu đến thử nghiệm POC và thử nghiệm trên sản xuất khá dài. Điều này là do chúng tôi cần tạo các công việc Spark để thu thập, làm sạch và chuẩn hóa dữ liệu. DevOps yêu cầu công việc này để đọc từng nguồn dữ liệu. DevOps và kỹ năng kỹ thuật dữ liệu không thuộc nhóm ML của chúng tôi và điều này gây ra sự phụ thuộc cao giữa các nhóm.

Một thách thức khác là cung cấp dịch vụ suy luận ML cho các sản phẩm của chúng tôi trong khi vẫn đạt được tỷ lệ chi phí so với hiệu suất tối ưu. Kịch bản tối ưu của chúng tôi là hỗ trợ nhiều mô hình nhất có thể cho một đơn vị điện toán, đồng thời cung cấp khả năng xử lý đồng thời cao cho khách hàng với nhiều mô hình. Chúng tôi có sự linh hoạt về thời gian suy luận vì khoảng thời gian ban đầu của luồng dữ liệu cho dịch vụ suy luận là nhóm nhật ký dài 5 phút.

Giai đoạn nghiên cứu

Khoa học dữ liệu là một quá trình lặp đi lặp lại đòi hỏi môi trường phát triển tương tác để nghiên cứu, xác thực dữ liệu đầu ra trên mỗi lần lặp và xử lý dữ liệu. Do đó, chúng tôi khuyến khích các nhà nghiên cứu ML sử dụng sổ ghi chép.

Để đẩy nhanh chu trình lặp lại, chúng tôi muốn kiểm tra mã của sổ ghi chép của mình trên dữ liệu sản xuất thực trong khi chạy mã đó trên quy mô lớn. Hơn nữa, chúng tôi muốn tránh tình trạng tắc nghẽn của DevOps và kỹ thuật dữ liệu trong quá trình thử nghiệm ban đầu trong quá trình sản xuất, đồng thời có khả năng xem kết quả đầu ra và cố gắng ước tính thời gian chạy mã.

Để thực hiện điều này, chúng tôi muốn cung cấp cho nhóm khoa học dữ liệu của mình toàn quyền kiểm soát và chịu trách nhiệm từ đầu đến cuối từ nghiên cứu đến thử nghiệm ban đầu trên sản xuất. Chúng tôi cần chúng để dễ dàng lấy dữ liệu, đồng thời duy trì việc quản lý quyền truy cập dữ liệu và giám sát quyền truy cập này. Họ cũng cần dễ dàng triển khai sổ ghi chép POC tùy chỉnh của mình vào sản xuất theo cách có thể mở rộng, đồng thời giám sát thời gian chạy và chi phí dự kiến.

Giai đoạn đánh giá

Trong giai đoạn này, chúng tôi đã đánh giá một số nền tảng ML để hỗ trợ cả yêu cầu đào tạo và phục vụ. Chúng tôi nhận thấy rằng SageMaker là giải pháp phù hợp nhất cho các trường hợp sử dụng của chúng tôi vì nó hỗ trợ cả đào tạo và suy luận. Hơn nữa, nó có thể tùy chỉnh nên chúng tôi có thể điều chỉnh nó theo quy trình nghiên cứu ưa thích của mình.

Ban đầu, chúng tôi bắt đầu từ sổ ghi chép cục bộ, thử nghiệm nhiều thư viện khác nhau. Chúng tôi gặp vấn đề với việc lấy dữ liệu lớn từ sản xuất. Sau đó, chúng tôi bị mắc kẹt ở giai đoạn tạo mô hình mất nhiều giờ trên máy cục bộ.

Chúng tôi đã đánh giá nhiều giải pháp và cuối cùng đã chọn kiến ​​trúc sau:

  • Tấm dữ liệu – Phiên bản mã nguồn mở của Tấm dữ liệu đã giúp chúng tôi lấy và kết hợp dữ liệu của mình một cách dễ dàng bằng cách sử dụng Spark Amazon EMR các cụm bằng SQL đơn giản, đồng thời giám sát việc truy cập dữ liệu
  • Công việc xử lý và phiên bản sổ ghi chép SageMaker – Điều này đã giúp chúng tôi có khả năng mở rộng thời gian chạy và tính linh hoạt của các loại máy và khung ML, đồng thời cộng tác mã của chúng tôi thông qua kết nối Git

Kiến trúc giải pháp giai đoạn nghiên cứu

Sơ đồ sau minh họa kiến ​​trúc giải pháp của giai đoạn nghiên cứu và bao gồm các thành phần sau:

  • sổ ghi chép SageMaker – Các nhà khoa học dữ liệu sử dụng những thứ này máy tính xách tay để tiến hành nghiên cứu của họ.
  • Chức năng AWS Lambda – AWS Lambda là một giải pháp không có máy chủ chạy công việc xử lý theo yêu cầu. Công việc sử dụng vùng chứa Docker với sổ ghi chép mà chúng tôi muốn chạy trong quá trình thử nghiệm, cùng với tất cả các tệp phổ biến cần hỗ trợ sổ ghi chép (requirements.txt và mã chức năng đa xử lý trong một sổ ghi chép riêng).
  • Amazon ECR – Đăng ký container đàn hồi Amazon (Amazon ECR) lưu trữ vùng chứa Docker của chúng tôi.
  • SageMaker Xử lý công việc – Chúng ta có thể chạy cái này công việc xử lý dữ liệu trên bất kỳ máy ML nào và nó chạy sổ ghi chép của chúng tôi với các tham số.
  • Tấm dữ liệu – Dịch vụ này giúp chúng tôi sử dụng SQL và kết hợp nhiều nguồn dữ liệu một cách dễ dàng. Nó dịch nó sang mã Spark và tối ưu hóa nó, đồng thời giám sát việc truy cập dữ liệu và giúp giảm vi phạm dữ liệu. Phiên bản Xtra thậm chí còn cung cấp nhiều khả năng hơn.
  • Amazon EMR – Dịch vụ này chạy trích xuất dữ liệu của chúng tôi dưới dạng khối lượng công việc trên Spark, liên hệ với tất cả các tài nguyên dữ liệu của chúng tôi.

Với vòng đời phiên bản sổ ghi chép SageMaker, chúng tôi có thể kiểm soát thời gian chạy phiên bản sổ ghi chép tối đa bằng cách sử dụng autostop.py mẫu kịch bản.

Sau khi thử nghiệm khung ML, chúng tôi đã chọn nhân SageMaker MXNet cho các giai đoạn phân cụm và xếp hạng.

Để kiểm tra mã sổ ghi chép trên dữ liệu sản xuất của mình, chúng tôi đã chạy sổ ghi chép bằng cách đóng gói sổ ghi chép đó qua Docker trong Amazon ECS và chạy sổ ghi chép đó như một công việc xử lý để xác thực thời gian chạy tối đa trên các loại máy khác nhau.

Bộ chứa Docker cũng giúp chúng tôi chia sẻ tài nguyên giữa các bài kiểm tra của sổ ghi chép. Trong một số trường hợp, một máy tính xách tay gọi các máy tính xách tay khác sử dụng nhiều quy trình bằng cách chia các khung dữ liệu lớn thành các khung dữ liệu nhỏ hơn, có thể chạy đồng thời trên mỗi vCPU trong loại máy lớn.

Giải pháp suy luận sản xuất theo thời gian thực

Trong giai đoạn nghiên cứu, chúng tôi đã sử dụng Parquet Dịch vụ lưu trữ đơn giản của Amazon (Amazon S3) để duy trì các đề xuất của chúng tôi. Chúng được sử dụng mỗi ngày một lần từ quy trình kỹ thuật của chúng tôi để đính kèm các đề xuất vào cơ chế cảnh báo của chúng tôi.

Tuy nhiên, lộ trình của chúng tôi yêu cầu giải pháp tốc độ làm mới cao hơn và việc kéo một lần mỗi ngày là không đủ về lâu dài vì chúng tôi muốn đưa ra đề xuất ngay cả trong quá trình điều tra.

Để triển khai giải pháp này trên quy mô lớn, chúng tôi đã thử nghiệm hầu hết các giải pháp điểm cuối SageMaker trong nghiên cứu phát hiện sự bất thường của mình. Chúng tôi đã thử nghiệm 500 mô hình dựng sẵn với một máy điểm cuối duy nhất thuộc nhiều loại khác nhau và sử dụng các máy khách đa luồng đồng thời để thực hiện các yêu cầu tới điểm cuối. Chúng tôi đã đo thời gian phản hồi, CPU, bộ nhớ và các số liệu khác (để biết thêm thông tin, hãy xem Giám sát Amazon SageMaker với Amazon CloudWatch). Chúng tôi nhận thấy rằng điểm cuối đa mô hình hoàn toàn phù hợp cho các trường hợp sử dụng của chúng tôi.

Điểm cuối đa mô hình có thể giảm đáng kể chi phí của chúng tôi so với một điểm cuối duy nhất hoặc thậm chí so với Kubernetes để sử dụng các dịch vụ web Flask (hoặc Python khác). Giả định đầu tiên của chúng tôi là chúng tôi phải cung cấp một điểm cuối duy nhất, sử dụng máy nhỏ 4 vCPU cho mỗi khách hàng và trung bình truy vấn bốn mô hình chuyên dụng vì mỗi vCPU phục vụ một mô hình. Với điểm cuối đa mô hình, chúng tôi có thể tổng hợp nhiều khách hàng hơn trên một máy có nhiều điểm cuối.

Chúng tôi có một mô hình và các tệp mã hóa cho mỗi khách hàng và sau khi thực hiện các thử nghiệm tải, chúng tôi xác định rằng chúng tôi có thể phục vụ 50 khách hàng, mỗi khách hàng sử dụng 10 mô hình và thậm chí sử dụng phiên bản ml.t2.medium nhỏ nhất cho các giải pháp của mình.

Ở giai đoạn này, chúng tôi đã cân nhắc việc sử dụng điểm cuối đa mô hình. Điểm cuối nhiều mô hình cung cấp giải pháp có thể mở rộng và tiết kiệm chi phí để triển khai một số lượng lớn mô hình, cho phép bạn lưu trữ nhiều mô hình bằng một vùng chứa suy luận duy nhất. Điều này giúp giảm chi phí lưu trữ bằng cách cải thiện việc sử dụng điểm cuối so với việc sử dụng nhiều điểm cuối mô hình đơn nhỏ, mỗi điểm phục vụ một khách hàng. Nó cũng giảm chi phí triển khai vì SageMaker quản lý việc tải các mô hình trong bộ nhớ và điều chỉnh quy mô chúng dựa trên các mẫu lưu lượng truy cập tới chúng.

Hơn nữa, lợi thế của điểm cuối đa mô hình là nếu bạn có tỷ lệ suy luận cao từ các khách hàng cụ thể thì khung của nó sẽ lưu giữ các mô hình phân phát cuối cùng trong bộ nhớ để có hiệu suất tốt hơn.

Sau khi ước tính chi phí bằng cách sử dụng điểm cuối nhiều mô hình so với điểm cuối tiêu chuẩn, chúng tôi phát hiện ra rằng điều này có thể giúp giảm chi phí khoảng 80%.

Cuối cùng

Trong phần này, chúng ta xem xét các bước và kết quả của quá trình.

Chúng tôi sử dụng cấu hình sổ ghi chép vòng đời để cho phép chạy sổ ghi chép dưới dạng công việc xử lý, bằng cách đóng gói sổ ghi chép trong vùng chứa Docker để xác thực mã nhanh hơn và sử dụng cơ chế tự động dừng:

#!/bin/bash # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License"). You
# may not use this file except in compliance with the License. A copy of
# the License is located at
#
# http://aws.amazon.com/apache2.0/
#
# or in the "license" file accompanying this file. This file is
# distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
# ANY KIND, either express or implied. See the License for the specific
# language governing permissions and limitations under the License. set -e # OVERVIEW
# This script installs the sagemaker_run_notebook extension package in SageMaker Notebook Instance
#
# There are two parameters you need to set:
# 1. S3_LOCATION is the place in S3 where you put the extension tarball
# 2. TARBALL is the name of the tar file that you uploaded to S3. You should just need to check
# that you have the version right.
sudo -u ec2-user -i <<'EOF'
# PARAMETERS
VERSION=0.18.0
EXTENSION_NAME=sagemaker_run_notebook
# Set up the user setting and workspace directories
mkdir -p /home/ec2-user/SageMaker/.jupyter-user/{workspaces,user-settings}
# Run in the conda environment that the Jupyter server uses so that our changes are picked up
source /home/ec2-user/anaconda3/bin/activate JupyterSystemEnv
# Install the extension and rebuild JupyterLab so it picks up the new UI
aws s3 cp s3://aws-emr-resources-11111111-us-east-1/infra-sagemaker/sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz ./sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz
pip install sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz jupyter lab build
source /home/ec2-user/anaconda3/bin/deactivate
EOF # sudo -u ec2-user -i <<'EOF'
# PARAMETERS
for PACKAGE in pandas dataplate awswrangler==2.0.0 ipynb==0.5.1 prison==0.1.3 PyMySQL==0.10.1 requests==2.25.0 scipy==1.5.4 dtaidistance joblib sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz fuzzywuzzy==0.18.0; do echo $PACKAGE # Note that "base" is special environment name, include it there as well. for env in base /home/ec2-user/anaconda3/envs/*; do source /home/ec2-user/anaconda3/bin/activate $(basename "$env") if [ $env = 'JupyterSystemEnv' ]; then continue fi pip install --upgrade "$PACKAGE" source /home/ec2-user/anaconda3/bin/deactivate done
done
jupyter lab build # Tell Jupyter to use the user-settings and workspaces directory on the EBS
# volume.
echo "export JUPYTERLAB_SETTINGS_DIR=/home/ec2-user/SageMaker/.jupyter-user/user-settings" >> /etc/profile.d/jupyter-env.sh
echo "export JUPYTERLAB_WORKSPACES_DIR=/home/ec2-user/SageMaker/.jupyter-user/workspaces" >> /etc/profile.d/jupyter-env.sh # The Jupyter server needs to be restarted to pick up the server part of the
# extension. This needs to be done as root.
initctl restart jupyter-server --no-wait # OVERVIEW
# This script stops a SageMaker notebook once it's idle for more than 2 hour (default time)
# You can change the idle time for stop using the environment variable below.
# If you want the notebook the stop only if no browsers are open, remove the --ignore-connections flag
#
# Note that this script will fail if either condition is not met
# 1. Ensure the Notebook Instance has internet connectivity to fetch the example config
# 2. Ensure the Notebook Instance execution role permissions to SageMaker:StopNotebookInstance to stop the notebook
# and SageMaker:DescribeNotebookInstance to describe the notebook.
# PARAMETERS
IDLE_TIME=3600 echo "Fetching the autostop script"
wget https://raw.githubusercontent.com/aws-samples/amazon-sagemaker-notebook-instance-lifecycle-config-samples/master/scripts/auto-stop-idle/autostop.py echo "Starting the SageMaker autostop script in cron" (crontab -l 2>/dev/null; echo "*/5 * * * * /usr/bin/python $PWD/autostop.py --time $IDLE_TIME --ignore-connections") | crontab -

Chúng tôi nhân bản sagemaker-run-notebook Dự án GitHub và thêm phần sau vào vùng chứa:

  • Yêu cầu pip của chúng tôi
  • Khả năng chạy sổ ghi chép từ bên trong sổ ghi chép, cho phép chúng tôi thực hiện nhiều hành vi xử lý để tận dụng tất cả các lõi phiên bản ml.m5.12xlarge

Điều này cho phép chúng tôi chạy các quy trình công việc bao gồm nhiều sổ ghi chép đang chạy dưới dạng công việc xử lý trong một dòng mã, đồng thời xác định loại phiên bản để chạy.

Vì có thể thêm tham số vào sổ ghi chép nên chúng tôi có thể mở rộng quy mô xử lý bằng cách chạy đồng thời vào các giờ, ngày hoặc tháng khác nhau để lấy và xử lý dữ liệu.

Chúng tôi cũng có thể tạo các công việc lập lịch chạy sổ ghi chép (và thậm chí giới hạn thời gian chạy).

Chúng tôi cũng có thể quan sát các lần chạy cuối cùng và thông tin chi tiết của chúng, chẳng hạn như thời gian xử lý.

Với máy nghiền giấy được sử dụng trong container, chúng ta có thể xem kết quả đầu ra của mỗi lần chạy, điều này giúp chúng ta gỡ lỗi trong sản xuất.

Đánh giá đầu ra sổ ghi chép của chúng tôi ở dạng sổ ghi chép chỉ đọc tiêu chuẩn.

Việc sử dụng đa xử lý giúp chúng tôi mở rộng quy mô trên mỗi quá trình xử lý máy tính xách tay và tận dụng tất cả các lõi của nó. Chúng tôi đã tạo các hàm trong các máy tính xách tay khác có thể thực hiện xử lý nặng, chẳng hạn như sau:

  • Phát nổ JSON
  • Tìm các hàng có liên quan trong DataFrame trong khi sổ ghi chép chính chia DataFrame thành #cpu-cores các yếu tố
  • Chạy đồng thời phân cụm cho mỗi hành động loại cảnh báo

Sau đó, chúng tôi thêm các sổ ghi chép chức năng này vào vùng chứa chạy sổ ghi chép dưới dạng công việc xử lý. Xem tệp Docker sau (chú ý các lệnh COPY):

ARG BASE_IMAGE=need_an_image
FROM $BASE_IMAGE ENV JUPYTER_ENABLE_LAB yes
ENV PYTHONUNBUFFERED TRUE COPY requirements.txt /tmp/requirements.txt
RUN pip install papermill jupyter nteract-scrapbook boto3 requests==2.20.1
RUN pip install -r /tmp/requirements.txt ENV PYTHONUNBUFFERED=TRUE
ENV PATH="/opt/program:${PATH}" # Set up the program in the image
COPY multiprocessDownloadNormalizeFunctions.ipynb /tmp/multiprocessDownloadNormalizeFunctions.ipynb
COPY multiprocessFunctions.ipynb /tmp/multiprocessFunctions.ipynb
COPY run_notebook execute.py /opt/program/
ENTRYPOINT ["/bin/bash"] # because there is a bug where you have to be root to access the directories
USER root

Kết quả

Trong giai đoạn nghiên cứu, chúng tôi đã đánh giá tùy chọn chạy sổ ghi chép của mình nhằm thử nghiệm và đánh giá cách mã của chúng tôi hoạt động trên tất cả dữ liệu liên quan chứ không chỉ một mẫu dữ liệu. Chúng tôi nhận thấy rằng việc đóng gói sổ ghi chép của mình bằng các tác vụ xử lý có thể rất phù hợp với chúng tôi vì chúng tôi không cần viết lại mã và chúng tôi có thể tận dụng sức mạnh của các phiên bản được tối ưu hóa tính toán và tối ưu hóa bộ nhớ của AWS cũng như theo dõi trạng thái của quy trình một cách dễ dàng.

Trong quá trình đánh giá suy luận, chúng tôi đã đánh giá nhiều giải pháp điểm cuối SageMaker khác nhau. Chúng tôi nhận thấy rằng việc sử dụng điểm cuối nhiều mô hình có thể giúp chúng tôi phục vụ khoảng 50 khách hàng, mỗi khách hàng có nhiều (khoảng 10) mô hình trong một phiên bản duy nhất, có thể đáp ứng các ràng buộc về độ trễ thấp của chúng tôi và do đó giúp chúng tôi tiết kiệm tới 80% chi phí .

Với kiến ​​trúc giải pháp này, chúng tôi có thể giảm MTTR của khách hàng, đây là thước đo chính để đo lường sự thành công khi sử dụng nền tảng của chúng tôi. Nó giúp giảm tổng thời gian kể từ thời điểm phản hồi liên kết cảnh báo của chúng tôi, liên kết này mô tả sự cố trong hệ thống của bạn, cho đến khi bạn hoàn tất việc điều tra sự cố bằng nền tảng của chúng tôi. Trong giai đoạn điều tra, chúng tôi đo lường hành động của người dùng khi có và không có giải pháp đề xuất ML của chúng tôi. Điều này giúp chúng tôi đưa ra đề xuất về hành động tốt nhất nhằm giải quyết vấn đề cụ thể nhanh hơn và xác định những điểm bất thường để xác định nguyên nhân thực sự của vấn đề.

Kết luận và các bước tiếp theo

Trong bài đăng này, chúng tôi đã chia sẻ cách Logz.io sử dụng SageMaker để cải thiện MTTD và MTTR.

Bước tiếp theo, chúng tôi đang xem xét mở rộng giải pháp với các tính năng sau:

Chúng tôi khuyến khích bạn dùng thử sổ ghi chép SageMaker. Để biết thêm ví dụ, hãy xem Ví dụ về SageMaker GitHub repo.

Về các tác giả

Amit Gross đang lãnh đạo bộ phận Nghiên cứu của Logz.io, chịu trách nhiệm về các giải pháp AI của tất cả các sản phẩm Logz.io, từ giai đoạn nghiên cứu đến giai đoạn tích hợp. Trước Logz.io, Amit đã quản lý cả Nhóm nghiên cứu bảo mật và khoa học dữ liệu tại Here inc. và Cellebrite inc. Amit có bằng Thạc sĩ về khoa học máy tính tại Đại học Tel-Aviv.

Yaniv Vaknin là Chuyên gia Máy học tại Amazon Web Services. Trước AWS, Yaniv đã giữ các vị trí lãnh đạo với các công ty khởi nghiệp về AI và Doanh nghiệp, bao gồm cả người đồng sáng lập và Giám đốc điều hành của Dipsee.ai. Yaniv làm việc với khách hàng AWS để khai thác sức mạnh của Machine Learning nhằm giải quyết các nhiệm vụ trong thế giới thực và thu được giá trị. Khi rảnh rỗi, Yaniv thích chơi bóng đá với các cậu con trai của mình.

Eitan Sela là một Kiến trúc sư Giải pháp Chuyên gia về Học máy với Dịch vụ Web của Amazon. Anh làm việc với các khách hàng của AWS để cung cấp hướng dẫn và hỗ trợ kỹ thuật, giúp họ xây dựng và vận hành các giải pháp học máy trên AWS. Khi rảnh rỗi, Eitan thích chạy bộ và đọc các bài báo mới nhất về máy học.

Nguồn: https://aws.amazon.com/blogs/machine-learning/how-logz-io-accelerates-ml-recommendations-and-anomaly- detection-solutions-with-amazon-sagemaker/

Dấu thời gian:

Thêm từ Blog Học máy AWS