モノリシックなデータレイクから分散型データメッシュへの移行方法とは

多くの企業は、次世代のデータレイクに投資しており、大規模なデータを民主化してビジネスインサイトを提供し、最終的には自動化されたインテリジェントな意思決定を行うことを期待しています。データレイクアーキテクチャに基づくデータプラットフォームには、大規模化しても約束が果たされないという共通の失敗モードがあります。これらの問題に対処するためには、データレイクやその前身であるデータウェアハウスの中央集権的なパラダイムからシフトする必要があります。すなわち、ドメインを第一級の関心事とし、プラットフォーム思考を適用してセルフサービスのデータインフラを構築し、データを製品として扱うという、最新の分散型アーキテクチャを採用したパラダイムに移行する必要があるのです。

Dict[]に複数の型を指定する

Python

h = {'a': [], 'b': {})

のような辞書にたいして型ヒントを設定したい場合どうすればいいだろうか?

これは「混合辞書(Heterogeneous dictionaries)」と呼ばれるもので、特定のキーに対して特定の型の値を定義する必要がある。この問題は、文字列キーを持つ混合辞書のTypeで議論されていますが、最近になってようやくPythonで実装された(3.8以降)。 https://github.com/python/typing/issues/28

docs.python.org

PythonでInner class(Nested Class)を使うケース

なぜInnerクラス(Nested クラス)なのか?

主に以下の3つのメリットがあげられる

  1. 2つ以上のクラスをグループ化することができる 車とエンジンの2つのクラスがあるとします。車にはエンジンが必要です。しかし、エンジンは車がないと使えません。そこで、エンジンを車の内部クラスにします。これでコードの節約になります。

  2. クラスの隠蔽。Nestedクラスを利用することでそのクラスを外部から隠すことができます。

  3. クラスがわかりやすくなります。ここではクラスは密接に関係しています。コードの中でクラスを探す必要はありません。全部一緒になっています。

インナークラスやネストされたクラスは、Pythonではあまり使われていない機能です。しかし、コードを実装する上では良い機能になります。インナークラスやネストされたクラスを使うと、コードが整理しやすくなることがあります。

class Outer:

    
    class Inner:
        pass

python ; json serialize時の変数の命名・改変

変数の命名・改変をしたい

モチベーション

データソースのフィールド名がコードスタイルと一致しない場合(キャメルケースのフィールドなど)、classに変換方法を記述し自動的にエイリアスjson でdumpするときに生成したいことがある。JSON形式などで生のキー-値のようなデータを受け取る場合、キーはあらゆる種類の命名規則に従うかもしれません。例えば、{"user-name". "Peter"}を受け取ることができます。(ケバブの場合), {"userName". "Peter"} (キャメルの場合)、または {"user_name". "Peter"} (スネークケース)を使用します。しかし、Pythonではスネークケースが一般的で、他の規約を使うのはまれだ。

こうした需要をサポートするのがmarshmallow と Pydantic だ。marshmallow と Pydantic の両方が、実際にフィールドの名前を動的に変更するサポートを提供する。marshmallowはこちら、Pydanticはこちらを参照。

Pydanticの場合、 シリアライズのためにはo.dict()の代わりにo.dict(by_alias=True)を呼び出す必要がある点に注意する。

dataclassのmetadataにアクセスする方法 : __dataclass_fields__を使う.

メタデータ。これは通常は辞書であり、様々な情報とそのデータを示すキーと値のペアです。 この属性は、ほとんどの場合には使用されていないようですが、もしあなたのDataClassが開発中にどこかで実際に使用されていて、サードパーティのツールやソフトウェアがプロジェクトに統合されているときに、属性のデータが使用されたり、サードパーティによってアクセスされたりする場合には重要です。 スクリプトでは、オブジェクトの dataclass_fields 変数を問い合わせることで、その値にアクセスすることができます。

ライブラリ紹介:schema libraryの marshmallow

marshmallow はオブジェクトのような複雑なデータ型を Python のネイティブデータ型との間で変換するための ORM/ODM/フレームワークに依存しないライブラリ。

marshmallow.readthedocs.io

PythonのNLPライブラリ入門 - NLTKと spaCyの比較

NLPで使用されている2つの重要なライブラリはNLTKとspaCyです。両者にはそれぞれ性質が異なる。

機能性・言語対応

NLTKは、研究者のためさまざまな問題のために選択するアルゴリズムを提供するが、逆にこれは開発者のための悩みの種となっています. 一方、spaCyは、そのツールキット内の問題に最適なアルゴリズムを保持し、state of artを常に更新し続けている。 一方でNLTKは様々な言語に対応している点では分があると言える。spaCyは7つの言語(英語、ドイツ語、スペイン語、フランス語、ポルトガル語、イタリア語、オランダ語)に対応した統計モデルを持っている。また、多言語に対応した名前付きエンティティもサポートしている。 また最近リクルートからSpacy日本語対応の鍵となるライブラリGINZAがでたことで、実質日本語でも利用可能となった。 (spaCy と GiNZA の関係性は、自然言語の文字列を形態素に分割する Tokenizer, spaCy の統計モデルに相当する Language といった部分の実装を GiNZA が担当している。)

アーキテクチャ

NLTKは文字列処理ライブラリで、文字列を入力として受け取り、出力として文字列または文字列のリストを返します。一方 spaCy はオブジェクト指向のアアーキテクチャを採用している。テキストを解析すると、単語や文章をオブジェクト化したドキュメントオブジェクトが返されます。 また、NLTKがサポートしていないのに対し、spaCyは単語ベクトルをサポートしています。 spaCyは最新のアルゴリズムを使用しているため、NLTKと比較して性能は通常良好です。以下に示すように、単語のトークン化とPOSタグ付けではspaCyの方が性能が良いのですが、文のトークン化では、NLTKがspaCyを上回っています。文章のトークン化でのパフォーマンスが低いのは、アプローチの違いによるものです。NLTKは、テキストを文に分割しようとします。対照的に, spaCyは各文に対して構文木を構築します, テキストについてのより多くの情報が得られるよりロバストな方法といえる。