Giới thiệu

Dữ liệu lớn là thuật ngữ dành cho 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á sức mạnh tính toán hoặc lưu trữ của một máy tính đơn lẻ không phải là mới, sự phổ biến, quy mô và giá trị của loại máy tính này đã mở rộng đáng kể trong những năm gần đây.

Trong một hướng dẫn trước, chúng tôi đã thảo luận một số khái niệm chung, các giai đoạn xử lý và thuật ngữ được sử dụng trong các hệ thống dữ liệu lớn. Trong bài viết này, chúng ta sẽ xem xét một trong những thành phần thiết yếu nhất của một hệ thống dữ liệu lớn: các khung công tác xử lý. Các khung xử lý tính toán dữ liệu trong hệ thống, hoặc 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 trên dữ liệu là quá trình trích xuất thông tin và thông tin chi tiết từ số lượng lớn các điểm dữ liệu riêng lẻ.

Chúng tôi sẽ bao gồm các khuôn khổ sau:

  • Các khung chỉ có hàng loạt:
    • Apache Hadoop
  • Các khung chỉ dành cho luồng:
    • Apache Storm
    • Apache Samza
  • Khung lai:
    • Apache Spark
    • Apache Flink

Khung xử lý dữ liệu lớn là gì?

Khung chế biếnđộng cơ chế biến 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ó thiết lập định nghĩa độc quyền ngoài "động cơ" từ "khung công tác", đôi khi rất hữu ích để xác định nguyên là thành phần thực sự chịu trách nhiệm vận hành trên dữ liệu và sau đó là một bộ thành phần được thiết kế để thực hiện tương tự.

Ví dụ, Apache Hadoop có thể được coi là một khuôn khổ xử lý với MapReduce làm mặc định công cụ chế biến. Động cơ và khung công tác thường có thể được hoán đổi 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 trong những lý do mà các hệ thống dữ liệu lớn có tính linh hoạt cao.

Trong khi 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, các mục tiêu ở mức độ rộng là rất giống nhau: vận hành trên dữ liệu để tăng hiểu biết, mô hình bề mặt và hiểu rõ 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, chúng tôi sẽ nhóm các khung xử lý này theo trạng thái của 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 các hệ thống khác xử lý dữ liệu trong một luồng liên tục khi nó chảy vào hệ thống. Những người khác vẫn có thể xử lý dữ liệu theo một trong hai cách này.

Chúng tôi sẽ giới thiệu từng loại xử lý như một 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 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 dài trong thế giới dữ liệu lớn. Xử lý hàng loạt liên quan đến hoạt động trên một tập dữ liệu lớn, tĩnh và trả về kết quả sau một thời gian khi tính toán hoàn tất.

Các bộ dữ liệu trong xử lý hàng loạt thường là ...

  • bounded: các tập dữ liệu bó đại diện cho một tập hợp dữ liệu hữu hạn
  • liên tục: dữ liệu hầu như luôn được hỗ trợ bởi một số loại bộ nhớ vĩnh viễn
  • lớn: hoạt động theo lô 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 phép tính khi cần truy cập vào bộ bản ghi hoàn chỉnh. Ví dụ, khi tính tổng số và trung bình, bộ dữ liệu phải được xử lý 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 tác vụ yêu cầu khối lượng dữ liệu rất lớn thường được xử lý tốt nhất theo các thao tác theo lô. Cho dù các bộ dữ liệu được xử lý trực tiếp từ lưu trữ vĩnh viễn hoặc được nạp vào bộ nhớ, hệ thống lô được xây dựng với số lượng lớn trong tâm trí và có các nguồn lực để xử lý chúng. Bởi vì xử lý hàng loạt vượt trội tại xử lý khối 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ử.

Sự cân bằng để xử lý một lượng lớn dữ liệu là thời gian tính toán dài hơn. Bởi vì điều này, 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 khung xử lý chuyên cung cấp xử lý hàng loạt. Hadoop là khuôn khổ dữ liệu lớn đầu tiên có được lực kéo đá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 đã thực hiện lại các thuật toán và ngăn xếp thành phần để xử lý hàng loạt quy mô lớn dễ tiếp cận hơn.

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

  • HDFS: HDFS là lớp hệ thống tệp phân tán phối hợp lưu trữ và sao chép trên các nút cụm. HDFS đảm bảo rằng dữ liệu vẫn có sẵn mặc dù các lỗi máy chủ không thể tránh khỏi. Nó được sử dụng như là nguồn dữ liệu, để lưu trữ các kết quả xử lý trung gian và duy trì kết quả 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 phối hợp cụm của ngăn xếp Hadoop. Nó có trách nhiệm điều phối và quản lý các tài nguyên cơ bản và lập kế hoạch công việc để được chạy. YARN làm cho nó có thể chạy nhiều khối lượng công việc đa dạng hơn trên một cụm Hadoop hơn là 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 gốc của Hadoop.

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

Chức năng xử lý của Hadoop xuất phát từ công cụ MapReduce. Kỹ thuật xử lý của MapReduce tuân theo bản đồ, trộn, giảm thuật toán bằng các cặp khóa-giá trị. Quy trình cơ bản bao gồm:

  • Đọc tập dữ liệu từ hệ thống tập tin HDFS
  • Chia bộ dữ liệu thành các phần và phân phối giữa các nút 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 lại cho HDFS)
  • Phân phối lại kết quả trung gian theo nhóm theo khóa
  • "Giảm" giá trị của mỗi khóa bằng cách tóm tắt và kết hợp các kết quả được tính bằng các nút riêng lẻ
  • Viết 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 sử dụng rất nhiều lưu trữ vĩnh viễn, đọc và viết 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 máy chủ phong phú nhất, nó có nghĩa là MapReduce có thể xử lý các tập dữ liệu khổng lồ. Điều này cũng có nghĩa là MapReduce của Hadoop thường có thể chạy trên phần cứng ít tốn kém 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 sản xuất 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 với 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 đến các mức độ khác nhau, nhưng nó vẫn có thể là một yếu tố để nhanh chóng triển khai một ý tưởng về một cụm Hadoop.

Hadoop có một hệ sinh thái rộng lớn, với cụm Hadoop thường được sử dụng như một khối xây dựng cho các phần mềm khác. Nhiều khung công tác và công cụ xử lý 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 kiểm tra tốt, phù hợp nhất cho việc xử lý các tập dữ liệu rất lớn trong đó thời gian không phải là một 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 công cụ và động cơ khác có nghĩa là Hadoop thường có thể phục vụ như là nền tảng cho nhiều khối 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ý luồng

Xử lý luồng hệ thống tính toán dữ liệu khi nó xâm nhập vào hệ thống. Điều này đòi hỏi 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ý luồng 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 bộ dữ liệu trong xử lý luồng được coi là "không bị chặn". Điều này có một vài ý nghĩa quan trọng:

  • Các toàn bộ tập dữ liệu chỉ được định nghĩa là lượng dữ liệu đã nhập vào hệ thống cho đến nay.
  • Các đang làm việc tập dữ liệu có lẽ phù hợp hơn và được giới hạn ở một mục duy nhất tại một thời điểm.
  • Xử lý dựa trên sự kiện và không "kết thúc" cho đến khi dừng lại 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 dữ liệu mới đến.

Các hệ thống xử lý luồng có thể xử lý số 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ý luồng thực) hoặc rất ít (xử lý hàng loạt) một lần, 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, chế biến hơi nước được tối ưu hóa cao để có thêm xử lý chức năng với ít tác dụng phụ.

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

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

Apache Storm

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

Mô hình xử lý luồng

Công nghệ xử lý luồng bão hoạt động bằng cách phối hợp DAG (Đồ thị tuần hoàn hướng) trong khuôn khổ mà nó gọi topo. Các cấu trúc liên kết này mô tả các phép biế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:

  • Dòng: Luồng dữ liệu thông thường. Đây là dữ liệu không bị chặn liên tục đến hệ thống.
  • Vòi: Nguồn luồng 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 được vận hành.
  • Bu lông: Bu lông đại diện cho một bước xử lý tiêu thụ luồng, áp dụng một hoạt động cho chúng và xuất kết quả dưới dạng luồng. Bu lông được kết nối với từng vòi, và sau đó kết nối với nhau để sắp xếp tất cả các xử lý cần thiết. Ở cuối cấu trúc liên kết, đầu ra bu lông cuối cùng có thể được sử dụng làm đầu vào cho một 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 đó 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, có nghĩa là nó có thể đảm bảo rằng mỗi thông báo được xử lý ít nhất một lần, nhưng có thể có bản sao trong một số trường hợp lỗi. Storm không đảm bảo rằng 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 sự trừu tượng được gọi là Trident cũng có sẵn. Để rõ ràng, Storm không có Trident thường được gọi là Cốt lõi. Trident làm thay đổi đáng kể các động thái 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 theo lô vi thay vì một hệ thống phát trực tiếp theo từng mục.

Người dùng Storm thường khuyên bạn nên sử dụng Core Storm bất cứ khi nào có thể để tránh những hình phạt đó. Với ý nghĩ đó, bảo đảm của Trident để xử lý các mục chính xác một lần là hữu ích trong trường hợp hệ thống không thể xử lý thông điệp 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 người dùng nhấp vào liên kết trong vòng một giờ. Trident cho phép tính linh hoạt của Storm, mặc dù nó không chơi theo thế mạnh tự nhiên của khung công tác.

Tract topology bao gồm:

  • Luồng luồng: Đây là những lô vi dữ liệu luồng được phân đoạn để cung cấp ngữ nghĩa xử lý hàng loạt.
  • Hoạt động: Đây là các quy trình lô 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ó sẵn để 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 khối lượng công việc phải được xử lý với độ trễ tối thiểu. Bão thường là lựa chọn tốt khi thời gian xử lý ảnh hưởng trực tiếp đến trải nghiệm người dùng, ví dụ: 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 với Trident cung cấp cho bạn tùy chọn sử dụng các lô vi thay vì xử lý luồng thuần túy. Mặc dù điều này giúp người dùng linh hoạt hơn trong việc định hình công cụ cho mục đích sử dụng, nó cũng có xu hướng phủ nhận một số lợi thế 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ó sự lựa chọn cho phong cách xử lý luồng vẫn hữu ích.

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

Về khả năng tương tác, Storm có thể tích hợp với nhà đàm phán 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 khung công tác xử lý, Storm có hỗ trợ ngôn ngữ rất rộng, cung cấp cho người dùng nhiều tùy chọn để xác định cấu trúc liên kết.

Tóm lược

Đối với khối lượng công việc xử lý luồng thuần túy với các yêu cầu độ trễ rất nghiêm ngặt, Storm có lẽ là lựa chọn tốt nhất cho người trưởng thành. Nó có thể đảm bảo xử lý tin nhắn và có thể được sử dụng với một số lượng lớn các ngôn ngữ lập trình. Vì Storm không thực hiện 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 mạnh mẽ về bảo đảm xử lý chính xác một lần, Trident có thể cung cấp điều đó. Tuy nhiên, các khung xử lý luồng khác cũng có thể phù hợp hơn tại thời điểm đó.

Apache Samza

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

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

Mô hình xử lý luồng

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

  • Chủ đề: Mỗi luồng dữ liệu nhập vào hệ thống Kafka được gọi là chủ đề. Chủ đề về cơ bản là luồng thông tin có liên quan mà người tiêu dùng có thể đăng ký.
  • Phân vùng: Để phân phối một chủ đề giữa các nút, Kafka chia các tin nhắn đến thành các phân vùng. Các phân vùng phân vùng được dựa trên một khóa sao cho mỗi tin nhắn với cùng một khóa được đảm bảo được gửi đến cùng một phân vùng. Phân vùng đã được bảo đảm đặt hàng.
  • Môi giới: Các nút riêng lẻ tạo thành một cụm Kafka được gọi là các nhà môi giới.
  • Nhà sản xuất: Bất kỳ văn bản thành phần nào về chủ đề Kafka đều được gọi là nhà sản xuất. Nhà sản xuất cung cấp khóa được sử dụng để phân chia 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ừ chủ đề Kafka. Người tiêu dùng chịu trách nhiệm duy trì thông tin về khoản bù đắp của mình, để họ biết được hồ sơ nào đã được xử lý nếu xảy ra lỗi.

Bởi vì Kafka đại diện cho một bản ghi bất biến, Samza giao dịch với những dòng suối bất biến. Điều này có nghĩa là bất kỳ phép biến đổi nào tạo luồng mới được tiêu thụ bởi các thành phần khác mà không ảnh hưởng đến luồng ban đầu.

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

Sự phụ thuộc của Samza vào hệ thống xếp hàng giống như Kafka ngay từ cái nhìn đầu tiên có vẻ có vẻ hạn chế. Tuy nhiên, nó dành cho hệ thống một số bảo đảm độc đáo và các tính năng không phổ biến trong các hệ thống xử lý luồng khác.

Ví dụ, Kafka đã cung cấp lưu trữ nhân bản 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 đa thuê bao rất dễ dàng và không tốn kém cho mỗi phân vùng dữ liệu riêng lẻ. Tất cả các đầu ra, bao gồm các kết quả trung gian, cũng được viết cho Kafka và có thể được tiêu thụ độc lập bởi các giai đoạn hạ lưu.

Theo nhiều cách, sự phụ thuộc chặt chẽ này vào Kafka phản ánh cách mà công cụ MapReduce thường xuyên tham khảo HDFS. Trong khi 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ý theo lô, nó giải quyết một số vấn đề khi xử lý luồng.

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

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

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

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

Tóm lược

Apache Samza là một lựa chọn tốt cho việc tải luồng công việc, nơi Hadoop và Kafka đã sẵn sàng hoặc hợp lý để thực hiện. Bản thân Samza thích hợp cho các tổ chức có nhiều nhóm sử dụng (nhưng không nhất thiết phải phối hợp chặt chẽ) các luồng dữ liệu ở các giai đoạn xử lý khác nhau. Samza đơn giản hóa rất nhiều phần xử lý luồng và cung cấp hiệu suất độ trễ thấp. Nó có thể không phù hợp nếu 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 kỳ thấp hoặc nếu bạn có nhu cầu mạnh mẽ cho các ngữ nghĩa chính xác một lần.

Hệ thống xử lý lai: Bộ xử lý hàng loạt và luồng

Một số khung công tác xử lý có thể xử lý cả khối lượng công việc hàng loạt và luồng. Các khung công tác 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 tương tự hoặc liên quan được sử dụng cho cả hai loại dữ liệu.

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

Mặc dù các dự án tập trung vào một loại xử lý có thể phù hợp với các trường hợp sử dụng cụ thể, các khung công tác lai cố gắng đưa ra một giải pháp chung cho xử lý dữ liệu. Chúng không chỉ cung cấp các phương pháp để xử lý dữ liệu, chúng có tích hợp, thư viện và công cụ của riêng chúng để thực hiện những việc như phân tích biểu đồ, học máy và truy vấn tương tác.

Apache Spark

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

Spark có thể được triển khai như một cụm độc lập (nếu được ghép nối với một lớp lưu trữ có khả năng) hoặc có thể móc nối vào 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 để 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 trên các tác vụ liên quan đến đĩa vì tối ưu hóa toàn diện có thể đạt được bằng cách phân tích toàn bộ các nhiệm vụ trước thời hạn. Nó đạt được điều này bằng cách tạo ra đồ thị theo chu kỳ được chỉ định, 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, cho phép bộ vi xử lý có khả năng phối hợp công việc thông minh hơn.

Để thực hiện tính toán lô trong bộ nhớ, Spark sử dụng một mô hình được gọi là Tập dữ liệu phân tán linh hoạt 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 bộ sưu tậ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 cha 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 phải ghi lại đĩa sau mỗi thao tác.

Mô hình xử lý luồng

Khả năng xử lý luồng được cung cấp bởi Spark Streaming. Bản thân Spark được thiết kế với khối lượng công việc định hướng theo 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 tải công việc truyền trực tuyến, Spark thực hiện một khái niệm gọi là lô vi mô*. Chiến lược này được thiết kế để xử lý các luồng dữ liệu dưới dạng một loạt các lô rất nhỏ có thể được xử lý bằng cách sử dụng ngữ nghĩa gốc của công cụ lô.

Spark Streaming hoạt động bằng cách đệm luồng theo gia số phụ thứ hai. Chúng được gửi dưới dạng các 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 hồ sơ hiệu suất khác với các khung xử lý luồng thực.

Ư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ể nhờ vào 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 ưu điểm 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 đượ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à luồng, cho phép bạn vận hành một cụm đơn lẻ để xử lý nhiều kiểu xử lý.

Ngoài các khả năng của bản thân động cơ, Spark cũng có một hệ sinh thái thư viện có thể được sử dụng để học máy, truy vấn tương tác, vv. Nhiệm vụ Spark gần như được thừa nhận dễ viết hơn MapReduce, có thể có ý nghĩa quan trọng đối với năng suất.

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

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

Một hệ quả khác của thiết kế bộ nhớ trong Spark là sự khan hiếm tài nguyên có thể là một vấn đề khi được 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ể can thiệp vào các tác vụ 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 ít 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ó khối lượng công việc xử lý đa dạng. Xử lý hàng loạt Spark cung cấp các lợi thế về tốc độ đáng kinh ngạc, giảm mức sử dụng bộ nhớ cao. Spark Streaming là một giải pháp xử lý luồng tốt cho khối lượng công việc có giá trị thông qua độ trễ.

Apache Flink

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

Cách tiếp cận luồng đầ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 (nơi việc tạo nhóm được sử dụng làm phương pháp xử lý chính với các luồng được sử dụng để bổ sung và cung cấp các kết quả sớm nhưng không tinh chế). Kiến trúc Kappa, nơi các luồng được sử dụng cho mọi thứ, đơn giản hóa mô hình và chỉ mới có thể trở thành có thể khi các công cụ xử lý luồng đã phát triển phức tạp hơn.

Mô hình xử lý luồng

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

  • Dòng là các bộ dữ liệu không thay đổi, không bị chặn mà chảy qua hệ thống
  • Nhà khai thác là các hàm hoạt động trên luồng dữ liệu để tạo ra các luồng khác
  • Nguồn là điểm vào cho các luồng vào hệ thống
  • Chậu rửa là nơi dòng suối chảy ra khỏi hệ thống Flink. Chúng có thể đại diện cho một cơ sở dữ liệu hoặc một kết nối đến một hệ thống khác

Các nhiệm vụ xử lý luồng có ảnh 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 để khôi phục trong trường hợp có sự cố. Để lưu trữ trạng thái, Flink có thể làm việc với một số chương trình phụ trợ của tiểu bang tùy thuộc vào mức độ phức tạp và sự kiên trì khác nhau.

Ngoài ra, quá trình xử lý luồng 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 có nghĩa rằng nó có thể đảm bảo đặt hàng và nhóm 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à phần mở rộng của mô hình xử lý luồng. Thay vì đọc từ luồng liên tục, nó đọc tập dữ liệu bị chặn khỏi lưu trữ liên tục dưới dạng luồng. Flink sử dụng cùng thời gian chạy chính xác cho cả hai mô hình xử lý này.

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

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

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

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

Flink tự quản lý nhiều thứ. Hơi độc đáo, nó quản lý bộ nhớ của riêng mình thay vì dựa vào cơ chế thu gom rác Java nguyên gốc 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ó xử lý phân vùng dữ liệu và bộ nhớ đệm tự động là tốt.

Flink phân tích công việc của mình và tối ưu hóa các tác vụ 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ì các nhà lập kế hoạch truy vấn SQL làm trong cơ sở dữ liệu quan hệ, lập bản đồ ra cách hiệu quả nhất để thực hiện một nhiệm vụ nhất định. Nó có thể song song các giai đoạn có thể được hoàn thành song song, đồng thời mang dữ liệu lại với nhau để chặn các tác vụ. Đối với các tác vụ lặp lại, Flink cố gắng thực hiện tính toán trên các nút nơi dữ liệu được lưu trữ vì lý do hiệu suất. Nó cũng có thể làm "delta iteration", hoặc lặp lại trên các phần dữ liệu có thay đổi.

Về công cụ người dùng, Flink cung cấp chế độ xem lịch dựa trên web để dễ dàng quản lý các tác vụ và xem hệ thống. Người dùng cũng có thể hiển thị kế hoạch tối ưu hóa cho các tác vụ được 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 nhiệm vụ 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, và 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à hàng xóm tốt nếu được sử dụng trong một 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 với YARN, HDFS và Kafka dễ dàng. Flink có thể chạy các tác vụ được viết cho các khung công tác xử lý 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 tại thời điểm này là nó vẫn còn là một dự án rất trẻ. Triển khai quy mô lớn trong tự nhiên vẫn không phổ biến như các khung công tác chế biến khác và chưa có nhiều nghiên cứu về giới hạn mở rộng của Flink. Với chu kỳ phát triển nhanh 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 nó.

Tóm lược

Flink cung cấp cả xử lý luồng độ trễ thấp với sự hỗ trợ cho các tác vụ 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ý luồng nặng và một số nhiệm vụ theo lô. Tính tương thích của nó với các chương trình Bão và Hadoop bản địa, và khả năng chạy trên một cụm được quản lý YARN có thể giúp dễ dàng đánh giá. Sự phát triển nhanh chóng của nó làm cho nó đáng chú ý.

Phần 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 khối lượng công việc chỉ có khối mà không phải là thời gian nhạy cảm, Hadoop là một lựa chọn tốt mà có thể ít tốn kém để thực hiện hơn một số giải pháp khác.

Đối với khối lượng công việc chỉ có luồng, Storm có hỗ trợ ngôn ngữ rộng và có thể phân phối xử lý độ trễ rất thấp, nhưng có thể phân phối 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 sự linh hoạt, dễ sử dụng nhiều nhóm, và nhân rộng đơn giản và quản lý nhà nước.

Đối với khối 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, 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ý luồng đúng 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 tác vụ đượ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 còn trong những ngày đầu tiên được chấp nhận.

Sự phù hợp nhất cho tình huống của bạn sẽ phụ thuộc rất nhiều vào trạng thái của dữ liệu để xử lý, thời gian yêu cầu của bạn là bao nhiêu và loại kết quả bạn quan tâm. Có sự cân bằng 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 đối với các đối tác trưởng thành và được thử nghiệm tốt của họ.