Khối xây dựng dữ liệu lớn: Chọn kiến ​​trúc và nguồn mở ...


Xuân Thanh Nguyễn
10 tháng trước
Hữu ích 5 Chia sẻ Viết bình luận 0
Đã xem 3940

Bài viết này được giới thiệu trong Hướng dẫn DZone mới  về Dữ liệu lớn: Khối lượng, Đa dạng và Vận tốc.  Nhận bản sao miễn phí của bạn cho các bài viết sâu sắc, số liệu thống kê ngành và nhiều hơn nữa!

Từ các máy chủ kim loại trần cho đến đám mây, dữ liệu ở quy mô có ở khắp mọi nơi. Tuy nhiên, điều chúng ta không nói nhiều là nó thường kết thúc thành một chuỗi các nhiệm vụ tẻ nhạt - từ xử lý thời gian thực phức tạp, xử lý sự kiện, phân tích dữ liệu, truyền dữ liệu và xây dựng mô hình học máy, tất cả các cách xuống các hoạt động đơn giản hơn như làm sạch và chuẩn bị dữ liệu. Các nhà phát triển, nhóm DevOps và các nhà khoa học dữ liệu trong các ngành và tổ chức đang tìm cách tự động hóa các quy trình này, nhưng họ vẫn phải đối mặt với một vấn đề khác: tìm giải pháp tốt nhất cho những thách thức lớn nhất của dữ liệu lớn, như tính sẵn sàng cao, tỷ lệ ngang và khả năng chịu lỗi. Nhiều công cụ nguồn mở, như Apache Kafka và ApacheSpark, yêu cầu giải quyết những thách thức này, nhưng điều đó khiến các đội đặt câu hỏi như:

  • Làm thế nào để chúng tôi chọn công cụ tốt nhất cho tổ chức và sản phẩm của chúng tôi?
  • Có một kiến ​​trúc chung cho dữ liệu ở quy mô?
  • Chúng ta có thể sử dụng một kiến ​​trúc cơ bản để bắt đầu không?

Trong bài viết này, chúng tôi sẽ sử dụng các ví dụ về các tình huống kinh doanh phổ biến, xem qua các yêu cầu và quy trình ra quyết định cơ sở dữ liệu của chúng tôi để giúp bạn xem cách đánh giá các kiến ​​trúc khác nhau và các công cụ nguồn mở để tìm giải pháp tốt nhất cho kịch bản của bạn.

Kịch bản: Phân tích tình cảm Twitter

Nhiều khách hàng sử dụng phương tiện truyền thông xã hội để nói về sản phẩm và dịch vụ. Twitter cũng không khác. Các tweet chứa đầy ý kiến ​​có thể lan truyền và ảnh hưởng đáng kể đến danh tiếng của sản phẩm (và công ty) của bạn. Vì vậy, trong kịch bản mẫu của chúng tôi, hãy tưởng tượng chúng tôi là một công ty bán lẻ khu vực. Chúng tôi muốn theo dõi và phân tích các bài đăng trên Twitter trong thời gian thực để chúng tôi có thể hành động khi cần thiết, thể hiện sự đánh giá cao của chúng tôi đối với phản hồi tích cực và giảm thiểu sự không hài lòng của khách hàng một cách nhanh chóng.

  • Vấn đề: Chúng tôi có nhiều sản phẩm và dịch vụ, và trên tất cả các đơn vị kinh doanh, khách hàng của chúng tôi tạo ra 100.000 tweet mỗi giờ, bảy ngày một tuần.
  • Mục tiêu kinh doanh: Một cách dễ dàng, tự động để hiểu được tình cảm xã hội để chúng tôi nắm bắt các vấn đề trước khi chúng leo thang.
  • Các yêu cầu giải pháp: Giám sát phương tiện truyền thông xã hội thời gian thực, mở rộng theo chiều ngang để phù hợp với sự phát triển trong tương lai và hệ thống tóm tắt và cảnh báo theo thời gian thực, điều chỉnh các nhóm thành công / hoạt động của khách hàng (dựa trên các tiêu chí nhất định).

Chúng ta sẽ sử dụng cái gì

  • Người đăng ký theo thời gian thực sẽ đăng ký và lấy dữ liệu từ API Twitter.
  • Hàng đợi tin nhắn.
  • Trình phân tích cú pháp văn bản sẽ điều chỉnh các tweet thành định dạng mà công cụ phân tích tình cảm của chúng tôi có thể tiêu thụ, cũng như thêm các yếu tố như lượt thích, tin nhắn lại, v.v.
  • Công cụ phân tích tình cảm sẽ đánh giá "cảm giác" tweet và trả lại tình cảm của nó (tích cực / tiêu cực).
  • Công cụ tính điểm sẽ nhận dữ liệu từ công cụ phân tích tình cảm và trình phân tích cú pháp, chạy thuật toán xác định mức độ nghiêm trọng của tweet và đánh giá xem có nên đưa ra cảnh báo cho các nhóm của chúng tôi hay không.
  • Cơ sở dữ liệu sẽ lưu trữ dữ liệu của chúng tôi, lớp dịch vụ sẽ sử dụng để chuyển sang bảng điều khiển trong thời gian thực.

Tùy chọn kiến ​​trúc chung

Kiến trúc Kappa bao gồm hàng đợi tin nhắn, lớp xử lý thời gian thực và lớp dịch vụ. Nó được thiết kế cho cả đường ống xử lý song song và đường ống không đồng bộ hoặc đồng bộ.

Một kiến ​​trúc Lambda tương tự như Kappa, với một lớp bổ sung, lớp lô, kết hợp đầu ra từ tất cả các dữ liệu được nhập theo nhu cầu của sản phẩm. Trong ví dụ của chúng tôi, lớp dịch vụ chịu trách nhiệm tạo chế độ xem bảng điều khiển của chúng tôi, nơi chúng tôi kết hợp đầu ra từ đầu vào xử lý theo thời gian thực và xử lý hàng loạt để tạo chế độ xem bao gồm thông tin chi tiết từ cả hai.

Lựa chọn giải pháp của chúng tôi: Kiến trúc Kappa

Kiến trúc Lambda có thể hơi phức tạp do nhu cầu duy trì cả hai cơ sở mã xử lý theo lô và thời gian thực. Vì chúng tôi muốn bắt đầu với một giải pháp đơn giản hóa, chúng tôi sẽ sử dụng tùy chọn kiến ​​trúc Kappa.

Mục tiêu của chúng tôi:

  • Độ trễ tối thiểu: Đánh giá các tweet mới càng nhanh càng tốt (tức là một vài giây).
  • Thông lượng cao: Tiêu hóa nhiều tweet song song.
  • Khả năng mở rộng theo chiều ngang: Giúp tăng tải.
  • Tích hợp: Cho phép các thành phần khác nhau trong hệ thống của chúng tôi tích hợp với các hệ thống khác, chẳng hạn như hệ thống cảnh báo, dịch vụ web, v.v. Điều này sẽ giúp chúng tôi đánh giá các thay đổi trong tương lai trong kiến ​​trúc để hỗ trợ các tính năng mới.

Quy trình quyết định của chúng tôi

Đối với người đăng ký theo thời gian thực, nhiều sản phẩm thương mại tồn tại, cả trên đám mây (ví dụ: Ứng dụng Azure Logic ) và tại cơ sở. Điều tương tự cũng xảy ra với hệ thống cảnh báo. Một tùy chọn là Graphite, hoạt động tốt với Grafana . Mặc dù hai cái này là phổ biến, chúng ta nên sử dụng Prometheus thay thế. Prometheus hoạt động tốt hơn đối với chúng tôi vì nó cung cấp một hệ thống quản lý cảnh báo đầy đủ có sẵn (mà Graphite và Grafana thiếu), cũng như thu thập dữ liệu và trực quan hóa cơ bản.

Đối với hàng đợi tin nhắn của chúng tôi, có nhiều sản phẩm (ví dụ RabbitMQ , Apache ActiveMQApache Kafka ). Nhiều khung công tác, như Apache Spark và Apache Storm, được tích hợp tích hợp với Kafka. Chúng tôi đã chọn Kafka vì khả năng mở rộng, thông lượng cao, tích hợp dễ dàng và hỗ trợ cộng đồng. Trên hết, các máy khách Kafka Stream được hỗ trợ bằng nhiều ngôn ngữ lập trình khác nhau, giúp giảm thời gian học tập của ngôn ngữ lập trình chuyên dụng.

Trình phân tích cú pháp văn bản, công cụ phân tích tình cảm và công cụ tính điểm của chúng tôi có thể được xây dựng với Apache Storm hoặc Apache Spark Streaming . Apache Storm tập trung vào xử lý luồng, thực hiện các tính toán song song với nhiệm vụ và có thể được sử dụng với bất kỳ ngôn ngữ lập trình nào. Apache Spark bao gồm thư viện máy học MLlib tích hợp, có thể giúp chúng ta với động cơ tình cảm. Nhưng Spark Streaming xử lý dữ liệu theo lô nhỏ, có thể hạn chế khả năng trễ. Vì điều này và vì MLlib không hỗ trợ tất cả các thuật toán học máy, chúng tôi đã chọn làm việc với Apache Storm. Với Storm là lớp phát trực tuyến, chúng ta có thể xử lý mỗi tweet dưới dạng một tác vụ, kết thúc nhanh hơn so với làm việc với Spark điều khiển song song dữ liệu. Điều này đáp ứng khả năng mở rộng của chúng tôi, độ trễ thấp và mục tiêu thông lượng cao.

Cuối cùng, chúng ta cần đánh giá các tùy chọn cơ sở dữ liệu của chúng tôi. Vì chúng tôi muốn xem tóm tắt các phân tích của chúng tôi trong thời gian thực trên bảng điều khiển, chúng tôi sẽ sử dụng một DB trong bộ nhớ được lập chỉ mục như Redis cho các truy vấn nhanh hơn và độ trễ tối thiểu.

Điều quan trọng cần lưu ý là thiết lập kiến ​​trúc của chúng tôi cho phép thay đổi. Khi hệ thống của chúng tôi phát triển và chúng tôi thêm các tính năng thống kê, chúng tôi có thể thêm một lớp lô, biến kiến ​​trúc Kappa thành Lambda. Kiến trúc cũng hỗ trợ thêm nhiều đầu vào từ các mạng xã hội khác nhau, như LinkedIn. Nếu có cơ hội tốt bạn sẽ thêm một lớp lô trong tương lai, hãy xem xét sử dụng Apache Spark thay vì Apache Storm. Bằng cách này, bạn sẽ duy trì một khung cho cả xử lý luồng và xử lý hàng loạt.

Toàn cảnh dữ liệu lớn trong nháy mắt: Tổng quan và cân nhắc

Apache Kafka cung cấp một nền tảng thống nhất, thông lượng cao, độ trễ thấp để xử lý các nguồn cấp dữ liệu thời gian thực và hầu hết các đám mây hỗ trợ Kafka được quản lý. Kafka cũng cung cấp Kafka Stream cho các ứng dụng phát trực tuyến, cũng như Kafka Connect, trong đó chúng ta có thể tạo một trình kết nối cơ sở dữ liệu đọc dữ liệu từ Kafka và ghi nó vào cơ sở dữ liệu mong muốn, như PostgreQuery, MongoDB, v.v. Kafka cung cấp một hệ thống nhắn tin theo thứ tự, liên tục và có thể mở rộng, hỗ trợ các dịch vụ siêu nhỏ và có một cộng đồng nguồn mở thịnh vượng - biến nó thành một khung xếp hàng tin nhắn cực kỳ phổ biến.

Redis là một dự án cấu trúc dữ liệu trong bộ nhớ nguồn mở, thực hiện cơ sở dữ liệu khóa-giá trị trong bộ nhớ phân tán với độ bền tùy chọn. Redis hỗ trợ các loại cấu trúc dữ liệu trừu tượng khác nhau, chẳng hạn như chuỗi, danh sách, bản đồ, bộ, bộ được sắp xếp, HyperLogLogs , bitmap, luồng và chỉ mục không gian. Trong Khảo sát nhà phát triển StackOverflow 2018 , Redis được xếp hạng là "cơ sở dữ liệu được yêu thích nhất" của nhà phát triển, nhưng điều quan trọng cần lưu ý là Redis không hỗ trợ hoạt động tham gia hoặc ngoài ngôn ngữ truy vấn. Bạn cũng cần học Lua để tạo thủ tục lưu trữ của riêng bạn; quá trình học tập dài hơn và có lẽ khó hơn.

Apache Spark là một khung tính toán cụm mục đích chung phân tán nguồn mở được sử dụng thường xuyên nhất cho học máy, xử lý luồng, tích hợp dữ liệu và phân tích tương tác. Spark Streaming được xây dựng dựa trên Apache Spark. Đây là một hệ thống xử lý luồng chịu lỗi có thể mở rộng, hỗ trợ cả khối lượng công việc theo khối và luồng, với sự hỗ trợ vượt trội cho các biểu đồ và thư viện máy học. Spark tương đối đơn giản để nắm bắt, cực kỳ nhanh chóng và có sự hỗ trợ cộng đồng rộng lớn.

Apache Storm là một khung tính toán xử lý luồng phân tán được viết chủ yếu bằng ngôn ngữ lập trình Clojure. Thường được so sánh với Spark Streaming, Storm tập trung vào xử lý luồng và thực hiện các tính toán song song với nhiệm vụ. Storm thường được sử dụng với Kafka, trong đó Storm xử lý dữ liệu và Kafka được sử dụng cho mục đích truyền phát sự kiện hoặc tin nhắn trên xe buýt. Storm có sự hỗ trợ rất lớn trong đám mây và có thể được sử dụng với bất kỳ ngôn ngữ lập trình nào vì giao tiếp qua giao thức dựa trên JSON. Các bộ điều hợp hiện tại tồn tại trong Python, Ruby, JavaScript, Perl, v.v.

So với Apache Samza , một khung xử lý luồng khác, Storm tỏa sáng trong xử lý sự kiện tốc độ cao (tốt cho các hệ thống đồng bộ), trong khi Samza tỏa sáng trong việc xử lý nhiều gigabyte. Cả hai đều rất phù hợp để làm việc với lượng lớn dữ liệu thời gian thực.

Cái gì tiếp theo

Có vô số chủ đề, công nghệ, kịch bản và yêu cầu, vì vậy không thể bao quát hết được. Bài viết này cung cấp cho bạn một nền tảng để đánh giá nhu cầu của bạn, hiểu kiến ​​trúc cơ sở dữ liệu và cảnh quan công nghệ rộng hơn và chọn từ các công cụ và dịch vụ nguồn mở phổ biến.

Tuy nhiên, điều quan trọng cần nhớ là, như với tất cả các công nghệ, các sản phẩm và bản cập nhật mới được phát hành với tốc độ nhanh chóng. Khi bạn xây dựng giải pháp của mình, hãy nghĩ về cách nó sẽ xử lý các cải tiến trong tương lai và liên tục đánh giá xem giải pháp của bạn có đáp ứng nhu cầu của bạn hay không.

Tóm lại: tiếp tục học, luôn luôn.

Và tôi là một người học suốt đời, người sẽ học cùng với bạn. Nếu bạn muốn xem những gì tôi đang khám phá, tôi viết về tất cả những thứ dữ liệu lớn trên blog cá nhân của tôi .

Nếu bạn muốn xây dựng công cụ phân tích tình cảm của riêng mình, hãy xem hướng dẫn Azure Stream Analytics này .

Bài viết này được giới thiệu trong Hướng dẫn DZone mới  về Dữ liệu lớn: Khối lượng, Đa dạng và Vận tốc.  Nhận bản sao miễn phí của bạn cho các bài viết sâu sắc, số liệu thống kê ngành và nhiều hơn nữa!

Hữu ích 5 Chia sẻ Viết bình luận 0
Đã xem 3940