GALAXY TECH
Chuyên gia Công nghệ
Thứ sáu, 28/10/2016 | 00:00 GMT+7

Hadoop, Storm, Samza, Spark và Flink: So sánh các khung dữ liệu lớn

Dữ liệu lớn là một thuật ngữ chung để chỉ các chiến lược và công nghệ phi truyền thống cần thiết để thu thập, tổ chức, xử lý và thu thập thông tin chi tiết từ các tập dữ liệu lớn. Mặc dù vấn đề làm việc với dữ liệu vượt quá khả năng tính toán hoặc khả năng lưu trữ của một máy tính không phải là mới, nhưng sức lan tỏa, quy mô và giá trị của loại máy tính này đã mở rộng rất nhiều trong những năm gần đây.

Trong hướng dẫn trước, ta đã thảo luận về một số khái niệm chung, các giai đoạn xử lý và thuật ngữ được sử dụng trong hệ thống dữ liệu lớn . Trong bài viết này, ta sẽ xem xét một trong những thành phần thiết yếu nhất của hệ thống dữ liệu lớn: framework. Các framework tính toán dữ liệu trong hệ thống, bằng cách đọc từ bộ nhớ không bay hơi hoặc khi nó được nhập vào hệ thống. Tính toán qua dữ liệu là quá trình extract thông tin và cái nhìn sâu sắc từ số lượng lớn các điểm dữ liệu riêng lẻ.

Ta sẽ đề cập đến các khuôn khổ sau:

Framework dữ liệu lớn là gì?

Các framework và công cụ xử lý chịu trách nhiệm tính toán dữ liệu trong hệ thống dữ liệu. Mặc dù không có định nghĩa có thẩm quyền nào đặt ra ngoài “động cơ” khỏi “khuôn khổ”, nhưng đôi khi sẽ hữu ích khi xác định cái trước là thành phần thực tế chịu trách nhiệm hoạt động trên dữ liệu và cái sau là một tập hợp các thành phần được thiết kế để làm việc tương tự.

Ví dụ, Apache Hadoop có thể được coi là một framework với MapReduce là công cụ xử lý mặc định của nó. Các động cơ và khuôn khổ thường có thể được swap hoặc sử dụng song song. Ví dụ, Apache Spark , một khung công tác khác, có thể kết nối với Hadoop để thay thế MapReduce. Khả năng tương tác giữa các thành phần này là một lý do mà hệ thống dữ liệu lớn có tính linh hoạt cao.

Mặc dù các hệ thống xử lý giai đoạn này của vòng đời dữ liệu có thể phức tạp, nhưng các mục tiêu ở cấp độ rộng lại rất giống nhau: vận hành trên dữ liệu để tăng cường hiểu biết, các mẫu bề mặt và hiểu sâu hơn về các tương tác phức tạp.

Để đơn giản hóa việc thảo luận về các thành phần này, ta sẽ group các framework này theo trạng thái dữ liệu mà chúng được thiết kế để xử lý. Một số hệ thống xử lý dữ liệu theo lô, trong khi những hệ thống khác xử lý dữ liệu theo dòng liên tục khi nó chảy vào hệ thống. Vẫn có những người khác có thể xử lý dữ liệu theo một trong hai cách này.

Ta sẽ giới thiệu từng loại xử lý dưới dạng khái niệm trước khi đi sâu vào các chi tiết cụ thể và hậu quả của các cách triển khai khác nhau.

Hệ thống xử lý hàng loạt

Xử lý hàng loạt có một lịch sử lâu đời trong thế giới dữ liệu lớn. Xử lý hàng loạt liên quan đến việc vận hành trên một tập dữ liệu tĩnh, lớn và trả lại kết quả sau đó khi quá trình tính toán hoàn tất.

Các tập dữ liệu trong quá trình xử lý hàng loạt thường…

  • bị ràng buộc: bộ dữ liệu hàng loạt đại diện cho một bộ sưu tập dữ liệu hữu hạn
  • liên tục: dữ liệu hầu như luôn được backup bằng một số loại lưu trữ vĩnh viễn
  • lớn: hoạt động hàng loạt thường là lựa chọn duy nhất để xử lý các tập dữ liệu cực lớn

Xử lý hàng loạt rất phù hợp cho các tính toán yêu cầu quyền truy cập vào một bộ profile hoàn chỉnh. Ví dụ: khi tính toán tổng và trung bình, tập dữ liệu phải được xử lý một cách tổng thể thay vì như một tập hợp các bản ghi riêng lẻ.Các hoạt động này yêu cầu trạng thái đó được duy trì trong suốt thời gian tính toán.

Các việc yêu cầu data volumes rất lớn thường được xử lý tốt nhất bằng các hoạt động hàng loạt. Cho dù tập dữ liệu được xử lý trực tiếp từ bộ lưu trữ vĩnh viễn hay được tải vào bộ nhớ, các hệ thống hàng loạt được xây dựng với số lượng lớn và có đủ tài nguyên để xử lý chúng. Bởi vì xử lý hàng loạt vượt trội trong việc xử lý dung lượng lớn dữ liệu liên tục, nó thường được sử dụng với dữ liệu lịch sử.

Đánh đổi để xử lý số lượng lớn dữ liệu là thời gian tính toán lâu hơn. Do đó, xử lý hàng loạt không thích hợp trong các tình huống mà thời gian xử lý đặc biệt quan trọng.

Apache Hadoop

Apache Hadoop là một framework độc quyền cung cấp xử lý hàng loạt. Hadoop là khuôn khổ dữ liệu lớn đầu tiên đạt được sức hút đáng kể trong cộng đồng nguồn mở. Dựa trên một số bài báo và bài thuyết trình của Google về cách họ xử lý lượng dữ liệu khổng lồ vào thời điểm đó, Hadoop đã hoàn thiện lại các thuật toán và ngăn xếp thành phần để giúp xử lý hàng loạt quy mô lớn dễ tiếp cận hơn.

Các version hiện đại của Hadoop bao gồm một số thành phần hoặc lớp, hoạt động cùng nhau để xử lý dữ liệu hàng loạt:

  • HDFS : HDFS là lớp hệ thống file phân tán điều phối việc lưu trữ và nhân rộng trên các node cụm. HDFS đảm bảo dữ liệu vẫn có sẵn mặc dù không thể tránh khỏi lỗi server . Nó được sử dụng làm nguồn dữ liệu, để lưu trữ các kết quả xử lý trung gian và lưu giữ các kết quả được tính toán cuối cùng.
  • YARN : YARN, viết tắt của Yet Another Resource Negotiator, là thành phần điều phối cụm của ngăn xếp Hadoop. Nó chịu trách nhiệm điều phối và quản lý các tài nguyên cơ bản và lập lịch trình cho các công việc được thực hiện. YARN làm cho nó có thể chạy nhiều dung lượng công việc đa dạng hơn trên một cụm Hadoop so với khả năng có thể trong các lần lặp trước đó bằng cách hoạt động như một giao diện cho các tài nguyên cụm.
  • MapReduce : MapReduce là công cụ xử lý hàng loạt root của Hadoop.

Mô hình xử lý hàng loạt

Chức năng xử lý của Hadoop đến từ công cụ MapReduce. Kỹ thuật xử lý của MapReduce tuân theo bản đồ, xáo trộn, giảm thuật toán bằng cách sử dụng các cặp key-value . Thủ tục cơ bản bao gồm:

  • Đọc tập dữ liệu từ hệ thống file HDFS
  • Chia tập dữ liệu thành nhiều phần và phân phối giữa các node có sẵn
  • Áp dụng tính toán trên mỗi nút cho tập hợp con dữ liệu (kết quả trung gian được ghi trở lại HDFS)
  • Phân phối lại các kết quả trung gian để group theo khóa
  • "Giảm" giá trị của từng khóa bằng cách tóm tắt và kết hợp các kết quả được tính toán bởi các node riêng lẻ
  • Ghi kết quả cuối cùng được tính toán trở lại HDFS

Ưu điểm và Hạn chế

Bởi vì phương pháp này tận dụng nhiều khả năng lưu trữ vĩnh viễn, đọc và ghi nhiều lần cho mỗi tác vụ, nó có xu hướng khá chậm. Mặt khác, vì không gian đĩa thường là một trong những tài nguyên server dồi dào nhất, điều đó nghĩa là MapReduce có thể xử lý các bộ dữ liệu khổng lồ. Điều này cũng nghĩa là MapReduce của Hadoop thường có thể chạy trên phần cứng rẻ hơn so với một số lựa chọn thay thế vì nó không cố gắng lưu trữ mọi thứ trong bộ nhớ. MapReduce có tiềm năng mở rộng đáng kinh ngạc và đã được sử dụng trong production trên hàng chục nghìn nút.

Là một mục tiêu để phát triển, MapReduce được biết đến là có một đường cong học tập khá dốc.Các bổ sung khác cho hệ sinh thái Hadoop có thể làm giảm tác động của điều này ở các mức độ khác nhau, nhưng nó vẫn có thể là một yếu tố giúp nhanh chóng triển khai ý tưởng trên một cụm Hadoop.

Hadoop có một hệ sinh thái rộng lớn, với chính cụm Hadoop thường được sử dụng như một khối xây dựng cho phần mềm khác. Nhiều công cụ và framework khác có tích hợp Hadoop để sử dụng HDFS và trình quản lý tài nguyên YARN.

Tóm lược

Apache Hadoop và công cụ xử lý MapReduce của nó cung cấp một mô hình xử lý hàng loạt đã được thử nghiệm tốt, phù hợp nhất để xử lý các tập dữ liệu rất lớn trong đó thời gian không phải là yếu tố quan trọng. Chi phí thấp của các thành phần cần thiết cho một cụm Hadoop hoạt động tốt làm cho việc xử lý này không tốn kém và hiệu quả đối với nhiều trường hợp sử dụng. Khả năng tương thích và tích hợp với các khung và công cụ khác nghĩa là Hadoop thường có thể đóng role là nền tảng cho nhiều dung lượng công việc xử lý bằng cách sử dụng công nghệ đa dạng.

Hệ thống xử lý stream

Hệ thống xử lý stream tính toán dữ liệu khi nó xâm nhập vào hệ thống. Điều này yêu cầu một mô hình xử lý khác với mô hình lô. Thay vì xác định các hoạt động để áp dụng cho toàn bộ tập dữ liệu, bộ xử lý stream xác định các hoạt động sẽ được áp dụng cho từng mục dữ liệu riêng lẻ khi nó đi qua hệ thống.

Các tập dữ liệu trong quá trình xử lý stream được coi là "không bị ràng buộc". Điều này có một số ý nghĩa quan trọng:

  • Tập dữ liệu tổng chỉ được định nghĩa là lượng dữ liệu đã vào hệ thống cho đến nay.
  • Tập dữ liệu hoạt động có lẽ phù hợp hơn và được giới hạn cho một mục duy nhất tại một thời điểm.
  • Quá trình xử lý dựa trên sự kiện và không "kết thúc" cho đến khi dừng một cách rõ ràng. Kết quả có sẵn ngay lập tức và sẽ được cập nhật liên tục khi có dữ liệu mới.

Hệ thống xử lý stream có thể xử lý một lượng dữ liệu gần như không giới hạn, nhưng chúng chỉ xử lý một (xử lý stream thực) hoặc rất ít mục (xử lý theo lô vi mô) tại một thời điểm, với trạng thái tối thiểu được duy trì giữa các bản ghi. Trong khi hầu hết các hệ thống cung cấp các phương pháp duy trì một số trạng thái, xử lý hơi nước được tối ưu hóa cao để xử lý nhiều chức năng hơn với ít tác dụng phụ.

Các hoạt động chức năng tập trung vào các bước rời rạc có trạng thái hạn chế hoặc tác dụng phụ. Thực hiện cùng một thao tác trên cùng một phần dữ liệu sẽ tạo ra cùng một kết quả độc lập với các yếu tố khác. Loại xử lý này rất phù hợp với các stream vì trạng thái giữa các mục thường là một số kết hợp khó, hạn chế và đôi khi không mong muốn. Vì vậy, mặc dù một số loại hình quản lý nhà nước thường có thể thực hiện được, nhưng các khuôn khổ này đơn giản và hiệu quả hơn nhiều khi không có chúng.

Loại xử lý này cho vay một số loại dung lượng công việc nhất định. Việc xử lý với các yêu cầu gần thời gian thực được mô hình phát trực tuyến đáp ứng tốt. Phân tích, ghi log lỗi server hoặc ứng dụng và các chỉ số dựa trên thời gian khác là phù hợp tự nhiên vì phản ứng với những thay đổi trong các lĩnh vực này có thể rất quan trọng đối với các chức năng kinh doanh. Xử lý stream phù hợp tốt với dữ liệu nơi bạn phải phản ứng với các thay đổi hoặc mức tăng đột biến và nơi bạn quan tâm đến xu hướng theo thời gian.

Bão Apache

Apache Storm là một framework stream tập trung vào độ trễ cực thấp và có lẽ là lựa chọn tốt nhất cho các dung lượng công việc yêu cầu xử lý gần thời gian thực.Nó có thể xử lý số lượng rất lớn dữ liệu và cung cấp kết quả với độ trễ ít hơn các giải pháp khác.

Mô hình xử lý stream

Xử lý dòng bão hoạt động bằng cách sắp xếp các DAG (Đồ thị vòng được hướng dẫn) trong một khuôn khổ mà nó gọi là cấu trúc liên kết . Các cấu trúc liên kết này mô tả các bước chuyển đổi hoặc các bước khác nhau sẽ được thực hiện trên mỗi phần dữ liệu đến khi nó đi vào hệ thống.

Các cấu trúc liên kết bao gồm:

  • Luồng : Luồng dữ liệu thông thường. Đây là dữ liệu không bị ràng buộc liên tục đến hệ thống.
  • Vòi phun : Nguồn stream dữ liệu ở rìa của cấu trúc liên kết. Đây có thể là các API, hàng đợi, v.v. tạo ra dữ liệu để vận hành.
  • Bu lông : Bu lông đại diện cho một bước xử lý tiêu thụ các stream , áp dụng một hoạt động cho chúng và xuất kết quả dưới dạng một stream . Các bu lông được kết nối với mỗi vòi, sau đó kết nối với nhau để sắp xếp tất cả các quá trình xử lý cần thiết. Ở phần cuối của cấu trúc liên kết, kết quả bu lông cuối cùng được dùng làm đầu vào cho hệ thống được kết nối.

Ý tưởng đằng sau Storm là xác định các hoạt động nhỏ, rời rạc bằng cách sử dụng các thành phần trên và sau đó biên soạn chúng thành một cấu trúc liên kết. Theo mặc định, Storm cung cấp bảo đảm xử lý ít nhất một lần, nghĩa là nó có thể đảm bảo mỗi thư được xử lý ít nhất một lần, nhưng có thể có các bản sao trong một số trường hợp lỗi. Storm không đảm bảo các tin nhắn sẽ được xử lý theo thứ tự.

Để đạt được chính xác một lần, xử lý trạng thái, một phép trừu tượng gọi là Trident cũng có sẵn. Nói một cách rõ ràng, Storm không có Trident thường được gọi là Core Storm . Trident thay đổi đáng kể động lực xử lý của Storm, tăng độ trễ, thêm trạng thái vào quá trình xử lý và triển khai mô hình phân phối vi mô thay vì hệ thống phát trực tuyến thuần túy từng mục.

User Storm thường khuyên bạn nên sử dụng Core Storm khi nào có thể để tránh những hình phạt đó. Với suy nghĩ đó, việc đảm bảo xử lý các mục chính xác một lần của Trident rất hữu ích trong các trường hợp hệ thống không thể xử lý các thông báo trùng lặp một cách thông minh. Trident cũng là lựa chọn duy nhất trong Storm khi bạn cần duy trì trạng thái giữa các mục, như khi đếm số lượng user nhấp vào liên kết trong vòng một giờ. Trident mang lại cho Storm sự linh hoạt, mặc dù nó không phát huy hết sức mạnh tự nhiên của khung.

Các cấu trúc liên kết đinh ba bao gồm:

  • Luồng stream : Đây là các lô dữ liệu stream vi mô được chia nhỏ để cung cấp ngữ nghĩa xử lý hàng loạt.
  • Hoạt động : Đây là các thủ tục hàng loạt có thể được thực hiện trên dữ liệu.

Ưu điểm và Hạn chế

Storm có lẽ là giải pháp tốt nhất hiện có để xử lý gần thời gian thực. Nó có thể xử lý dữ liệu với độ trễ cực thấp cho dung lượng công việc phải được xử lý với độ trễ tối thiểu. Storm thường là một lựa chọn tốt khi thời gian xử lý ảnh hưởng trực tiếp đến trải nghiệm user , chẳng hạn như khi phản hồi từ quá trình xử lý được đưa trực tiếp trở lại trang của khách truy cập trên trang web.

Storm with Trident cung cấp cho bạn tùy chọn sử dụng các lô nhỏ thay vì xử lý theo stream thuần túy. Mặc dù điều này mang lại cho user sự linh hoạt hơn trong việc định hình công cụ theo mục đích sử dụng, nhưng nó cũng có xu hướng phủ nhận một số ưu điểm lớn nhất của phần mềm so với các giải pháp khác.Điều đó đang được nói, có một lựa chọn cho phong cách xử lý stream vẫn hữu ích.

Core Storm không cung cấp bảo đảm đặt hàng cho các tin nhắn. Core Storm cung cấp bảo đảm xử lý ít nhất một lần, nghĩa là việc xử lý từng thông báo có thể được đảm bảo nhưng có thể xảy ra trùng lặp. Trident cung cấp đảm bảo chính xác một lần và có thể cung cấp đặt hàng giữa các lô, nhưng không phải trong vòng.

Về khả năng tương tác, Storm có thể tích hợp với trình thương lượng tài nguyên YARN của Hadoop, giúp dễ dàng kết nối với triển khai Hadoop hiện có. Hơn hầu hết các khuôn khổ xử lý, Storm có hỗ trợ ngôn ngữ rất rộng, mang đến cho user nhiều tùy chọn để xác định cấu trúc liên kết.

Tóm lược

Đối với dung lượng công việc xử lý stream thuần túy với các yêu cầu về độ trễ rất nghiêm ngặt, Storm có lẽ là lựa chọn hoàn thiện tốt nhất. Nó có thể đảm bảo xử lý tin nhắn và được dùng với một số lượng lớn các ngôn ngữ lập trình. Bởi vì Storm không xử lý hàng loạt, bạn sẽ phải sử dụng phần mềm bổ sung nếu bạn yêu cầu những khả năng đó. Nếu bạn có nhu cầu cao về đảm bảo xử lý chính xác một lần, Trident có thể cung cấp điều đó. Tuy nhiên, các framework stream khác cũng có thể phù hợp hơn vào thời điểm đó.

Apache Samza

Apache Samza là một framework stream được liên kết chặt chẽ với hệ thống nhắn tin Apache Kafka. Trong khi Kafka được dùng bởi nhiều hệ thống xử lý stream , Samza được thiết kế đặc biệt để tận dụng kiến trúc độc đáo và đảm bảo của Kafka. Nó sử dụng Kafka để cung cấp khả năng chịu lỗi, cache và lưu trữ trạng thái.

Samza sử dụng YARN để thương lượng tài nguyên. Điều này nghĩa là theo mặc định, cần có một cụm Hadoop (ít nhất là HDFS và YARN), nhưng điều đó cũng nghĩa là Samza có thể dựa vào các tính năng phong phú được tích hợp trong YARN.

Mô hình xử lý stream

Samza dựa vào ngữ nghĩa của Kafka để xác định cách xử lý stream . Kafka sử dụng các khái niệm sau khi xử lý dữ liệu:

  • Chủ đề : Mỗi stream dữ liệu đi vào hệ thống Kafka được gọi là một chủ đề. Chủ đề về cơ bản là một stream thông tin liên quan mà người tiêu dùng có thể đăng ký.
  • Phân vùng : Để phân phối chủ đề giữa các node, Kafka chia các tin nhắn đến thành các phân vùng. Việc phân chia phân vùng dựa trên một khóa sao cho mỗi thông báo có cùng khóa được đảm bảo gửi đến cùng một phân vùng. Các phần có thứ tự đảm bảo.
  • Các nhà broker : Các node riêng lẻ tạo thành một cụm Kafka được gọi là các nhà broker .
  • Nhà production : Bất kỳ thành phần nào viết về chủ đề Kafka đều được gọi là nhà production . Nhà production cung cấp khóa được sử dụng để phân vùng một chủ đề.
  • Người tiêu dùng : Người tiêu dùng là bất kỳ thành phần nào đọc từ một chủ đề Kafka. Người tiêu dùng có trách nhiệm duy trì thông tin về phần bù của chính họ, để họ biết profile nào đã được xử lý nếu xảy ra lỗi.

Vì Kafka đại diện cho một bản ghi bất biến, Samza xử lý các stream bất biến. Điều này nghĩa là bất kỳ phép biến đổi nào cũng tạo ra các stream mới được các thành phần khác sử dụng mà không ảnh hưởng đến stream ban đầu.

Ưu điểm và Hạn chế

Việc Samza dựa vào hệ thống xếp hàng giống Kafka thoạt nhìn có vẻ hạn chế.Tuy nhiên, nó cung cấp cho hệ thống một số đảm bảo và tính năng độc đáo không phổ biến trong các hệ thống xử lý stream khác.

Ví dụ: Kafka đã cung cấp khả năng lưu trữ sao chép dữ liệu có thể được truy cập với độ trễ thấp. Nó cũng cung cấp một mô hình nhiều người đăng ký rất dễ dàng và không tốn kém cho từng phân vùng dữ liệu riêng lẻ. Tất cả kết quả , bao gồm cả kết quả trung gian, cũng được ghi vào Kafka và có thể được tiêu thụ độc lập bởi các công đoạn hạ nguồn.

Theo nhiều cách, dependencies chặt chẽ vào Kafka này phản ánh cách mà công cụ MapReduce thường tham chiếu đến HDFS. Trong khi việc tham chiếu HDFS giữa mỗi phép tính dẫn đến một số vấn đề hiệu suất nghiêm trọng khi xử lý hàng loạt, nó giải quyết một số vấn đề khi xử lý stream .

Mối quan hệ bền chặt của Samza với Kafka cho phép bản thân các bước xử lý được gắn với nhau rất lỏng lẻo. Một số lượng người đăng ký tùy ý có thể được thêm vào kết quả của bất kỳ bước nào mà không cần điều phối trước. Điều này có thể rất hữu ích cho các tổ chức nơi nhiều group có thể cần truy cập vào dữ liệu tương tự. Tất cả các đội đều có thể đăng ký chủ đề nhập dữ liệu vào hệ thống, hoặc có thể dễ dàng đăng ký chủ đề do các đội khác tạo ra đã trải qua một số xử lý. Điều này có thể được thực hiện mà không gây thêm căng thẳng cho cơ sở hạ tầng nhạy cảm với tải như database .

Viết thư thẳng cho Kafka cũng giúp loại bỏ các vấn đề về áp suất ngược . Áp suất ngược là khi tải trọng tăng đột biến gây ra dòng dữ liệu lớn hơn tốc độ các thành phần có thể xử lý trong thời gian thực, dẫn đến ngừng xử lý và có khả năng mất dữ liệu. Kafka được thiết kế để lưu giữ dữ liệu trong thời gian rất dài, nghĩa là các thành phần có thể xử lý thuận tiện và có thể khởi động lại mà không gây hậu quả.

Samza có thể lưu trữ trạng thái, sử dụng hệ thống điểm kiểm tra chịu được lỗi được triển khai như một repository giá trị-khóa local . Điều này cho phép Samza cung cấp bảo đảm phân phối ít nhất một lần, nhưng nó không cung cấp khả năng khôi phục chính xác trạng thái tổng hợp (như số lượng) trong trường hợp bị lỗi vì dữ liệu có thể được phân phối nhiều lần.

Samza cung cấp các bản tóm tắt cấp cao theo nhiều cách dễ làm việc hơn so với các bản root được cung cấp bởi các hệ thống như Storm. Samza chỉ hỗ trợ ngôn ngữ JVM tại thời điểm này, nghĩa là nó không có tính linh hoạt về ngôn ngữ như Storm.

Tóm lược

Apache Samza là một lựa chọn tốt để phát trực tuyến dung lượng công việc trong đó Hadoop và Kafka đã có sẵn hoặc hợp lý để triển khai. Bản thân Samza rất phù hợp cho các tổ chức có nhiều group sử dụng (nhưng không nhất thiết phải phối hợp chặt chẽ với nhau) các stream dữ liệu ở các giai đoạn xử lý khác nhau. Samza đơn giản hóa nhiều phần của quá trình xử lý stream và cung cấp hiệu suất độ trễ thấp. Nó có thể không phù hợp nếu các yêu cầu triển khai không tương thích với hệ thống hiện tại của bạn, nếu bạn cần xử lý độ trễ cực thấp hoặc nếu bạn có nhu cầu cao về ngữ nghĩa chính xác một lần.

Hệ thống xử lý hỗn hợp: Bộ xử lý hàng loạt và dòng

Một số framework có thể xử lý cả dung lượng công việc hàng loạt và dòng. Các khuôn khổ này đơn giản hóa các yêu cầu xử lý đa dạng bằng cách cho phép các thành phần và API giống nhau hoặc có liên quan được sử dụng cho cả hai loại dữ liệu.

Như bạn sẽ thấy, cách thức đạt được điều này khác nhau đáng kể giữa Spark và Flink, hai khuôn khổ ta sẽ thảo luận. Đây chủ yếu là một chức năng về cách hai mô hình xử lý được kết hợp với nhau và những giả định nào được thực hiện về mối quan hệ giữa tập dữ liệu cố định và không cố định.

Trong khi các dự án tập trung vào một kiểu xử lý có thể phù hợp nhất với các trường hợp sử dụng cụ thể, thì các khuôn khổ kết hợp cố gắng đưa ra một giải pháp chung để xử lý dữ liệu. Họ không chỉ cung cấp các phương pháp xử lý dữ liệu mà còn có các tích hợp, thư viện và công cụ riêng để thực hiện những việc như phân tích đồ thị, học máy và truy vấn tương tác.

Apache Spark

Apache Spark là một framework hàng loạt thế hệ tiếp theo với khả năng xử lý stream . Được xây dựng bằng cách sử dụng nhiều nguyên tắc giống nhau của công cụ MapReduce của Hadoop, Spark chủ yếu tập trung vào việc tăng tốc dung lượng công việc xử lý hàng loạt bằng cách cung cấp tính toán đầy đủ trong bộ nhớ và tối ưu hóa xử lý.

Spark có thể được triển khai dưới dạng một cụm độc lập (nếu được ghép nối với lớp lưu trữ có khả năng) hoặc có thể kết nối với Hadoop như một sự thay thế cho công cụ MapReduce.

Mô hình xử lý hàng loạt

Không giống như MapReduce, Spark xử lý tất cả dữ liệu trong bộ nhớ, chỉ tương tác với lớp lưu trữ để tải dữ liệu ban đầu vào bộ nhớ và cuối cùng để duy trì kết quả cuối cùng. Tất cả các kết quả trung gian được quản lý trong bộ nhớ.

Trong khi xử lý trong bộ nhớ đóng góp đáng kể vào tốc độ, Spark cũng nhanh hơn đối với các việc liên quan đến đĩa do tối ưu hóa toàn diện có thể đạt được bằng cách phân tích tập hợp hoàn chỉnh các việc trước thời hạn. Nó đạt được điều này bằng cách tạo Đồ thị vòng có hướng hoặc DAG đại diện cho tất cả các hoạt động phải được thực hiện, dữ liệu được vận hành, cũng như các mối quan hệ giữa chúng, mang lại cho bộ xử lý khả năng điều phối công việc một cách thông minh hơn.

Để thực hiện tính toán hàng loạt trong bộ nhớ, Spark sử dụng một mô hình được gọi là Bộ dữ liệu phân tán có khả năng phục hồi, hoặc RDD , để làm việc với dữ liệu. Đây là những cấu trúc bất biến tồn tại trong bộ nhớ đại diện cho các tập hợp dữ liệu. Các hoạt động trên RDD tạo ra RDD mới. Mỗi RDD có thể theo dõi dòng dõi của nó trở lại thông qua các RDD mẹ của nó và cuối cùng là dữ liệu trên đĩa. Về cơ bản, RDD là một cách để Spark duy trì khả năng chịu lỗi mà không cần ghi lại vào đĩa sau mỗi lần hoạt động.

Mô hình xử lý stream

Khả năng xử lý stream được cung cấp bởi Spark Streaming. Bản thân Spark được thiết kế với dung lượng công việc theo định hướng hàng loạt. Để đối phó với sự khác biệt giữa thiết kế động cơ và các đặc điểm của dung lượng công việc trực tuyến, Spark triển khai một khái niệm gọi là lô vi mô *. Chiến lược này được thiết kế để coi các stream dữ liệu là một chuỗi các lô rất nhỏ có thể được xử lý bằng cách sử dụng ngữ nghĩa root của công cụ lô.

Spark Streaming hoạt động bằng cách đệm stream theo từng bước nhỏ hơn giây. Chúng được gửi dưới dạng tập dữ liệu cố định nhỏ để xử lý hàng loạt. Trong thực tế, điều này hoạt động khá tốt, nhưng nó dẫn đến một profile hiệu suất khác với các framework stream thực sự.

Ưu điểm và Hạn chế

Lý do rõ ràng để sử dụng Spark trên Hadoop MapReduce là tốc độ.Spark có thể xử lý cùng một bộ dữ liệu nhanh hơn đáng kể do chiến lược tính toán trong bộ nhớ và lập lịch DAG nâng cao của nó.

Một trong những lợi thế lớn khác của Spark là tính linh hoạt của nó. Nó có thể được triển khai như một cụm độc lập hoặc tích hợp với một cụm Hadoop hiện có. Nó có thể thực hiện cả xử lý hàng loạt và stream , cho phép bạn vận hành một cụm duy nhất để xử lý nhiều kiểu xử lý.

Ngoài khả năng của chính engine, Spark còn có một hệ sinh thái các thư viện được dùng cho máy học, các truy vấn tương tác, v.v. Các việc Spark hầu như được thừa nhận là dễ viết hơn MapReduce, điều này có thể có ý nghĩa đáng kể đối với năng suất.

Việc điều chỉnh phương pháp theo lô để xử lý stream liên quan đến việc đệm dữ liệu khi dữ liệu đi vào hệ thống. Cache cho phép nó xử lý một dung lượng lớn dữ liệu đến, tăng thông lượng tổng thể, nhưng việc chờ đợi để làm sạch cache cũng dẫn đến sự gia tăng đáng kể độ trễ. Điều này nghĩa là Spark Streaming có thể không thích hợp để xử lý khi bắt buộc phải có độ trễ thấp.

Vì RAM thường đắt hơn dung lượng đĩa, nên Spark có thể tốn nhiều chi phí để chạy hơn các hệ thống dựa trên đĩa. Tuy nhiên, tốc độ xử lý tăng lên nghĩa là các việc có thể hoàn thành nhanh hơn nhiều, điều này có thể bù đắp hoàn toàn chi phí khi hoạt động trong môi trường mà bạn phải trả tiền cho tài nguyên hàng giờ.

Một hệ quả khác của thiết kế trong bộ nhớ của Spark là sự khan hiếm tài nguyên có thể là một vấn đề khi triển khai trên các cụm chia sẻ. So với MapReduce của Hadoop, Spark sử dụng nhiều tài nguyên hơn đáng kể, có thể ảnh hưởng đến các việc khác có thể đang cố gắng sử dụng cụm vào thời điểm đó. Về bản chất, Spark có thể là một người hàng xóm kém quan tâm hơn các thành phần khác có thể hoạt động trên ngăn xếp Hadoop.

Tóm lược

Spark là một lựa chọn tuyệt vời cho những người có dung lượng công việc xử lý đa dạng. Xử lý hàng loạt Spark mang lại lợi thế tốc độ đáng kinh ngạc, đánh đổi mức sử dụng bộ nhớ cao. Spark Streaming là một giải pháp xử lý stream tốt cho các dung lượng công việc coi trọng thông lượng hơn độ trễ.

Apache Flink là một framework stream cũng có thể xử lý các việc hàng loạt. Nó coi các lô chỉ đơn giản là các stream dữ liệu có ranh giới hữu hạn và do đó coi xử lý theo lô như một tập con của xử lý stream . Phương pháp tiếp cận đầu tiên đối với tất cả quá trình xử lý này có một số tác dụng phụ thú vị.

Phương pháp tiếp cận stream đầu tiên này được gọi là kiến trúc Kappa , trái ngược với kiến trúc Lambda được biết đến rộng rãi hơn (trong đó việc phân lô được sử dụng làm phương pháp xử lý chính với các stream được sử dụng để bổ sung và cung cấp kết quả sớm nhưng chưa tinh chế). Kiến trúc Kappa, nơi các stream được sử dụng cho mọi thứ, đơn giản hóa mô hình và chỉ gần đây mới trở nên khả thi khi các công cụ xử lý stream ngày càng phức tạp hơn.

Mô hình xử lý stream

Mô hình xử lý stream của Flink xử lý dữ liệu đến trên cơ sở từng mục như một stream thực. Flink cung cấp API DataStream của nó để hoạt động với các stream dữ liệu không bị ràng buộc. Các thành phần cơ bản mà Flink hoạt động là:

  • Luồng là tập dữ liệu bất biến, không bị ràng buộc, chạy qua hệ thống
  • Toán tử là các hàm hoạt động trên các stream dữ liệu để tạo ra các stream khác
  • Nguồn là điểm đầu vào cho các stream đi vào hệ thống
  • Chậu rửa là nơi có các dòng chảy ra khỏi hệ thống Flink.Chúng có thể đại diện cho một database hoặc một trình kết nối với một hệ thống khác

Các việc xử lý stream sẽ chụp nhanh tại các điểm đã đặt trong quá trình tính toán của chúng để sử dụng cho việc khôi phục trong trường hợp có sự cố. Đối với trạng thái lưu trữ, Flink có thể hoạt động với một số backend trạng thái tùy thuộc vào mức độ phức tạp và bền bỉ khác nhau.

Ngoài ra, quá trình xử lý stream của Flink có thể hiểu khái niệm “thời gian sự kiện”, nghĩa là thời gian sự kiện thực sự xảy ra và cũng có thể xử lý các phiên. Điều này nghĩa là nó có thể đảm bảo thứ tự và group theo một số cách thú vị.

Mô hình xử lý hàng loạt

Mô hình xử lý hàng loạt của Flink theo nhiều cách chỉ là một phần mở rộng của mô hình xử lý stream . Thay vì đọc từ một stream liên tục, nó đọc một tập dữ liệu bị ràng buộc khỏi bộ nhớ liên tục dưới dạng một stream . Flink sử dụng cùng một thời gian chạy cho cả hai mô hình xử lý này.

Flink cung cấp một số tối ưu hóa cho dung lượng công việc hàng loạt. Ví dụ: vì các hoạt động hàng loạt được hỗ trợ bởi lưu trữ liên tục, Flink loại bỏ tính năng chụp nhanh khỏi tải hàng loạt. Dữ liệu vẫn có thể khôi phục được nhưng quá trình xử lý thông thường sẽ hoàn tất nhanh hơn.

Một tối ưu hóa khác liên quan đến việc chia nhỏ các nhiệm vụ hàng loạt để các giai đoạn và thành phần chỉ được tham gia khi cần thiết. Điều này giúp Flink chơi tốt với những user khác của cụm. Phân tích trước các nhiệm vụ mang lại cho Flink khả năng cũng tối ưu hóa bằng cách xem toàn bộ tập hợp hoạt động, kích thước của tập dữ liệu và yêu cầu của các bước sắp tới.

Ưu điểm và Hạn chế

Flink hiện là một tùy chọn duy nhất trong thế giới framework. Trong khi Spark thực hiện xử lý hàng loạt và stream , stream của nó không thích hợp cho nhiều trường hợp sử dụng vì kiến trúc vi lô của nó. Phương pháp tiếp cận stream đầu tiên của Flink cung cấp độ trễ thấp, thông lượng cao và xử lý từng mục nhập thực.

Flink tự quản lý nhiều thứ. Hơi khác thường, nó quản lý bộ nhớ của chính nó thay vì dựa vào cơ chế thu thập rác Java bản địa vì lý do hiệu suất. Không giống như Spark, Flink không yêu cầu tối ưu hóa và điều chỉnh thủ công khi các đặc tính của dữ liệu mà nó xử lý thay đổi. Nó cũng tự động xử lý phân vùng dữ liệu và bộ nhớ đệm.

Flink phân tích công việc của nó và tối ưu hóa các việc theo một số cách. Một phần của phân tích này tương tự như những gì người lập kế hoạch truy vấn SQL thực hiện trong database mối quan hệ, vạch ra cách hiệu quả nhất để triển khai một nhiệm vụ nhất định. Nó có thể sắp xếp song song các giai đoạn có thể hoàn thành song song, đồng thời tập hợp dữ liệu lại với nhau cho các nhiệm vụ ngăn chặn. Đối với các việc lặp đi lặp lại, Flink cố gắng thực hiện tính toán trên các node nơi dữ liệu được lưu trữ vì lý do hiệu suất. Nó cũng có thể thực hiện "lặp lại delta" hoặc lặp lại chỉ trên các phần dữ liệu có thay đổi.

Về công cụ user , Flink cung cấp chế độ xem lập lịch dựa trên web để dễ dàng quản lý các việc và xem hệ thống. User cũng có thể hiển thị kế hoạch tối ưu hóa cho các nhiệm vụ đã gửi để xem nó sẽ thực sự được triển khai như thế nào trên cụm. Đối với các việc phân tích, Flink cung cấp truy vấn kiểu SQL, xử lý đồ thị và thư viện học máy cũng như tính toán trong bộ nhớ.

Flink hoạt động tốt với các thành phần khác. Nó được viết là một người hàng xóm tốt nếu được sử dụng trong ngăn xếp Hadoop, chỉ chiếm các tài nguyên cần thiết tại bất kỳ thời điểm nào. Nó tích hợp dễ dàng với YARN, HDFS và Kafka. Flink có thể chạy các việc được viết cho các framework khác như Hadoop và Storm với các gói tương thích.

Một trong những hạn chế lớn nhất của Flink ở thời điểm hiện tại là nó vẫn là một dự án còn rất non trẻ. Việc triển khai quy mô lớn trong tự nhiên vẫn không phổ biến như các khuôn khổ xử lý khác và chưa có nhiều nghiên cứu về các hạn chế mở rộng của Flink. Với chu kỳ phát triển nhanh chóng và các tính năng như các gói tương thích, có thể bắt đầu có nhiều triển khai Flink hơn khi các tổ chức có cơ hội thử nghiệm với nó.

Tóm lược

Flink cung cấp cả xử lý stream có độ trễ thấp với sự hỗ trợ cho các việc hàng loạt truyền thống. Flink có lẽ phù hợp nhất cho các tổ chức có yêu cầu xử lý stream nặng và một số tác vụ theo hướng hàng loạt. Khả năng tương thích của nó với các chương trình Storm và Hadoop bản địa cũng như khả năng chạy trên một cụm do YARN quản lý có thể giúp bạn dễ dàng đánh giá. Sự phát triển nhanh chóng của nó khiến nó đáng được để mắt tới.

Kết luận

Có rất nhiều tùy chọn để xử lý trong một hệ thống dữ liệu lớn.

Đối với dung lượng công việc chỉ theo lô không nhạy cảm về thời gian, Hadoop là một lựa chọn tốt có khả năng triển khai ít tốn kém hơn so với một số giải pháp khác.

Đối với dung lượng công việc chỉ phát trực tuyến, Storm có hỗ trợ ngôn ngữ rộng rãi và có thể xử lý độ trễ rất thấp, nhưng có thể phân phối các bản sao và không thể đảm bảo thứ tự trong cấu hình mặc định của nó. Samza tích hợp chặt chẽ với YARN và Kafka để cung cấp tính linh hoạt, dễ dàng sử dụng cho nhiều group , nhân rộng và quản lý nhà nước dễ dàng.

Đối với dung lượng công việc hỗn hợp, Spark cung cấp xử lý hàng loạt tốc độ cao và xử lý hàng loạt vi mô để phát trực tuyến. Nó có hỗ trợ rộng rãi, thư viện tích hợp và công cụ, và tích hợp linh hoạt. Flink cung cấp xử lý stream thực sự với hỗ trợ xử lý hàng loạt. Nó được tối ưu hóa rất nhiều, có thể chạy các việc được viết cho các nền tảng khác và cung cấp xử lý độ trễ thấp, nhưng vẫn đang trong những ngày đầu được áp dụng.

Sự phù hợp nhất với tình huống của bạn sẽ phụ thuộc nhiều vào trạng thái dữ liệu cần xử lý, yêu cầu của bạn bị ràng buộc về thời gian như thế nào và loại kết quả bạn quan tâm. Có sự đánh đổi giữa việc triển khai giải pháp tất cả trong một và làm việc với các dự án tập trung chặt chẽ và có những cân nhắc tương tự khi đánh giá các giải pháp mới và sáng tạo so với các đối tác đã trưởng thành và đã được thử nghiệm tốt của chúng.

Tags:

Các tin liên quan