言語エピックが失敗する、またはPower BIでロシア語の辞書全体を詰め込む方法

どういうわけか、Power BIの言語分析の問題を解決すると同時に、 以前の記事の例を探して、数年前にExcelで解決しようとした問題を思い出しました：多数のクエリの言語分析のために分析システムにロシア語辞書を実装する必要がありました自然言語で。 また、標準のオフィスツールを使用することが望ましいとされました。 大多数の人がすぐにこのタスクをExcelで処理し、かつて同じ方法で作業を行いました。 ロシア語のオープンコーパス（ http://opencorpora.org/ ）を辞書として使用しました。



しかし、失望は私を待っていました-辞書は30万語の形式、500万以上のエントリで構成されていました、そして、Excelのために、それは原則として、不可能な量です。 100万行だけを押し込んだとしても、急いでいることのない非常に辛抱強い人だけが、それらの操作や神の禁じられた計算を行うことができます。 しかし、今回は、タスクに適したツール-Power BIを設定することにしました。

Power BIとは何ですか？

この製品は、専門家コミュニティによって大きく過小評価されています。 Power BIは、「列ごとに金額をノックダウンする」よりも少し高いレベルでExcelを所有しているユーザー向けに作成されたビジネス分析ツールのセットです。 Excelで中程度の複雑さの数式を作成できる人は、数晩でPower BIを習得します。



これは、何らかの内部プログラミングロジックを備えた単一の製品ではなく、3つのコンポーネントのシステムです。

• パワークエリ これはETLであり、独自の完全に機能するプログラミング言語を使用してクエリを記述する必要があります-M.公平に言うと、ほとんどの場合、通常のユーザーがプログラムする必要はほとんどないことに注意してください：ほとんどの機能は、コンポーネントインターフェイスのメニューまたはウィザードから直接利用できます。 M言語は、DAXクエリ言語（PowerPivot）とはまったく異なります。 ただし、Microsoftはそれらをまとめました。 これは、開発の観点からは意味があります。ETLは、データの受信と初期飽和（高速ではない）、およびDAX-このデータの視覚化に役立つ計算（高速）向けに設計されています。 つまり、DAXはフロントエンド用で、Power Queryはバックエンド用で、データの抽出とフォーマットのプロセスです。
• PowerPivot xVelocityエンジンに基づくメモリ内処理モジュール。 Excelの式言語に非常によく似たDAXクエリ言語を使用します。
• 視覚化コンポーネント 。 企業のウェブサイト、技術サポートポータル（リクエストクラウドなど）、または社内のリソースなど、データを視覚化する必要があるシステムでの使用に非常に便利です。 Power BIを使用せずにこれを実行できるツールはありますが、それらの多くは、レコード数が数百万単位であり、データを何らかの方法で集約する必要がある場合に役立ちません。 また、この種の他のツールを使用すると、Power BIはそのシンプルさと低コストのメモリ内処理により競合します。 テラバイトのデータについて話している場合、別のアプローチが必要になることは明らかです。 そして、そのような場合、マイクロソフトはすでに提供するものを持っていますが、これは別の記事のトピックです。

最初の段階の学習曲線は非常に急激に増加します。Excelが得意であれば、Power BIの機能の80％が短時間の研究で明らかになります。 これは非常に強力なツールであり、非常に使いやすいですが、特定のポイントまでは。 最大限に活用するには、M言語とDAX言語の経験と深い知識がすでに必要です。

Power BI Desktopとは何ですか？

誰に役立つのでしょうか？ まず、Excelが対応できなくなったり、限界に達したときに大量のデータを処理および分析する必要があるビジネスユーザー。 Power BI Desktopは、非常に多様なタスクを解決する幅広いユーザー向けに設計されています 。 たとえば、私の場合、キーワードの頻度を後で決定するために500万のテキストエントリを正規化することでした。



これは、アンケート、検索エンジンクエリ、広告、口述/エッセイ、ある種の統計配列などを処理するとき、またはクロスワードを解決するために必要です...



別のケースと実装オプションは、Dmitry Tumaikinの「認識」 に関する記事で検討されています。 クラシックExcelに実装されていますが、マクロを使用しています...



Power BIのこのアプリケーションのもう1つの一般的なシナリオは、現在の期間と前の期間のインジケーターの比率を計算することです。 たとえば、事前に集計された収益データがあるため、前の四半期、年、または同様の期間と日単位で比較する必要があります。 そして、式ではなく、値の形式で次の列に比較の結果を挿入する必要があります。 Excelの最も単純なタスクは、単純な比較式を記述し、列内のすべてのセルにまたがることです。 しかし、テーブルに数百万行ある場合はそうではありません。 DAX自体では、このタスクはExcelの場合よりもさらに簡単ですが、計算後の助けが必要です。



Power BIを使用するための他の多くの実用的なシナリオを提供できますが、あなたはすでにその本質を理解していると思います。 もちろん、これらのタスクはすべて、たとえばPythonやRを所有しているプログラマーにとっては問題ではありませんが、このような専門家はExcelの専門家よりも数桁先験的です。 Excelの可能性は限られていますが、Power BIではそうではありません。PowerBIは、Excel式言語に非常によく似たDAX式言語を使用し、何百万および何千万ものレコードをオンザフライで処理できます。 次に、RAMを増やす必要があります（少なくとも最大100、少なくとも最大300 GB）。

技術サポートプロセスのリクエストを支援します

しかし、私の仕事に戻ります。 テクニカルサポートゼロラインがユーザー要求のトピックを自動的に評価する方法を考え出す必要がありました。 まず、特定の単語形式を分離し、ユーザーが最も頻繁に取り上げる最も重要なトピックを、メッセージに出現する頻度によって決定することにしました。



ソース辞書は、次のような規則的な構造を持つ単純なテキストファイルです。







統計目的のために、各単語形式の初期形式を決定する必要がありました：名詞-名詞格の単一の番号、動詞-不定形など プログラマーにとって、このタスクは単純ではありませんでした。左側の列の各単語について、辞書内のこの単語の番号の直後に続くフォームへの対応を見つけます。



これは、Python、特殊なツール、開発スキルを所有していない平均的なビジネスユーザーであり、自己分析BIまたは同様のユーザーフレンドリーなツールを使用しないとこの問題を解決できません。 さらに、内部ニーズのためにデータを処理する必要がある場合、または保護を必要とする機密情報がない場合、この場合のPower BIも無料になります*。





データを分析するには、Power Queryで、500万件のレコードのテーブルに、1列シフトした新しい列を追加する必要がありました。 最初に、Power Queryを使用した従来のアプローチを適用しようとしました。これは、元のオンラインPower Queryオンラインリファレンス（Power Queryでも作成）の著者であるMarcel BeugによるPower BIコミュニティポータルで説明されています。 この記事では、2つの異なるアルゴリズムが提案されています。1つは有名な指導者であり、Power BIトレーナーであるMatt Elingtonのアイデアから着想を得たものです。 生産性を高めるためにソースデータを完全にキャッシュしたという事実にもかかわらず、どちらのアプローチも膨大な時間を必要としました。すでに8日目であり、プロセスは完了していませんでした。 ソースファイルのサイズは270 MBで、処理されたデータの現在のサイズは17 TBに近かった。 ファイルソースからデータをロードするためのウィンドウでこのような数値を見たPower BIユーザーはほとんどいないと思います。







なぜボリュームが非常に腫れているのかは明らかではありません。 すべてのレコードのデカルト積でさえ16 Tbをはるかに下回っています。 ここで、内部オプティマイザーは明らかに標準以下でした。 また、たとえば、DAX-StudioはPower Queryクエリのトレースを許可せず、DAXのみを許可します。 誰かがPQ Troubleshippingでの経験を共有するでしょうか？



最初のプロセスの完了を待たずに、別のマシンを使用して、自己記述クエリを通じてDAXを使用して問題の解決を試みることにしました。 リクエストは約180秒で完了し、メモリ消費がわずかに増加しました。







DAXリクエストのソースコード：



KeyWord =

CALCULATE(

TOPN(1;

CALCULATETABLE(

VALUES(ShiftedList[Word])

;ALLEXCEPT(ShiftedList;ShiftedList[Word Nr])

)

)//TOPN

)//CALCULATE











つまり、新しい[KeyWord]列の各行について、同じ基本単語形式番号（[Word Nr]列）を持つ単語形式のすべてのバリアントを含む[Word]列の最初の値が検索されます。 ソースファイルの形式が変更されない限り、辞書の後続のすべてのリリースでリクエストはエラーなしで実行されます。



必要な形式でソーステーブルを形成するPower Queryのクエリコードは「自動的に」生成され、1分以内で完了しました。







PowerPivotインターフェイスで3分間でキーワードの列が形成された後、Power BIインターフェイスで単語形式を検索するのに必要な時間は4秒以内です。 さらに、お気に入りのNotepad ++ x64で同じデータをコントロール検索するには、20秒以上かかります。 しかし、これはNPPの庭にある石ではありません-既にマークアップされているデータよりもデータ配列全体を検索するのはより困難です（そしてより長いです）。



ちなみに、上記のDAXリクエストは初めて生まれたものではなく、中間オプションは使用可能なメモリをすべて消費し、長時間動作し、データエラーまたは無関係な結果で終了しました。







その結果、保存されたPBIXファイルのサイズは元のテキスト辞書より60％小さくなりましたが（112 Mb）、同じ辞書を使用したZIPアーカイブのサイズの4倍以上になりました。



Power QueryとDAXの戦いに戻りましょう。異なるコンポーネントでの同じ操作の期間の違いは、Power BIが受信がないクローバーではないことを示唆しています。 彼は彼自身の性格とアプリケーションの特徴を持っているので、彼の仕事ではそれらを考慮しなければなりません。 実際、他のツールと同じです。 そして、認められているグルの推奨すら慎重に扱われるべきです。



ノーベル賞受賞者のリチャード・スモーリーは、クラークの最初の法則を言い換えて言っていたようです。「専門家が何かが実行可能であると言ったとき、彼らはおそらく正しい（いつ彼らは知らない）。 これが不可能だと言うと、おそらく彼らは間違っているでしょう。」



試験機の特性：

プロセッサー：Intel Core i7 4770 @ 3.4 GHz（4コア）

RAM：16 GB

OS：Windows 7 Enterprise SP1 x64



Power BI形式の既製の辞書は、こちらからダウンロードできます 。



そして、 ここでは辞書の修正されたオンライン版が利用可能です。 それであなたの余暇にクロスワードを解決することができます:)







...ところで、数年前に、タスクは100％ではありませんが、それでもExcelで解決されました。 テキストの分析のために、ロシア語のコーパス全体ではなく、頻度辞書が使用されました。 基本的なテキストクリーニングには 、数十キロバイトのtop100使用可能な頻度リストのいずれかが非常に適しています。



ユーリ・コルマコフ、Jet Infosystems（McCow）統合およびデータ可視化システム学科、エキスパート