3.1.1. Động cơ thúc đẩy
Đây là một lĩnh vực đang thu hút được nhiều quan tâm hiện nay. Tuy nhiên những tài liệu nghiên cứu về thời gian thực và làm thế nào để tạo ra thời gian thực có rất ít, dường như giải pháp cho báo cáo thời gian thực vẫn trong giai đoạn thử nghiệm nên những thuật toán cho thời gian thực vẫn chưa được công bố nhiều. Vì vậy để xây dựng BI thời gian thực là một thách thức với các nhà phát triển của nước ta, trong khi nhu cầu về báo cáo thời gian thực ngày càng lớn trong nhiều lĩnh vực.
Theo sự hiểu biết của mình, tôi thấy Google Analystic dùng để theo dõi và phân tích truy cập các trang Web, mới bắt đầu thử nghiệm với dạng báo cáo thông minh thời gian thực ở bản beta như hình 3.1.
Hình 3.1: Báo cáo thời gian thực của Google Analystic
Theo hình trên ta có thể theo dõi được các thông số theo thời gian thực, Google Analystic đã tạo các biểu đồ theo dõi và cập nhật từng phút và từng giây, thậm chí ta có thể biết được người truy cập đang ở vị trí địa lý nào. Với
báo cáo này, người quản lý có thể theo dõi thường xuyên tình trạng trang Web của mình. Theo đánh giá của tôi các báo cáo này được gọi là báo cáo liên tục. Trên thế giới các nghiên cứu về báo cáo liên tục chủ yếu được áp dụng cho hệ thống GPS để theo dõi tình hình giao thông. Do đó trong luận văn này tôi muốn nghiên cứu về thuật toán báo cáo liên tục ứng dụng vào trong việc xây dựng báo cáo BI thời gian thực và kỹ thuật để tạo báo cáo liên tục bằng công nghệ của Microsoft. Tiếp theo trong phần 3.1.2, tôi sẽ trình bày về luồng dữ liệu và báo cáo liên tục (Continuous Queries). Phần 3.1.3 tôi sẽ trình bày về kiến trúc của truy vấn liên tục.
3.1.2. Tìm hiểu luồng dữ liệu và báo cáo liên tục
Các hệ thống quản trị cơ sở dữ liệu truyền thống (DBMS) được dành cho quản lý các tập dữ liệu (Data sets) có tính chất ít thay đổi về mặt giá trị theo thời gian. Tuy nhiên với những ứng dụng gần đây, các khái niệm luồng dữ liệu liên tục phù hợp hơn với khái niệm tập dữ liệu hiện tại. Bởi vì với những tập dữ liệu được lưu trữ chỉ phù hợp với dạng dữ liệu tĩnh được truy vấn lặp đi lặp lại và ít hoặc không thường xuyên thay đổi về mặt giá trị thông tin của nó. Trong khi đó luồng dữ liệu phù hợp hơn với dạng dữ liệu thay đổi thường xuyên (như chèn dữ liệu thường xuyên).
Ngày nay rất nhiều ứng dụng sinh ra những luồng dữ liệu như các phần mềm kiểm tra dữ liệu tài chính, các phần mềm theo dõi và đánh giá lưu lượng mạng, các trang Web có theo dõi tình trạng tham gia sử dụng của người dùng (số lần truy cập, số lần click chuột), các ứng dụng liên quan đến bộ cảm biến dữ liệu, các bản ghi chi tiết cuộc gọi trong viễn thông, … Tuy nhiên hiện nay các hệ thống cơ sở dữ liệu còn thiếu trang bị để có khả năng quản lý, lưu trữ hay xử lý truy vấn trong các luồng dữ liệu nên các ứng dụng phải xử lý các luồng dữ liệu lớn có xu hướng DBMS như một hệ thống lưu trữ ngoài hoặc không sử dụng. Hay nói cách khác, công việc xử lý luồng dữ liệu như một sự
bổ sung kết hợp với một hệ thống DBMS. Trong đề tài này tác giả tập trung nghiên cứu xử lý truy vấn liên tục cho các luồng dữ liệu liên tục.
Một truy vấn phạm vi (range query) tĩnh hoặc động được gọi là một truy vấn (phạm vi) liên tục nếu nó truy xuất liên tục các đối tượng chuyển động bên trong nó trong một khoảng thời gian như theo dõi các đối tượng chuyển động đang di chuyển trong một khu vực giao thông hoặc không gian. Nói cách khác, một truy vấn liên tục duy trì hoạt động trong một khoảng thời gian nhất định cho đến khi nó được chấm dứt bởi người sử dụng. Chúng ta có thể hiểu truy vấn liên tục là: “Các truy vấn được kích hoạt một lần và sau đó tiếp tục hoạt động để có kết quả liên tục theo thời gian” [5] (Ngược lại với các truy vấn truyền thống là các truy vấn này chỉ chạy một lần và kết thúc với các tập dữ liệu hiện tại).
Ví dụ: Trong quản lý lưu lượng mạng các truy vấn liên tục có thể được sử dụng để theo dõi trực tuyến các hành vi mạng để tìm ra điểm dị thường (như nghẽn liên kết ) và các nguyên nhân (như lỗi phần cứng, bị tấn công từ chối dịch vụ). Các truy vấn có thể được sử dụng để cân bằng tải hoặc các điều chỉnh hiệu suất mạng. Với các ứng dụng tài chính truy vấn liên tục có thể được sử dụng để theo dõi xu hướng và phát hiện các cơ hội để lướt sóng. Rõ ràng cả hai ứng dụng trên đều đòi hỏi quá trình xử lý dữ liệu phải nhanh, kịp thời đưa ra các thông số quan trọng để ra quyết định. Để đáp ứng đòi hỏi này ta cần sự hỗ trợ của truy vấn liên tục nhằm xử lý các luồng dữ liệu nhanh và có các câu trả lời trực tuyến kịp thời sẽ tốt hơn so với cách sử dụng truy vấn thông thường mỗi lần cần thông tin lại phải gọi một truy vấn.
3.1.3. Thuật toán truy vấn liên tục
Ở phần này tôi sẽ trình bày các tình huống trong luồng dữ liệu liên tục và thuật toán cho truy vấn liên tục.
a. Các giả thiết về truy vấn liên tục
Giả thiết rằng chúng ta có luồng dữ liệu liên tục các bản ghi và một truy vấn Q, chúng ta cần kết quả trả lời của Q dựa trên luồng dữ liệu đó như miêu tả hình 3.2 dưới đây:
Hình 3.2: Kiến trúc truy vấn liên tục trong luồng dữ liệu
Vì Q là một truy vấn liên tục do đó nó sẽ được kích hoạt một lần và hoạt động liên tục đón các bản ghi mới trong luồng dữ liệu đó. Với giả thiết rằng chúng ta cần kết quả trả lời chính xác của Q (trong tình huống khác có thể là xấp xỉ). Hơn nữa chúng ta giả thiết luồng dữ liệu này chỉ có thêm mới mà không có cập nhật hay xóa dữ liệu. Vì vậy kích thước của luồng dữ liệu này là không giới hạn bổ sung mới cho cơ sở dữ liệu D, chúng ta có một số tình huống để thực hiện Q sau đây [2] [3]:
(1) Giả thiết chúng ta muốn lưu toàn bộ kết quả trả lời A của Q. Vì cơ sở dữ liệu D là có kích thước không giới hạn, kích thước của A cũng không giới hạn (Ví dụ như Q là truy vấn Select).
(2) Giả thiết chúng ta không cần lưu giữ kết quả A thay vào đó chúng chỉ cần các bản ghi mới của A khi chúng sinh ra từ các luồng dữ liệu liên tục. Mặc dù chúng ta không cần lưu trữ cho A nhưng chúng ta sẽ vẫn cần không gian để giữ các bản ghi đó nhằm xác định các bản ghi mới trong A. (Ví dụ Q là một self-join).
(3) Thậm chí khi luồng dữ liệu chỉ thêm mới thì vẫn có thể xảy ra trường hợp thay đổi, xóa bản ghi trong kết quả trả lời A. (Ví dụ như Q là 1 truy vấn Group by với tính toán tổng hợp dữ liệu). Bây giờ trong trường hợp 2 ở trên
----<A,B><B,C><A,D>----
Luồng dữ liệu liên tục
Truy vấn liên tục
Q A Kết quả
chúng ta có thể phải thay đổi hoặc xóa bản ghi trong luồng dữ liệu ra (Luồng dữ liệu kết quả) cùng với các bản ghi được bổ sung mới.
(4) Trong phần lớn các trường hợp tổng hợp chung, luồng dữ liệu đầu vào có thể bao gồm cả cập nhật và xóa. Trong trường hợp này sẽ phải có nhiều luồng dữ liệu cần phải lưu trữ để xác định kết quả chính xác ở Q. Do đó nảy sinh vấn đề cần phải giới hạn kích thước A, khi đó kết quả trả lời truy vấn liên tục chỉ tính xấp xỉ. Tuy nhiên trong đề tài này tôi chưa đề cập đến vấn đề xấp xỉ của truy vấn liên tục.
b. Kiến trúc
Trong phần này tôi sẽ đưa ra một kiến trúc cho việc xử lý truy vấn liên tục trên các luồng dữ liệu như được mô tả trong hình 3.3.
Hình 3.3: Mô hình kiến trúc xử lý truy vấn liên tục
Chúng ta sẽ xem xét tình huống một truy vấn liên tục với kết quả trả lời A hoạt động trên một số luồng dữ liệu vào. Nhiều truy vấn liên tục cũng có thể được sử dụng với kiến trúc này như trong hình vẽ, hơn nữa kiến trúc này cũng có thể áp dụng cho các dữ liệu đầu vào kết hợp với các bảng sơ sở dữ liệu truyền thống.
Khi truy vấn Q kết luận rằng một bản dữ liệu mới t có trong một luồng dữ liệu, nó sẽ thực hiện một số hành động sau:
Stream 1 Stream 2 . . . Stream n Q Store Scratch Throw Stream
(i) Phải xác định rằng bởi vì t mà kết quả trả lời A sẽ có những bản ghi mới. Nếu mỗi bản ghi mới a trong A sẽ duy trì trong A “vĩnh viễn hay lâu dài” thì Q sẽ gửi các bản ghi a tới thành phần Stream (Luồng). Stream chứa một luồng dữ liệu được bổ xung vào A
(ii) Nếu bản ghi mới a được xác định thuộc A nhưng một lúc nào đó không thuộc A thì a sẽ được thêm vào thành phần Store (Kho) mô tả ở hình 3.3. Nói một cách khác Stream và Store sẽ xác định kết quả trả lời hiện tại của A. Nếu muốn tối thiểu không gian lưu trữ kết quả truy vấn thì các bản ghi mới sẽ được gửi thẳng tới Stream, Store bất kể khi nào.
(iii) Nếu một bản ghi mới trong luồng có thể gây nên hiện tượng thay đổi và xóa các bản ghi kết quả trả lời trong Store, các bản ghi kết quả trả lời có thể được chuyển từ Store qua Stream.
(iv) Chúng ta có thể cần lưu lại t hoặc dữ liệu dẫn xuất từ t, vì trong tương lai chúng ta có thể cần chúng để đảm bảo tính toán được kết quả truy vấn. Trong trường hợp này t hoặc dữ liệu dẫn xuất từ t có thể được gửi đến Scratch (Nháp). Kết hợp với hành động (iii) chúng ta cũng có thể chuyển dữ liệu từ store sang Scratch.
(v) Nếu chúng ta không cần t thì t sẽ được gửi đến thành phần Throw (Bỏ). Xem hình 3.3 với chú ý rằng Throw không cần bất kỳ không gian lưu trữ nào (trừ khi chúng ta quan tâm tới việc thu thập dữ liệu không cần thiết).
(vi) Với bản ghi mới t trong luồng dữ liệu, chúng ta có thể dùng để thay thế bản ghi dữ liệu đã lưu trong Stream hoặc Store trước đó và bản ghi trước đó đưa vào Throw. Nếu chúng ta muốn tối thiểu hóa không gian lưu trữ thì chúng ta cần bảo đảm rằng dữ liệu không cần thiết trong mọi trường được gửi đến Throw, hơn là Scratch.
3.1.4. Các tình huống xử lý truy vấn
Với các tình huống xử lý truy vấn từ (1) đến (4) và thuật toán đưa ra trong mục 3.1.3. Trong tình huống (1) chúng ta muốn lưu kết quả trả lời A của Q. Theo thuật toán Stream sẽ là rỗng, Store sẽ chứa toàn bộ A, Scratch sẽ lưu giá trị nào đó mà cần cho cập nhật kết quả trong Store. Ví dụ Q là truy vấn Select, Store có kích thước không giới hạn, trong khi Scratch là rỗng. Ngược lại trong tình huống (2), chúng ta sẽ để cho A như một luồng dữ liệu, Stream sẽ là luồng dữ liệu chứa toàn bộ kết quả trả lời tới A, trong khi Store là rỗng. Ví dụ Q là một self-join, chúng ta có thể gửi toàn bộ những bản ghi kết quả tới Stream vì sẽ duy trì kết quả trong mãi mãi, nhưng Scratch có thể cần phải có kích thước giới hạn.
Với tình huống (3) kết quả trả lời A có hiện tượng chuyển đổi hoặc xóa ngay cả khi các luồng dữ liệu vào chỉ có thêm mới. Ví dụ một truy vấn thực hiện các phép phân nhóm hoặc tổng hợp. Trong tình huống (4) khi các luồng dữ liệu vào có thể có cập nhật và xóa. Ví dụ giả thiết Q là một truy vấn Group by trên một luồng dữ liệu với một hàm tổng hợp min. Bởi vì min là đồng điệu với thêm mới. Trong tình huống (3) A được duy trì trong Store, Scratch có thể rỗng. Trong tình huống (4) không gian lưu trữ không giới hạn là cần thiết cho Scratch để bảo đảm các giá trị min luôn được tính toán trong toàn bộ dữ liệu. Trong cả hai trường hợp (3) và (4) khi một số nhóm không có thêm, chuyển đổi hoặc xóa các bản ghi trong nhóm thì bản ghi kết quả trả lời chỉ có trong Stream hoặc chuyển từ Store sang Stream.
3.1.5. Ý tƣởng của đề tài
Trong khi các ứng dụng cơ sở dữ liệu quan hệ dựa trên truy vấn đã thành điển hình, các ứng dụng hướng sự kiện cũng đã trở nên ngày càng quan trọng. Các ứng dụng hướng sự kiện được đặc trưng bởi tốc độ dữ liệu sự kiện cao,
các truy vấn liên tục và yêu cầu độ trễ vào khoảng millisecond, do vậy lưu trữ dữ liệu trong một cơ sở dữ liệu quan hệ để xử lý là không thực tế. Những yêu cầu chia sẻ bởi chiều dọc các thị trường như dịch vụ tài chính, y tế, giám sát, sản xuất, dầu khí, giao thông vận tải, các tiện ích và phân tích Web.
Hình 3.4: Kiến trúc tạo báo cáo BI sử dụng thuật toán truy vấn liên tục
Ở phần này tôi sẽ trình bày kiến trúc tạo báo cáo thời gian thực cho BI sử dụng StreamInsight để xử lý cho truy vấn liên tục trong BI được thể hiện như hình 3.4 với tình huống (2) của mục 3.1 trong đó giả thiết các luồng dữ liệu đầu vào là chỉ thêm mới, dữ liệu đầu ra chỉ quan tâm đến dữ liệu mới và toàn bộ dữ liệu của truy vấn liên tục sẽ không được lưu trữ. Thử nghiệm thuật toán cho tình huống (2) trong truy vấn liên tục này. Phần 3.2 cung cấp một cái nhìn tổng quan về StreamInsight – một nền tảng của Microsoft SQL Server để xử lý sự kiện phức tạp công suất cao, độ trễ thấp. StreamInsight cho phép các nhà phát triển phần mềm tạo ra các giải pháp CEP theo hai kịch bản là xây dựng đóng gói các ứng dụng hướng sự kiện và phát triển tùy chỉnh các ứng dụng hướng sự kiện cho các doanh nghiệp, đồng thời sẽ mô tả kiến trúc StreamInsight và các thành phần chính để làm thế nào viết các truy vấn liên tục, phân tích và xử lý các sự kiện qua hệ thống.
Bộ xử lý liên tục luồng dữ liệu
Adapter Input Adapter Output Streaming Data sources: Devices, sensors Web servers Event strores, Database Stock ticker Output BI Report Web
3.2. Microsoft StreamInsight và báo cáo trong BI
Thời gian thực của báo cáo đề cập đến một quá trình mà trong đó người dùng sẽ nhận được một báo cáo tại thời điểm các dữ liệu giao dịch xảy ra ở một nơi nào đó trong hệ thống của tổ chức. Khách quan mà nói, chúng ta thấy khả năng này không bao giờ có thể thực hiện được trong thực tế vốn chịu ảnh hưởng của rất nhiều yếu tố. Với báo cáo thời gian thực chúng ta có thể hiểu theo nghĩa giảm thời gian trễ trong báo cáo tới xấp xỉ một giây hay đến mili giây báo cáo cho một sự kiện phát sinh. Đây là một dạng báo cáo rất quan trọng trong hệ thống BI.
Microsoft StreamInsight là một nền tảng mạnh có thể sử dụng để phát triển và triển khai ứng dụng xử lý những sự kiện phức tạp (CEP). Kiến trúc chung cho một ứng dụng dựa trên StreamInsight được thể hiện trong hình 3.5.
Hình 3.5: Nền tảng ứng dụng StreamInsight
Dựa trên kiến trúc xử lý thông lượng cao trên nền tảng phát triển Microsoft .NET, bạn có thể nhanh chóng tạo ra các ứng dụng lấy dữ liệu từ
nhiều nguồn sự kiện ngay lập tức (thường lấy từ các ứng dụng sản xuất, các ứng dụng tài chính trong kinh doanh, phân tích Web và phân tích hoạt động) và xuất ra thông tin quan trọng vào những thiết bị hiển thị hoặc kho dữ liệu của hệ thống hình 3.5
StreamInsight không chỉ giúp giảm chi phí từ việc khai thác, phân tích