による写真 Unsplashの Pedro Gonzalez むかしむかし、データサイエンスを学びたいと熱望している学生がいました。 彼は何をすべきか人々に尋ねたところ、彼らはパンダを学ぶように彼に言いました.彼はウェブでデータ コースを探しましたが、それらはすべてパンダを特集していました。そこで学生はパンダを学び、アカデミアに就職しました。そこでは誰もがパンダを扱っていました。 そのため、彼は睡眠中にデータフレームをスライスできるようになるまで、何ヶ月にもわたってパンダで苦労しました。終わった後、彼はデータ ブートキャンプに参加しました。見よ、彼らはパンダを教えていました。彼が終わったとき、ブートキャンプはパンダを教えるために彼を雇いました。 そして、学生が最初の会社に入った時が来ました。彼のマスターは、彼にデータを処理することを望んでいました。 「私はパンダを使います」と学生は言いました。 「なんてこった！」マスターは言った。 「ここでは S-Q-L を使用します」と彼は反論し、棒で一撃して各文字を強調しました。 「しかし...しかし...冗長...醜い...機能の欠如...無限のネスト...そして、結合、結合は恐ろしいです!...」 「森が見えないなら、木に触れてはいけない」と主人は言い、頭を殴りました。 その学生は悟りを開いた。 またはそう彼は思った。実際、マスターの打撃は彼をひどく気絶させたので、彼の判断力は一時的に損なわれました. 数か月後、痛みを伴う引きこもりの後、学生は SQL を理解するようになりました。それ以来、彼は再びパンダを使う必要性を感じなくなり、マスターは二度と彼に打撃を与えることはありませんでした. SQL >> パンダ 上記の公案は自伝的なものですが、私の監督者は誰も私を殴ったことはありません (殴るはずの時でさえ)。 始めた頃とほとんど変わりません。ほとんどのデータ ブートキャンプのカリキュラムでは、(Jupyter ノートブックと並んで) pandas に多額の投資が行われていますが、SQL はせいぜい後付けです。 Udemy で「データ サイエンス」を検索すると、Python (必然的に pandas が含まれます) と R、場合によっては Scala に言及しているトップ コースが表示されます。それらの中で SQL に言及しているものはほとんどありません。 これは、価値の観点からも、教育学的な観点からも、悪いことだと思います。 価値の問題 標準的な分析を行っている場合、SQL は pandas よりも優れたツールです。それはよりシンプルで、より明確で、より強力で効率的です。また、理解、共有、再現が容易になります。それが何十年にもわたってデータ分析の であったのには理由があります。 共通語 SQL を犠牲にして Pandas に集中している場合は、より優れた効果的なデータ プラクティショナーになる機会を逃しています。 もちろん、pandas の方が優れている点もあり、記事の最後で簡単に説明します。しかし全体として、純粋な分析に関して言えば、SQL に勝るものはありません。 多くの人は、pandas が複雑さ、非効率性、特異性、および混乱の可能性という点で大きなオーバーヘッドをもたらすことに気付かないことがよくあります。 学習の問題 パンダを過度に強調することは、データを学ぶ学生を傷つけるのではないかと思います。私の経験では、 になるポイントがあります。つまり、時間の経過とともに単純に混乱します。 より多くの pandas を行うと 反学習 特に新入生は、彼らを混乱させ、盲目的な暗記で補う奇妙な問題を経験します. また、テーブル操作を使用できるときに行をループするなど、後であきらめるのが難しい悪い習慣も身に付けます。タイプが混在する列を作成する。データを CSV に保存します。その場でデータを変更します。同じデータフレームの複数のコピーとスライスでメモリを詰まらせる...私は続けることができました。 これには、Python が非常に寛容な言語であるため、ユーザーに悪いことをしないという負担がかかります (混合型の pandas など)。その一部は、pandas が (必ずしも推奨するわけではありませんが) 命令型アプローチを受け入れるという事実に由来しています。 Series たとえば、学生が 2 つのテーブルのデータを結合したい場合、このアルゴリズムの使用を妨げるものは何もありません。 をループする table1 行ごとに、ルックアップのためにすべての をスキャンします。 table1 table2 のデータから の行を更新します。 table2 table1 はい、これは明らかに非常に悪いです。しかし、初心者はそれ以上のことを知りません。 対照的に、SQL の宣言型アプローチにより、悪いことを行うのが難しくなります。 。これにより、問題や奇妙なバグに常に悩まされるのではなく、分析の背後にあるロジックに集中するために必要なスペースが得られます。 宣言型プログラミングでは、ユーザーは結果を生成する方法ではなく、見たい結果の観点から考える必要があります また、SQL は学生 強制します。 にテーブル (つまりリレーショナル モデル) と列レベルの操作で考えるように 最後に、SQL を学習すると、その普遍性と移植性により、投資収益率が向上します。 免責事項 パンダは嫌いじゃない。これは 2 年間、私の基本的な分析ツールでしたが、今でも個人的なプロジェクトに使用しています。人々がそれを学んでいるのを見るのはうれしいです。 しかし、私は全体像を見ようとしています。 ことだと思います。特に、適切な を実行する前に について学んでいる初心者の場合。 SQL を犠牲にしてパンダを過度に強調することは 、良いことよりも悪い GROUP BY MultiIndex 見込み 次のセクションでは、pandas の最も奇妙な側面をいくつか分析し、SQL と直接比較します。 繰り返しますが、目標は pandas を下に置くことではなく、自由に使えるツールに対する読者の視点を広げることです。 掘り下げてみましょう。 SELECT * FROM opinionated_comparison WHERE sql > pandas 比較 列の選択 単一のステートメントで、SQL の を使用すると、次のことができます。 SELECT 必要な列と、それらが返される順序を選択します。 既存の列の組み合わせと変換に基づいて、新しい列を作成します。 列の名前を変更します。 この例では、1 つを除くすべての列を選択し、他の 2 つの列の線形結合に基づいて新しい列を作成します。 SELECT * EXCEPT (first_name), equity_comp / total_comp * 100 AS percent_equity FROM salaries pandas の列選択では、列の選択と順序付けのみが可能です。一部の名前を変更したり変換したりする場合は、複数のステートメントが必要であり、多くの人がデータをその場で変換するというエラーに陥ります (以下の不変性を参照)。 初心者は、単一の列を選択するには 1 セットの括弧 ( ) が必要であり、複数の列を選択するには 2 組の括弧 ( ) が必要であるため、混乱します。 df[”first_name”] df[[”first_name”, "last_name"]] ここで pandas に関して私が抱えている最大の問題は、ドット表記です: のように列を選択できるという事実です。 df.first_name これは、括弧や引用符を使用するよりもはるかに簡単であるため、人々はまったくの怠惰からそれを好むことになります.それが少なくとも私に起こったことです。ドット表記が悪いことだとわかっていても、私はまだドット表記を自動的に使用しています。 または または と呼ばれる列、またはデータフレームの他の多くの標準属性のいずれかがある場合に問題が発生します (それらはすべて で表示できます)。 count shape diff dir(df) ドット表記でそれらにアクセスしようとすると、列ではなく属性が取得され、コードが壊れます。 そのため、pandas には列を選択する 3 つの方法があります。1 つの列を取得するための 2 つ (そのうちの 1 つは悪いが、より魅力的です!) と、複数の列を選択するための 3 つ目の方法です。 行の選択 SQL では、特定の行を選択するには、 ステートメントを使用するだけです (以下のフィルタリングを参照)。 WHERE Pandas で行を選択するのは... 複雑です。複雑さを確認するには、 を確認してください。または、典型的な を詳しく調べてください。 ユーザー スタート ガイド 30 分間のチュートリアル 例を 1 つだけ挙げます。すべての DataFrame には があります。デフォルトのインデックスは整数のシーケンスです: 。 Index [0,1,2,3,4,5...] 当然のことながら、ほとんどの人は、インデックスが行のカーディナリティを表していると想定しています。 、数値は単なるカテゴリ ラベルです。 ようなランダムな文字でもかまいません。暗示されるカーディナリティはありません。 実際には ['x', 'z', 'a'] インデックスで行を取得するには、 を使用します。ただし、行のカーディナリティで選択するには、 を使用します。 df.loc df.iloc デフォルトのインデックスでは、これら 2 つのメソッドは同じ結果を返します。 いつでもインデックスが ような完全にランダムなものに変更される可能性があるため、これは混乱を招くだけです。はい、これはすべて許可されています。また、それを防ぐための制約はありません (以下の制約を参照してください)。 [7, 2, 2, 'c', True, None] インデックスが行のカーディナリティを表すと仮定してコードを記述したと想像してください。今： は最初の行を返します df.loc[7] は、行ではなくデータフレーム スライスを返します (インデックス内で複数回発生するため)。 df.loc[2] は実際の行を返します! df.loc[None] 私が泣いているのではなく、あなたが泣いているのです。 はい: で、インデックスの構成方法に応じて、スカラー値、行、またはデータフレーム スライスを返すことができます。 は、この狂気を認めています。 同じメソッド パンダのドキュメント インデックス作成などの他の方法では、非常に驚くべき結果が得られる場合があります。通常、スカラーでインデックスを作成すると、 れます。スカラーで をスライスすると、 が返されます。 をスカラーでスライスすると、スカラーが返されます。しかし、[index] の重複では、そうではありません。 次元が削減さ DataFrame Series Series インデックスに重複が含まれないようにするための制約はありません。これが私を引き起こした頭痛の数をあなたに伝えることはできません. (これまでに説明したすべての選択方法に加えて、pandas には単一の値用の と もあります。混乱を避けるために覚えておくべきもう 1 つのことです。) df.at df.iat フィルタリング SQL では、フィルタリングは簡単です。 を記述し、必要な数のステートメントを挿入し、それらを論理演算子で連結します。ブラケットを使用すると、式の構造化をより細かく制御できます。 WHERE たとえば、次のクエリは、2 人とも 30 歳以上で、勤続年数が 5 年以上、または株式報酬が 50 年未満の 2 つの条件の少なくとも 1 つを満たす人をフィルター処理します。 SELECT * from salaries WHERE age > 30 AND (tenure > 5 OR equity_comp < 50) これはパンダではどのように見えますか? new_df = df[(df["age"] > 30) & ((df["tenure"] > 5) | (df["equity_comp"] < 50))] うーん。これを初心者に説明して楽しんでください。 確かに、あまりにも醜いので、おそらくこのようには書かないでしょう。複数のステートメントでフィルタリングを実行すると、コード、変数、および繰り返しの行が増えることになります。 Pandas フィルターは、 と呼ばれる方法に基づいています。すべてのフィルタリング操作は、次の 2 つの手順で行われます。 ブール インデックス (列オブジェクト) を取得し、各要素をブール値テストで実行します。したがって、ブール値 (true または false) で構成される新しい に変換します。 Series Series この列でデータフレームを選択すると、ブール値 に false 値が含まれる行が除外されます。 Series ここに隠れた前提があることに気付きましたか?フィルタリングに使用される とフィルタリングされるデータフレームは、同じインデックスを同じ順序で共有する必要があります。これは常に保証されるわけではありません。 Series 実際には、ブール値のインデックス付けは、フィルタリングするときに、常にデータフレーム変数を繰り返さなければならないことを意味します (例: 。たくさんのコードを書いているとき、これは非常に面倒です!上記の例を参照してください。データフレーム変数は 4 回参照されています。 salaries[salaries["cash_comp"] > 20] ブール値のインデックス付けは初心者にとって理解しにくいということも経験から言えます。根底にあるメカニズムをまったく理解できない人もいます。彼らはコーディングパターンを覚えているだけです。 ( メソッドは ようです。) df.query() 、フィルタリングのためのより良い方法を提供している グループ化 ここには大きな不満はありません。しかし、SQL は間違いなく英語に近いです。これら 2 つは同等です。 SELECT AVG(cash_comp), SUM(tenure) FROM salaries GROUP BY department grouped_df = df.groupby('department').agg({"cash_comp": np.mean, "tenure": np.sum}) ジョイン SQL には 1 種類の結合があります。それは と呼ばれます。もちろん、左/右、内側/外側のどちらでもかまいませんが、使用方法は非常に簡単です。 JOIN Pandas には、 と の 2 つのメソッドがあります。なぜ2つ必要なのか理解できませんでした。 はインデックスで動作するはずであり、 は任意の列で動作するはずです。 join merge join merge しかし、ドキュメント [ ][ ] を見ると、それぞれがインデックスと列の両方をサポートしているようです。私は混乱しています。 (確信が持てない場合は、常に結合を選択することをお勧めします。 、 は従来の方法に近いからです。) 1 2 merge join SQL を使用すると、次のような一連の論理条件に基づいて JOIN を実行するのが非常に簡単になります。たとえば、ロールごとに参加しますが、ロンドンの給与がワシントンの給与よりも高い場合や、その人の在職期間が長い場合に限られます。 SELECT * FROM london_hq lhq JOIN washington_hq whq ON lhq.role = whq.role AND (lhq.salary > whq.salary OR lhq.tenure > whq.tenure) 私の知る限り、これはパンダでは不可能です。結合 (またはマージ) するときは、等価条件のみを使用できます。 したがって、最初に で JOIN を実行し、各列のオリジンを追跡してから、結果をフィルタリングする必要があります。 role ただし、これらの条件は当然 JOIN に属しており、等値比較を使用しないこととの関連性が低いわけではないと私は主張します。 タイピング SQL の主な利点の 1 つは、すべての列に適切に定義された型があることです。さらに、列に型を混在させることはできません。これにより、長期的には多くのバグや頭痛の種が節約されます。 pandas にデータをロードすると、ほとんどの列は として自動的に型指定されます。これは、次の 3 つのいずれかを意味します。 object 列には文字列のみが含まれています 列には、プリミティブ データ型ではない Python オブジェクト (リストや辞書など) が含まれています。 列に混合型が含まれています のデータ型を見ると、どちらが当てはまるかわかりません。これは非常に面倒です。 object SQL とは異なり、pandas では型が混在するデータを読み込むことができます。それらは単純に として型付けされます。 object Pandas は、スキーマを指定してそれに固執することを強制しません。これにより、開始時の速度が向上しますが、将来のバグや混乱のために多額の費用がかかることがよくあります. これは、一般的な落とし穴に注意を払っていない初心者にとって特に問題です。たとえば、Pandas を扱っていたとき、datetime 列が文字列で構成されている (したがって、 として分類されている) ことに気付くためにだけ、datetime 操作を試みることがよくありました。私は単純にこれを行います： object df['Date'] = df['Date'].astype('datetime64[ns]') Pandas の日付パーサーが私の文字列を読み違えていて、日付が意味をなさないことを後で知りました。 ファイルと CSV 正直に言うと、ほとんどの人はデータフレームを CSV として保存しています。パンダの学生は、これを行うことを歓迎します。これは悪い考えです！ 確かに、CSV は人間が読める形式であり、その利点はここまでです。それらの欠点は次のとおりです。 CSV に変換すると、スキーマと列の型に関するすべての情報が失われます。すべてがテキストに戻ります。 CSV は、不適切なフォーマット、破損、および解析エラーが発生しやすい傾向があります。 CSV は圧縮が難しいため、ストレージ コストが増加します。 指定されていません。つまり、さまざまなプログラムがさまざまな方法で CSV を作成し、それらを解析する方法を理解するのはユーザーの負担になります。データの専門家なら誰でも証明するように、これはすぐに地獄のような体験に変わる可能性があります。 CSV 形式は スキーマの損失は、通常、pandas で作業する人々にとって最大の問題です。これは一般的な状況です。 あなたの仕事はCSVから始まります。適切なフォーマット、エンコーディング、quote char 仕様、および pandas の への残りの を理解していれば、それをデータフレームにロードします。ここで、時間をかけて列を調査し、各列を正しい型にキャストし、プロセスで発生するバグに対処し、最終結果が理にかなっていることを確認する必要があります。 (または、すぐに作業を開始して、後で多くのバグに直面することもできます)。 read_csv 多くの引数 作業が完了すると、新しいデータフレームが作成されます。あなたはそれで何をするつもりですか？なぜ、CSVとして保存します。データフレームがテキストにダンプされるため、スキーマ定義に関する以前の作業はすべてなくなりました。 別のワークフロー用に新しいデータフレームをロードする必要があります。これは、ダンプしたばかりの CSV をロードすることを意味します。スキーマを正常に復元できる関数を作成したことを願っています。そうしないと、作業を最初からやり直す必要があります (各列が何をすべきかを覚えている場合)。 CSV を友人と共有したり、GitHub に投稿したりしたいですか?スキーマを再代入できるコードを共有したほうがよいでしょう。彼らが喜んでそれを実行できることを願っています。または、テキストの塊が残り、すべてのスキーマ代入作業を最初からやり直す必要があります。 ばかげているように聞こえますか？私はこれが 行われるのを見てきました。私はこれを自分でやった！しかし今思うのは、なぜ私たちは人々にこのような働き方を教えているのだろうかということです。そのような狂気と残酷さを正当化するものは何ですか？ 数え切れないほど ここには 2 つの解決策があります。 本当に pandas で作業する必要がある場合は、データフレームを Parquet にエクスポートしてください。 または、SQL で作業して、すべての問題を解決することもできます。結局のところ、データベースはデータを保存するのに最適な場所です。 自問してみてください: データを読み取って処理し、結果を保存するだけの場合は、おそらくそうではありません。データベースから読み込み、データベースで作業し、データベースに保存します。それはとても簡単です。外部とデータを共有する必要がありますか?寄木細工でエクスポートします。 なぜファイル層が必要なのですか? 世界はこれ以上 CSV を必要としません。 注: データフレームを してスキーマの問題を解決しようとする人もいます。 です。 ピクル これはひどい考え ピクルス化は非効率的で安全ではありません (信頼できないピクルスを開かないでください!)。 pickle 化されたデータフレームは Python 内でのみ開くことができ、同じライブラリ環境内で発生する必要があります (ユーザーはまったく何も知らない可能性があります)。 pickle を読み取るパンダが、それを書き込んだパンダとは異なるバージョンである場合、ファイルを読み取れない可能性があります。 ヌル SQL は NULL 値を使用して欠落データを示します。 null は簡単に除外できます。 SELECT * FROM salaries WHERE equity_comp IS NOT NULL AND cash_comp IS NOT NULL Pandas では、欠損値は次のいずれかになります。 Python のネイティブ (Pandas では として表示されますが、 のように扱われます) None None nan numpy.nan pandas.NA (日時用) pandas.NaT 最も一般的な に注目しましょう。 numpy.nan このオブジェクトの型は であるため、型チェックで検出することは忘れてください。 float それは真実なので、ブール値のテストを忘れてください。 は です。 bool(np.nan) True が false であるため、同等性テストに失敗します。 はそれ自体と等しくありません! numpy.nan == numpy.nan nan 操作で を使用しても例外はスローされません。結果が であることを意味するだけです。 nan nan 楽しくないですか？ を検出する唯一の方法は、 を使用することです。ドキュメントを読んで、pythonic の本能をすべて忘れたら、それで問題ありません。それでも、この動作は初心者にとって非常に紛らわしいものです。 nan pandas.isna() Pandas で上記のクエリを複製する方法は次のとおりです。 new_df = df.dropna(subset=["equity_comp", "cash_comp"]) 制約 は SQL で重要です。これにより、データの安全性と一貫性を維持するルールを指定できます。たとえば、各行の一意の識別子として機能する主キーは、null ではなく一意である必要があります。 制約 パンダにはこのようなものはありません。 pandas の主キーに最も近いのはインデックスです。残念ながら、インデックス値は繰り返しと null の両方になる可能性があります (はい、 値を持つインデックスを持つことができます)。 None ユーザーは、多くの場合、インデックスが主キーであるという暗黙の仮定を使用して作業します。これは、デフォルトのインデックスが の整数で構成されているという事実によって強制される考え方です。したがって、人々はインデックスを使用して特定の行を参照する傾向があります (例: 。 [0,1,2,3,4...] df.loc[2] これは愚かな信仰の行為です。これは、異なるデータフレームを連結またはマージするときに明らかになります。同様のインデックスが混同され、 のようなインデックスが得られることがよくあります。 [0,1,2,2,2,3...] Pandas はこれに関する警告をスローしないため、最初は気付かないでしょう。しかし、次に を使用すると、単一の行ではなく 3 つの行を持つデータフレームが返されるため、コードが壊れます。 df.loc[2] 各行が再び一意の値を取得するように、マージされたデータフレームで を実行する必要があることを理解する前に、多くの涙が流れます。 reset_index() さらに、SQL 制約により、書き込み時にチェックを実行できます。 制約を持つ列に NULL 値を挿入しようとすると、例外が発生し、不正な書き込みは発生しません。 Pandas では、読み取り時にのみチェックを実行できます。つまり、あなたがそれをすることを覚えていれば。 NOT NULL ベクトル化された操作 これは主に教育上のポイントです。よく知られているように、Pandas は、ベクトル化された操作 (シリーズのすべての要素が並列にアクセスされる) を許可し、さらには推奨しています。 しかし、Python で作業している多くの人は、自動的にこのように考えるわけではありません。彼らはループを学ぶことから始めましたが、今で 、それらのループを使用したいと考えています。 は Guido によって を使い始めると、すぐに iterrows メソッドと メソッドを発見し、データフレームを行ごとにループできるようにします。 iterrows itertuples ベクトルで考えるように強制するものは何もないため、ほとんど必然的に、彼らは再びループパターンに陥ります。これにより、実行速度が非常に遅いひどいコードを作成することになります。 pandas での長い経験の後、私は SQL に注目し始めました。 SQL の問題に直面するたびに、私の本能はループ ソリューションを思いつくことでした。残念なことに、SQL ではそれができませんでした。 その宣言構文により、列操作、JOIN、およびウィンドウ関数の観点から考える必要がありました。徐々に、より優れたアナリストになる新しい一連のメンタル モデルを構築しました。 学習者は、pandas を始める前に、SQL でデータを操作する自信をつけるべきだと思います。行ごとのループが避けられない場合 (これはまれです) をよりよく理解できるようになります。 不変性 データフレームをメモリにロードします。そのデータフレームを変更する必要があります。その場で変更しますか、それともコピーを作成しますか?既存の列を更新するか、新しい列を作成する必要がありますか? 複数のデータフレーム スライスを作成する必要がある場合は、各スライスで何らかの作業を行いますか?各スライスを個別の変数に格納するか、同じ変数を使用して異なるスライスを順番に保持する必要がありますか? 人々が pandas で作業するとき、これらすべてのことを同時に行う傾向があります。データフレーム、データフレームのスライス、およびスライスのスライスを含むすべての変数を追跡し、データがどのように追加または変更されたかを知ることはすぐに困難になります。 (いつも pandas と書いているわけではありませんが、書く 。) と copy warning の設定が入ります ほとんどの人は pandas をノートブックで使用しているため、これらの問題は典型的な と組み合わさり、最終的に大きな頭痛の種になります。 ノートブックの落とし穴 これが、pandas がデータ分析に最適な選択肢ではないと私が考える理由の 1 つです。 SQL でデータを処理する場合、元のデータは変更しません。 ステートメントは分析では使用されません。代わりに、さまざまな選択を表すテーブルとビューのパイプラインを作成します。 UPDATE 結果を保存する必要がある場合は、新しいテーブルを作成します (または、既存のターゲット テーブルに行を追加しますが、以前の行を変更または削除することはありません)。これは、 の信条を尊重します。つまり、ソース データを変更したり削除したりしないでください。これにより、プロセスが安全で透過的になり、複製が容易になります。 不変性 はい、pandas で不変性を尊重する ますが、そうするべきかどうかは明らかではなく、多くの人はそれを学ぶことはありません。一般的に見られるのは、 のレベルでの不変性です。通常、人々は CSV をロードして、新しい CSV を出力します。しかし、その間に起こる仕事のために？何でもあり。 ことはでき ファイル (ほとんどの メソッドは、前のデータフレームを変更するのではなく、新しいデータフレームを返すため、理論的には「純粋」です。しかし、それらはすべて、データフレームをその場で変更するインプレース オプションを提供します。そして、人々はそれを喜んで使用します。) inplace パンダが足りないとき pandas で本格的な作業を行うと、最終的にはパフォーマンスの壁にぶつかります。分析しているデータが大きすぎるか、処理のニーズが高すぎます。 これは、パンダの研究をしていたときによく見かけました。それが起こったとき、私の同僚と私は「パンダをより速くする」とグーグルで検索し、このホットな話題に関する数え切れないほどの記事を見つけました。 このような状況にある場合は、利用可能なリソースをぜひチェックしてください。特に 使い方を説明するもの。しかし、期待を高くしすぎないでください。パンダができることには厳しい制限があります。大丈夫です。データ分析のすべてを終わらせるように設計されたわけではありません。 pandas のより良い データ ワークロードをスケーリングする必要がある場合の最適な代替手段は次の 2 つです。 。 Spark は、大規模な分析と並列化されたデータ処理のためのエンジンです。 PySpark を使用すると、Python でそれを活用でき、pandas を連想させる構文を使用します。 pandas API もあります。 パイスパーク 。非常に大規模 (テラバイトやペタバイトと考えてください) でデータを保存および分析するためのシステム。最新のデータ ウェアハウスはクラウドで実行されるため、サーバーを管理することなく分散システムの機能を活用できます。 Google Cloud のデータ ウェアハウス ソリューションである BigQuery は 。通常、データ ウェアハウスは SQL で動作します。 （BigQuery を無料で試してみたい方 ） データ ウェアハウス 、30 秒で 1,000 億行または 7 テラバイトのデータを処理できます は、こちらに書きました。 パンダはいつより良いですか？ パンダを遠ざけてほしくありません。これは間違いなく学ぶ価値のある素晴らしいツールです。 pandas が SQL よりも適し 場合があります。ここでは詳しく説明しませんが、簡単なリストを次に示します。 ている 他の Python ワークフローと統合する場合 (機械学習を行っている場合や、Python 視覚化ライブラリを使用したい場合など)。 簡単な統計が必要な場合。 メソッドは非常に便利です。 describe() 規模や再現性を気にせずに、すばやく分析を行う必要がある場合。ただし、Excel や Google スプレッドシートも同様に機能する場合があります。 Python アプリケーションを構築している場合。 Pandas は、任意のデータ構造からテーブルに、またはその逆に移動する最も速い方法かもしれません。 命令型のワークフローとループが必要な場合。たとえば、マルコフ シミュレーションの構築。 実際に 通常とは異なる関数を作成または再利用する必要がある場合。 Pandas は、任意の Python 関数を適用するのに優れています。 非常に動的でパラメーター化されたワークフローがある場合。 結論 この記事が、SQL と pandas、およびそれらの相対的な長所と短所についてより深く考えるきっかけになれば幸いです。 現在のデータの傾向はパンダに有利に傾いていると思います。SQL は自己責任で無視してください。 これが私のアドバイスです： : SQL を学習し、それを分析に使用する方法を学びます。後悔することはありません。 学習者の場合 : 生徒がテーブルで夢を見て、すべて大文字で話すまで、生徒を SQL で溺れさせます。それはタフな愛であり、彼らはあなたを憎むでしょうが、いつの日か彼らは理解するでしょう. （ただし、頭を殴らないでください。） あなたがカリキュラムの設計者である場合 : 生徒を Pandas から徐々に引き離し、SQL の問題に挑戦するように促してください。 あなたが指導者の場合 会話を盛り上げたいです。コメントを残すか、私に か、 に私を追加してください。 メールを書く LinkedIn
