2013-02-06 22 views
7

Chúng tôi có một số lượng lớn các ứng dụng được phân phối trên nhiều máy trong nhiều trung tâm dữ liệu.Sử dụng Twitter Storm để xử lý dữ liệu nhật ký?

Trong suốt cả ngày, chúng tôi sẽ nhận được tín hiệu (nội bộ hoặc bên ngoài), điều này gây ra một loạt các sự kiện trong mỗi ứng dụng.

Mỗi tín hiệu do đó tạo ra một lượng lớn dữ liệu nhật ký sự kiện. Bản thân các logline không được cấu trúc đặc biệt và chúng cũng khá khác nhau giữa các ứng dụng. Họ thực hiện theo quy ước cơ bản mặc dù:

<timestamp> <calling function/method> <payload> 

Chúng tôi có số ID trong nhật ký có thể giúp liên kết các sự kiện với nhau - tuy nhiên, chúng tôi không cần sử dụng các cách khác để cố gắng mảnh sự kiện với nhau.

Tôi đã đọc về hệ thống Storm của Twitter và tôi rất muốn thử nó để phân tích khối lượng dữ liệu nhật ký này trong thời gian thực và ghép lại với nhau.

Tôi muốn làm những việc như:

  • báo cáo Sản xuất và đồ thị trực tuyến dựa trên xu hướng từ các dữ liệu trong thời gian thực.
  • Truy vấn tín hiệu, sau đó hiển thị toàn bộ chuỗi sự kiện liên quan đến tín hiệu đó trong tất cả các ứng dụng, bao gồm cả độ trễ giữa các bước trong chuỗi. (Điều này quan trọng).
  • Xem các sự kiện có liên quan và xem xét những ứng dụng khác đang hoạt động vào khoảng thời gian của một sự kiện nhất định.

Tải dữ liệu vào?

Dữ liệu nhật ký được lưu trữ trong tệp nhật ký cục bộ (và điều này không có khả năng thay đổi), vì vậy chúng tôi cần có cách để tự nhập dữ liệu vào chính Storm. Logfiles cũng có thể được nén. Tôi đã sử dụng Flume, hoặc Logstash - suy nghĩ của mọi người về điều này là gì? Hoặc có những cách thay thế mà sẽ làm việc tốt với Storm?

Lưu trữ sự kiện?

Tôi cũng cần cả hai cách để lưu trữ dữ liệu cho báo cáo và biểu đồ trực tiếp, cũng như chính dữ liệu sự kiện.

Đó là phần thứ hai tôi đang tìm kiếm một chút khó khăn - loại phụ trợ lưu trữ nào phù hợp cho các sự kiện lưu trữ, cũng như các liên kết giữa chúng? Liệu một số loại cơ sở dữ liệu đồ thị có phù hợp không, một trong những loại lược đồ NoSQL mới lạ, hay cái gì đó truyền thống hơn một chút?

Bão có phù hợp không?

Cuối cùng, Storm có phù hợp với vai trò này hay không?

Và nếu tôi đi với Storm, tôi có thể thực hiện phương pháp tiếp cận nào để giải quyết vấn đề này? Tôi hy vọng những người khác có kinh nghiệm với các vấn đề tương tự.

Chúc mừng, Victor

Trả lời

3

báo cáo Sản xuất và đồ thị trực tuyến dựa trên xu hướng từ các dữ liệu trong thời gian thực

Cái này nghe có vẻ như một sự phù hợp tuyệt vời.

Query một tín hiệu, sau đó đưa lên toàn bộ chuỗi sự kiện liên quan đến rằng tín hiệu trong tất cả các ứng dụng, bao gồm cả sự chậm trễ giữa các bước trong chuỗi . (Cái này quan trọng).

Nếu truy vấn của bạn bị giới hạn trong dữ liệu gần đây (= không nhiều dữ liệu) & bạn có thể cho phép mất dữ liệu, tôi có thể hình dung việc này chỉ bằng Storm. Nếu không, tôi có thể kết hợp Storm với một cơ sở dữ liệu và sử dụng Storm chủ yếu để tiền xử lý & lưu trữ dữ liệu vào cơ sở dữ liệu. Truy vấn có lẽ được xử lý tốt hơn bằng cách sử dụng cơ sở dữ liệu trong trường hợp này.

Xem các sự kiện tương quan và tìm hiểu xem ứng dụng nào khác là làm khoảng thời gian của một sự kiện nhất định.

Bão là điều tuyệt vời khi bạn biết bạn sẽ thực hiện truy vấn nào và bạn không cần truy cập vào nhiều dữ liệu cho các truy vấn. Ví dụ: việc phân phát nguồn cấp dữ liệu cho thấy các sự kiện có liên quan sẽ rất phù hợp. Cung cấp phương tiện để thực hiện các truy vấn đặc biệt (xem chi tiết) có thể sẽ dễ dàng hơn với cơ sở dữ liệu. Ngoài ra, nếu bạn muốn cho phép người dùng truy vấn một lượng lớn dữ liệu (ví dụ: giá trị tuần của dữ liệu thay vì giá trị dữ liệu trong một giờ v.v.), thì có thể bạn sẽ cần một cơ sở dữ liệu.

Để cho ăn dữ liệu, tôi sẽ sử dụng sản phẩm tập trung vào nhật ký. Bạn có thể tạo Spout tương tác với bất kỳ giao diện nào mà sản phẩm sẽ cung cấp. Ngoài ra, nếu bạn đang sử dụng khung ghi nhật ký cho phép gửi nhật ký qua ổ cắm, qua JMS, v.v. (như log4j), bạn có thể đọc vòi từ cổng đó/hàng đợi JMS, v.v.

Đối với lựa chọn DB, nó thực sự phụ thuộc về những gì bạn muốn làm. Nếu bạn không biết loại hoạt động nào bạn sẽ đăng nhập và muốn tương quan với các sự kiện, đặt cược của tôi sẽ có trên cơ sở dữ liệu đồ thị, vì các sự kiện đi ngang sẽ dễ dàng.

2

Điều này nghe có vẻ giống như trường hợp tôi đang làm việc vào lúc này vì vậy tôi sẽ đưa ra một vài ý tưởng về những gì có thể làm được.

Để nhận dữ liệu, bạn có thể xem Apache Kafka. Hệ thống nhắn tin này có thể xóa nhật ký của bạn khỏi các ứng dụng và lưu trữ trung gian. Từ đó, các hệ thống khác nhau có thể gắn kết với tư cách là người tiêu dùng với Storm là một trong số chúng tích hợp tốt bằng cách sử dụng một vòi Storm-Kafka đặc biệt.

Trong trường hợp của chúng tôi, chúng tôi có một số dữ liệu thời gian thực được tiêu thụ trực tiếp từ nhà môi giới Kafka và theo dõi/bảng điều khiển và các luồng dữ liệu khác cần xử lý thông qua Storm. Cái sau được lưu trữ trong một DB phân tán (MongoDB, Cassandra hoặc Couchbase) tùy thuộc vào bản chất của dữ liệu, sau đó được tải trong các bảng điều khiển và các hệ thống khác.

Đối với công việc theo lô, bạn cũng có thể tải dữ liệu từ Kafka vào Hadoop và tất cả điều này có thể được thực hiện độc lập với nhau, kéo cùng một dữ liệu từ Kafka đến nhiều hệ thống.

Kafka cũng hỗ trợ nhiều trung tâm dữ liệu thông qua trình tạo gương.