Trong bài báo [15] đã sử dụng BigQuery, công cụ dữ liệu lớn từ Google Cloud Platform để truy vấn SQL trên một khối lượng dữ liệu khổng lồ, cụ thể ở đây là các bảng có kích thước lên tới 12TB có trên hàng tỷ dòng dữ liệu.
Từ bảng task events thu được các dữ liệu theo thời gian cách nhau 5 phút. Tổng cộng 7 thuộc tính được trích xuất, có chung số lượng task hiện đang chạy, số lượng task đã bắt đầu trong 5 phút trước đó và tất cả đã kết thúc với cái trạng thái khác nhau gồm: evicted, failed, fished normally, killed, lost. Từ bảng task usage data (dữ liệu nhiệm vụ sử dụng), ta lấy thêm 5 thuộc tính (cứ khoảng 5 phút) tải trên máy gồm: CPU, memory, disk time, cycles per instruction (CPI) và memory access per instruction extracted (MAI). Kết quả ta có 12 thuộc tính được trích ra. Với mỗi bộ thuộc tính như vậy căn cứ theo thời gian ta lấy 6 lần mốc cửa sổ (windows)
tương ứng với trạng thái của máy trong suốt 30 phút trước đó được 72 thuộc tính (12 thuộc tính ban đầu x 6 mốc thời gian).
Với BigQuery thì thao tác trích xuất từ bảng dữ liệu gốc rất nhanh. Cho việc đếm số lượng task, ta bắt đầu với việc liên kết bảng running task, nơi mỗi dòng tương ứng với một task có các thuộc tính: start time, end time, end status và máy đang chạy task đó.
Bảng 3.1: Thời gian chạy của BigQuery để có được các tính năng được tổng hợp qua các cửa sổ thời gian khác nhau cho hai loại kết hợp: tính toán, độ lệch chuẩn (SD) và hệ số biến thể (CV) so với các tương quan máy tính. Đối với các cửa sổ 1 giờ và 12 giờ, mức trung bình, SD và CV được tính cho tất cả các tính năng trong một truy vấn. Đối với tất cả các trường hợp khác, độ lệch chuẩn (và độ lệch chuẩn) của thời gian yêu cầu cho mỗi tính năng được hiển thị.
Mức kết hợp thứ hai có nghĩa là xem các thuộc tính trong các cửa sổ thời gian dài hơn không chỉ là 5 phút cuối. Tại mỗi bước thời gian, 3 thống kê khác nhau - trung bình, độ lệch tiêu chuẩn và hệ số biến thiên - được tính cho từng thuộc tính cơ bản thu được ở bước trước. Điều này đã được thúc đẩy bởi sự nghi ngờ rằng không chỉ tính giá trị mà còn sai lệch của trung bình có thể là quan trọng trong việc hiểu hành vi của hệ thống. Sáu cửa sổ khác nhau có kích cỡ 1, 12, 24, 48, 72 và 96 giờ được sử dụng để nắm bắt hành vi ở các độ phân giải thời gian khác nhau. Điều này dẫn đến 216 tính năng bổ sung (3 thống kê × 12 tính năng × 6 kích cỡ cửa sổ).
Để tạo ra các tính năng tổng hợp này, một tập hợp các bảng trung gian đã được sử dụng. Đối với mỗi điểm thời gian, các bảng này bao gồm toàn bộ tập các điểm dữ liệu được tính trung bình. Ví dụ: đối với trung bình 1 giờ, bảng sẽ chứa 6 giá trị cho mỗi tính năng và cho mỗi điểm thời gian, cho thấy sự tiến triển của hệ thống trong một giờ qua. Trong khi tạo ra các bảng này không tốn nhiều thời gian (cần khoảng 197 đến 960 giây), kích thước khá ấn tượng: từ 143 GB (trên 1 tỷ hàng) trong 1 giờ đến 12,5 TB (trên 100 tỷ hàng) trong trường hợp Cửa sổ 96 giờ. Việc xử lý các bảng này để có được các tính năng tổng hợp quan tâm yêu cầu nguồn
tài nguyên quan trọng và sẽ không thể có nếu không có nền tảng BigQuery. Ngay cả khi đó, các truy vấn trực tiếp sử dụng một thao tác GROUP BY duy nhất để có được tất cả 216 tính năng là không thể, chỉ cần một tính năng cơ bản được xử lý tại một thời điểm và kết hợp các kết quả vào một bảng duy nhất ở cuối. Bảng 3.1 liệt kê số liệu thống kê theo thời gian cần thiết để có được một tính năng cho các kích cỡ cửa sổ khác nhau.
Mặc dù các giá trị tính độc lập rất quan trọng, nhưng một tiêu chí khác có thể là quan trọng cho dự đoán là các mối quan hệ tồn tại giữa các biện pháp khác nhau. Sự tương quan giữa các tính năng là một trong những biện pháp đó, với các giá trị tương quan khác nhau cho biết những thay đổi trong hành vi của hệ thống. Do đó, bài báo này đã giới thiệu mức kết tập dữ liệu thứ ba bằng cách tính các tương quan giữa một cặp đối tượng được chọn, một lần nữa qua các kích cỡ cửa sổ khác nhau (từ 1 đến 96 giờ như trước). Bài báo đã chọn 7 tính năng để phân tích: số lần chạy, bắt đầu và không thành công cùng với CPU, bộ nhớ, thời gian đĩa và chỉ số CPI. Bằng cách tính toán các mối tương quan giữa tất cả các kết nối có thể của 7 tính năng, luận văn đã thu được tổng cộng 21 giá trị tương quan cho mỗi kích thước cửa sổ. Điều này giới thiệu thêm 126 tính năng cho bộ dữ liệu. Phân tích BigQuery bắt đầu từ cùng các bảng trung gian như trước và tính tương quan cho một cặp trong một lần. Như có thể thấy trong Bảng 3.1, bước này tốn nhiều thời gian hơn, đòi hỏi nhiều thời gian hơn so với bước tổng hợp trước đó nhưng vẫn có thể quản lý được khi xem xét kích thước của dữ liệu. Số lượng dữ liệu được xử lý cho các truy vấn này dao động từ 49.6GB (cho mỗi cặp tính năng cho cửa sổ 1 giờ) đến 4.33TB (mỗi cặp tính năng cho cửa sổ 96 giờ), dẫn đến chi phí xử lý cao hơn (5 USD cho mỗi TB được xử lý). Tuy nhiên, một phân tích tương tự sẽ không thể thực hiện nếu không có nền tảng BigQuery.
Nhật ký theo dõi của Google cũng báo cáo sự kiện máy (machine event). Đây là các sự kiện lập lịch trình tương ứng với các máy được thêm vào hoặc loại bỏ khỏi các nguồn tài nguyên. Đặc biệt ta quan tâm là các máy có sự kiện XÓA, có thể là do hai nguyên nhân: lỗi máy hoặc cập nhật phần mềm máy. Mục tiêu của công việc này là để dự đoán các sự kiện XÓA do sự cố, do đó hai nguyên nhân phải được phân biệt. Các nhà xuất bản tập nhật kí của Google đã kiểm tra cách tốt nhất để thực hiện sự phân biệt này và gợi ý xem khoảng thời gian mà máy vẫn không hoạt động -
thời gian từ sự kiện XÓA quan tâm tới sự kiện THÊM tiếp theo cho cùng một máy. Nếu "thời gian trễ" này lớn, thì ta có thể giả định rằng sự kiện XÓA là do lỗi máy, trong khi nếu nhỏ, máy tính này hầu như được gỡ bỏ để thực hiện cập nhật phần mềm. Để đảm bảo rằng một sự kiện được coi là thất bại thực sự là một lỗi thực sự, bài báo đã sử dụng một ngưỡng thời gian "down time" tương đối dài là 2 giờ, lớn hơn thời gian cần cho một bản cập nhật phần mềm điển hình. Dựa vào ngưỡng này, trên tổng số 8.957 sự kiện XÓA, 2.298 đã được coi là thất bại và là mục tiêu của nghiên cứu dự báo. Đối với các sự kiện còn lại, ta không thể chắc chắn về nguyên nhân, điểm dữ liệu trong cửa sổ 24 giờ trước đó đã được xóa hoàn toàn khỏi bộ dữ liệu. Một giải pháp thay thế sẽ được coi là một phần của lớp SAFE, tuy nhiên điều này có thể không đúng đối với một số điểm. Vì vậy, loại bỏ chúng hoàn toàn đảm bảo rằng tất cả các dữ liệu có nhãn là SAFE (an toàn) trong thực tế SAFE.
Đối với các tính năng trên dựa chủ yếu vào các phép đo tải, ta đã thêm hai tính năng mới: thời gian tính thời gian của mỗi máy (thời gian kể từ lần kết cuối tương ứng) và số lần XÓA. Vậy cho toàn bộ cụm trong vòng một giờ trước. Kết quả là tổng cộng 416 tính năng cho 104.197.215 điểm dữ liệu (gần 300GB dữ liệu được xử lý). Hình 3.2 hiển thị chuỗi thời gian cho 4 tính năng được chọn (và các sự kiện XÓA) tại một máy điển hình.
Bốn chuỗi thời gian (4 trong 416 tính năng) cho một máy trong hệ thống. Các tính năng hiển thị là: CPU cho cửa sổ thời gian đã qua, trung bình CPU trên 12 giờ, hệ số hệ số biến thiên trong 12 giờ qua và tương quan giữa CPU và số lượng công việc đang chạy trong 12 giờ qua. Các đường thẳng màu xám cho biết thời gian f xóa các sự kiện, một số tiếp theo là khoảng trống trong đó máy không có sẵn. Khoảng trống lớn từ ~ 250 giờ đến ~ 370 giờ là một ví dụ về thời gian chết của máy dài, sau một loạt các lỗi không thành công (nhóm các đường thẳng màu xám trong khoảng 250 giờ). Trong trường hợp này, máy có thể cần kiểm tra và sửa chữa rộng rãi hơn trước khi đưa vào bộ dữ liệu của luận văn. Kết thúc quá trình ta được 2 files safe.24h và fail.24h.