Vấn đề dữ liệu lớn
Khối lượng dữ liệu lớn đang tăng lên theo cấp số nhân. Hiện tượng này đã xảy ra trong nhiều năm, nhưng tốc độ của nó đã tăng nhanh đáng kể kể từ năm 2012. Hãy xem blog này có tựa đề Big Data Just Beginning to Explode từ CSC để có quan điểm tương tự về sự xuất hiện của dữ liệu lớn và những thách thức liên quan đến nó.
IRI đã nhận thức được xu hướng này kể từ khi thành lập công ty vào cuối những năm 1970. Gói CoSort hàng đầu của nó được thiết kế để xử lý khối lượng dữ liệu ngày càng tăng thông qua hiệu quả trong các thuật toán và thiết kế phần mềm, kỹ thuật khai thác phần cứng “di động” và hợp nhất tác vụ (ví dụ:sort-join-tổng hợp-mã hóa-báo cáo). Câu hỏi mà bài viết này đặt ra là một trong những cách tiếp cận, dựa trên “sự phát triển của máy móc”.
Giới hạn phần cứng trong việc giải quyết nó
Chắc chắn hiệu suất máy tính đã tăng nhanh về mọi mặt trong nhiều thập kỷ. Và đối với nhiều người, việc ném phần cứng vào vấn đề dữ liệu lớn chỉ là bản chất thứ hai. Tuy nhiên, vấn đề có thể lớn hơn thế. Hãy xem xét Định luật Moore, trong đó sức mạnh của CPU chỉ tăng gấp đôi tốt nhất là 18 tháng một lần và các vấn đề lỗi thời, bảo trì và chi phí thuần túy của chiến lược tập trung vào phần cứng.
Một điều gì đó mới mẻ cũng cần được xem xét là kỳ vọng rằng mô hình hiệu suất cho dữ liệu lớn này có thể sắp kết thúc. Theo Gery Menegaz, tiền đề của ông là sự kết thúc của Định luật Moore đã gần kề. Tạp chí Time đã đăng một câu chuyện tương tự vào tháng 5 năm 2012 với tựa đề Sự sụp đổ của Định luật Moore:Nhà vật lý học nói nó đã xảy ra. Theo bài báo Time,
Do đó, Kaku nói rằng khi Định luật Moore cuối cùng sụp đổ vào cuối thập kỷ tới, chúng tôi sẽ “chỉ cần chỉnh sửa [nó] một chút với các máy tính dạng chip trong không gian ba chiều.” Ngoài ra, ông nói “chúng ta có thể phải sử dụng máy tính phân tử và có lẽ là cuối thế kỷ 21 máy tính lượng tử.”
Tuy nhiên, đối với hầu hết người dùng, phần cứng của họ được mua để xử lý, và ở một mức độ nào đó, để đáp ứng những thách thức xử lý dữ liệu lớn mà họ phải đối mặt hoặc thấy trước. Nhưng phần mềm chạy trên nó càng hoạt động kém hiệu quả thì càng phải sử dụng nhiều tài nguyên phần cứng để khắc phục tình trạng kém hiệu quả. Một ví dụ trong thế giới của chúng ta có thể là mua một chiếc IBM p595 để chạy / bin / sort khi một chiếc máy có kích thước và chi phí bằng 1/3 chạy CoSort thay thế sẽ tạo ra kết quả tương tự.
Trong khi đó, các thiết bị DB và ELT như Exadata và Netezza được xây dựng dựa trên phần cứng đã yêu cầu đầu tư 6-7 con số. Và trong khi họ có thể mở rộng quy mô để đảm nhận các tải lớn hơn, thường có giới hạn về mức độ họ có thể mở rộng (chắc chắn không theo cấp số nhân), số tiền có thể được chi cho nỗ lực duy trì quy mô và mức độ sẵn sàng của mọi người dựa vào nhà cung cấp duy nhất cho mọi khía cạnh quan trọng của sứ mệnh trong khối lượng công việc của họ. Và, liệu có nên áp đặt chi phí chuyển đổi dữ liệu lớn trong cơ sở dữ liệu được thiết kế để tối ưu hóa lưu trữ và truy xuất (truy vấn) thay thế không?
Ngay cả khi tất cả những câu hỏi đó đều có câu trả lời dễ dàng, thì làm cách nào để giải quyết các vấn đề tính toán (thậm chí chỉ tăng trưởng theo quy mô tuyến tính của dữ liệu lớn) đòi hỏi mức tiêu thụ tài nguyên lớn hơn theo cấp số nhân (như sắp xếp)? Bằng cách nào đó, câu trả lời dường như không chỉ nằm ở việc chờ đợi máy tính lượng tử giá cả phải chăng…
Vai trò của phần mềm
Như các kiến trúc sư của Hadoop và kho dữ liệu đã biết, Sắp xếp - và các hoạt động Tham gia, Tổng hợp và Tải trong ETL dựa vào Sắp xếp - là trung tâm của thách thức xử lý dữ liệu lớn và là người tiêu dùng theo cấp số nhân của tài nguyên máy tính. Khi dữ liệu lớn tăng gấp đôi, các yêu cầu về tài nguyên để sắp xếp nó có thể tăng gấp ba. Do đó, các thuật toán, kỹ thuật khai thác phần cứng và kế hoạch xử lý liên quan đến phần mềm phân loại đa nền tảng, đa lõi là chìa khóa để quản lý vấn đề này theo những cách có thể mở rộng, giá cả phải chăng và hiệu quả.
Đóng góp của CoSort
Hiệu suất của CoSort tính theo khối lượng một cách tuyến tính, theo các dòng của Định luật Amdahl. Trong khi CoSort có thể chuyển đổi hàng trăm gigabyte dữ liệu lớn trong vài phút với vài chục lõi, các công cụ khác có thể mất nhiều thời gian hơn gấp đôi, không mở rộng quy mô gần bằng và / hoặc tiêu tốn nhiều bộ nhớ và I / O hơn trong quá trình này. Có lẽ quan trọng hơn, CoSort tích hợp phân loại trực tiếp vào các ứng dụng liên quan và thực hiện tất cả các công việc nặng nhọc của nó bên ngoài lớp DB và BI, nơi dữ liệu dàn dựng sẽ kém hiệu quả hơn.
Kiến trúc đồng quy trình của CoSort di chuyển các bản ghi giữa trình sắp xếp và các chương trình như SortCL (tiện ích chuyển đổi, lọc, tra cứu, báo cáo, di chuyển và bảo vệ dữ liệu của CoSort) một cách tương tác thông qua bộ nhớ. Vì vậy, ngay khi có bản ghi được sắp xếp tiếp theo, nó có thể di chuyển vào ứng dụng, tải, v.v. Có vẻ như ứng dụng đang đọc tệp đầu vào nhưng trên thực tế, phần cuối của nguồn vẫn chưa được tạo. Và không, bạn sẽ không vượt lên được trình sắp xếp.
Vào cuối năm 2015, CoSort cũng đã trở thành công cụ bên trong nền tảng thao tác và quản lý dữ liệu lớn hiện đại của IRI, Voracity. Voracity thúc đẩy cả hai công cụ CoSort hoặc Hadoop một cách liền mạch.
Kết luận
Không thể chỉ tính riêng tài nguyên máy tính vật lý để mở rộng quy mô cho vấn đề xử lý dữ liệu lớn. Môi trường phần mềm CoSort là môi trường yêu cầu chuyển đổi dữ liệu lớn và các công việc liên quan không phải chạy như các quy trình độc lập mà chạy song song trong cùng một lần chuyển I / O.
Vì vậy, nếu bạn cần sắp xếp nhanh cho một số mục đích khác ngoài thời gian để sắp xếp, bạn nên suy nghĩ về những gì xảy ra sau khi sắp xếp và những cách tốt nhất để liên kết các quy trình như vậy với nhau. Và một khi bạn đã xác định được mô hình thời gian chạy tốt nhất, liệu bạn có thể kết hợp phần cứng hiệu suất cao với phần mềm như vậy để tối ưu hóa hiệu suất không? Ví dụ, bạn có thể phân chia dữ liệu DW với CoSort trong phía máy chủ cơ sở dữ liệu của Exadata không? Hay sẽ có ý nghĩa hơn nếu giữ IBM p595 của bạn và thêm CoSort để tăng gấp ba lần thông lượng? Hoặc nếu bạn có ý định sử dụng Hadoop, hãy cân nhắc sử dụng cùng một 4GL CoSort đơn giản hoặc ánh xạ ETL trực quan của Voracity để thúc đẩy các công việc MapReduce 2, Spark, Storm hoặc Tez.
Hãy để ngân sách và trí tưởng tượng của bạn làm hướng dẫn cho bạn để giải quyết vấn đề tăng trưởng dữ liệu.
