0

Xử lý dữ liệu quy mô lớn đã chuyển sang một thời đại mới của sự tinh tế và bằng chứng lớn nhất là yêu cầu ngày càng tăng để xử lý dữ liệu trong thời gian thực. Các trình điều khiển cho động thái này rất nhiều, nhưng động lực cơ bản có thể được hiểu bằng cách chỉ cần nhớ lại khái niệm Time-Value-of-Data cổ điển và cách giá trị của dữ liệu đạt đến đỉnh điểm trong vài phút đầu tiên tạo ra, sau đó nhanh chóng tắt đi tăng ca. Xử lý dữ liệu thời gian thực là một khả năng thiết yếu trong các trường hợp sử dụng ngày càng nhiều. May mắn thay, có rất nhiều khung xử lý dữ liệu thời gian thực có sẵn, như Apache Spark, Storm, Heron, Flink, Apex, Kafka Streams và các loại khác. Nhưng trong khi mỗi khung cung cấp một tập hợp các khả năng quan trọng mới, nó cũng bổ sung thêm những phức tạp đáng kể và những thách thức vận hành.

Trong bài đăng này, chúng tôi sẽ thảo luận về việc xử lý dữ liệu phát trực tuyến bằng một trong những công nghệ xử lý dữ liệu phổ biến nhất, Apache Spark. Thảo luận này sẽ đi sâu vào cách bạn nên suy nghĩ về việc giám sát các đường ống dữ liệu Spark của bạn. Nhưng trước tiên, hãy lùi lại và nhìn vào những điều cơ bản.

Hiểu về Spark

Spark là một công cụ có mục đích chung để xử lý dữ liệu quy mô lớn, nhanh, đang được áp dụng rộng rãi trong thế giới hàng loạt và phát trực tuyến. Trước khi hiểu các cách tốt nhất để giám sát Spark khi chạy các ứng dụng, điều quan trọng là phải hiểu mô hình thực thi và các thành phần khác nhau trong kiến ​​trúc Spark.

Nguồn: Spark Spark


  1. Spark Manager / Master quản lý tài nguyên cụm. Nó có thể được chạy trong một trong các chế độ sau:
    1. Độc lập: Một trình quản lý cụm đi kèm với Spark để dễ dàng thiết lập.
    2. Mesos: Trừu tượng hóa tài nguyên hệ thống và làm cho chúng có sẵn như là một hệ thống phân tán đàn hồi.
    3. Sợi: Trình quản lý tài nguyên mặc định bắt đầu Phiên bản 2 của Hadoop.
  2. Spark Worker : Trong chế độ độc lập, các công nhân là các tiến trình đang chạy trên các nút riêng lẻ quản lý các yêu cầu phân bổ tài nguyên cho nút đó và cũng giám sát các trình thực thi.
  3. Spark Executor : Một người thực thi là một quá trình được khởi chạy cùng với worker cho mọi ứng dụng được tạo trong cluster. Nó thực hiện công việc thực tế của việc chạy các tác vụ bên trong nó.
  4. Spark Driver : Một quá trình tạo SparkContext và điều khiển toàn bộ ứng dụng từ đầu đến cuối.

Trình điều khiển Spark tạo ra một bối cảnh Spark và liên lạc với người quản lý / Master để có được tài nguyên trên các nút worker. Các công nhân sau đó tạo các quy trình thực thi cục bộ cho mọi ứng dụng tia lửa. Sau khi hoàn thành, tài xế trực tiếp liên lạc với Nhân viên điều hành để hoàn thành công việc. Các công nhân liên tục theo dõi các Chấp hành viên cho các thất bại. Một DAGScheduler trong trình điều khiển bên trong chia nhỏ kế hoạch tính toán thành các giai đoạn và nhiệm vụ cuối cùng được thực thi trên các trình thực thi. Người thi hành cho một ứng dụng còn sống miễn là người lái xe còn sống.

Như bạn có thể thấy, có rất nhiều thành phần kết hợp với nhau để làm cho ứng dụng spark hoạt động. Nếu bạn dự định triển khai Spark trong môi trường sản xuất của mình, bạn muốn đảm bảo rằng bạn có thể giám sát các thành phần khác nhau, hiểu các thông số hiệu suất, được cảnh báo khi có sự cố và biết cách khắc phục sự cố. Để đạt được mức độ tự tin và trưởng thành để bạn có thể chủ động triển khai và chạy trong môi trường sản xuất của mình, bạn cần phải suy nghĩ nhiều hơn là chỉ thu thập và vẽ biểu đồ các số liệu khác nhau. Blog này và bài tiếp theo trong loạt bài này sẽ cố gắng mô tả những thách thức và thực tiễn tốt nhất để theo dõi.

Tại sao giám sát Spark Streaming đầy thách thức?

Câu hỏi có vẻ đơn giản, nhưng có lẽ là câu hỏi khó nhất bạn cần trả lời. Giao diện người dùng Spark cung cấp bảng điều khiển cơ bản nhưng điều này là không đủ nếu bạn nghĩ đến việc chuyển sang thiết lập sẵn sàng sản xuất. Không có bất kỳ cái nhìn sâu sắc nào về hoạt động bên trong của Spark và các bộ phận của nó, bạn sẽ bị mù. Vì vậy, thiết lập giám sát của bạn nên như thế nào?

Hãy chia nhỏ vấn đề thành nhiều phần dễ hiểu hơn. Bạn nên nghĩ về vấn đề như giám sát ở ba cấp độ:

  1. Cơ sở hạ tầng tia lửa bao gồm
    • Bậc thầy
      1. Độc lập
      2. Mesos
      3. Sợi
    • Công nhân
  2. Các ứng dụng chạy trên cơ sở hạ tầng Spark
    • Người lái xe
    • Giám đốc điều hành
  3. Bên dưới máy chủ lưu trữ , các CPU, Mạng.

Khi bạn chia nhỏ vấn đề giám sát thành ba cấp độ được hiển thị ở trên, bạn cũng sẽ thấy các mức độ phụ thuộc lẫn nhau như thế nào. Bất cứ điều gì ảnh hưởng đến một máy chủ, nói là lỗi đĩa, sẽ lan truyền sự thất bại thông qua cơ sở hạ tầng tia lửa và cuối cùng đến ứng dụng. Thiết lập một quan điểm tương quan về sức khỏe qua ba cấp độ là rất quan trọng. Bạn cần một hệ thống giám sát có thể hiểu được các phụ thuộc lẫn nhau này và giúp bạn tương quan trực quan vấn đề trên ứng dụng với một vấn đề trên cơ sở hạ tầng và cuối cùng là vấn đề trên máy chủ. Nếu không có mối tương quan phức tạp này, bạn sẽ mất hàng giờ cố gắng để gỡ lỗi nguyên nhân gốc rễ của vấn đề khi mọi thứ trở nên tồi tệ.

Là một ví dụ về dịch vụ phần mềm hỗ trợ quá trình này, OpsClarity đã phát triển một khái niệm về sức khỏe của dịch vụ tự động phát hiện ra toàn bộ cấu trúc liên kết dịch vụ của đường ống dữ liệu và ứng dụng. Giao diện có các vòng tròn màu đỏ, xanh lá cây và màu cam tương ứng với sức khỏe. Nó làm cho nó dễ dàng hơn để đáp ứng các vấn đề nhanh hơn, đó là điểm của một hệ thống giám sát. Xem hình ảnh dưới đây:

Tôi nên cấu hình giám sát của mình như thế nào?

Spark cung cấp số liệu cho từng thành phần trên thông qua các điểm cuối khác nhau. Ví dụ: nếu bạn muốn xem chi tiết về trình điều khiển Spark, bạn cần biết chính xác URL, điều này luôn thay đổi theo thời gian, Spark Spark giúp bạn đoán được URL. Vấn đề điển hình là khi bạn khởi động trình điều khiển của mình ở chế độ cụm. Làm thế nào để bạn phát hiện trên nút worker mà trình điều khiển đã được bắt đầu? Khi đó, làm thế nào để bạn xác định cổng mà trình điều khiển Spark hiển thị giao diện người dùng của nó? Đây dường như là một vấn đề gây khó chịu phổ biến cho hầu hết các nhà phát triển và chuyên gia DevOps đang quản lý các cụm Spark. Trong thực tế, hầu hết cuối cùng chạy trình điều khiển của họ trong chế độ máy khách như một cách giải quyết, vì vậy họ có một điểm cuối URL cố định để xem xét. Tuy nhiên, điều này đang được thực hiện với chi phí mất bảo vệ chuyển đổi dự phòng cho người lái xe.

Đối với cơ sở hạ tầng động như Spark, cụm của bạn có thể được thay đổi kích thước một cách nhanh chóng. Bạn phải đảm bảo các thành phần mới được sinh ra (Công nhân, người thực thi) được cấu hình tự động để theo dõi. Không có chỗ cho sự can thiệp thủ công ở đây. Bạn không nên bỏ lỡ việc theo dõi các quy trình mới hơn xuất hiện trên cụm. Mặt khác, bạn không nên tạo cảnh báo sai khi người thi hành di chuyển xung quanh. Một giải pháp giám sát chung thường sẽ bắt đầu cảnh báo bạn nếu người thi hành bị giết và khởi động một công nhân mới. Điều này là do các giải pháp giám sát chung chỉ giám sát cổng của bạn để kiểm tra xem nó lên hay xuống. Với một hệ thống phát trực tuyến thời gian thực như Spark, ý tưởng cốt lõi là mọi thứ có thể di chuyển mọi lúc.

Hãy xem xét một ứng dụng Spark chỉ kiểm tra. Trong trường hợp trình điều khiển bị lỗi, ứng dụng có thể quay lại với cùng bối cảnh ứng dụng cùng với một nhân viên khác. Trong trường hợp này, bộ sưu tập số liệu, kiểm tra cổng và các màn hình khác được định cấu hình sẽ truyền tới nút trình điều khiển mới và giữ nguyên cấu hình. Giải pháp giám sát của bạn sẽ có thể xử lý các tình huống như vậy? Chỉ cần thu thập số liệu và hiển thị chúng trên bảng điều khiển sẽ không hoạt động đối với các hệ thống trung tâm dữ liệu như Spark.

Các tính năng tự động phát hiện và cấu hình cấu trúc liên kết phát hiện và định cấu hình cơ sở hạ tầng thay đổi linh hoạt của Spark trong thời gian thực. Không có sự can thiệp thủ công là cần thiết cho công nhân mới hoặc người thực thi. 

Bạn cần tự tin 100% về thiết lập giám sát của mình và hiểu cách giám sát của bạn sẽ hoạt động với cơ sở hạ tầng động như vậy. Hãy chắc chắn rằng bạn suy nghĩ thông qua từng trường hợp nêu trên để theo dõi. Khác, khi địa ngục vỡ ra, bạn mất.

Trong phần tiếp theo của loạt Giám sát Spark Spark, chúng ta sẽ xem xét các số liệu Spark chính, các mẫu hành vi của chúng và cách khắc phục hiệu quả một ứng dụng Spark Streaming phức tạp và phân tán.

|