Hiệu suất hàng tối đa của mysql
|
Bài viết này là một phần trong gói tài nguyên Amazon Athena của chúng tôi. Nếu bạn muốn có nhiều nội dung Athena bổ sung bao gồm phân vùng, so sánh với BigQuery và Redshift, các ví dụ về trường hợp sử dụng và kiến trúc tham khảo, bạn nên đăng ký để truy cập MIỄN PHÍ tất cả các tài nguyên Athena của chúng tôi Show
Amazon Athena là dịch vụ phát triển nhanh nhất của Amazon Web Services – nhờ tăng cường áp dụng các kho dữ liệu AWS và mô hình liền mạch, đơn giản mà Athena cung cấp để truy vấn các bộ dữ liệu khổng lồ được lưu trữ trên Amazon bằng cách sử dụng SQL thông thường Tuy nhiên, Athena không phải không có hạn chế. và trong nhiều tình huống, Athena có thể chạy rất chậm hoặc làm bùng nổ ngân sách của bạn, đặc biệt nếu bạn không chú ý nhiều đến việc chuẩn bị dữ liệu. Chúng tôi sẽ giúp bạn tránh những sự cố này và chỉ ra cách tối ưu hóa các truy vấn cũng như dữ liệu cơ bản trên S3 để giúp Athena đáp ứng lời hứa về hiệu suất của nó Athena là công cụ truy vấn phổ biến nhất được sử dụng với Upsolver SQLake, nền tảng đường dẫn dữ liệu toàn SQL của chúng tôi cho phép bạn chỉ cần “viết truy vấn và nhận một đường dẫn” cho dữ liệu đang chuyển động, cho dù trong luồng sự kiện hay lô thường xuyên. SQLake tự động hóa mọi thứ khác, bao gồm điều phối, tối ưu hóa hệ thống tệp và tất cả các phương pháp hay nhất được đề xuất của Amazon cho Athena. Để dùng thử, bạn có thể thực thi các mẫu đường dẫn Athena mẫu hoặc bắt đầu xây dựng mẫu của riêng bạn trong Upsolver SQLake miễn phí Amazon Athena là gì?Amazon Athena là một dịch vụ truy vấn tương tác mà các nhà phát triển và nhà phân tích dữ liệu sử dụng để phân tích dữ liệu được lưu trữ trong Amazon S3. Kiến trúc không có máy chủ của Athena giúp giảm chi phí nền tảng dữ liệu và có nghĩa là người dùng không cần mở rộng quy mô, cung cấp hoặc quản lý bất kỳ máy chủ nào Người dùng Amazon Athena có thể sử dụng SQL tiêu chuẩn khi phân tích dữ liệu. Athena không yêu cầu máy chủ nên không cần giám sát cơ sở hạ tầng; . Người dùng chỉ cần trỏ đến dữ liệu của họ trong Amazon S3, xác định lược đồ và bắt đầu truy vấn Tuy nhiên, giống như hầu hết các công cụ phân tích dữ liệu, cần ghi nhớ một số phương pháp hay nhất để đảm bảo hiệu suất trên quy mô lớn. Hãy xem xét một số yếu tố chính có thể ảnh hưởng đến hiệu suất của Athena và xem cách chúng có thể áp dụng cho ngăn xếp đám mây của bạn Hiểu hiệu suất AthenaAthena tự động thay đổi quy mô và chạy nhiều truy vấn cùng một lúc. Điều này mang lại hiệu suất cao ngay cả khi các truy vấn phức tạp hoặc khi làm việc với các tập dữ liệu rất lớn. Tuy nhiên, Athena dựa vào tổ chức dữ liệu cơ bản trong S3 và thực hiện quét toàn bộ bảng thay vì sử dụng chỉ mục, điều này tạo ra các vấn đề về hiệu suất trong một số tình huống nhất định SQLake mang đến tối ưu hóa hiệu suất tự động, miễn phí cho người dùng Amazon AthenaMã bên dưới giới thiệu (sử dụng dữ liệu mẫu) quá trình nhập dữ liệu thô từ S3 và tối ưu hóa dữ liệu đó để truy vấn với Amazon Athena. Bằng cách làm theo các bước trong mã này, bạn có thể dễ dàng biết cách chuẩn bị dữ liệu đúng cách để sử dụng với Athena và bắt đầu tận dụng các khả năng truy vấn mạnh mẽ của nó /**************************************************************
*** Getting started pipeline. Run the statements one by one ***
**************************************************************/
/* This template walks you through transforming raw data in S3 and storing the results,
fully optimized in your data lake to be queried with Athena. */
/* Ingest data into SQLake */
-- 1. Create a connection to SQLake sample data source.
CREATE S3 CONNECTION upsolver_s3_samples
AWS_ROLE = 'arn:aws:iam::949275490180:role/upsolver_samples_role'
EXTERNAL_ID = 'SAMPLES'
READ_ONLY = TRUE;
-- 2. Create an empty table to use as staging for the raw data.
CREATE TABLE default_glue_catalog.database_5088dd.orders_raw_data()
PARTITIONED BY $event_date;
-- 3. Create a streaming job to ingest data from the sample bucket into the staging table.
CREATE JOB load_orders_raw_data_from_s3
CONTENT_TYPE = JSON
AS COPY FROM S3 upsolver_s3_samples BUCKET = 'upsolver-samples' PREFIX = 'orders/'
INTO default_glue_catalog.database_5088dd.orders_raw_data;
-- 4. Query your raw data in SQLake. It may take a minute for the data to appear.
SELECT * FROM default_glue_catalog.database_5088dd.orders_raw_data limit 10;
/* Create a table where the output data will be consumed */
-- 5. Create an output table in AWS Glue Data Catalog. The table will be accessible in Athena once data has been added.
CREATE TABLE default_glue_catalog.database_5088dd.orders_transformed_data(partition_date date)
PARTITIONED BY partition_date;
/* Transform and insert into the output table */
-- 6. Create a streaming job to read from the staging table, apply business logic transformations and insert the results into the output table.
CREATE JOB transform_orders_and_insert_into_athena
START_FROM = BEGINNING
ADD_MISSING_COLUMNS = true
RUN_INTERVAL = 1 MINUTE
AS INSERT INTO default_glue_catalog.database_5088dd.orders_transformed_data MAP_COLUMNS_BY_NAME
-- Use the SELECT statement to choose columns from the source and implement your business logic transformations.
SELECT
orderid AS order_id,
MD5(customer.email) AS customer_id, -- hash or mask columns using built-in functions
customer_name, -- computed field defined later in the query
nettotal AS total,
$commit_time AS partition_date
FROM default_glue_catalog.database_5088dd.orders_raw_data
LET customer_name = customer.firstname || ' ' || customer.lastname -- create a computed column
WHERE ordertype = 'SHIPPING'
AND $commit_time BETWEEN run_start_time() AND run_end_time();
/** Your pipeline is now running, bringing data from the source S3 bucket into a staging table, transforming it and saving it to an output table. **/
-- 7. Query the output table to view the results of the transformation job. SQLake queries the table using the Athena APIs.
SELECT * FROM default_glue_catalog.database_5088dd.orders_transformed_data LIMIT 10;Làm Thế Nào Để Athena Đạt Được Hiệu Suất Cao?Truy vấn song song ồ ạtAthena thực hiện các truy vấn đồng thời, do đó, ngay cả các truy vấn trên bộ dữ liệu rất lớn cũng có thể được hoàn thành trong vài giây. Do kiến trúc phi máy chủ, phân tán của Athena, nó có thể hỗ trợ số lượng lớn người dùng và truy vấn, đồng thời các tài nguyên máy tính như CPU và RAM được cung cấp liên tục Tối ưu hóa đọc theo hướng siêu dữ liệuCác định dạng lưu trữ dữ liệu hiện đại như ORC và Parquet dựa vào siêu dữ liệu mô tả một tập hợp các giá trị trong một phần dữ liệu (đôi khi được gọi là một dải). Ví dụ: nếu người dùng quan tâm đến các giá trị < 5 và siêu dữ liệu cho biết tất cả dữ liệu trong dải này nằm trong khoảng từ 100 đến 500, thì dải này hoàn toàn không liên quan đến truy vấn và truy vấn có thể bỏ qua nó Đây là cơ chế được Athena sử dụng để quét nhanh khối lượng dữ liệu khổng lồ. Để cải thiện cơ chế này, người dùng nên khéo léo sắp xếp dữ liệu (e. g. sắp xếp theo giá trị) để các bộ lọc chung có thể sử dụng siêu dữ liệu một cách hiệu quả Coi S3 là chỉ đọcMột phương pháp khác mà Athena sử dụng để tối ưu hóa hiệu suất bằng cách tạo các bảng tham chiếu bên ngoài và coi S3 là tài nguyên chỉ đọc. Điều này tránh thao tác ghi trên S3, để giảm độ trễ và tránh khóa bảng Các vấn đề về hiệu suất của AthenaAthena là một công cụ truy vấn phân tán, sử dụng S3 làm công cụ lưu trữ cơ bản của nó. Không giống như các sản phẩm cơ sở dữ liệu đầy đủ, nó không có lớp lưu trữ được tối ưu hóa riêng. Do đó, hiệu suất của nó phụ thuộc rất nhiều vào cách tổ chức dữ liệu trong S3—nếu dữ liệu được sắp xếp để cho phép lọc dựa trên siêu dữ liệu hiệu quả, thì nó sẽ hoạt động nhanh và nếu không, một số truy vấn có thể rất chậm Ngoài ra, Athena không có chỉ mục—nó dựa vào tính năng quét nhanh toàn bộ bảng. Điều này có nghĩa là một số thao tác, chẳng hạn như tham gia giữa các bảng lớn, có thể rất chậm, đó là lý do Amazon khuyên bạn nên chạy chúng bên ngoài Athena Chúng tôi đề cập đến các phương pháp hay nhất chính mà bạn cần triển khai để đảm bảo hiệu suất cao trong Athena trong bài viết này – nhưng bạn có thể bỏ qua tất cả các phương pháp đó bằng cách sử dụng Upsolver SQLake. SQLake là sản phẩm mới nhất của Upsolver. Nó cho phép bạn xây dựng và chạy các đường dẫn dữ liệu đáng tin cậy trên luồng và dữ liệu hàng loạt thông qua trải nghiệm toàn SQL. Nó nhập dữ liệu theo lô và truyền trực tuyến dưới dạng sự kiện, hỗ trợ các hoạt động có trạng thái như tập hợp luân phiên, chức năng cửa sổ, liên kết bản số cao và UPSERT, đồng thời cung cấp dữ liệu được tối ưu hóa và cập nhật từng phút cho các công cụ truy vấn, kho dữ liệu và hệ thống phân tích Giới hạn sản phẩm AthenaTheo giới hạn dịch vụ của Athena, nó không thể xây dựng các hàm tùy chỉnh do người dùng xác định (UDF), ghi lại S3 hoặc lên lịch và tự động hóa công việc. Amazon đặt một số hạn chế đối với các truy vấn. ví dụ: người dùng chỉ có thể gửi một truy vấn tại một thời điểm và chỉ có thể chạy tối đa năm truy vấn đồng thời cho mỗi tài khoản Athena giới hạn mỗi tài khoản ở 100 cơ sở dữ liệu và cơ sở dữ liệu không thể bao gồm hơn 100 bảng. Nền tảng hỗ trợ một số khu vực hạn chế 7 mẹo điều chỉnh hiệu suất hàng đầu cho Amazon AthenaNói chung, có hai lĩnh vực chính mà bạn cần tập trung vào để cải thiện hiệu suất của các truy vấn trong Athena
Chúng tôi sẽ tiếp tục xem xét sáu mẹo để cải thiện hiệu suất - năm mẹo đầu tiên áp dụng cho bộ nhớ và hai mẹo cuối cùng để điều chỉnh truy vấn 1. Phân vùng dữ liệuPhân vùng chia nhỏ bảng của bạn dựa trên các giá trị cột như quốc gia, khu vực, ngày, v.v. Các phân vùng hoạt động như các cột ảo và có thể giảm khối lượng dữ liệu được quét bởi mỗi truy vấn, do đó giảm chi phí và tối đa hóa hiệu suất. Người dùng xác định phân vùng khi họ tạo bảng của họ Đây là một ví dụ về cách bạn sẽ phân vùng dữ liệu theo ngày - nghĩa là bằng cách lưu trữ tất cả các sự kiện từ cùng một ngày trong một phân vùng Bạn phải tải các phân vùng vào bảng trước khi bắt đầu truy vấn dữ liệu, bằng cách
Bạn có thể đọc thêm về các chiến lược phân vùng và các phương pháp hay nhất trong hướng dẫn của chúng tôi về phân vùng dữ liệu trên S3 2. Nén và chia nhỏ tập tinBạn có thể tăng tốc đáng kể các truy vấn của mình bằng cách nén dữ liệu, với điều kiện là các tệp có thể chia nhỏ hoặc có kích thước tối ưu (kích thước tệp S3 tối ưu nằm trong khoảng 200MB-1GB). Kích thước dữ liệu nhỏ hơn có nghĩa là lưu lượng mạng ít hơn giữa Amazon S3 đến Athena Công cụ thực thi Athena có thể xử lý một tệp có nhiều trình đọc để tối đa hóa tính song song. Khi bạn có một tệp không thể chia, chỉ một trình đọc có thể đọc tệp và tất cả các trình đọc khác đều trống Nên sử dụng Apache Parquet hoặc Apache ORC, có thể chia nhỏ và nén dữ liệu theo mặc định khi làm việc với Athena. Nếu đây không phải là một tùy chọn, bạn có thể sử dụng BZip2 hoặc Gzip với kích thước tệp tối ưu. LZO và Snappy không được khuyến khích vì tỷ lệ nén của chúng thấp Khi bạn nhập dữ liệu bằng SQLake, đầu ra Athena được lưu trữ ở định dạng Parquet cột trong khi dữ liệu lịch sử được lưu trữ trong một nhóm riêng trên S3 3. Tối ưu hóa kích thước tập tinAthena có thể chạy các truy vấn hiệu quả hơn khi các khối dữ liệu có thể được đọc tuần tự và khi việc đọc dữ liệu có thể được song song hóa. Kiểm tra xem các định dạng tệp của bạn có thể chia được không, để hỗ trợ xử lý song song Tuy nhiên, nếu tệp rất nhỏ (dưới 128 MB), công cụ thực thi có thể dành thêm thời gian để mở tệp Amazon S3, truy cập siêu dữ liệu đối tượng, liệt kê thư mục, thiết lập truyền dữ liệu, đọc tiêu đề tệp và đọc từ điển nén, v.v. Nếu tệp của bạn quá lớn hoặc không thể chia nhỏ, quá trình xử lý truy vấn sẽ tạm dừng cho đến khi một trình đọc đọc xong tệp hoàn chỉnh, điều này có thể hạn chế tính song song Sử dụng Athena để truy vấn các tệp dữ liệu nhỏ có thể sẽ làm hỏng hiệu suất và ngân sách của bạn. SQLake cho phép bạn khắc phục sự cố này bằng cách tự động hợp nhất các tệp nhỏ để có hiệu suất tối ưu khi bạn xác định đầu ra cho Athena, sử dụng thuật toán nén và lập chỉ mục đột phá Để hiểu tác động của việc hợp nhất các tệp nhỏ, bạn có thể xem các tài nguyên sau
4. Tham gia các bảng lớn trong lớp ETLVì Athena không có chỉ mục nên nó dựa vào việc quét toàn bộ bảng để tham gia. Điều này tốt khi nối hai bảng nhỏ, nhưng rất chậm và tốn nhiều tài nguyên đối với các phép nối liên quan đến các bảng lớn Để tránh điều này, bạn nên kết hợp trước dữ liệu bằng công cụ ETL, trước khi truy vấn dữ liệu trong Athena Để hiểu cách thức hoạt động của tính năng này, hãy xem video này trình bày cách sử dụng SQLake để kết hợp dữ liệu cửa hàng với dữ liệu nhân viên trước khi truy vấn dữ liệu trong Athena 5. Tối ưu hóa việc tạo kho lưu trữ dữ liệu dạng cộtĐây là một tính năng khác mà SQLake xử lý ẩn; Apache ORC và Apache Parquet là các kho lưu trữ dữ liệu dạng cột có thể chia nhỏ. Họ cũng cung cấp các tính năng lưu trữ dữ liệu bằng cách sử dụng mã hóa khác nhau, nén theo cột, nén dựa trên loại dữ liệu và đẩy xuống vị từ. Thông thường, tỷ lệ nén nâng cao hoặc bỏ qua các khối dữ liệu liên quan đến việc đọc ít byte hơn từ Amazon S3, dẫn đến hiệu suất truy vấn nâng cao bạn có thể điều chỉnh
6. Tối ưu hóa các hoạt động SQLPresto là công cụ được Athena sử dụng để thực hiện các truy vấn. Khi bạn hiểu cách hoạt động của Presto, bạn có thể tối ưu hóa truy vấn tốt hơn khi chạy chúng. Bạn có thể tối ưu hóa các thao tác bên dưới ĐẶT BỞI
tham gia
Ngoại lệ là khi nối nhiều bảng lại với nhau và có tùy chọn nối chéo. Presto sẽ tiến hành nối từ trái sang phải vì nó vẫn không hỗ trợ sắp xếp lại thứ tự nối. Trong trường hợp này, bạn nên chỉ định các bảng từ lớn nhất đến nhỏ nhất. Đảm bảo rằng hai bảng không được chỉ định cùng nhau vì điều này có thể gây ra liên kết chéo
NHÓM THEO
THÍCH
7. Sử dụng các hàm gần đúngKhi bạn khám phá các tập dữ liệu lớn, một trường hợp sử dụng phổ biến là tách biệt số lượng giá trị riêng biệt cho một cột bằng cách sử dụng COUNT(DISTINCT column). Ví dụ: khi bạn đang xem số lượng người dùng duy nhất truy cập trang web Ví dụ: khi bạn không cần con số chính xác, nếu bạn đang quyết định xem trang web nào cần xem xét kỹ hơn, bạn có thể sử dụng approx_distinct(). Hàm này cố gắng giảm thiểu mức sử dụng bộ nhớ bằng cách đếm các giá trị băm duy nhất thay vì toàn bộ chuỗi. Nhược điểm là có sai số chuẩn là 2. 3%
Do Athena là lựa chọn tự nhiên để truy vấn dữ liệu phát trực tuyến trên S3, điều quan trọng là phải làm theo 6 mẹo này để cải thiện hiệu suất Chuẩn bị dữ liệu cho Athena – Spark vs AlternativesNhư chúng ta đã thấy, khi sử dụng Amazon Athena trong kiến trúc hồ dữ liệu, việc chuẩn bị dữ liệu là rất cần thiết. Việc áp dụng các phương pháp hay nhất về phân vùng, nén và nén tệp yêu cầu xử lý khối lượng dữ liệu lớn để chuyển đổi dữ liệu từ dạng thô sang dạng sẵn sàng phân tích, điều này có thể tạo ra các thách thức về độ trễ, sử dụng tài nguyên hiệu quả và chi phí kỹ thuật. Thách thức này trở nên gay gắt hơn với dữ liệu phát trực tuyến, là dữ liệu bán cấu trúc, thường xuyên thay đổi và được tạo ở tốc độ cao Công cụ truyền thống dành cho kỹ thuật hồ dữ liệu là khung nguồn mở Apache Spark hoặc các sản phẩm thương mại khác nhau cung cấp phiên bản Spark được quản lý. Mặc dù Spark là một framework mạnh mẽ với cộng đồng nguồn mở rất lớn và tận tâm, nhưng nó có thể gây khó khăn cho các tổ chức không có đội ngũ kỹ thuật nội bộ lớn do yêu cầu kiến thức chuyên môn cao để chạy Spark ở quy mô lớn Các giải pháp thay thế cho Spark, bao gồm SQLake, hướng nhiều hơn đến các hoạt động tự phục vụ bằng cách thay thế quản lý đường dẫn dữ liệu sử dụng nhiều mã bằng SQL khai báo. Bạn có thể tìm hiểu thêm về sự khác biệt giữa nền tảng Spark và công cụ xử lý dựa trên đám mây được SQLake sử dụng trong sách điện tử so sánh Spark của chúng tôi. Điểm chuẩn hiệu suất AthenaChúng tôi đã chạy nhiều thử nghiệm trong suốt nhiều năm để xem hiệu suất của Athena so với các công cụ truy vấn không có máy chủ khác như Google BigQuery như thế nào, cũng như để thử và đo lường tác động của việc chuẩn bị dữ liệu đối với hiệu suất và chi phí truy vấn. Bạn có thể xem kết quả của các bài kiểm tra này được tóm tắt tại đây. Điểm chuẩn Amazon Athena so với BigQuery Bạn có thể xem một ví dụ khác về cách tích hợp dữ liệu có thể tạo ra lợi nhuận khổng lồ khi nói đến hiệu suất trong hội thảo trên web mà chúng tôi đã thực hiện với Looker, nơi chúng tôi giới thiệu cách bảng thông tin của Looker dựa trên truy vấn Athena có thể hoạt động hiệu quả hơn đáng kể. Bạn có thể xem toàn bộ hội thảo trực tuyến dưới đây (Lưu ý rằng trong Upsolver SQLake, bản phát hành mới nhất của chúng tôi, giao diện người dùng đã thay đổi thành trải nghiệm toàn SQL, giúp việc xây dựng quy trình dễ dàng như viết truy vấn SQL. Tuy nhiên, công cụ xử lý gốc trên đám mây và hiệu suất vượt trội giống như đã được trình bày trong hội thảo trên web. Cuộn xuống để biết thêm chi tiết. ) Athena vs Quang phổ dịch chuyển đỏ Amazon Redshift Spectrum là một dịch vụ khác cho phép bạn truy vấn dữ liệu trên S3 bằng cách sử dụng SQL và để dễ dàng chạy các truy vấn tương tự trên dữ liệu được lưu trữ trong cụm Redshift của bạn và thực hiện liên kết giữa dữ liệu S3 và Redshift Do đó, bạn sẽ cần xem xét liệu Redshift có phù hợp hơn với trường hợp của mình hay không và chúng tôi đã đề cập đến những cân nhắc chính về cách quyết định giữa Athena và Redshift trong bài viết trước của chúng tôi. Trận đấu không có máy chủ. Amazon Athena so với Redshift Spectrum, đạt được những phát hiện sau
Cách cải thiện hiệu suất truy vấn của bạn lên 10-15 lầnMặc dù SQLake không điều chỉnh các truy vấn của bạn trong Athena, nhưng SQLake sẽ loại bỏ khoảng 95% nỗ lực ETL liên quan đến việc tối ưu hóa lớp lưu trữ (điều mà bạn cần thực hiện trong Spark/Hadoop/MapReduce). Bạn có thể xây dựng quy trình xử lý đáng tin cậy, có thể bảo trì và có thể kiểm tra đối với dữ liệu theo lô và dữ liệu truyền trực tuyến, chỉ sử dụng SQL, trong 3 bước đơn giản
SQLake trừu tượng hóa sự phức tạp của các hoạt động ETL. Tất cả các phương pháp hay nhất khác nhau mà chúng tôi đã đề cập trong bài viết này và rất phức tạp để triển khai – chẳng hạn như hợp nhất các tệp nhỏ và phân vùng dữ liệu một cách tối ưu – đều ẩn đối với người dùng và được xử lý tự động bên dưới. SQLake tự động quản lý việc sắp xếp các tác vụ (không cần tạo DAG thủ công), tăng và giảm tỷ lệ tài nguyên điện toán và tối ưu hóa dữ liệu đầu ra. Và nó dễ dàng mở rộng quy mô thành hàng triệu sự kiện mỗi giây với các phép biến đổi trạng thái phức tạp như tham gia, tập hợp và upserts Đường ống SQLake thường dẫn đến các truy vấn nhanh hơn 10-15 lần trong Athena so với các giải pháp thay thế và mất một phần nhỏ thời gian để triển khai Xem cho chính mình. Dùng thử SQLake miễn phí trong 30 ngày – không cần thẻ tín dụng. Bạn có thể bắt đầu ngay lập tức thông qua một loạt các mẫu SQL được thiết kế để giúp bạn thiết lập và chạy trong thời gian gần như nhanh chóng. Sử dụng dữ liệu của riêng bạn hoặc dữ liệu mẫu của chúng tôi. Các mẫu đường dẫn dữ liệu bao gồm
Và hơn thế nữa Bạn muốn thành thạo kỹ thuật dữ liệu cho Amazon Athena? Tìm hiểu mọi thứ bạn cần để xây dựng kiến trúc đám mây hiệu quả trên Amazon S3 với gói Amazon Athena tối ưu của chúng tôi, bao gồm - Sách điện tử. Phân vùng dữ liệu trên S3 để cải thiện hiệu suất Athena – Hội thảo trên web được ghi lại. Cải thiện hiệu suất Athena + Looker lên 380% – Hội thảo trên web được ghi lại. 6 mẹo ETL phải biết cho Amazon Athena – Athena so với Google BigQuery + điểm chuẩn hiệu suất Và nhiều hơn nữa. Nhận gói đầy đủ MIỄN PHÍ ngay tại đây Hiệu suất Athena – Câu hỏi thường gặpTại sao Athena chạy chậm? Các vấn đề về hiệu suất của Athena thường do chạy truy vấn SQL được tối ưu hóa kém hoặc do cách lưu trữ dữ liệu trên S3. Nếu dữ liệu không được nén hoặc sắp xếp hiệu quả, một số truy vấn có thể mất nhiều thời gian để trả về. Ngoài ra, Athena không có chỉ mục, điều này có thể khiến việc liên kết giữa các bảng lớn bị chậm Chi phí Athena có hiệu quả không? Sử dụng Athena thay vì kho dữ liệu đám mây có thể giảm chi phí đám mây tổng thể của bạn. Vì Athena không có máy chủ và có thể đọc trực tiếp từ S3 nên nó cho phép tách biệt mạnh mẽ giữa lưu trữ và tính toán. Lưu trữ hiệu quả như Parquet có thể giúp bạn giảm lượng dữ liệu được quét cho mỗi truy vấn, giảm hơn nữa chi phí Athena Amazon Athena có thể mở rộng được không? Mặc dù Athena thường được sử dụng để phân tích tương tác, nhưng nó có thể mở rộng theo khối lượng công việc sản xuất. Việc triển khai Athena được điều chỉnh tốt có thể mở rộng tới hàng petabyte và nhiều khách hàng Upsolver hiện tại sử dụng Athena để chạy khối lượng công việc BI và phân tích thay cho kho dữ liệu như Redshift Sự khác biệt giữa Athena và Redshift là gì? AWS Athena là một công cụ truy vấn không có máy chủ được sử dụng để truy xuất dữ liệu từ Amazon S3 bằng SQL. Amazon Redshift là kho dữ liệu đám mây được tối ưu hóa cho hiệu suất phân tích. Dịch chuyển đỏ có thể nhanh hơn và mạnh mẽ hơn, nhưng Athena linh hoạt hơn. (Tìm hiểu thêm về sự khác biệt giữa Athena và Redshift. ) |
