Luận văn: Giải pháp nền tảng cho hệ thống tích hợp dữ liệu lớn và không đồng nhất

Khám phá giải pháp nền tảng tích hợp dữ liệu lớn không đồng nhất hiệu quả. Tối ưu hóa quy trình, giảm chi phí, tăng tốc độ phân tích dữ liệu.

Chuyên ngành

Công nghệ Thông tin

Người đăng

Ẩn danh

Thể loại

Luận văn thạc sỹ

2015

72
1
0

Phí lưu trữ

30 Point

Mục lục chi tiết

LỜI CAM ĐOAN

LỜI CẢM ƠN

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

DANH MỤC CÁC HÌNH VẼ

1. CHƯƠNG 1: SỰ CẦN THIẾT PHẢI XỬ LÝ TÍCH HỢP DỮ LIỆU TẬP TRUNG

1.1. Tổng quan về dữ liệu lớn và không đồng nhất

1.2. Log - dữ liệu không đồng nhất

1.2.1. Các cấp độ của log

1.2.2. Chi tiết về Log File

1.3. Tại sao phân tích dữ liệu log

1.4. Khó khăn của việc thực hiện hệ thống tích hợp dữ liệu không đồng nhất

1.5. Khó khăn khi thực hiện xử lý tích hợp dữ liệu thời gian thực

2. CHƯƠNG 2: HỆ THỐNG TÍCH HỢP DỮ LIỆU LỚN VÀ KHÔNG ĐỒNG NHẤT LÀ GÌ?

2.1. Thực hiện quản lý tích hợp dữ liệu tập trung

2.1.1. Vòng đời xử lý của hệ thống tích hợp và không đồng nhất

2.1.2. Chi tiết bộ thu thập dữ liệu Shipper

2.1.3. Chi tiết về hàng đợi

2.1.4. Chi tiết về bộ phân giải dữ liệu Parser

2.1.5. Chi tiết về Database

2.1.6. Chi tiết về Client

2.2. Nền tảng từ các hệ thống hiện có

2.2.1. Hệ thống Hadoop

2.2.2. Hệ thống Splunk

2.2.3. Hệ thống ELK

2.3. Các vấn đề tiếp cận

2.3.1. Đọc dữ liệu log mới sinh ra

2.3.2. Đọc dữ liệu từ file lớn

2.3.3. Các mô hình nghiên cứu

2.3.4. Lưu trữ dữ liệu và chỉ số index

2.3.5. Filter – Format – Tag

2.3.6. Vấn đề xếp hàng đợi Queue

2.3.7. Vận chuyển dữ liệu tới server tập trung

3. CHƯƠNG 3: ĐỀ XUẤT eLMS – HỆ THỐNG TÍCH HỢP GỌN NHẸ, THỜI GIAN THỰC

3.1. Xây dựng giải pháp

3.2. Triển khai mô hình cơ sở eLMS

3.3. Các công việc tiếp theo

TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng Quan Về Tích Hợp Dữ Liệu Lớn Không Đồng Nhất

Dữ liệu ngày nay đến từ vô số nguồn, mỗi nguồn lại có định dạng và cấu trúc riêng. Điều này đặt ra thách thức lớn cho việc tích hợp dữ liệu lớntích hợp dữ liệu không đồng nhất. Các nguồn dữ liệu lớn có thể khác nhau về kích thước (tăng trưởng liên tục), sự đa dạng (từ cảm biến, internet, hệ thống dữ liệu khác nhau) và tốc độ (dữ liệu tĩnh, động, streaming). Dữ liệu không đồng nhất có thể khác nhau về khuôn dạng (XML, metadata, weblog) và nội dung (weblog, syslog, window log, database). Việc thiếu một bản ghi chung giữa các nguồn dữ liệu, thậm chí khi chúng có cùng định dạng, khiến cho việc tham chiếu và tích hợp trở nên khó khăn. Mục tiêu là tạo ra một cấu trúc chuẩn chung, cho phép truy vấn và tham chiếu dữ liệu một cách hiệu quả. Ví dụ, một bản ghi có địa chỉ IP nhưng thiếu username, trong khi một bản ghi khác lại có username nhưng thiếu địa chỉ IP. Khi dữ liệu được tích hợp, nó phục vụ trực tiếp cho việc truy vấn từ một trường bản ghi này có thể tham chiếu đến các dữ liệu xung quanh, đưa tới một kết luận, báo cáo đầy đủ hơn. Các loại dữ liệu lớn và không đồng nhất điển hình bao gồm file và thư mục (file log, file XML, file CSV), network events (từ web server, router, firewall) và window sources (từ ứng dụng trên hệ điều hành Windows). Để cụ thể, luận văn sẽ tập trung vào dữ liệu log, đại diện cho phần lớn các loại dữ liệu lớn và không đồng nhất khác. Dữ liệu Log có thể coi là một bản ghi sự kiện xảy ra trong hệ thống, phản ánh tình trạng hoạt động của hệ thống đó.

1.1. Khái Niệm Dữ Liệu Lớn Không Đồng Nhất Big Data

Dữ liệu lớn không chỉ là về dung lượng lưu trữ. Nó còn liên quan đến tốc độ tạo ra dữ liệu và sự đa dạng của dữ liệu đó. Sự không đồng nhất xuất phát từ các nguồn và định dạng khác nhau, ví dụ, các file log, file csv, XML, meta-data. Việc xử lý loại dữ liệu này đòi hỏi một hệ thống có khả năng linh hoạt và mở rộng cao để có thể thu thập, xử lý và phân tích các nguồn dữ liệu với các định dạng khác nhau. Các hệ thống truyền thống thường gặp khó khăn trong việc đối phó với sự phức tạp này, dẫn đến nhu cầu về các giải pháp mới và sáng tạo.

1.2. Đặc Điểm và Phân Loại Các Dữ Liệu Log Phổ Biến

Dữ liệu log ghi lại mọi hoạt động trên hệ thống một cách chi tiết. Từ các sự kiện của router, firewall, các giao dịch database, các cuộc tấn công, các kết nối, các hoạt động của người dùng. Có rất nhiều nguồn sinh ra log, ngay cả khi có một nguồn log này, từ nó cũng sinh ra các nguồn log khác và cũng có rất nhiều loại. Ví dụ như các file log của host (Unix, Linux, Windows, VMS.), là khác biệt hoàn toàn so với log của các ứng dụng network (switch, route, hoặc các thiết bị mạng khác của Cisco, Nortel, Lucent). Tương tự như vậy, các log của ứng dụng an toàn thông tin (Firewall, IDS, thiết bị chống DDoS, hệ thống phòng bị.) cũng rất khác nhau trên cả phương diện host và các log từ network. Để tìm hiểu thêm thông tin bạn có thể tìm hiểu tài liệu về quản lý sự kiện và thông tin bảo mật (SIEM).

1.3. Tầm Quan Trọng Của Phân Tích Tích Hợp Dữ Liệu Log Tập Trung

Phân tích dữ liệu log là con đường thực tế và duy nhất để hiểu được cách thức mà hệ thống hoạt động và khách hàng đã sử dụng nó như thế nào. Nó cho phép truy cập tức thì vào nội dung các file log mà không ảnh hưởng đến bảo mật và tính toàn vẹn của dữ liệu. Việc trích lọc và phân tích nội dung log cần được thực hiện sớm để dự đoán và ra quyết định kịp thời. Log chứa các thông tin quan trọng để tìm ra những mối nguy hại trước khi chúng trở nên rõ ràng. Phân tích log giúp hiểu hệ thống và ứng dụng giao tiếp với khách hàng. Việc phân tích có thể cần tập hợp dữ liệu log từ nhiều server khác nhau. Phân tích và tập hợp dữ liệu log giúp ích cho việc thống kê và có thể chuyển giao các sản phẩm dịch vụ liên quan thành tiền bạc đồng thời giúp chúng ta trả lời được rất nhiều câu hỏi như: Có bao nhiêu khách hàng mà chúng ta đã bị mất bởi vì các vấn đề không ổn định của hệ thống, Có khách hàng nào sử dụng nhiều dịch vụ hơn so với số tiền họ chi trả hay không, Phiên bản triển khai cuối cùng của hệ thống đã thực sự cải thiện trong quá trình đáp ứng khách hàng hay chưa, Có bao nhiều khách hàng sử dụng các tính năng mới phát triển.

II. Thách Thức Khi Tích Hợp Dữ Liệu Lớn Không Đồng Nhất

Việc tích hợp dữ liệu từ nhiều nguồn và định dạng khác nhau đặt ra nhiều thách thức. Sự khác biệt về hệ điều hành (Linux, Windows, Mac OSX), phần mềm, dịch vụ và ứng dụng tạo ra dữ liệu khác nhau và lưu trữ chúng dưới nhiều định dạng khác nhau. Có rất nhiều nguồn dữ liệu khác nhau nhưng có mối quan hệ, đòi hỏi phải xử lý tích hợp trên toàn bộ tổ chức. Nội dung dữ liệu không đồng nhất, ví dụ, một nguồn có địa chỉ IP nhưng thiếu username, trong khi nguồn khác lại có username nhưng thiếu địa chỉ IP. Định dạng dữ liệu không đồng nhất (syslog, database, SNMP, XML, binary file, meta-data) gây khó khăn trong việc chuẩn hóa cấu trúc. Bảo vệ dữ liệu đảm bảo tính bí mật, toàn vẹn và sẵn sàng cho việc điều tra, phân tích đòi hỏi các quy trình và chính sách riêng. Cuối cùng, nguồn nhân lực để phân tích dữ liệu là rất quan trọng. Tất cả mọi giải pháp, công nghệ áp dụng cho hệ thống quản lý dữ liệu tập trung sẽ vô nghĩa khi thiếu đội ngũ đáp ứng được việc phân tích và truy vấn dữ liệu lớn ở server trung tâm. Yêu cầu đặt ra là cần phải có một đội ngũ có kỹ năng, chuyên môn cao để xử lý nhanh tình huống xảy ra dựa vào các dữ liệu thu được từ hệ thống quản lý.

2.1. Vấn Đề Về Quản Lý và Chuẩn Hóa Dữ Liệu

Thách thức lớn nhất là việc thống nhất và chuẩn hóa dữ liệu từ các nguồn khác nhau. Các nguồn dữ liệu có thể có các cấu trúc và định dạng khác nhau, ví dụ như syslog, databases, SNMP, XML, binary file, meta-data gây ra khó khăn trong việc chuẩn hóa cấu trúc chung cho tất cả các dữ liệu. Việc xây dựng một lược đồ chung và các quy tắc chuyển đổi dữ liệu là cần thiết để đảm bảo tính nhất quán và khả năng truy vấn dữ liệu hiệu quả. Điều này đòi hỏi kiến thức sâu rộng về các nguồn dữ liệu và các công cụ ETL(Extract, Transform, Load) mạnh mẽ.

2.2. Khó Khăn Khi Xử Lý Dữ Liệu Tích Hợp Thời Gian Thực

Việc xử lý dữ liệu ở thời gian thực được xem là rất phức tạp và khó khăn. Như chúng ta đã biết, Big Data thường được tổ chức bởi khối lượng, vận tốc và một khối dữ liệu khổng lồ. Thực thi nhiệm vụ ở thời gian thực yêu cầu phải có tốc độ xử lý dữ liệu cực kỳ tốt, mà vấn đề xử lý vận tốc của Big Data không phải là một nhiệm vụ dễ dàng. Hệ thống có thể thu thập dữ liệu thời gian thực từ các dòng dữ liệu đầu vào với tốc độ hàng triệu message mỗi giây. Cần phải thực hiện song song nhiệm vụ xử dữ liệu ngay khi nó đang được thu thập. Cần phải có phương thức trích lọc dữ liệu để trích xuất và sàng lọc ra các thông tin có nghĩa. Chưa kể việc định dạng lại cấu trúc dữ liệu để quy về một cấu trúc chuẩn chung. Cả ba bước trên là ba bước cơ bản đều yêu cầu phải có ở một hệ thống thu gom và xử lý dữ liệu thời gian thực.

III. Cách Xây Dựng Hệ Thống Tích Hợp Dữ Liệu ELMS Hiệu Quả

Việc xây dựng một hệ thống quản lý tích hợp dữ liệu tập trung, phân tích và hiển thị giúp tổ chức có cái nhìn cụ thể và chi tiết về từng sản phẩm, dịch vụ mà các hệ thống đang hoạt động. Các vấn đề về bảo mật, lỗi kỹ thuật hay các vấn đề về lỗi vận hành hoặc khi có sự cố bất ngờ xảy ra. Các giải pháp quản lý tích hợp dữ liệu tập trung phải sẵn sàng cung cấp thông tin chi tiết về vấn đề đang gặp phải, và có quan điểm rõ ràng hơn về các hướng giải quyết. Ngoài ra cần đảm bảo tính toàn vẹn của dữ liệu ở server trung tâm, phục vụ cho việc điều tra phân tích hệ thống. Việc tập trung một khối lượng dữ liệu lớn cho phép có thể khai thác và đưa ra dự đoán, quyết định. Vòng đời xử lý của hệ thống tích hợp dữ liệu bao gồm: (1) ứng dụng sinh ra dữ liệu, (2) bộ thu thập dữ liệu (shipper), (3) hàng đợi lưu trữ dữ liệu tạm thời, (4) bộ phân giải dữ liệu (parser), (5) client – giao diện và (6) xóa dữ liệu cũ ra khỏi database.

3.1. Thiết Kế Kiến Trúc Hệ Thống Shippers Queues Parsers

Với các nguồn dữ liệu chúng ta muốn nhanh chóng thu thập, vận chuyển nó tới một server tập trung, trong thời gian thực. Chúng ta sẽ phải sử dụng các thành phần shipper. Nó là một ứng dụng nhẹ được thực hiện để thu thập các dữ liệu sinh ra từ nhiều nguồn khác nhau và gửi đến một hoặc nhiều đích đầu ra. Ứng dụng chạy nền shipper: Một shipper tốt là một thành phần ẩn, sử dụng CPU, bộ nhớ, các tài nguyên I\O ít nhất có thể và không bao giờ gây xung đột với các ứng dụng đang chạy trên server. Trong nhiều trường hợp, có thể một shipper đọc rất nhiều file ở cùng một thời điểm trên cùng một server mà các ứng dụng đang chạy đó đang cố gắng ghi thêm dữ liệu mới vào các file hay các nguồn đang bận xử lý trước đó. Khi thực hiện đọc các file, shipper không được khóa file để cho việc ghi thêm dữ liệu không bị xung đột. Nếu chúng ta cảm thấy shipper ảnh hưởng tới các ứng dụng đang chạy, thì nên cân nhắc sử dụng một shipper khác hoặc tìm một giải pháp khác cho việc gửi dữ liệu tới server tập trung.

3.2. Giải Quyết Vấn Đề Hiệu Năng Parser và Quản Lý Tài Nguyên

Parser đôi khi cũng được gọi là Indexer (tương tự Logstash indexer). Là thành phần tâm điểm cho vòng đời xử lý dữ liệu. Chịu trách nhiệm phân tách từng giá trị có ý nghĩa ở trên mỗi bản ghi dữ liệu, trích lọc và làm cho các dữ liệu trở lên có cấu trúc. Thông thường, nếu số lượng dữ liệu là vừa phải, chúng ta sẽ gửi tất cả tới một thành phần parser duy nhất để thực hiện phân tích nội dung của từng bản ghi dữ liệu và xử lý nó. Quá trình này sẽ tiêu tốn rất nhiều tài nguyên CPU như đã nói ở trên và bởi vì lý do này, thành phần parser nên được cài đặt và cấu hình ở một server riêng biệt mà không có các thành phần khác. Nếu chúng ta cảm thấy rằng server cài đặt thành phần parser đủ mạnh và các dữ liệu đầu vào từ thành phần shippser là không lớn. Chúng ta có thể bỏ qua thành phần hàng đợi để giảm thiểu thời gian tiêu tốn ở các bước trung gian. Sau khi parser kết thúc việc xử lý dữ liệu, nó sẽ chuyển sang cho bộ lưu trữ. Để thực hiện quá trình này hiệu quả, nên triển khai cài đặt database và server parser trên cùng một mạng để đạt tốc độ tối đa việc trao đổi dữ liệu mà không xảy ra vấn đề mất mát dữ liệu.

IV. Hướng Dẫn Tối Ưu Lưu Trữ và Tìm Kiếm Dữ Liệu Lớn

Đối với việc thống kê và phân tích các dữ liệu tích hợp, chúng ta cần phải lưu các thông tin vào trong một DB. Thành phần DB được chọn phải hiệu quả trong việc nhận dữ liệu tới và gửi các dữ liệu đi, hỗ trợ việc tìm kiếm nhanh, dễ dàng cho việc phân tích. Để chia sẻ gánh nặng gây ra bởi các file dữ liệu lớn, chúng ta lựa chọn bổ sung thêm trong kiến trúc với nhiều thành phần hàng đợi và nhiều thành phần xử lý phân tích parser. Và cuối cùng chúng ta muốn tất cả các dữ liệu, không cần biết nó đến từ đâu đều phải được gửi tập trung vào cùng một DB. Có nghĩa rằng DB mà chúng ta lựa chọn cần phải đảm bảo có hiệu suất cao. Các dữ liệu liên tục đọc ghi vào trong DB, vì thế nó cần sử dụng rất nhiều bộ nhớ RAM, tài nguyên CPU và hiệu suất cao của ổ cứng. Nếu nhận thấy rằng DB luôn luôn trong tình trạng quá tải và bắt đầu mất dữ liệu, đó là thời điểm chúng ta cần xem xét nâng cấp phần cứng hoặc lựa chọn ghi với khối dữ liệu nhỏ hơn.

4.1. Chọn Cơ Sở Dữ Liệu Phù Hợp Elasticsearch và Các Lựa Chọn

Elasticsearch cho phép chúng ta chia sẻ cùng một DB giữa các server khác nhau. Một lượng lớn các dữ liệu tích hợp trở nên vô ích nếu không có ai thể truy cập và lấy thông tin từ chúng. Để đọc các dữ liệu được lưu trữ trong DB, chúng ta sẽ sử dụng một hoặc nhiều client kết nối đến nhằm thực hiện truy vấn thông tin. Sự phức tạp và số lượng của các câu lệnh truy vấn đồng thời sẽ quyết định sử dụng bao nhiêu tài nguyên của CPU để xử lý. Ngoài ra, các câu lệnh truy vấn cũng sẽ tiêu tốn tài nguyên khi đọc dữ liệu từ ổ đĩa, điều này có thể ảnh hưởng tới hiệu suất ghi các dữ liệu đến. Nếu sử dụng lập lịch cho các câu lệnh truy vấn để giám sát các loại dữ liệu lỗi và cảnh báo. Các truy vấn này sẽ làm tăng tải trọng của trên máy chủ DB, do đó chúng ta luôn luôn phải để mắt tới DB sẽ bị ảnh hưởng như thế nào do các lệnh truy vấn gây ra.

4.2. Chiến Lược Đánh Index Indexing và Phân Vùng Dữ Liệu

Việc đánh chỉ số index ở Elasticsearch, hệ thống ELK mặc định đánh chỉ số index bằng nhãn “logstash-DDMMYYY”, và nhãn này có thể thay đổi bởi người dùng. Tuy nhiên để hiệu quả cho việc truy vấn và thống kê ở bảng biểu dashboard cung cấp ở client, eLMS thực hiện 2 chiến lược đánh chỉ số index như sau: Gán chỉ số index theo từng ngày và loại. Ưu điểm của gán index kiểu này giúp cho việc truy vấn dữ liệu và thống kê theo ngày nhanh chóng. Gán chỉ số index theo phân loại category hoặc địa chỉ server mà source log gửi tới. Ưu điểm là giúp cho việc tìm kiếm, thống kê theo category hoặc địa chỉ nguồn nhanh chóng. Việc tạo ra các câu lệnh truy vấn ở trên màn hình dashboard ở hệ thống eLMS luôn phải xác định cụ thể khoảng thời gian truy vấn. Do vậy, nếu không có các xử lý đặc biệt thì mặc định chúng ta sẽ gán chỉ số index theo ngày và loại.

V. Mô Hình ELMS Tích Hợp Gọn Nhẹ và Thời Gian Thực

Hệ thống quản lý log eLMS được dựa trên 3 thành phần mã nguồn mở: Logstash, Elasticsearch và Kibana thuộc trên nền tảng công nghệ Elastic. Logstash được sử dụng để vận chuyển và cấu trúc lại nội dung dữ liệu. Elasticsearch có trách nhiệm đánh chỉ mục index, cung cấp khả năng tìm kiếm full-text search. Kibana cung cấp một giao diện web để phân tích và hiển thị nội dung kết quả. Kể từ khi Elastic đưa dự án thành mã nguồn mở, các thành phần không còn được hoạt động trơn tru, vẫn có nhiều sai sót và tiềm tàng nhiều lỗi phát sinh. Một khi gặp các vấn đề về lỗi chúng ta phải trả chi phí để nhận được sự giúp đỡ từ đội phát triển cũng như chi phí thuê chuyên gia. Và bởi vì là mã nguồn mở nên rất khó có thể triển khai hệ thống ở môi trường production.

5.1. Kiến Trúc Tổng Quan Hệ Thống ELMS và Các Thành Phần

Để thực hiện xây dựng hệ thống eLMS, luận văn trình bày từng bước tối ưu hóa nền tảng từ Elastic. Đầu tiên là việc đơn giản hóa việc xếp hàng đợi dữ liệu giúp cho hệ thống giảm thiểu việc tiêu thụ nguồn tài nguyên của máy tính như CPU và RAM. Thứ hai, đề xuất một số kỹ thuật đọc log ở từng máy server riêng lẻ. Thứ ba, đề cập tới vấn đề thay đổi kiến trúc và các chiến lược đánh index dữ liệu ở trong DB. Thứ tư, cải thiện cơ chế trích lọc, định dạng cấu trúc và thực hiện tag dữ liệu. Do vậy, hệ thống eLMS xây dựng bằng các giải pháp tốt nhất cho từng giai đoạn xử lý dữ liệu của hệ thống.

5.2. Đánh Giá Hiệu Năng ELMS So Với Các Hệ Thống Khác

Hệ thống eLMS tiếp cận các giải pháp mã nguồn mở liên quan từ hệ thống ELK tối ưu và xây dựng mô hình ổn định dành cho doanh nghiệp. Do có những cải tiến và tùy chỉnh trong thiết kế và triển khai, hệ thống eLMS có khả năng hoạt động hiệu quả hơn so với các hệ thống khác. Các thử nghiệm và so sánh hiệu năng sẽ cung cấp bằng chứng thực nghiệm về những ưu điểm của eLMS, đặc biệt là trong các tình huống tải cao và yêu cầu thời gian thực.

VI. Kết Luận Hướng Phát Triển Tích Hợp Dữ Liệu Tương Lai

Các đóng góp và nghiên cứu trong luận văn này là để xây dựng hệ thống eLMS kế thừa một vài thành phần từ nền tảng Elastic, tối ưu hóa và phát triển hệ thống theo những đề xuất riêng của bản thân dựa vào những nghiên cứu trong thời gian qua. Để thực hiện xây dựng hệ thống eLMS, luận văn trình bày từng bước tối ưu hóa nền tảng từ Elastic. Đầu tiên là việc đơn giản hóa việc xếp hàng đợi dữ liệu giúp cho hệ thống giảm thiểu việc tiêu thụ nguồn tài nguyên của máy tính như CPU và RAM. Thứ hai, đề xuất một số kỹ thuật đọc log ở từng máy server riêng lẻ. Thứ ba, đề cập tới vấn đề thay đổi kiến trúc và các chiến lược đánh index dữ liệu ở trong DB. Thứ tư, cải thiện cơ chế trích lọc, định dạng cấu trúc và thực hiện tag dữ liệu. Do vậy, hệ thống eLMS xây dựng bằng các giải pháp tốt nhất cho từng giai đoạn xử lý dữ liệu của hệ thống.

6.1. Tóm Tắt Những Điểm Chính và Đóng Góp Của Nghiên Cứu

Tóm lại, luận văn này đã đề xuất và xây dựng một hệ thống tích hợp dữ liệu lớn không đồng nhất hiệu quả, với tên gọi eLMS. Hệ thống này được thiết kế để tối ưu hóa hiệu năng, giảm thiểu việc sử dụng tài nguyên và cung cấp khả năng mở rộng linh hoạt. Các đóng góp chính của nghiên cứu bao gồm việc đơn giản hóa hàng đợi dữ liệu, đề xuất các kỹ thuật đọc log, cải thiện chiến lược đánh index dữ liệu và tối ưu hóa cơ chế trích lọc, định dạng cấu trúc và tag dữ liệu. Những cải tiến này giúp eLMS hoạt động hiệu quả hơn so với các hệ thống hiện có.

6.2. Hướng Nghiên Cứu Tiếp Theo và Ứng Dụng Thực Tế

Các hướng nghiên cứu tiếp theo có thể tập trung vào việc mở rộng hệ thống eLMS để hỗ trợ nhiều loại dữ liệu không đồng nhất hơn, cải thiện khả năng phân tích dữ liệu thông minh và tích hợp các thuật toán học máy để dự đoán và phát hiện các sự cố tiềm ẩn. Ngoài ra, việc áp dụng eLMS vào các lĩnh vực khác nhau, như an ninh mạng, giám sát hệ thống và phân tích kinh doanh, có thể mang lại nhiều lợi ích thiết thực. Các nghiên cứu thực tế sẽ cung cấp thêm thông tin để tinh chỉnh và cải thiện hệ thống, đồng thời chứng minh giá trị của nó trong việc giải quyết các vấn đề thực tế.

24/09/2025

Trích đoạn nội dung tài liệu

Mở đầu cho vấn đề mà luận văn đang đề cập tới. CHƯƠNG 2: HỆ THỐNG TÍCH HỢP DỮ LIỆU LỚN VÀ KHÔNG ĐỒNG NHẤT LÀ GÌ? 2.1 User Case Tầm quan trọng của việc phân tích và quản lý dữ liệu từ các nguồn khác nhau để chuyển về server tập trung là rất quan trọng. Chúng ta hiểu rằng cần phải tìm ra một giải pháp mà sẽ phải giải quyết được các trường hợp sau đây:  Tích hợp tất cả các dữ liệu định dạng khác nhau từ tất cả các server và lưu trữ ở một nơi duy nhất.  Cung cấp chức năng tìm kiếm nhanh chóng để phát hiện ra các lỗi và tìm ra các cảnh báo chứa trong dữ liệu được chuyển về ở một thời gian cụ thể.

 Phải dễ dàng phân tích các file dữ liệu lớn từ nhiều nguồn khác nhau.  Sẵn sàng chia sẻ các dữ liệu ở server trung tâm mỗi khi cần cho đội phát triển mà không cần cung cấp cho họ quyền truy cập trực tiếp vào server chính. TIEU LUAN MOI download : skknchat@gmail.com 14  Trích lọc ra các dữ liệu liên quan trực tiếp tới vấn đề đang gặp phải.  Thống kê các dữ liệu lỗi, các giao dịch bất thường, đưa các vấn đề chi tiết từ yêu cầu của người quản trị.

 Phải có thông báo từ hệ thống quản lý trong trường hợp có các lỗi tương tự xảy ra.2 Thực hiện quản lý tích hợp dữ liệu tập trung Việc xử lý tích hợp dữ liệu từ đa dạng các nguồn, định dạng khác nhau có hai vấn đề cơ bản:  Cấu hình server tập trung sẽ thu thập, xử lý, sàng lọc và hiển thị dữ liệu sau khi đã được tích hợp, trích lọc.  Cấu hình các máy trạm để gửi dữ liệu về tới server tập trung, lựa chọn các đích lưu trữ dữ liệu tạm thời và bảo mật trong khi vận chuyển. Việc xây dựng một hệ thống quản lý tích hợp dữ liệu tập trung, phân tích và hiển thị giúp tổ chức có cái nhìn cụ thể và chi tiết về từng sản phẩm, dịch vụ mà các hệ thống đang hoạt động. Những vấn đề về bảo mật, lỗi kỹ thuật hay các vấn đề về lỗi vận hành hoặc khi có sự cố bất ngờ xảy ra.

Các giải pháp quản lý tích hợp dữ liệu tập trung phải sẵn sàng cung cấp thông tin chi tiết về vấn đề đang gặp phải, và có quan điểm rõ ràng hơn về các hướng giải quyết. Ngoài ra cần đảm bảo tính toàn vẹn của dữ liệu ở server trung tâm, phục vụ cho việc điều tra phân tích hệ thống. Việc tập trung một khối lượng dữ liệu lớn cho phép có thể khai thác và đưa ra dự đoán, quyết định.1 Vòng đời xử lý của hệ thống tích hợp và không đồng nhất [1][11] Có thể thấy rằng, ngày này có rất nhiều sản phẩm về tích hợp dữ liệu dữ liệu tập trung sẵn sàng đáp ứng cho các nhu cầu quản lý và cũng có rất nhiều loại hình với nhiều kiểu cấu trúc xử lý khác nhau. Nhưng về cơ bản, chúng có cùng bản chất khi đều là tích hợp và xử lý dữ liệu tập trung.

Cho nên, các kiến trúc đều có chung một vòng đời xử lý như sau: TIEU LUAN MOI download : skknchat@gmail.1: Vòng đời xử của hệ thống tích hợp và không đồng nhất Bước 1: Ứng dụng sinh ra các dữ liệu Một sự kiện được sinh ra bởi một ứng dụng. Vòng đời bắt đầu với một dữ liệu được ghi và lưu trữ trên một server. Có thể có rất nhiều loại dữ liệu khác nhau, nhưng chủ yếu là thuộc phạm vi các loại dữ liệu đã đề cập ở bên trên. Bước 2: Bộ thu thập dữ liệu (shipper) Nội dung dữ liệu được thu thập bởi một công cụ được xây dựng gọi là các shipper.

Các shipper thực hiện đẩy dữ liệu từ các máy trạm và gửi đến các hàng đợi hoặc đẩy dữ liệu trực tiếp về trung tâm. Thành phần shipper sẽ thực hiện đọc các tập tin, các nguồn dữ liệu và lấy các dữ liệu mới sinh ra, để gửi tới thành phần hàng đợi hoặc đẩy trực tiếp vào bộ phân giải dữ liệu (parser). Có điều quan trọng là các shipper phải được thiết kế nhẹ, hiệu quả, chiếm ít tài nguyên và có thể chạy song song với các ứng dụng máy chủ mà không gây ra bất kỳ vấn đề hiệu suất nào. Ví dụ một vài thành phần shipper như: Beaver, Logstash-forwarder, Log-courier, Splunk universal forwarder.

Bước 3: Hàng đợi lưu trữ các dữ liệu tạm thời Khi chúng ta bắt đầu thực hiện thu thập các dữ liệu từ nhiều nguồn và nhiều server, có thể tạo ra một lưu lượng dữ liệu khổng lồ mà ở thành phần parser xử lý phân tích, trích lọc và định dạng chuẩn cấu trúc chung. không thể theo kịp, gây ra mất dữ liệu tại đây. Trong trường hợp đó, chúng ta sẽ phải đưa ra một thành phần trung gian đóng vai trò là một hàng đợi. Nó lưu trữ dữ liệu tạm thời và cho phép việc xử lý dữ liệu ở bộ phân giải dữ liệu (parser) thực hiện tuần tự theo tốc độ riêng của nó.

Việc đọc và xóa liên tục ở hàng đợi mà parser xử lý là tốn nhiều thời gian, dẫn TIEU LUAN MOI download : skknchat@gmail.com 16 tới hệ thống có độ trễ nhất định. Ví dụ các Message Queues: ZeroMQ, RabbitMQ, Redis. Bước 4: Bộ phân giải dữ liệu (Parser) Khi nhận dữ liệu từ các thành phần khác chuyển tới, chúng ta đưa ra một thành phần xử lý dữ liệu chính của luồng dữ liệu được gọi là bộ phân giải dữ liệu parser. Khi thành phần parser nhận dữ liệu từ hàng đợi hoặc trực tiếp từ shipper chuyển tới, nó sẽ thực hiện các nhiệm vụ phân tích như: Trích lọc những thông tin có ích, đọc từng dòng dữ liệu và định dạng lại về dữ liệu có cấu trúc, chuyển về định dạng dữ liệu json, tags các thông tin quan trọng.

Và cuối cùng, parser sẽ thực hiện đẩy tất cả dữ liệu đã xử lý vào trong DB. Một số parser như: Logstash, Heka, Fluentd, Splunk Indexer. Bước 5: Client – Giao diện Cung cấp chức năng xem nội dung thông tin dữ liệu sau khi đã được tích hợp và xử lý, lập biểu đồ thống kê, truy vấn và tìm kiếm thông tin. Cũng có thể xử lý bởi các thuật toán bởi Data Mining nhằm đưa ra một vài quyết định hay kết luận có ý nghĩa từ dữ liệu đã thu thập được.

Điển hình như Kibana, Graphite, Splunk Web-UI, Grafana. Bước 6: Xóa dữ liệu cũ ra khỏi Database Tất nhiên chúng ta có thể giữ tất cả dữ liệu ở trong DB mãi mãi. Nhưng trong nhiều trường hợp, việc lưu trữ cộng với giá thành của phần cứng quá cao mà các dữ liệu cũ ngày càng trở lên không có giá trị gì nữa. Vì vậy, để chỉ giữ lại những dữ liệu cần thiết, chúng ta cần thêm một xử lý phân loại dữ liệu đẩy vào các thể loại category khác nhau theo mức độ quan trọng của chúng trước khi lưu trữ vào trong DB.

Mỗi category sẽ phải xác định số lượng, thời gian mà dữ liệu được lưu trữ hoặc cũng có thể lưu trữ tối đa kích cỡ category ở trong DB. Theo lập lịch ở cấu hình mà DB sẽ tạo ra một xử lý chạy ngầm để xóa các dữ liệu cũ, giữ cho DB nhẹ nhàng, sạch sẽ và chỉ lưu trữ các dữ liệu cần thiết.2 Chi tiết bộ thu thập dữ liệu Shipper Với các nguồn dữ liệu chúng ta muốn nhanh chóng thu thập, vận chuyển nó tới một server tập trung, trong thời gian thực. Chúng ta sẽ phải sử dụng các thành phần TIEU LUAN MOI download : skknchat@gmail. Nó là một ứng dụng nhẹ được thực hiện để thu thập các dữ liệu sinh ra từ nhiều nguồn khác nhau và gửi đến một hoặc nhiều đích đầu ra.

Ứng dụng chạy nền shipper: Một shipper tốt là một thành phần ẩn, sử dụng CPU, bộ nhớ, các tài nguyên I\O ít nhất có thể và không bao giờ gây xung đột với các ứng dụng đang chạy trên server. Trong nhiều trường hợp, có thể một shipper đọc rất nhiều file ở cùng một thời điểm trên cùng một server mà các ứng dụng đang chạy đó đang cố gắng ghi thêm dữ liệu mới vào các file hay các nguồn đang bận xử lý trước đó. Khi thực hiện đọc các file, shipper không được khóa file để cho việc ghi thêm dữ liệu không bị xung đột. Nếu chúng ta cảm thấy shipper ảnh hưởng tới các ứng dụng đang chạy, thì nên cân nhắc sử dụng một shipper khác hoặc tìm một giải pháp khác cho việc gửi dữ liệu tới server tập trung.

Gửi dữ liệu an toàn: Thành phần shipper sẽ gửi các dữ liệu tới một hoặc nhiều đích và để thực hiện điều này, nó cần truy cập được vào network ở các đích đến đó. Để bảo vệ các ứng dụng và tầng mạng network, thì chúng ta nên chắc chắn rằng chỉ mở các cổng cần thiết cho việc kết nối. Luôn luôn sử dụng một firewall để bảo vệ cho các hệ thống. Trong một vài trường hợp, dữ liệu chứa các thông tin nhạy cảm mà chúng ta sẽ có ý định mã hóa dữ liệu này trước khi gửi đi.

Tránh trường hợp xấu nhất là hệ thống có thể bị tấn công và bị lộ các thông tin đó gây ra thiệt hại lớn. Hầu hết các shipper của một vài ứng dụng quản lý dữ liệu log hiện như ELK đều hỗ trợ mã hóa SSL. Vì thế chúng ta luôn phải sử dụng khi gửi dữ liệu qua mạng, trừ khi có một vài trường hợp với lý do chính đáng. Hệ thống quản lý tích hợp dữ liệu sử dụng một cổng duy nhất để truyền tải dữ liệu giữa shipper và parser, các dữ liệu có thể được mã hóa trước khi gửi để đảm bảo vấn đề bảo mật thông tin.

Vậy sự khác biệt giữa một shipper và một parser là gì? Cả hai thành phần này có chức năng tương tự là đều thực hiện thu thập dữ liệu từ các nguồn và gửi dữ liệu tới các đích đến. Trong một vài trường hợp các parser được sử dụng như là các shipper, nhưng có một điều quan trọng khác nhau giữa chúng: Parser luôn được sử TIEU LUAN MOI download : skknchat@gmail.com 18 dụng để thực hiện xử lý trích lọc, quy về dữ liệu có cấu trúc, tags các thông tin từ các dữ liệu thu thập được và việc xử lý này tốn rất nhiều tài nguyên CPU. Chạy các parser cùng với các ứng dụng trên cùng một server sẽ gây ra các việc xử lý quá tải không cần thiết. Trong một vài trường hợp cụ thể mà chúng ta chủ định thực hiện triển khai chúng trên cùng một server, điều cần thiết là phải ước lượng và kiểm soát được rằng không ảnh hưởng tới hiệu năng của các ứng dụng hiện tại.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ