Tại sao chúng tôi dạy gấu trúc thay vì SQL?

Ảnh của Pedro Gonzalez trên Unsplash

Ngày xửa ngày xưa có một sinh viên ham học hỏi khoa học dữ liệu.

Anh ấy hỏi mọi người rằng anh ấy nên làm gì, và họ bảo anh ấy học gấu trúc. Anh ấy lùng sục trên mạng để tìm các khóa học về dữ liệu, và tất cả đều có hình ảnh gấu trúc. Vì vậy, sinh viên đã học gấu trúc, và sau đó kiếm được việc làm trong học viện, nơi mọi người đều làm việc với gấu trúc.

Vì vậy, anh ấy đã làm việc với gấu trúc trong nhiều tuần trăng, cho đến khi anh ấy có thể cắt các khung dữ liệu trong giấc ngủ của mình. Khi xong việc, anh ấy tham gia vào một data bootcamp: lo và kìa, họ đang dạy gấu trúc. Khi anh ấy hoàn thành, bootcamp đã thuê anh ấy - dạy cho gấu trúc.

Rồi đến thời sinh viên vào công ty đầu tiên. Chủ nhân của anh ta muốn anh ta xử lý một số dữ liệu.

"Tôi sẽ sử dụng gấu trúc" học sinh nói.

"Bạn sẽ làm cái quái gì!" ông chủ nói. “Chúng tôi sử dụng S-Q-L ở đây”, anh ấy vặn lại, nhấn mạnh từng chữ cái bằng một nhát gậy của mình.

“Nhưng ... Nhưng ... Tính dài dòng ... Xấu xí ... Thiếu chức năng ... Làm tổ vô tận ... Và các liên kết, các liên kết thật kinh khủng! ..."

“Nếu bạn không thể nhìn thấy rừng, thì bạn không nên chạm vào cây cối”, ông chủ nói và đánh vào đầu anh ta.

Cậu sinh viên đã được khai sáng.

Hay anh nghĩ; trên thực tế, cú đánh của chủ nhân đã khiến anh ta choáng váng đến nỗi khả năng phán đoán của anh ta tạm thời bị suy giảm.

Nhiều trăng sau đó, sau một lần rút lui đau đớn, cậu học sinh đã hiểu SQL. Kể từ đó, anh ta không cảm thấy cần thiết phải sử dụng gấu trúc nữa, và người chủ không bao giờ giáng đòn nữa vào anh ta.

SQL >> Gấu trúc

Công án trên là tự truyện, mặc dù tôi nên nhận xét rằng không ai trong số những người giám sát của tôi đã từng đánh tôi (ngay cả khi họ nên làm như vậy).

Không có nhiều thay đổi kể từ khi tôi bắt đầu. Hầu hết các giáo trình đào tạo dữ liệu đều có sự đầu tư lớn vào gấu trúc (cùng với sổ ghi chép Jupyter) trong khi SQL tốt nhất là một sự suy nghĩ sau.

Tìm kiếm “khoa học dữ liệu” trên Udemy, và bạn sẽ thấy các khóa học hàng đầu đề cập đến Python (chắc chắn bao gồm gấu trúc) và R, đôi khi thậm chí là Scala. Rất ít người trong số họ đề cập đến SQL.

Tôi cho rằng điều này thật tệ, cả từ quan điểm giá trị lẫn quan điểm sư phạm.

Vấn đề giá trị

Nếu bạn đang thực hiện phân tích tiêu chuẩn, SQL đơn giản là một công cụ tốt hơn gấu trúc. Nó đơn giản hơn, rõ ràng hơn, mạnh mẽ hơn và hiệu quả hơn. Nó cũng dễ hiểu hơn, chia sẻ và tái sản xuất. Có một lý do tại sao nó là ngôn ngữ phổ biến của phân tích dữ liệu trong nhiều thập kỷ.

Nếu bạn đang tập trung vào Gấu trúc với chi phí là SQL, bạn đang bỏ lỡ việc trở thành một người thực hành dữ liệu tốt hơn, hiệu quả hơn.

Tất nhiên, có những thứ mà gấu trúc làm tốt hơn, và tôi khám phá chúng một cách ngắn gọn ở cuối bài viết. Nhưng nhìn chung, khi nói đến phân tích thuần túy, SQL khó bị đánh bại.

Mọi người thường không nhận thấy rằng gấu trúc giới thiệu chi phí đáng kể về độ phức tạp, kém hiệu quả, đặc trưng và cơ hội gây nhầm lẫn.

Vấn đề học tập

Tôi nghi ngờ rằng sự chú trọng quá mức vào gấu trúc làm tổn hại đến sinh viên dữ liệu. Theo kinh nghiệm của tôi, có một điểm mà việc làm nhiều gấu trúc dẫn đến phản học tập , tức là người đó đơn giản trở nên bối rối hơn theo thời gian.

Đặc biệt, các sinh viên mới gặp phải những vấn đề kỳ lạ khiến họ bối rối và họ phải bù đắp bằng cách ghi nhớ mù quáng.

Chúng cũng có những thói quen xấu khó bỏ sau này, như lặp lại các hàng khi chúng có thể sử dụng các thao tác trên bảng; tạo cột với nhiều kiểu hỗn hợp; lưu dữ liệu trong CSV; sửa đổi dữ liệu tại chỗ; làm tắc nghẽn bộ nhớ với nhiều bản sao và lát cắt của cùng một khung dữ liệu ... Tôi có thể tiếp tục.

Một phần của điều này là do Python là một ngôn ngữ cực kỳ khoan dung, đặt gánh nặng cho người dùng không làm những điều xấu (như Series gấu trúc với nhiều loại hỗn hợp). Một phần của nó đến từ việc gấu trúc chấp nhận (mặc dù không nhất thiết phải khuyến khích) một cách tiếp cận bắt buộc.

Ví dụ: nếu một học sinh muốn kết hợp dữ liệu từ hai bảng, không có gì ngăn cản cô ấy sử dụng thuật toán này:

1. Lặp lại table1

2. Đối với mỗi hàng table1 , hãy quét tất cả table2 để tra cứu

3. Cập nhật hàng trong table1 từ dữ liệu trong table2

   
   

Vâng, điều này rõ ràng là rất tệ. Nhưng người mới bắt đầu không biết bất kỳ tốt hơn.

Ngược lại, cách tiếp cận khai báo của SQL làm cho việc làm điều xấu trở nên khó khăn hơn.

Lập trình khai báo buộc người dùng phải suy nghĩ về kết quả mà họ muốn thấy, thay vì làm thế nào để tạo ra nó . Điều này mang lại cho họ không gian cần thiết để tập trung vào logic đằng sau phân tích của họ, thay vì liên tục bị sa lầy bởi các vấn đề và lỗi kỳ lạ.

SQL cũng buộc sinh viên phải suy nghĩ trong các bảng (tức là mô hình quan hệ) và các phép toán cấp cột, điều này rất có lợi khi bản năng đầu tiên của họ là lặp lại mọi thứ.

Cuối cùng, học SQL tạo ra lợi tức đầu tư lớn hơn vì tính phổ biến và tính di động của nó.

Tuyên bố từ chối trách nhiệm

Tôi không ghét gấu trúc. Đó là công cụ phân tích cơ bản của tôi trong hai năm và tôi vẫn sử dụng nó cho các dự án cá nhân của mình. Tôi rất vui khi thấy mọi người học nó.

Nhưng tôi đang cố gắng nhìn thấy bức tranh lớn hơn. Tôi nghĩ rằng việc quá nhấn mạnh vào gấu trúc với chi phí là SQL sẽ gây hại nhiều hơn là có lợi . Đặc biệt là khi nói đến những người mới bắt đầu, những người đang tìm hiểu về MultiIndex của gấu trúc trước khi họ có thể thực hiện một GROUP BY thích hợp.

Tiềm năng

Trong phần tiếp theo, tôi phân tích một số khía cạnh kỳ lạ nhất của gấu trúc và so sánh chúng trực tiếp với SQL.

Một lần nữa, mục tiêu không phải là hạ gục gấu trúc, mà là mở rộng góc nhìn của người đọc về các công cụ theo ý của họ.

Hãy đi sâu vào.

 SELECT * FROM opinionated_comparison WHERE sql > pandas

So sánh

Chọn cột

Trong một câu lệnh duy nhất, SELECT của SQL cho phép bạn:

1. Chọn các cột bạn muốn và thứ tự mà chúng sẽ được trả lại.

   
   

2. Tạo cột mới dựa trên sự kết hợp và biến đổi của các cột hiện có.

   
   

3. Đổi tên các cột.

   
   

Ví dụ này chọn tất cả các cột ngoại trừ một cột, sau đó tạo một cột mới dựa trên sự kết hợp tuyến tính của hai cột khác:

 SELECT * EXCEPT (first_name), equity_comp / total_comp * 100 AS percent_equity FROM salaries

Lựa chọn cột gấu trúc chỉ cho phép chọn và sắp xếp các cột. Nếu bạn muốn đổi tên hoặc chuyển đổi một số, bạn cần nhiều câu lệnh và nhiều người mắc phải lỗi chuyển đổi dữ liệu tại chỗ (xem tính bất biến bên dưới).

Người mới bắt đầu cảm thấy bối rối vì việc chọn một cột đơn cần một bộ dấu ngoặc ( df[”first_name”] ) trong khi chọn nhiều cột yêu cầu một bộ dấu ngoặc kép ( df[[”first_name”, "last_name"]] ).

Vấn đề lớn nhất mà tôi gặp phải với gấu trúc ở đây là ký hiệu dấu chấm: thực tế là bạn có thể chọn các cột như thế này: df.first_name .

Điều này dễ dàng hơn nhiều so với việc sử dụng dấu ngoặc và dấu ngoặc kép, vì vậy mọi người cuối cùng thích nó hơn vì sự lười biếng tuyệt đối. Đó là những gì đã xảy ra với tôi ít nhất: Tôi vẫn tự động sử dụng ký hiệu dấu chấm, mặc dù tôi biết điều đó rất tệ.

Các vấn đề xuất hiện khi bạn có một cột được gọi là count hoặc shape hoặc diff hoặc bất kỳ thuộc tính nào khác trong số nhiều thuộc tính tiêu chuẩn của khung dữ liệu (bạn có thể xem tất cả chúng bằng dir(df) ).

Khi bạn cố gắng truy cập chúng bằng ký hiệu dấu chấm, bạn sẽ nhận được thuộc tính thay vì cột và mã của bạn sẽ bị hỏng.

Vì vậy, gấu trúc có ba cách để chọn cột: hai để chọn một cột duy nhất (trong đó một cột xấu nhưng hấp dẫn hơn!) Và một cách thứ ba để chọn nhiều cột.

Chọn hàng

Trong SQL, để chọn các hàng cụ thể, bạn chỉ cần sử dụng câu lệnh WHERE (xem phần Lọc bên dưới).

Việc chọn hàng trong Pandas là ... phức tạp. Để xem mức độ phức tạp, hãy xem hướng dẫn bắt đầu sử dụng . Hoặc đi sâu vào hướng dẫn điển hình trong 30 phút .

Tôi sẽ giới hạn bản thân trong một ví dụ duy nhất. Mỗi DataFrame đều có một Index . Chỉ mục mặc định là một chuỗi các số nguyên: [0,1,2,3,4,5...] .

Đương nhiên, hầu hết mọi người đều giả định rằng chỉ mục đại diện cho số lượng của các hàng. Trên thực tế, những con số chỉ là nhãn phân loại! Chúng cũng có thể là các chữ cái ngẫu nhiên như ['x', 'z', 'a'] . Không có nội dung nào được ngụ ý.

Để lấy một hàng theo chỉ mục của nó, bạn sử dụng df.loc . Nhưng để chọn theo số lượng của hàng, bạn sử dụng df.iloc . Với chỉ mục mặc định, hai phương pháp này cho cùng một kết quả.

Điều này chỉ làm tăng thêm sự nhầm lẫn, bởi vì bất kỳ lúc nào chỉ mục của bạn có thể thay đổi thành một cái gì đó hoàn toàn ngẫu nhiên như [7, 2, 2, 'c', True, None] . Vâng, tất cả những điều này đều được phép! Và không có ràng buộc nào để ngăn chặn nó (xem Ràng buộc bên dưới).

Hãy tưởng tượng rằng bạn đã viết mã của mình với giả định rằng chỉ mục đại diện cho số lượng hàng. Hiện nay:

• df.loc[7] sẽ trả về hàng đầu tiên
• df.loc[2] sẽ trả về một lát khung dữ liệu thay vì một hàng (vì nó xuất hiện nhiều lần trong chỉ mục)
• df.loc[None] sẽ trả về một hàng thực tế!

• 
  

Tôi không khóc, bạn đang khóc.

Và có: cùng một phương thức có thể trả về một giá trị vô hướng, một hàng hoặc một lát khung dữ liệu tùy thuộc vào cách lập chỉ mục. Các tài liệu về gấu trúc thừa nhận sự điên rồ này:

Các phương pháp khác, như lập chỉ mục, có thể cho kết quả rất đáng ngạc nhiên. Thông thường, lập chỉ mục với một đại lượng vô hướng sẽ làm giảm số chiều . Việc cắt một DataFrame với một đại lượng sẽ trả về một Series . Cắt một Series với một đại lượng sẽ trả về một đại lượng vô hướng. Nhưng với các bản sao [index], đây không phải là trường hợp.

Và hãy nhớ rằng, không có ràng buộc nào để ngăn chỉ mục chứa các bản sao. Tôi không thể bắt đầu cho bạn biết điều này đã gây ra cho tôi bao nhiêu cơn đau đầu.

(Bên cạnh tất cả các phương pháp chọn mà chúng tôi đã đề cập, gấu trúc còn có df.at và df.iat cho các giá trị đơn lẻ. Một điều khác cần nhớ và tránh nhầm lẫn.)

Lọc

Trong SQL, lọc rất đơn giản. Viết WHERE , chèn bao nhiêu câu lệnh tùy thích và xâu chuỗi chúng lại với nhau bằng các toán tử logic. Dấu ngoặc cho phép bạn kiểm soát nhiều hơn đối với cấu trúc biểu thức.

Ví dụ: truy vấn sau đây lọc cho những người trên 30 tuổi và đáp ứng ít nhất một trong hai điều kiện: nhiệm kỳ hơn 5 năm hoặc khoản bồi thường vốn chủ sở hữu dưới 50:

 SELECT * from salaries WHERE age > 30 AND (tenure > 5 OR equity_comp < 50)

Điều này trông như thế nào ở Gấu trúc?

 new_df = df[(df["age"] > 30) & ((df["tenure"] > 5) | (df["equity_comp"] < 50))]

Ặc. Vui vẻ giải thích điều này cho người mới bắt đầu.

Phải, bạn có thể sẽ không viết nó như thế này vì nó quá xấu. Bạn sẽ thực hiện lọc trong nhiều câu lệnh: có nghĩa là nhiều dòng mã, biến và lặp lại hơn.

Bộ lọc gấu trúc dựa trên một phương pháp gọi là lập chỉ mục boolean . Mọi thao tác lọc diễn ra theo hai bước:

1. Bạn lấy một Series (đó là đối tượng cột) và chạy từng phần tử thông qua kiểm tra boolean. Do đó, biến nó thành một Series mới được tạo bằng các giá trị boolean (đúng hoặc sai).

   
   

2. Bạn chọn khung dữ liệu với cột này, kết thúc loại trừ các hàng trong đó Series boolean chứa giá trị sai.

   
   

Chú ý đến giả định ẩn ở đây? Series được sử dụng để lọc và khung dữ liệu đang được lọc cần phải chia sẻ cùng một chỉ mục, theo cùng một thứ tự. Điều này không phải lúc nào cũng được đảm bảo.

Trong thực tế, lập chỉ mục boolean có nghĩa là khi bạn lọc, bạn luôn phải lặp lại biến khung dữ liệu, ví dụ: salaries[salaries["cash_comp"] > 20] . Điều này rất khó chịu khi bạn đang viết nhiều mã! Xem ví dụ ở trên: biến dataframe được tham chiếu 4 lần.

Tôi cũng có thể nói từ kinh nghiệm rằng lập chỉ mục boolean không dễ hiểu đối với người mới bắt đầu. Một số người không bao giờ có được cơ chế cơ bản nào cả. Họ chỉ cần ghi nhớ mẫu mã.

(Phương thức df.query() dường như cung cấp một phương pháp tốt hơn để lọc .)

Phân nhóm

Không có khiếu nại lớn ở đây. Nhưng SQL chắc chắn gần với tiếng Anh hơn. Hai cái này tương đương nhau:

 SELECT AVG(cash_comp), SUM(tenure) FROM salaries GROUP BY department

 grouped_df = df.groupby('department').agg({"cash_comp": np.mean, "tenure": np.sum})

Tham gia

SQL có một kiểu nối. Nó được gọi là JOIN . Chắc chắn, nó có thể ở bên trái / bên phải và bên trong / bên ngoài, nhưng việc sử dụng khá đơn giản.

Gấu trúc có hai phương pháp: join và merge . Tôi không bao giờ hiểu tại sao chúng tôi cần hai. phép join được cho là hoạt động trên các chỉ mục, merge được cho là hoạt động trên bất kỳ cột nào.

Nhưng nếu bạn nhìn vào tài liệu [ 1 ] [ 2 ], mỗi tài liệu dường như hỗ trợ cả chỉ mục và cột. Tôi đang bối rối. (Nếu bạn nghi ngờ, tôi khuyên bạn nên luôn chọn merge vì join là một phương pháp kế thừa.)

SQL giúp nó thực sự dễ dàng THAM GIA dựa trên một chuỗi các điều kiện logic, chẳng hạn như: tham gia theo vai trò, nhưng chỉ khi mức lương ở London cao hơn mức lương ở Washington hoặc người đó có nhiệm kỳ dài hơn.

 SELECT * FROM london_hq lhq JOIN washington_hq whq ON lhq.role = whq.role AND (lhq.salary > whq.salary OR lhq.tenure > whq.tenure)

Theo như tôi biết, điều này là không thể với gấu trúc. Khi tham gia (hoặc hợp nhất) bạn chỉ có thể sử dụng điều kiện bình đẳng.

Vì vậy, trước tiên bạn sẽ phải thực hiện role JOIN trên, theo dõi nguồn gốc của từng cột và sau đó lọc kết quả.

Tuy nhiên, tôi lập luận rằng những điều kiện đó thuộc đúng trong JOIN và không ít liên quan hơn đến việc không sử dụng phép so sánh bình đẳng.

Đánh máy

Một trong những ưu điểm chính của SQL là mọi cột đều có một kiểu được xác định rõ ràng. Hơn nữa, các cột không được phép có nhiều loại hỗn hợp. Điều này giúp tiết kiệm rất nhiều lỗi và đau đầu về lâu dài.

Khi bạn tải dữ liệu vào gấu trúc, hầu hết các cột được tự động nhập dưới dạng object . Điều này có thể có nghĩa là một trong ba điều:

1. Cột chỉ chứa các chuỗi

2. Cột chứa các đối tượng Python không phải là kiểu dữ liệu nguyên thủy, ví dụ: danh sách hoặc từ điển

3. Cột chứa các loại hỗn hợp

   
   

Khi bạn nhìn thấy kiểu dữ liệu object , bạn không bao giờ biết đó là trường hợp nào. Tôi thấy điều này rất khó chịu.

Không giống như với SQL, bạn có thể tải dữ liệu với các kiểu hỗn hợp trong gấu trúc: chúng sẽ đơn giản được nhập dưới dạng object .

Pandas không buộc bạn chỉ định một lược đồ và gắn bó với nó. Điều này mang lại cho bạn phí bảo hiểm về tốc độ khi bạn bắt đầu, nhưng bạn thường phải trả giá đắt cho nó trong các lỗi và nhầm lẫn trong tương lai.

Điều này đặc biệt có vấn đề đối với những người mới bắt đầu không tỉnh táo trước những cạm bẫy phổ biến. Ví dụ: khi tôi làm việc với Pandas, tôi thường thử thao tác datetime, chỉ để nhận ra rằng cột datetime được tạo từ các chuỗi (do đó được phân loại là object ). Tôi sẽ làm điều này một cách ngây thơ:

 df['Date'] = df['Date'].astype('datetime64[ns]')

Và tiếp tục, sau đó mới phát hiện ra rằng trình phân tích cú pháp ngày tháng của Pandas đã đọc sai chuỗi của tôi và ngày tháng chẳng có ý nghĩa gì.

Tệp và CSV

Thành thật mà nói: hầu hết mọi người lưu trữ khung dữ liệu của họ dưới dạng CSV. Sinh viên Pandas được hoan nghênh, nay được khuyến khích, làm điều này. Đây là một ý tưởng tồi!

Chắc chắn, con người có thể đọc được CSV và ... lợi thế của chúng kết thúc ở đây. Nhược điểm của chúng là:

• Khi chuyển đổi sang CSV, bạn sẽ mất tất cả thông tin về các loại lược đồ và cột. Mọi thứ trở lại thành văn bản.

  
  

• CSV dễ bị lỗi định dạng, hỏng và phân tích cú pháp.

  
  

• CSV khó nén, điều này làm tăng chi phí lưu trữ.

  
  

• Định dạng CSV không được chỉ định rõ ràng, có nghĩa là các chương trình khác nhau tạo CSV theo những cách khác nhau và người dùng phải chịu gánh nặng là phải tìm ra cách phân tích cú pháp chúng. Điều này có thể nhanh chóng biến thành một trải nghiệm kinh khủng, như bất kỳ chuyên gia dữ liệu nào cũng sẽ chứng thực.

  
  

Việc mất giản đồ thường là vấn đề lớn nhất đối với những người làm việc ở gấu trúc. Đây là một tình huống phổ biến:

1. Công việc của bạn bắt đầu với một CSV. Miễn là bạn đã tìm ra đúng định dạng, mã hóa, đặc tả biểu đồ trích dẫn và phần còn lại của nhiều đối số cho read_csv của gấu trúc, bạn sẽ tải nó trong một khung dữ liệu. Bây giờ bạn cần dành thời gian khám phá các cột, truyền từng cột đến đúng loại, quan tâm đến bất kỳ lỗi nào xuất hiện trong quá trình này và xác minh rằng kết quả cuối cùng có ý nghĩa hay không. (Hoặc bạn có thể bắt đầu làm việc ngay lập tức và phải đối mặt với rất nhiều lỗi sau đó).

   
   

2. Khi công việc của bạn hoàn thành, bạn có một khung dữ liệu mới. bạn sẽ làm gì với nó? Tại sao, hãy lưu nó dưới dạng CSV. Bây giờ tất cả công việc trước đây của bạn về định nghĩa lược đồ đã không còn nữa, vì khung dữ liệu được kết xuất thành văn bản.

   
   

3. Bạn cần tải khung dữ liệu mới cho một quy trình làm việc khác. Điều đó có nghĩa là tải CSV bạn vừa kết xuất. Tôi hy vọng bạn đã viết các hàm có thể khôi phục thành công lược đồ, nếu không bạn sẽ phải thực hiện lại toàn bộ công việc (miễn là bạn nhớ từng cột phải làm gì).

   
   

4. Bạn muốn chia sẻ CSV với bạn bè hoặc đăng nó lên GitHub? Tốt hơn bạn nên chia sẻ mã có thể áp dụng lại lược đồ và hy vọng họ sẵn sàng và có thể chạy nó. Hoặc chúng sẽ chỉ còn lại một mảng văn bản và sẽ phải lặp lại tất cả công việc áp dụng lược đồ từ đầu.

   
   

Nghe có vẻ vô lý? Tôi đã thấy điều này được thực hiện vô số lần . Tôi đã tự mình làm điều này! Nhưng bây giờ tôi tự hỏi: tại sao chúng ta lại dạy mọi người làm việc như thế này? Điều gì biện minh cho sự điên rồ và tàn ác như vậy?

Có hai giải pháp ở đây.

Nếu bạn thực sự cần làm việc với gấu trúc, hãy xuất khung dữ liệu của bạn trong Parquet.

Hoặc bạn có thể làm việc trong SQL và tự giải quyết mọi rắc rối. Rốt cuộc, cơ sở dữ liệu là nơi tốt nhất để lưu trữ dữ liệu.

Hãy tự hỏi bản thân: Tại sao tôi cần một lớp tệp? Nếu bạn chỉ đơn giản là đọc một số dữ liệu, xử lý nó và sau đó lưu trữ kết quả, có thể bạn không. Tải từ cơ sở dữ liệu, làm việc trong cơ sở dữ liệu, lưu trong cơ sở dữ liệu. Nó đơn giản mà. Cần chia sẻ dữ liệu ra bên ngoài? Xuất khẩu trong ván sàn.

Thế giới không cần thêm CSV.

Lưu ý: một số người cố gắng giải quyết vấn đề giản đồ bằng cách chọn khung dữ liệu của họ. Đây là một ý tưởng khủng khiếp .

Đồ chua không hiệu quả và không an toàn (đừng bao giờ mở một dây dưa mà bạn không tin tưởng!). Một khung dữ liệu đã chọn chỉ có thể được mở bên trong Python và nó phải diễn ra trong cùng một môi trường thư viện (về điều mà người dùng có thể hoàn toàn không biết gì). Nếu gấu trúc đọc bài ngâm là một phiên bản khác với gấu trúc đã viết nó, tệp có thể không đọc được!

Nulls

SQL sử dụng giá trị NULL để chỉ ra dữ liệu bị thiếu. Bạn có thể dễ dàng lọc ra các giá trị rỗng.

 SELECT * FROM salaries WHERE equity_comp IS NOT NULL AND cash_comp IS NOT NULL

Trong Pandas, các giá trị bị thiếu có thể là bất kỳ giá trị nào sau đây:

• Bản gốc của Python là None (mà Gấu trúc hiển thị là None nhưng xử lý như nan )

• numpy.nan

• pandas.NA

• pandas.NaT (cho ngày giờ)

  
  

Hãy tập trung vào numpy.nan là cái phổ biến nhất:

• Kiểu của đối tượng này là float , vì vậy hãy quên việc phát hiện nó bằng cách kiểm tra kiểu.

• Đó là sự thật, vì vậy hãy quên kiểm tra boolean. bool(np.nan) là True .

• Nó không thành công trong bài kiểm tra bình đẳng, vì numpy.nan == numpy.nan là false. nan không bằng chính nó!

• Sử dụng nan trong một phép toán không tạo ra một ngoại lệ, nó chỉ có nghĩa là kết quả là nan .

  
  

Điều này không vui phải không?

Cách duy nhất để phát hiện nan là sử dụng pandas.isna() . Tốt thôi, một khi bạn đọc tài liệu và quên hết bản năng loài trăn của mình. Tuy nhiên, hành vi này cực kỳ khó hiểu đối với người mới bắt đầu.

Đây là cách bạn có thể sao chép truy vấn trên trong Pandas:

 new_df = df.dropna(subset=["equity_comp", "cash_comp"])

Hạn chế

Các ràng buộc rất quan trọng trong SQL. Chúng cho phép bạn chỉ định các quy tắc giữ cho dữ liệu của bạn an toàn và nhất quán. Ví dụ: khóa chính, đóng vai trò là mã định danh duy nhất cho mỗi hàng, phải là duy nhất và không được rỗng.

Gấu trúc không có bất cứ điều gì như thế này.

Thứ gần nhất với khóa chính ở gấu trúc là chỉ mục. Thật không may, giá trị chỉ mục có thể vừa lặp lại vừa rỗng (vâng, bạn có thể có một chỉ mục với giá trị None ).

Người dùng thường làm việc với giả định ngầm định rằng chỉ mục là khóa chính, một ý tưởng được thực thi bởi thực tế là chỉ mục mặc định được tạo bằng các số nguyên: [0,1,2,3,4...] . Do đó, mọi người có xu hướng sử dụng chỉ mục để tham chiếu các hàng cụ thể, ví dụ: df.loc[2] .

'Đó là một hành động đức tin ngu ngốc. Điều này trở nên rõ ràng khi nối hoặc hợp nhất các khung dữ liệu khác nhau. Thường xảy ra trường hợp các chỉ mục tương tự bị trộn lẫn và bạn nhận được một chỉ mục trông giống như sau: [0,1,2,2,2,3...] .

Gấu trúc không đưa ra bất kỳ cảnh báo nào về điều này, vì vậy ban đầu bạn không nhận ra. Nhưng lần tới khi bạn sử dụng df.loc[2] mã của bạn sẽ bị hỏng vì thay vì một hàng, giờ đây nó sẽ trả về một khung dữ liệu có ba hàng.

Nhiều giọt nước mắt sẽ chảy ra trước khi bạn nhận ra rằng bạn cần chạy reset_index() trên khung dữ liệu đã hợp nhất để mỗi hàng nhận lại một giá trị duy nhất.

Hơn nữa, các quy tắc SQL cho phép bạn chạy kiểm tra tại thời điểm viết. Nếu bạn cố gắng chèn một giá trị null vào một cột có ràng buộc NOT NULL , bạn sẽ nhận được một ngoại lệ và việc ghi xấu sẽ không xảy ra. Pandas chỉ cho phép chạy kiểm tra khi đọc. Đó là, nếu bạn nhớ làm điều đó.

Hoạt động được vector hóa

Đây chủ yếu là điểm sư phạm. Pandas, như được biết đến nhiều, cho phép và thậm chí khuyến khích các hoạt động được vector hóa (trong đó tất cả các phần tử của một chuỗi được truy cập song song).

Nhưng nhiều người làm việc bằng Python không tự động nghĩ như vậy. Họ bắt đầu bằng cách học các vòng lặp và bây giờ, theo Guido , họ muốn sử dụng các vòng lặp đó.

Khi bắt đầu với gấu trúc, họ sớm phát hiện ra các phương thức iterrows và itertuples , cho phép họ lặp lại khung dữ liệu theo từng hàng.

Hầu như không thể tránh khỏi, họ lại rơi vào các mô hình lặp lại, bởi vì không có gì buộc họ phải suy nghĩ theo vectơ. Điều này làm cho họ viết mã khủng khiếp và chạy rất chậm.

Tôi bắt đầu tập trung vào SQL sau một thời gian dài trải nghiệm với gấu trúc. Mỗi khi đối mặt với một vấn đề SQL, bản năng của tôi là nghĩ ra một giải pháp lặp lại. Thật thất vọng, SQL không cho phép tôi làm điều đó.

Cú pháp khai báo của nó buộc tôi phải suy nghĩ về các phép toán cột, các hàm JOIN và các hàm cửa sổ. Dần dần, tôi đã xây dựng một tập hợp các mô hình tinh thần mới giúp tôi trở thành một nhà phân tích tốt hơn.

Tôi nghĩ rằng người học nên xây dựng sự tự tin khi thao tác dữ liệu trong SQL trước khi bắt đầu với gấu trúc. Họ sẽ được trang bị tốt hơn để hiểu khi nào việc lặp lại theo hàng là không thể tránh khỏi, điều này hiếm khi xảy ra.

Bất biến

Bạn tải một khung dữ liệu trong bộ nhớ. Bạn cần sửa đổi khung dữ liệu đó. Bạn có thay đổi nó tại chỗ hay bạn tạo một bản sao? Bạn nên cập nhật các cột hiện có hay tạo những cột mới?

Điều gì sẽ xảy ra nếu bạn cần tạo nhiều lát khung dữ liệu, sau đó thực hiện một số thao tác trên mỗi lát? Bạn nên lưu trữ từng lát cắt trong một biến riêng biệt hay sử dụng cùng một biến để giữ lần lượt các lát cắt khác nhau?

Khi mọi người làm việc với gấu trúc, họ có xu hướng làm tất cả những việc này cùng một lúc. Sẽ sớm trở nên khó theo dõi tất cả các biến có chứa khung dữ liệu, các phần khung dữ liệu và các phần của các phần và để biết dữ liệu đã được thêm vào hoặc sửa đổi như thế nào.

(Tôi không phải lúc nào cũng viết gấu trúc, nhưng khi tôi viết, tôi nhận được cài đặt với cảnh báo sao chép .)

Và vì hầu hết mọi người sử dụng gấu trúc với sổ ghi chép, những vấn đề này kết hợp với những cạm bẫy điển hình của máy tính xách tay và cuối cùng sẽ gây ra những cơn đau đầu rất lớn.

Đây là một trong những lý do tại sao tôi nghĩ rằng gấu trúc không phải là lựa chọn tốt nhất để phân tích dữ liệu.

Khi xử lý dữ liệu trong SQL, bạn không thay đổi dữ liệu gốc. Câu UPDATE không được sử dụng trong phân tích. Thay vào đó, bạn tạo các đường ống gồm các bảng và dạng xem đại diện cho các lựa chọn khác nhau.

Khi bạn cần lưu kết quả của mình, bạn tạo bảng mới (hoặc thêm hàng vào bảng mục tiêu hiện có, nhưng không sửa đổi hoặc xóa các hàng trước đó). Điều này tôn trọng nguyên lý bất biến : không bao giờ sửa đổi hoặc xóa dữ liệu nguồn. Nó làm cho quy trình của bạn an toàn, minh bạch và dễ dàng sao chép.

Đúng vậy, bạn có thể tôn trọng tính bất biến ở gấu trúc, nhưng không hiển nhiên là bạn nên làm như vậy, và nhiều người không bao giờ học cách làm điều đó. Những gì bạn thường thấy là tính bất biến ở cấp độ tệp : mọi người thường tải CSV và xuất CSV mới. Nhưng đối với công việc xảy ra ở giữa? Bất cứ điều gì đi.

(Hầu hết các phương pháp của gấu trúc về mặt lý thuyết là "thuần túy" vì chúng trả về khung dữ liệu mới thay vì sửa đổi khung dữ liệu trước đó. Nhưng tất cả chúng đều cung cấp inplace chọn thay thế để thay đổi khung dữ liệu tại chỗ. Và mọi người sử dụng nó một cách thích thú.)

Khi gấu trúc không đủ

Nếu bạn làm việc nghiêm túc với gấu trúc, cuối cùng bạn sẽ đạt được một bức tường hiệu suất. Dữ liệu bạn đang phân tích quá lớn hoặc nhu cầu xử lý của bạn quá cao.

Tôi thấy điều này thường xuyên khi tôi nghiên cứu với gấu trúc. Khi nó xảy ra, các đồng nghiệp của tôi và tôi sẽ google "làm cho gấu trúc nhanh hơn" và tìm thấy vô số bài báo về chủ đề nóng bỏng này, những người này lần lượt đề xuất vô số cách hack, tối ưu hóa và thư viện PyPI hứa hẹn sẽ thực hiện thủ thuật này.

Nếu bạn đang ở trong tình huống này, bằng mọi cách, hãy kiểm tra các tài nguyên hiện có. Đặc biệt là những bài giải thích cáchsử dụng gấu trúc tốt hơn . Nhưng đừng đặt hy vọng quá cao. Có những giới hạn khó đối với những gì gấu trúc có thể làm. Không sao cả: nó không được thiết kế để trở thành phần cuối của tất cả phân tích dữ liệu.

Hai lựa chọn thay thế tốt nhất khi bạn cần mở rộng khối lượng công việc dữ liệu của mình là:

• PySpark . Spark là một công cụ phân tích quy mô lớn và xử lý dữ liệu song song. PySpark cho phép bạn tận dụng nó với Python và sử dụng cú pháp gợi nhớ đến gấu trúc. Nó thậm chí còn có API gấu trúc.

  
  

• Kho dữ liệu . Một hệ thống lưu trữ và phân tích dữ liệu ở quy mô rất lớn (nghĩ là terabyte và petabyte). Kho dữ liệu hiện đại chạy trên đám mây để bạn có thể tận dụng sức mạnh của hệ thống phân tán mà không cần quản lý bất kỳ máy chủ nào. BigQuery, giải pháp kho dữ liệu của Google Cloud, có thể xử lý 100 tỷ hàng hoặc 7 terabyte dữ liệu trong 30 giây . Kho dữ liệu thường hoạt động với SQL. (Nếu bạn muốn dùng thử BigQuery miễn phí, tôi đã viết về nó ở đây. )

Khi nào thì gấu trúc tốt hơn?

Tôi không muốn bạn xa lánh gấu trúc. Đó là một công cụ tuyệt vời mà chắc chắn đáng để học hỏi.

Có những trường hợp gấu trúc là lựa chọn tốt hơn SQL. Tôi sẽ không đi vào chi tiết ở đây, nhưng đây là danh sách nhanh:

• Khi tích hợp với các quy trình làm việc Python khác, ví dụ: bạn đang thực hiện học máy hoặc bạn muốn sử dụng thư viện trực quan hóa Python.

  
  

• Khi bạn cần một số thống kê nhanh chóng. Phương thức describe() rất hữu ích.

  
  

• Khi bạn cần kết hợp một phân tích nhanh chóng, mà không cần lo lắng về tỷ lệ hoặc khả năng tái tạo. Mặc dù Excel hoặc Google Trang tính cũng có thể hoạt động.

  
  

• Nếu bạn đang xây dựng các ứng dụng Python. Gấu trúc có thể là cách nhanh nhất để chuyển từ cấu trúc dữ liệu tùy ý sang bảng và ngược lại.

  
  

• Khi bạn thực sự cần các quy trình và vòng lặp công việc bắt buộc. Ví dụ: xây dựng mô phỏng Markov.

  
  

• Khi bạn cần viết hoặc sử dụng lại các chức năng bất thường. Pandas rất giỏi trong việc áp dụng các hàm Python tùy ý.

  
  

• Nếu bạn có một quy trình làm việc năng động và được tham số hóa cao.

Sự kết luận

Tôi hy vọng bài viết này đã kích thích bạn suy nghĩ sâu hơn về SQL và gấu trúc cũng như những điểm mạnh và điểm yếu tương đối của chúng.

Tôi tin rằng xu hướng dữ liệu hiện tại đã đi quá xa theo hướng có lợi cho gấu trúc và bạn bỏ qua SQL sẽ gây nguy hiểm cho chính mình.

Đây là lời khuyên của tôi:

• Nếu bạn là người học : hãy nghiên cứu SQL và học cách sử dụng nó cho phân tích của bạn. Bạn sẽ không hối tiếc.

  
  

• Nếu bạn là một nhà thiết kế chương trình giảng dạy : hãy nhấn chìm sinh viên của bạn trong SQL cho đến khi họ mơ trong bảng và nói hoa. Đó là tình yêu khó khăn và họ sẽ ghét bạn vì điều đó, nhưng đến ngày họ sẽ hiểu. (Tuy nhiên, đừng đánh họ vào đầu.)

  
  

• Nếu bạn là một người cố vấn : hãy cố gắng cai nghiện dần dần các học sinh của bạn khỏi gấu trúc và khuyến khích chúng thử các vấn đề trong SQL.

  
  

Tôi rất muốn có được một cuộc trò chuyện. Hãy bình luận, viết email cho tôi hoặc thêm tôi trên LinkedIn .