Các tổ chức thường cần quản lý một lượng lớn dữ liệu đang tăng với tốc độ phi thường. Đồng thời, họ cần tối ưu hóa chi phí vận hành để khai thác giá trị của dữ liệu này để có được những hiểu biết kịp thời và đạt được hiệu suất ổn định.

Với sự tăng trưởng dữ liệu khổng lồ này, việc phổ biến dữ liệu trên các kho dữ liệu, kho dữ liệu và hồ dữ liệu của bạn có thể trở thành thách thức không kém. Với một kiến trúc dữ liệu hiện đại trên AWS, bạn có thể nhanh chóng xây dựng các hồ dữ liệu có khả năng mở rộng; sử dụng bộ sưu tập rộng rãi và chuyên sâu các dịch vụ dữ liệu được xây dựng có mục đích; đảm bảo tuân thủ thông qua truy cập, bảo mật và quản trị dữ liệu thống nhất; mở rộng quy mô hệ thống của bạn với chi phí thấp mà không ảnh hưởng đến hiệu suất; và chia sẻ dữ liệu xuyên ranh giới tổ chức một cách dễ dàng, cho phép bạn đưa ra quyết định nhanh chóng và linh hoạt trên quy mô lớn.

Bạn có thể lấy tất cả dữ liệu của mình từ nhiều kho lưu trữ khác nhau, tổng hợp dữ liệu đó trong kho dữ liệu của mình và thực hiện phân tích và học máy (ML) trực tiếp trên dữ liệu đó. Bạn cũng có thể lưu trữ dữ liệu khác trong kho dữ liệu chuyên dụng để phân tích và nhận thông tin chi tiết nhanh chóng từ cả dữ liệu có cấu trúc và không cấu trúc. Sự di chuyển dữ liệu này có thể từ trong ra ngoài, từ ngoài vào trong, xung quanh chu vi hoặc chia sẻ xuyên suốt.

Ví dụ: nhật ký ứng dụng và dấu vết từ ứng dụng web có thể được thu thập trực tiếp trong hồ dữ liệu và một phần dữ liệu đó có thể được chuyển đến kho phân tích nhật ký như Amazon OpenSearch Service để phân tích hàng ngày. Chúng tôi nghĩ về khái niệm này như trái ngược chuyển động dữ liệu. Dữ liệu được phân tích và tổng hợp được lưu trữ trong Amazon OpenSearch Service một lần nữa có thể được di chuyển đến hồ dữ liệu để chạy các thuật toán ML nhằm sử dụng tiếp theo từ các ứng dụng. Chúng tôi gọi khái niệm này là ngoài vào trong chuyển động dữ liệu.

Hãy xem xét một trường hợp sử dụng ví dụ. Ví dụ Corp. là công ty hàng đầu trong Fortune 500 chuyên về nội dung xã hội. Họ có hàng trăm ứng dụng tạo dữ liệu và dấu vết với tốc độ khoảng 500 TB mỗi ngày và có các tiêu chí sau:

• Có sẵn nhật ký để phân tích nhanh trong 2 ngày
• Sau 2 ngày, hãy chuẩn bị sẵn dữ liệu ở tầng lưu trữ để phân tích với SLA hợp lý
• Lưu giữ dữ liệu quá 1 tuần trong kho lạnh trong 30 ngày (cho mục đích tuân thủ, kiểm toán và các mục đích khác)

Trong các phần sau, chúng tôi thảo luận về ba giải pháp khả thi để giải quyết các trường hợp sử dụng tương tự:

• Lưu trữ theo cấp độ trong Amazon OpenSearch Service và quản lý vòng đời dữ liệu
• Nhập nhật ký theo yêu cầu bằng cách sử dụng Nhập liệu Amazon OpenSearch
• Truy vấn trực tiếp của Amazon OpenSearch Service với Amazon Simple Storage Service (Amazon S3)

Giải pháp 1: Lưu trữ theo cấp độ trong Dịch vụ OpenSearch và quản lý vòng đời dữ liệu

Dịch vụ OpenSearch hỗ trợ ba tầng lưu trữ tích hợp: lưu trữ nóng, UltraWarm và lạnh. Dựa trên yêu cầu về lưu giữ dữ liệu, độ trễ truy vấn và lập ngân sách, bạn có thể chọn chiến lược tốt nhất để cân bằng giữa chi phí và hiệu suất. Bạn cũng có thể di chuyển dữ liệu giữa các tầng lưu trữ khác nhau.

Bộ lưu trữ nóng được sử dụng để lập chỉ mục và cập nhật, đồng thời cung cấp khả năng truy cập dữ liệu nhanh nhất. Bộ lưu trữ nóng có dạng một cửa hàng mẫu hoặc Cửa hàng đàn hồi Amazon (Amazon EBS) được gắn vào mỗi nút.

UltraWarm cung cấp chi phí trên mỗi GiB thấp hơn đáng kể cho dữ liệu chỉ đọc mà bạn truy vấn ít thường xuyên hơn và không cần hiệu năng tương tự như bộ lưu trữ nóng. Các nút UltraWarm sử dụng Amazon S3 với các giải pháp bộ nhớ đệm liên quan để cải thiện hiệu suất.

Kho lạnh được tối ưu hóa để lưu trữ dữ liệu lịch sử hoặc dữ liệu được truy cập không thường xuyên. Khi sử dụng kho lạnh, bạn tách các chỉ mục của mình khỏi cấp UltraWarm, khiến chúng không thể truy cập được. Bạn có thể gắn lại các chỉ mục này sau vài giây khi cần truy vấn dữ liệu đó.

Để biết thêm chi tiết về các tầng dữ liệu trong Dịch vụ OpenSearch, hãy tham khảo Chọn cấp lưu trữ phù hợp với nhu cầu của bạn trong Amazon OpenSearch Service.

Tổng quan về giải pháp

Quy trình làm việc cho giải pháp này bao gồm các bước sau:

1. Dữ liệu đến do ứng dụng tạo ra sẽ được truyền tới hồ dữ liệu S3.
2. Dữ liệu được đưa vào Amazon OpenSearch bằng cách sử dụng Nhập S3-SQS gần thời gian thực thông qua các thông báo được thiết lập trên nhóm S3.
3. Sau 2 ngày, dữ liệu nóng sẽ được di chuyển sang bộ lưu trữ UltraWarm để hỗ trợ đọc truy vấn.
4. Sau 5 ngày ở UltraWarm, dữ liệu sẽ được di chuyển sang kho lạnh trong 21 ngày và tách khỏi mọi điện toán. Dữ liệu có thể được gắn lại vào UltraWarm khi cần. Dữ liệu sẽ bị xóa khỏi kho lạnh sau 21 ngày.
5. Các chỉ số hàng ngày được duy trì để dễ dàng chuyển đổi. Chính sách Quản lý trạng thái chỉ mục (ISM) tự động hóa việc chuyển đổi hoặc xóa các chỉ mục cũ hơn 2 ngày.

Sau đây là chính sách ISM mẫu sẽ chuyển dữ liệu sang tầng UltraWarm sau 2 ngày, chuyển dữ liệu sang kho lạnh sau 5 ngày và xóa dữ liệu khỏi kho lạnh sau 21 ngày:

{
    "policy": {
        "description": "hot warm delete workflow",
        "default_state": "hot",
        "schema_version": 1,
        "states": [
            {
                "name": "hot",
                "actions": [
                    {
                        "rollover": {
                            "min_index_age": "2d",
                            "min_primary_shard_size": "30gb"
                        }
                    }
                ],
                "transitions": [
                    {
                        "state_name": "warm"
                    }
                ]
            },
            {
                "name": "warm",
                "actions": [
                    {
                        "replica_count": {
                            "number_of_replicas": 5
                        }
                    }
                ],
                "transitions": [
                    {
                        "state_name": "cold",
                        "conditions": {
                            "min_index_age": "5d"
                        }
                    }
                ]
            },
            {
                "name": "cold",
                "actions": [
                    {
                        "retry": {
                            "count": 5,
                            "backoff": "exponential",
                            "delay": "1h"
                        },
                        "cold_migration": {
                            "start_time": null,
                            "end_time": null,
                            "timestamp_field": "@timestamp",
                            "ignore": "none"
                        }
                    }
                ],
                "transitions": [
                    {
                        "state_name": "delete",
                        "conditions": {
                            "min_index_age": "21d"
                        }
                    }
                ]
            },
            {
                "name": "delete",
                "actions": [
                    {
                        "retry": {
                            "count": 3,
                            "backoff": "exponential",
                            "delay": "1m"
                        },
                        "cold_delete": {}
                    }
                ],
                "transitions": []
            }
        ],
        "ism_template": {
            "index_patterns": [
                "log*"
            ],
            "priority": 100
        }
    }
}

Những cân nhắc

UltraWarm sử dụng các kỹ thuật bộ nhớ đệm phức tạp để cho phép truy vấn dữ liệu được truy cập không thường xuyên. Mặc dù việc truy cập dữ liệu không thường xuyên nhưng quá trình tính toán cho các nút UltraWarm cần phải chạy mọi lúc để có thể thực hiện được quyền truy cập này.

Khi vận hành ở quy mô PB, để giảm phạm vi ảnh hưởng của bất kỳ lỗi nào, chúng tôi khuyên bạn nên phân tách quá trình triển khai thành nhiều miền Dịch vụ OpenSearch khi sử dụng bộ nhớ theo cấp độ.

Hai mẫu tiếp theo loại bỏ nhu cầu tính toán lâu dài và mô tả các kỹ thuật theo yêu cầu, trong đó dữ liệu được đưa đến khi cần hoặc được truy vấn trực tiếp tại nơi dữ liệu lưu trữ.

Giải pháp 2: Nhập dữ liệu nhật ký theo yêu cầu thông qua Nhập OpenSearch

OpenSearch Ingestion là một công cụ thu thập dữ liệu được quản lý hoàn toàn, cung cấp dữ liệu theo dõi và nhật ký theo thời gian thực cho các miền Dịch vụ OpenSearch. OpenSearch Ingestion được hỗ trợ bởi trình thu thập dữ liệu nguồn mở Người chuẩn bị dữ liệu. Trình chuẩn bị dữ liệu là một phần của dự án OpenSearch mã nguồn mở.

Với OpenSearch Ingestion, bạn có thể lọc, làm phong phú, chuyển đổi và phân phối dữ liệu của mình để phân tích và trực quan hóa tiếp theo. Bạn định cấu hình nhà sản xuất dữ liệu của mình để gửi dữ liệu tới OpenSearch Ingestion. Nó tự động gửi dữ liệu đến miền hoặc bộ sưu tập mà bạn chỉ định. Bạn cũng có thể định cấu hình Nhập OpenSearch để chuyển đổi dữ liệu của mình trước khi phân phối. OpenSearch Ingestion không có máy chủ nên bạn không cần phải lo lắng về việc mở rộng cơ sở hạ tầng, vận hành nhóm nhập cũng như vá lỗi hoặc cập nhật phần mềm.

Có hai cách để bạn có thể sử dụng Amazon S3 làm nguồn để xử lý dữ liệu bằng OpenSearch Ingestion. Tùy chọn đầu tiên là xử lý S3-SQS. Bạn có thể sử dụng quy trình xử lý S3-SQS khi yêu cầu quét tệp gần như theo thời gian thực sau khi chúng được ghi vào S3. Nó đòi hỏi một Dịch vụ xếp hàng đơn giản trên Amazon (Amazon S3) hàng đợi nhận Thông báo sự kiện S3. Bạn có thể định cấu hình vùng lưu trữ S3 để phát sinh sự kiện bất cứ khi nào một đối tượng được lưu trữ hoặc sửa đổi trong vùng lưu trữ cần xử lý.

Ngoài ra, bạn có thể sử dụng tính năng quét theo lịch một lần hoặc định kỳ để xử lý hàng loạt dữ liệu trong bộ chứa S3. Để thiết lập quét theo lịch, hãy định cấu hình quy trình của bạn với lịch trình ở cấp độ quét áp dụng cho tất cả các nhóm S3 của bạn hoặc ở cấp độ nhóm. Bạn có thể định cấu hình quét theo lịch bằng quét một lần hoặc quét định kỳ để xử lý hàng loạt.

Để biết thông tin tổng quan toàn diện về Nhập OpenSearch, hãy xem Nhập liệu Amazon OpenSearch. Để biết thêm thông tin về dự án nguồn mở Data Prepper, hãy truy cập Người chuẩn bị dữ liệu.

Tổng quan về giải pháp

Chúng tôi trình bày một mẫu kiến ​​trúc với các thành phần chính sau:

• Nhật ký ứng dụng được truyền trực tuyến vào hồ dữ liệu, giúp cung cấp dữ liệu nóng vào Dịch vụ OpenSearch trong thời gian gần như thực bằng cách sử dụng OpenSearch Ingestion Xử lý S3-SQS.
• Chính sách ISM trong Dịch vụ OpenSearch xử lý việc chuyển đổi hoặc xóa chỉ mục. Chính sách ISM cho phép bạn tự động hóa các hoạt động quản trị, định kỳ này bằng cách kích hoạt chúng dựa trên những thay đổi về tuổi chỉ mục, kích thước chỉ mục hoặc số lượng tài liệu. Ví dụ: bạn có thể xác định chính sách chuyển chỉ mục của mình sang trạng thái chỉ đọc sau 2 ngày và sau đó xóa chỉ mục đó sau khoảng thời gian đã đặt là 3 ngày.
• Dữ liệu nguội có sẵn trong hồ dữ liệu S3 để được sử dụng theo yêu cầu vào Dịch vụ OpenSearch bằng cách sử dụng OpenSearch Ingestion quét theo lịch trình.

Sơ đồ sau minh họa kiến ​​trúc giải pháp.

Quy trình làm việc bao gồm các bước sau:

1. Dữ liệu đến do ứng dụng tạo ra sẽ được truyền tới hồ dữ liệu S3.
2. Đối với ngày hiện tại, dữ liệu được nhập vào Dịch vụ OpenSearch bằng cách nhập S3-SQS gần thời gian thực thông qua các thông báo được thiết lập trong nhóm S3.
3. Các chỉ số hàng ngày được duy trì để dễ dàng chuyển đổi. Chính sách ISM tự động hóa việc chuyển đổi hoặc xóa các chỉ mục cũ hơn 2 ngày.
4. Nếu yêu cầu phân tích dữ liệu vượt quá 2 ngày và dữ liệu không thuộc bậc UltraWarm, dữ liệu sẽ được nhập bằng tính năng quét một lần của Amazon S3 trong khoảng thời gian cụ thể.

Ví dụ: nếu ngày hiện tại là ngày 10 tháng 2024 năm 6 và bạn cần dữ liệu từ ngày 2024 tháng 3 năm XNUMX vào một khoảng thời gian cụ thể để phân tích, thì bạn có thể tạo quy trình Nhập OpenSearch bằng bản quét Amazon SXNUMX trong cấu hình YAML của mình, với start_time và end_time để chỉ định thời điểm bạn muốn quét các đối tượng trong nhóm:

version: "2"
ondemand-ingest-pipeline:
  source:
    s3:
      codec:
        newline:
      compression: "gzip"
      scan:
        start_time: 2023-12-28T01:00:00
        end_time: 2023-12-31T09:00:00
        buckets:
          - bucket:
              name: <bucket-name>
      aws:
        region: "us-east-1"
        sts_role_arn: "arn:aws:iam::<acct num>:role/PipelineRole"
    
    acknowledgments: true
  processor:
    - parse_json:
    - date:
        from_time_received: true
        destination: "@timestamp"           
  sink:
    - opensearch:                  
        index: "logs_ondemand_20231231"
        hosts: [ "https://search-XXXX-domain-XXXXXXXXXX.us-east-1.es.amazonaws.com" ]
        aws:                  
          sts_role_arn: "arn:aws:iam::<acct num>:role/PipelineRole"
          region: "us-east-1"

Những cân nhắc

Tận dụng khả năng nén

Dữ liệu trong Amazon S3 có thể được nén, giúp giảm dung lượng dữ liệu tổng thể của bạn và giúp tiết kiệm chi phí đáng kể. Ví dụ: nếu bạn đang tạo 15 PB nhật ký ứng dụng JSON thô mỗi tháng, bạn có thể sử dụng cơ chế nén như GZIP, cơ chế này có thể giảm kích thước xuống khoảng 1PB trở xuống, giúp tiết kiệm đáng kể chi phí.

Dừng đường ống khi có thể

OpenSearch Ingestion tự động chia tỷ lệ giữa OCU tối thiểu và tối đa được đặt cho quy trình. Sau khi quy trình hoàn tất quá trình quét Amazon S3 trong khoảng thời gian được chỉ định được đề cập trong cấu hình quy trình, quy trình tiếp tục chạy để giám sát liên tục ở OCU tối thiểu.

Để nhập theo yêu cầu trong khoảng thời gian trước đây mà bạn không mong muốn tạo đối tượng mới, hãy cân nhắc sử dụng các chỉ số quy trình được hỗ trợ, chẳng hạn như recordsOut.count để tạo ra amazoncloudwatch báo động có thể dừng đường ống. Để biết danh sách các số liệu được hỗ trợ, hãy tham khảo Giám sát số liệu đường ống.

Cảnh báo CloudWatch thực hiện hành động khi số liệu CloudWatch vượt quá giá trị được chỉ định trong một khoảng thời gian. Ví dụ: bạn có thể muốn theo dõi recordsOut.count bằng 0 trong hơn 5 phút để bắt đầu yêu cầu dừng đường ống thông qua Giao diện dòng lệnh AWS (AWS CLI) hoặc API.

Giải pháp 3: Truy vấn trực tiếp Dịch vụ OpenSearch với Amazon S3

Truy vấn trực tiếp Dịch vụ OpenSearch với Amazon S3 (bản xem trước) là một cách mới để truy vấn nhật ký vận hành trong hồ dữ liệu Amazon S3 và S3 mà không cần phải chuyển đổi giữa các dịch vụ. Giờ đây, bạn có thể phân tích dữ liệu được truy vấn không thường xuyên trong các cửa hàng đối tượng trên đám mây, đồng thời sử dụng khả năng phân tích hoạt động và trực quan hóa của Dịch vụ OpenSearch.

Truy vấn trực tiếp Dịch vụ OpenSearch với Amazon S3 cung cấp tích hợp không ETL để giảm độ phức tạp trong hoạt động của việc sao chép dữ liệu hoặc quản lý nhiều công cụ phân tích bằng cách cho phép bạn truy vấn trực tiếp dữ liệu hoạt động của mình, giảm chi phí và thời gian hành động. Tích hợp zero-ETL này có thể định cấu hình trong Dịch vụ OpenSearch, nơi bạn có thể tận dụng các mẫu loại nhật ký khác nhau, bao gồm bảng thông tin được xác định trước và đặt cấu hình tăng tốc dữ liệu phù hợp với loại nhật ký đó. Mẫu bao gồm Nhật ký luồng VPC, Cân bằng tải đàn hồi nhật ký, nhật ký NGINX và các phần tăng tốc bao gồm bỏ qua chỉ mục, chế độ xem cụ thể hóa và chỉ mục được bao phủ.

Với các truy vấn trực tiếp của Dịch vụ OpenSearch với Amazon S3, bạn có thể thực hiện các truy vấn phức tạp quan trọng đối với việc điều tra bảo mật và phân tích mối đe dọa cũng như liên kết dữ liệu trên nhiều nguồn dữ liệu, hỗ trợ các nhóm điều tra thời gian ngừng hoạt động của dịch vụ và các sự kiện bảo mật. Sau khi tạo tiện ích tích hợp, bạn có thể bắt đầu truy vấn dữ liệu của mình trực tiếp từ Bảng thông tin OpenSearch hoặc API OpenSearch. Bạn có thể kiểm tra các kết nối để đảm bảo rằng chúng được thiết lập theo cách có thể mở rộng, tiết kiệm chi phí và an toàn.

Truy vấn trực tiếp từ Dịch vụ OpenSearch tới Amazon S3 sử dụng bảng Spark trong Keo AWS Danh mục dữ liệu. Sau khi bảng được liệt kê trong danh mục siêu dữ liệu AWS Glue, bạn có thể chạy truy vấn trực tiếp trên dữ liệu của mình trong hồ dữ liệu S3 thông qua Bảng thông tin OpenSearch.

Tổng quan về giải pháp

Sơ đồ sau minh họa kiến ​​trúc giải pháp.

Giải pháp này bao gồm các thành phần chính sau:

• Dữ liệu nóng của ngày hiện tại được xử lý theo luồng vào các miền Dịch vụ OpenSearch thông qua mẫu kiến ​​trúc hướng sự kiện bằng cách sử dụng tính năng xử lý S3-SQS của OpenSearch Ingestion
• Vòng đời dữ liệu nóng được quản lý thông qua các chính sách ISM gắn liền với các chỉ mục hàng ngày
• Dữ liệu nguội nằm trong bộ chứa Amazon S3 của bạn và được phân vùng cũng như lập danh mục

Ảnh chụp màn hình sau đây hiển thị một mẫu http_logs bảng được liệt kê trong danh mục siêu dữ liệu AWS Glue. Để biết các bước chi tiết, hãy tham khảo Danh mục dữ liệu và trình thu thập thông tin trong AWS Glue.

Trước khi tạo nguồn dữ liệu, bạn phải có miền Dịch vụ OpenSearch với phiên bản 2.11 trở lên và bảng S3 mục tiêu trong Danh mục dữ liệu AWS Glue với thông tin thích hợp Quản lý truy cập và nhận dạng AWS (IAM) quyền. IAM sẽ cần quyền truy cập vào nhóm S3 mong muốn cũng như có quyền truy cập đọc và ghi vào Danh mục dữ liệu AWS Glue. Sau đây là vai trò mẫu và chính sách tin cậy với các quyền thích hợp để truy cập Danh mục dữ liệu AWS Glue thông qua Dịch vụ OpenSearch:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "directquery.opensearchservice.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Sau đây là chính sách tùy chỉnh mẫu có quyền truy cập vào Amazon S3 và AWS Glue:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": "es:ESHttp*",
            "Resource": "arn:aws:es:*:<acct_num>:domain/*"
        },
        {
            "Sid": "Statement2",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*",
                "s3:Put*",
                "s3:Describe*"
            ],
            "Resource": [
                "arn:aws:s3:::<bucket-name>",
                "arn:aws:s3:::<bucket-name>/*"
            ]
        },
        {
            "Sid": "GlueCreateAndReadDataCatalog",
            "Effect": "Allow",
            "Action": [
                "glue:GetDatabase",
                "glue:CreateDatabase",
                "glue:GetDatabases",
                "glue:CreateTable",
                "glue:GetTable",
                "glue:UpdateTable",
                "glue:DeleteTable",
                "glue:GetTables",
                "glue:GetPartition",
                "glue:GetPartitions",
                "glue:CreatePartition",
                "glue:BatchCreatePartition",
                "glue:GetUserDefinedFunctions"
            ],
            "Resource": [
                "arn:aws:glue:us-east-1:<acct_num>:catalog",
                "arn:aws:glue:us-east-1:<acct_num>:database/*",
                "arn:aws:glue:us-east-1:<acct_num>:table/*"
            ]
        }
    ]
}

Để tạo nguồn dữ liệu mới trên bảng điều khiển Dịch vụ OpenSearch, hãy cung cấp tên nguồn dữ liệu mới của bạn, chỉ định loại nguồn dữ liệu là Amazon S3 với Danh mục dữ liệu AWS Gluevà chọn vai trò IAM cho nguồn dữ liệu của bạn.

Sau khi tạo nguồn dữ liệu, bạn có thể đi tới bảng thông tin OpenSearch của miền mà bạn sử dụng để định cấu hình kiểm soát truy cập, xác định bảng, thiết lập bảng thông tin dựa trên loại nhật ký cho các loại nhật ký phổ biến và truy vấn dữ liệu của bạn.

Sau khi thiết lập bảng, bạn có thể truy vấn dữ liệu trong hồ dữ liệu S3 thông qua Bảng thông tin OpenSearch. Bạn có thể chạy một truy vấn SQL mẫu cho http_logs bảng bạn đã tạo trong các bảng Danh mục dữ liệu AWS Glue, như minh họa trong ảnh chụp màn hình sau.

Các phương pháp hay nhất

Chỉ nhập dữ liệu bạn cần

Làm việc ngược lại với nhu cầu kinh doanh của bạn và thiết lập các bộ dữ liệu phù hợp mà bạn cần. Đánh giá xem bạn có thể tránh nhập dữ liệu nhiễu và chỉ nhập dữ liệu được quản lý, lấy mẫu hoặc tổng hợp hay không. Việc sử dụng các bộ dữ liệu đã được làm sạch và tuyển chọn này sẽ giúp bạn tối ưu hóa tài nguyên điện toán và lưu trữ cần thiết để nhập dữ liệu này.

Giảm kích thước dữ liệu trước khi nhập

Khi bạn thiết kế quy trình nhập dữ liệu, hãy sử dụng các chiến lược như nén, lọc và tổng hợp để giảm kích thước của dữ liệu được nhập. Điều này sẽ cho phép kích thước dữ liệu nhỏ hơn được truyền qua mạng và được lưu trữ trong lớp dữ liệu của bạn.

Kết luận

Trong bài đăng này, chúng tôi đã thảo luận về các giải pháp cho phép phân tích nhật ký ở quy mô petabyte bằng Dịch vụ OpenSearch trong kiến ​​trúc dữ liệu hiện đại. Bạn đã tìm hiểu cách tạo quy trình nhập không có máy chủ để phân phối nhật ký đến miền Dịch vụ OpenSearch, quản lý chỉ mục thông qua chính sách ISM, định cấu hình quyền IAM để bắt đầu sử dụng OpenSearch Ingestion và tạo cấu hình quy trình cho dữ liệu trong kho dữ liệu của bạn. Bạn cũng đã tìm hiểu cách thiết lập và sử dụng truy vấn trực tiếp Dịch vụ OpenSearch với tính năng Amazon S3 (xem trước) để truy vấn dữ liệu từ kho dữ liệu của bạn.

Để chọn mẫu kiến ​​trúc phù hợp cho khối lượng công việc của bạn khi sử dụng Dịch vụ OpenSearch trên quy mô lớn, hãy xem xét mức tăng trưởng về hiệu suất, độ trễ, chi phí và khối lượng dữ liệu theo thời gian để đưa ra quyết định đúng đắn.

• Sử dụng kiến ​​trúc lưu trữ theo tầng với các chính sách Quản lý trạng thái chỉ mục khi bạn cần truy cập nhanh vào dữ liệu nóng của mình và muốn cân bằng chi phí cũng như hiệu suất với các nút UltraWarm cho dữ liệu chỉ đọc.
• Sử dụng Nhập theo yêu cầu dữ liệu của bạn vào Dịch vụ OpenSearch khi bạn có thể chấp nhận độ trễ nhập để truy vấn dữ liệu không được giữ lại trong các nút nóng của bạn. Bạn có thể tiết kiệm đáng kể chi phí khi sử dụng dữ liệu nén trong Amazon S3 và nhập dữ liệu theo yêu cầu vào Dịch vụ OpenSearch.
• Sử dụng Truy vấn trực tiếp với tính năng S3 khi bạn muốn phân tích trực tiếp nhật ký hoạt động của mình trong Amazon S3 bằng các tính năng trực quan và phân tích phong phú của Dịch vụ OpenSearch.

Bước tiếp theo, hãy tham khảo Hướng dẫn dành cho nhà phát triển Amazon OpenSearch để khám phá nhật ký và đường dẫn số liệu mà bạn có thể sử dụng để xây dựng giải pháp khả năng quan sát có thể mở rộng cho các ứng dụng doanh nghiệp của mình.

Về các tác giả

Jagadish Kumar (Jag) là Kiến trúc sư giải pháp chuyên môn cao cấp tại AWS tập trung vào Dịch vụ tìm kiếm mở của Amazon. Anh ấy rất đam mê Kiến trúc dữ liệu và giúp khách hàng xây dựng các giải pháp phân tích trên quy mô lớn trên AWS.

Muthu Pitchaimani là Kiến trúc sư giải pháp chuyên môn cao cấp của Dịch vụ tìm kiếm mở của Amazon. Ông xây dựng các ứng dụng và giải pháp tìm kiếm quy mô lớn. Muthu quan tâm đến các chủ đề về mạng và bảo mật và có trụ sở tại Austin, Texas.

Sam Selvan là Kiến trúc sư giải pháp chuyên môn chính của Dịch vụ Amazon OpenSearch.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
• PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
• PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
• nguồn: https://aws.amazon.com/blogs/big-data/petabyte-scale-log-analytics-with-amazon-s3-amazon-opensearch-service-and-amazon-opensearch-ingestion/