Tôi nghĩ rằng sự khác biệt chính mà tôi có thể mô tả liên quan đến các định dạng ghi theo định hướng so với cột. Các định dạng định hướng bản ghi là những gì chúng ta đều sử dụng - các tệp văn bản, các định dạng được phân tách như CSV, TSV. AVRO mát hơn một chút vì nó có thể thay đổi lược đồ theo thời gian, ví dụ: thêm hoặc xóa các cột khỏi bản ghi. Các thủ thuật khác của các định dạng khác nhau (đặc biệt là nén) liên quan đến việc có thể tách một định dạng hay không - nghĩa là bạn có thể đọc một khối các bản ghi từ bất kỳ đâu trong tập dữ liệu mà vẫn biết lược đồ của nó không? Nhưng đây là chi tiết hơn về các định dạng cột như Parquet.
Sàn gỗ và các định dạng cột khác xử lý tình huống Hadoop chung rất hiệu quả. Thông thường có các bảng (bộ dữ liệu) có nhiều cột hơn bạn mong đợi trong cơ sở dữ liệu quan hệ được thiết kế tốt - một trăm hoặc hai trăm cột không phải là bất thường. Điều này là như vậy bởi vì chúng ta thường sử dụng Hadoop như một nơi để chuẩn hóa dữ liệu từ các định dạng quan hệ - vâng, bạn nhận được rất nhiều giá trị lặp lại và nhiều bảng được làm phẳng thành một bảng. Nhưng nó trở nên dễ dàng hơn để truy vấn vì tất cả các phép nối được thực hiện. Có những lợi thế khác như giữ lại dữ liệu theo thời gian. Vì vậy, dù sao đi nữa cũng có một thuyền cột trong một bảng.
Giả sử có 132 cột và một số trong số chúng là các trường văn bản thực sự dài, mỗi cột khác nhau nối tiếp nhau và sử dụng tối đa 10 nghìn cho mỗi bản ghi.
Mặc dù việc truy vấn các bảng này rất dễ dàng với quan điểm SQL, nhưng thông thường bạn sẽ muốn nhận được một số phạm vi bản ghi chỉ dựa trên một vài trong số hàng trăm cột đó. Ví dụ: bạn có thể muốn tất cả các bản ghi vào tháng 2 và tháng 3 cho khách hàng có doanh số> $ 500.
Để thực hiện điều này trong một định dạng hàng, truy vấn sẽ cần quét mọi bản ghi của tập dữ liệu. Đọc hàng đầu tiên, phân tích bản ghi thành các trường (cột) và lấy cột ngày và cột bán hàng, đưa nó vào kết quả của bạn nếu nó thỏa mãn điều kiện. Nói lại. Nếu bạn có 10 năm (120 tháng) lịch sử, bạn đang đọc từng bản ghi chỉ để tìm 2 trong số những tháng đó. Tất nhiên đây là cơ hội tuyệt vời để sử dụng phân vùng theo năm và tháng, nhưng ngay cả như vậy, bạn đang đọc và phân tích 10K mỗi bản ghi / hàng trong hai tháng đó chỉ để xem liệu doanh số của khách hàng có> 500 đô la hay không.
Trong định dạng cột, mỗi cột (trường) của một bản ghi được lưu trữ cùng với các loại khác, trải đều trên nhiều khối khác nhau trên đĩa - các cột trong năm với nhau, các cột cho tháng, các cột cho sổ tay nhân viên khách hàng (hoặc khác văn bản dài) và tất cả những thứ khác làm cho những bản ghi đó trở nên rất lớn, nằm ở vị trí riêng biệt trên đĩa và tất nhiên là các cột để bán cùng nhau. Chà, ngày và tháng là những con số, và doanh số cũng vậy - chúng chỉ là một vài byte. Sẽ không tuyệt sao nếu chúng ta chỉ phải đọc một vài byte cho mỗi bản ghi để xác định bản ghi nào phù hợp với truy vấn của chúng tôi? Cột lưu trữ để giải cứu!
Ngay cả khi không có phân vùng, việc quét các trường nhỏ cần thiết để đáp ứng truy vấn của chúng tôi là cực nhanh - tất cả đều theo thứ tự theo bản ghi và tất cả cùng kích thước, do đó, đĩa tìm kiếm kiểm tra dữ liệu ít hơn nhiều cho các bản ghi được bao gồm. Không cần phải đọc qua sổ tay nhân viên đó và các trường văn bản dài khác - chỉ cần bỏ qua chúng. Vì vậy, bằng cách nhóm các cột với nhau, thay vì các hàng, bạn hầu như luôn có thể quét ít dữ liệu hơn. Thắng lợi!
Nhưng chờ đợi, nó sẽ tốt hơn. Nếu truy vấn của bạn chỉ cần biết các giá trị đó và một vài giá trị khác (giả sử 10 trong số 132 cột) và không quan tâm đến cột sổ tay nhân viên đó, một khi đã chọn đúng các bản ghi để trả về, thì bây giờ sẽ chỉ phải đi trở lại 10 cột cần thiết để hiển thị kết quả, bỏ qua 122 cột khác trong 132 dữ liệu của chúng tôi. Một lần nữa, chúng tôi bỏ qua rất nhiều đọc.
(Lưu ý: vì lý do này, các định dạng cột là một lựa chọn tệ hại khi thực hiện các phép biến đổi thẳng, ví dụ: nếu bạn tham gia cả hai bảng vào một kết quả (ger) lớn mà bạn đang lưu dưới dạng bảng mới, các nguồn Dù sao cũng sẽ được quét hoàn toàn, vì vậy không có nhiều lợi ích trong hiệu suất đọc và vì các định dạng cột cần nhớ nhiều hơn về vị trí của công cụ, nên chúng sử dụng nhiều bộ nhớ hơn định dạng hàng tương tự).
Thêm một lợi ích của cột: dữ liệu được lan truyền xung quanh. Để có được một bản ghi, bạn có thể có 132 công nhân mỗi lần đọc (và ghi) dữ liệu từ / đến 132 vị trí khác nhau trên 132 khối dữ liệu. Yay cho song song!
Và bây giờ đối với clincher: các thuật toán nén hoạt động tốt hơn nhiều khi nó có thể tìm thấy các mẫu lặp lại. Bạn có thể nén AABBBBBBCCCCCCCCCCCCCCCCnhư 2A6B16Cnhưng ABCABCBCBCBCCCCCCCCCCCCCCsẽ không nhỏ như vậy (thực ra, trong trường hợp này là vậy, nhưng hãy tin tôi :-)). Vì vậy, một lần nữa, ít đọc. Và viết cũng vậy.
Vì vậy, chúng tôi đọc ít dữ liệu hơn để trả lời các truy vấn phổ biến, có khả năng đọc và viết song song nhanh hơn và nén có xu hướng hoạt động tốt hơn nhiều.
Cột là tuyệt vời khi phía đầu vào của bạn lớn và đầu ra của bạn là một tập hợp con được lọc: từ lớn đến nhỏ là tuyệt vời. Không có lợi khi đầu vào và đầu ra giống nhau.
Nhưng trong trường hợp của chúng tôi, Impala đã lấy các truy vấn Hive cũ của chúng tôi chạy trong 5, 10, 20 hoặc 30 phút và hoàn thành hầu hết trong vài giây hoặc một phút.
Hy vọng điều này sẽ giúp trả lời ít nhất một phần câu hỏi của bạn!