2.4 Các vấn đề tiếp cận
2.4.3 Các mô hình nghiên cứu
Dựa vào đặc tả user-case mô tả ở trên và kiến trúc của một mô hình tích hợp và xử lý dữ liệu thời gian thực. Việc tích hợp dữ liệu về cơ bản có ba nhiệm vụ phải thực hiện
Thứ nhất, thu thập dữ liệu ở các server và đẩy chúng vào hàng đợi.
Thứ hai, đọc dữ liệu từ hàng đợi và thực hiện xử lý dữ liệu.
Thứ ba, lưu vào một bộ lưu trữ cho phép tìm kiếm thời gian thực.
Đối với một mô hình xử lý dữ liệu bất kỳ, chúng ta mặc định đều đưa ra một thành phần hàng đợi để xem xét tới vấn đề cân bằng tải và làm cho hệ thống trơn tru hơn. Trừ phi việc thực hiện triển khai ở một mô hình quá nhỏ, thì có thể bỏ vấn đề
xử lý hàng đợi mà đầu tư cấu hình mạnh ở Server. Dưới đây là mô hình cơ bản nhất mà chúng ta có thể tiếp cận tới:
Hình 2.7: Mô hình xử lý dữ liệu cơ bản nhất
Mô hình này là cơ sở áp dụng được cả cho dữ liệu mới sinh (online) và dữ liệu tĩnh (offline) có dung lượng lớn. Cụ thể như thế nào chúng ta sẽ đi vào chi tiết cho từng trường hợp.
Đầu tiên là việc giám sát các dữ liệu mới sinh ra (online). Quay trở lại với mô hình của ELK, chúng ta sẽ tìm hiểu kỹ hơn về kiến trúc của hệ thống này, xem xét các nhiệm vụ, vai trò của các module trong mô hình để rút ra các thành phần quý giá [16]:
Hình 2.8: Kiến trúc triển khai 2 server với ELK
Tại mô hình này, giả sử chúng ta đang thực hiện triển khai ELK cho một đơn vị có hai server thực hiện thu thập dữ liệu, cụ thể là dữ liệu log.
Chi tiết vai trò của từng module như sau:
Logstash shipper: Là một ứng dụng đọc, lắng nghe các dữ liệu log mới sinh ra bởi app server và sẽ liên tục gửi chúng tới Redis qua một kênh truyền có bảo mật sử dụng một cổng giao thức TCP.
Redis: Hoạt động giống như một hàng đợi dữ liệu giữa Logstash shipper và Logstash indexer.
Logstash indexer: Trích lọc dữ liệu từ hàng đợi Redis và xử lý các nhiệm vụ Filter/ Format/ Tags trước khi lưu trữ vào DB Elastichsearch.
Elasticsearch: Bộ lưu trữ các dữ liệu log, cho phép lập chỉ mục index, và tìm kiếm full-text search.
Kibana: Một front-end viết bằng ngôn ngữ php và javascript cung cấp giao diện hiển thị nội dung, tùy biến, xây dựng truy vấn và các biểu đồ thống kê.
Nhược điểm đối với kiến trúc hệ thống này là cần phải có môi trường JVM trên từng máy shipper và indexer. Cộng với thời gian bị trễ ở hàng đợi Redis.
So với kiến trúc cơ bản nhất mà chúng ta đưa ra ở trên, có thể thấy rõ được sự khác biệt ở Logstash shipper (thành phần thu thập) và Logstash indexer (thành phần xử lý). Có thể đặt câu hỏi tại sao lại chia hai chức năng này ra ở hai quá trình khác nhau mà không đồng thời xử lý cùng nhau, như mô hình bên dưới?
Có rất nhiều lý do được ở đặt vào các hoàn cảnh khác nhau, nhưng đều chứng minh rằng mô hình này là không tốt. Dưới đây liệt kê một vài lý do tiêu biểu:
Bởi vì chúng ta không muốn mất dữ liệu như đã giải thích ở trên.
Bởi vì Logstash indexer có thể thực thi một số nhiệm vụ (điển hình là
trích xuất, lọc và định dạng từng dòng dữ liệu) mất nhiều thời gian và gây ra nguy hiểm cho hệ thống bởi việc sử dụng rất nhiều tài nguyên CPU.
Bởi vì shipper và indexer là hai chức năng khác nhau và không đồng bộ,
không thể thực hiện xử lý song song.
Bởi vì dữ liệu thường là không có cấu trúc và việc cố gắng xử lý đưa về
một cấu trúc thống nhất có thể gây ra nhiều lỗi các dữ liệu không hợp lệ trong vòng lặp và cuối cùng là “Out of memory”. Kết thúc nhiệm vụ với một ngoại lệ.
Với các lý do như trên, việc sử dụng Redis làm hàng đợi giữa shipper và indexer giúp cho việc xử lý là tuần tự, chấp nhận xử lý dữ liệu với một độ trễ nhỏ nhưng lại giúp ích cho việc cân bằng tải của mô hình. Như vậy Redis ở đây đóng vai trò rất quan trọng và giúp giải quyết được nhiều vấn đề liên quan.
Tổng kết lại mô hình của ELK để giám sát các dữ liệu mới sinh ra chúng ta có như sau:
Hình 2.10: Mô hình đẩy dữ liệu mới sinh ra
Tiếp theo, chúng ta xây dựng mô hình cho trường hợp thứ hai đó là phải đọc dữ liệu lịch sử từ các file dữ liệu tĩnh (offline). Hệ thống đơn giản chỉ lấy trực tiếp dữ liệu ra mà không theo dõi thường xuyên. Với hệ thống ELK chỉ xử lý được những file có kích cỡ nhỏ. Tuy nhiên, chúng ta cần xây dựng ở hệ thống eLMS xử lý các file cỡ lớn bởi nhu cầu thực tế cần phải đáp ứng.
Đối với những file cỡ nhỏ và tầm trung, có thể sử dụng cơ chế upload thẳng lên server bằng một giao diện trực quan trên Dashboard (client). Tuy nhiên đối với những file có dung lượng lớn, chúng ta phải lựa chọn công nghệ batch job xử lý chạy ngầm cho việc đọc file. Có thể đưa ra mô hình xử lý cho trường hợp này như sau:
Hình 2.11: Mô hình xử lý dữ liệu lịch sử
Như vậy, với hai trường hợp khác nhau. Chúng ta đã hình dung được mô hình của hệ thống eLMS cần có là gộp từ 2 kiểu kiến trúc ở trên thành một. Đó là mô hình mà chúng ta đang nghiên cứu.
Hình 2.12: Mô hình tiếp cận