Events
時系列からベクトルへ：類似性検索のための InfluxDB と Milvus の活用

ウェビナー

時系列からベクトルへ：類似性検索のための InfluxDB と Milvus の活用

Name: 時系列からベクトルへ：類似性検索のための InfluxDB と Milvus の活用
Start: 2024-10-18T00:00:00.000Z
End: 2024-10-18T01:00:00.000Z

Zillizウェビナー | Zoom

Join the Webinar

何を学べますか？

このウェビナーでは、時系列データとベクトル類似検索の強力な組み合わせによって、都市交通管理を革新する方法を解説します。InfluxDB からの生のセンサーデータを意味のあるベクトルへ変換し、高性能ベクトルデータベースである Milvus を使用して高度なパターン認識と異常検知を可能にする方法を学びます。

リアルタイム交通監視の実践的なユースケースを通じて、この革新的なアプローチが、事故から工事区域まで、交通異常を迅速に特定・分類できることを実演します。このウェビナーは、複雑な実世界のアプリケーションにおいて時系列データの可能性を最大限に活用したいデータサイエンティスト、交通エンジニア、都市計画担当者にとって不可欠です。

取り上げるトピック:

時系列ベクトル化の基礎: ベクトルデータベースで使用するための InfluxDB データの変換
包括的な交通監視ソリューションのための InfluxDB と Milvus の統合
交通異常を分類するための Milvus における類似検索の実装
リアルタイムデータ処理と異常検知のベストプラクティス

View presentation slides

Transcript

本日は、えー、Influx、IBand MAL Listを活用した類似性検索のための、セッション「時系列からベクトルへ」をご紹介できて嬉しく思います。そして本日のゲストスピーカーはAnaiです。えー、彼女は、えー、時系列からベクトルへの変換についてお話しします。AnaiはInflux Dataのデベロッパーアドボケイトで、データ分析、AI、機械学習を活用してデータを美しくすることに情熱を持っています。彼女は収集したデータをもとに、リサーチ、探索、エンジニアリングを組み合わせて、そのデータを機能、価値、美しさを備えたものへと変換します。

画面の前にいないときは、外で絵を描いたり、ストレッチをしたり、ボーリングをしたり、ボールを追いかけたりしている彼女を見つけることができます。ようこそ、anise。ステージはあなたのものです。本当にありがとうございます、Stephan。えー、皆さんようこそ。

本日は、時系列データをベクトルに変換してvisに保存し、実際にその時系列データに対して類似性検索を実行する方法について学びます。これにより、えー、つまり、時系列データを他の種類の非構造化データと同様に扱い、それらを組み合わせて、いくつかの架空のユースケースに活用できるようになります。このトークには、Jupyter Notebookを使ってそれを行う方法、そして実際にデータを変換する方法を一通り確認する簡単なデモが含まれます。えー、そしてこれは、あくまで導入として、どのようにこれを行うのか、えー、つまり、実際に保存しているどのようなデータにも同じロジックを適用できるようにするためのものです。えー、実際に保存しているどのような時系列データでも、それをVISのようなものと組み合わせて活用できます。Stefanが言ったように、私の名前はanで、Influx Dataでデベロッパーアドボケイトをしています。Influx Dataは、時系列データベースおよびプラットフォームであるInfluxDBを作っています。

また、もしよろしければLinkedInで私とつながって、今日のプレゼンテーションについて、時系列、時系列予測、時系列、言語モデル、えー、統計、えー、データベース、そうですね、時系列に関することなら何でも質問していただきたいです。ですので、えー、ぜひそちらから気軽にご連絡いただき、よろしければつながってください。ただ本日はまずInfluxDBについて話し、それが何であるかを少し学びます。visのためにここにいらっしゃるなら、VISについてはすでにもう少しご存じかもしれないという前提です。そして、一般的な時系列データベースについてお話しします。次に、時系列データベース、VER対ベクトルデータベースについて話します。そして率直に言って、これはリンゴとオレンジを比較するようなものです。

かなり異なりますが、それぞれをよりよく理解するために、2つを比較することは有用だと思います。えー、その次に、ご自身で試せるさまざまなプロジェクトに入ります。いくつかのリソースやプロジェクトをご紹介したいと思いました。もし時系列予測や機械学習の分野に興味があり、時系列を使って何かをしたい、でも同時に非構造化データでも何かをしたい、そして、えー、その種のデータを1つのプロジェクトにどのように組み込めるか見てみたい、ということであれば。その後、デモを行い、InfluxDBとNovusを活用した類似性検索について話します。

その際には、交通データの中からいくつかの異常を見つけようとしているという架空のユースケースを使います。それから、機械学習分野におけるInfluxDBのいくつかのユースケースについて話します。これは、私がより具体的に取り組んでいる分野のいくつかについて、皆さんによりよく理解していただくためです。そして、機械学習や、えー、データ処理のようなタスクに使えるツールについては、たぶん、説明しないと思いますが、するかもしれません。なので、それは未定です。えー、それでは始めましょう。InfluxDBと時系列データベースの紹介です。

したがって、Influx、CCBand、そして時系列データベース全般を理解するために、まず理解する必要があるのは、時系列データとは何かということです。そして時系列データとは、タイムスタンプが関連付けられたあらゆるデータのことです。最も初期で、おそらく最も単純な例は株式市場データです。そして時系列について興味深い点、あるいはそれを独特にしている点の1つは、リレーショナルデータの場合のように単一の値自体は興味深くないということです。代わりに、時間の経過に伴うデータの傾向を見ており、それが買うべきか売るべきかといった意思決定に役立ちます。また、それは統計的な観点からも時系列を興味深いものにしています。なぜなら、Xとyxiを持つほとんどのデータでは、X軸を、ええと、Y軸、またはy変数が独立しているものと考えるからです。

しかし時系列では実際には依存しています。つまり、それはデータの分析方法や、どのような予測および異常検知ツールを使用する必要があるかに、さまざまな影響や効果をもたらすということです。時系列データの他の例には、IOT領域や、ええと、仮想世界のあらゆるものが含まれます。つまり、iotまたはセンサーの世界では、圧力センサー、温度、湿度、濃度、光、流量などのセンサーから来る時系列データを考えることができます。物理世界について測定しているあらゆるもの、それはすべてIOTデータであり、すべて時系列データです。

そして同じ論理を仮想世界にも適用します。ええと、ただしソフトウェア開発に関連する仮想的な概念です。つまり、アプリケーション監視、インフラストラクチャ監視、DevOps監視を考え、そして、ええと、仮想または物理環境に関する傾向や時間を理解したいと考えます。そこで私たちは、時系列データを2つの異なるタイプに分類したいと考えています。1つ目はメトリクスで、メトリクスは一定の時間間隔で現れます。

2つ目はイベントで、イベントは予測不可能であり、イベントがいつ発生するかを実際に判断することはできませんが、それでもイベントデータを同じように保存することはできます。医療分野では、心拍数はメトリクスであり、AFibや心臓発作のような心血管イベントはイベントになります。ええと、しかし2種類の時系列データの間で興味深い点の1つは、イベントをメトリクスに変換できるということです。つまり、イベントがいくつあるかを数えれば、たとえば産業用IOTのシナリオで、1日にどれだけの機械故障が発生するかを見ているとすると、このメトリクスはおそらく0以上になります。したがって、イベントデータからメトリクスが得られるわけです。

そしてこれは、InfluxDBが非常に得意としていることでもあります。ええと、さらに、時系列データは本当にあらゆる業界で発生します。製造業でも見られます。先ほど述べたように、機械を監視し、予知保全のようなことを行っています。再生可能エネルギーでは、電力消費からその再生可能エネルギーの生産まで見られます。開発者ツールやAPIでも見られます。

たとえば、ユーザーが特定のリクエストを何回トリガーするかを考えることができます。たとえばKubernetesでは、podアプリケーション、ええと、podおよびアプリケーション監視があります。そしてゲームアプリケーションでも見られます。ゲームサーバーの監視を考えることができ、傾向やゲーマーの活動を見たり、ええと、レイテンシを削減したいと考えたりできます。そしてもちろん、ネットワーク監視やSMP監視でも同様です。

そのため、時系列もカテゴリとして伸びているのがわかります。ただし今は、新しい、いわゆる、注目のクールなキットはベクトルデータベースです。ええ、とはいえ、時系列データベースもこの理由で伸びています。単に、時系列データが非常に多くのさまざまなユースケースの一部だからです。そして、ええ、それはもともと本当に登場しました。ご存じのとおり、私たちにはリレーショナルデータがあり、それは注文やレコード取得には本当に優れています。ええ、でも、非常に大量のデータに対するリクエストを処理するのはあまり得意ではありません。そして次に、非常に高スループットで適応的なスキーマを持つドキュメントデータベースが登場しましたが、それらはスペースやリソースを、ええ、大量に消費します。ええ、そして検索データベースがあります。それらはログやその他のテキストベースの時系列データを検索するのには優れていますが、ええ、メトリクスに対しては少し遅いことがあります。

ええ、だからこそ、イベントデータ、メトリクスデータ、ログ、トレース、そしてスパンも処理することを特に目的とした時系列の登場が見られるのです。ええ、では時系列データベースとは何で、何が得意なのでしょうか？時系列データベースを構成するコンポーネントや柱にはどのようなものがあるでしょうか？まず第一に、タイムスタンプ付きデータを受け入れて書き込めることです。これはある意味当然で、時系列データベース内のすべてのポイントはタイムスタンプに関連付けられています。時間でインデックス化され、順序付けられているので、時間順にクエリでき、実際に意味のあるデータを返すことができます。また、非常に高い書き込みスループットも備えています。たとえば、工業製造を見ている場合、もしかすると監視しているのは、ええ、何らかの機械やベルトで、振動センサー、産業用振動センサーセンサーがあり、ええ、非常に高いスループット、たとえば1秒あたり1〜10キロヘルツ程度のデータがあります。

つまり、時系列データベースに書き込むデータは最大で毎秒約10,000ポイントになります。そして、振動センサーを備えた複数の設備を監視している場合、1つの工場にある他のすべてのセンサーは言うまでもなく、書き込む必要のあるポイントが毎秒数十万、あるいは数百万にすぐ達することがわかるでしょう。ええ、さらに、時系列データベースに大量のデータを書き込めても、それをクエリできなければ、あまり役に立ちません。したがって、時間範囲にわたって非常に効率的なクエリを実行できる必要もあります。そして、その時間範囲にわたって、ええ、集計も実行する必要があります。

ご存じのとおり、ローカルおよびグローバルの最小値と最大値のようなものを見つけられるようにしたいわけです。つまり、データ全体に対して非常に高速なスキャンを実行できる必要もあり、そうすることで実際にそれらのポイントを返してもらうことができます。そして最後になりましたが、これは時系列データベースに固有のものではありませんが、スケーラビリティとパフォーマンスですよね？スケーラブルなアーキテクチャ、つまり分散されたマシンのクラスター全体にわたるあらゆる種類の負荷増加に対応するために、水平方向にスケールするよう設計されたものが必要です。そして、これが InfluxDB 3. 0 の姿です。

これは 3. 0 のアーキテクチャ図です。ええ、ひとつ面白い事実として、オープンソースの 3. 0 は1月にリリースされる予定です。なので本当に楽しみにしています。

ええ、ただしすべて Apache エコシステムの上に構築されています。つまり data fusion の上に構築されています。そして data fusion はクエリ実行フレームワークです。これにより、ユーザーは SQL と influx の両方で InfluxDB にクエリできます。QL Influx QL は、InfluxDB 独自の SQL に似たクエリ言語です。

そして、これらのクエリを非常に効率的にするための PR プルーニングやプッシュダウンも担っています。次に Apache Arrow もあり、これは私たちのインメモリの calmer データ形式です。そして Parquet は、同じく calmer な耐久性のあるファイル形式です。私たちが Apache エコシステムの一部であることにコミットしている理由の一つは、そのオープンデータアーキテクチャの一部となるためです。つまり、Parquet のようなものを活用する他のツール、Arrow や Arrow flight クライアントのようなものを活用する他のツールとの相互運用性を高めることができるということです。それによって、Influx CB からデータを簡単に取り出し、他のツールで利用できます。

ええと、多くの機械学習ツールはParquetを直接活用し、Parquetファイル上で動作します。ですから、たとえば一部のデータヒストリアンのようにベンダーロックインが多いものとは異なり、InfluxDB 3. 0の主な目標の1つは、最終的にはInfluxDBからParquetファイルを直接取り出してクエリできるようにし、好きなツールでそれらを活用できるようにすることです。ええと、さらに加えて、Apacheエコシステムの一部であるということは、私たちがそれらのアップストリーム技術に継続的に貢献し、そのより大きなコミュニティの一員であることを意味します。それにより、他の企業が私たちの行った貢献を活用できるだけでなく、それらを活用する他のすべてのツールとの相互運用性も持てるようになります。では次に、ベクトルデータベースについて話しましょう。

ここでウェビナーに参加されているので、皆さんがすでにベクトルデータベースにある程度詳しいことを願っています。VISについてですが、ベクトルデータベースはたくさんあり、ベクトルデータベースは間違いなく今注目の新しい存在です。ええと、ベクトル埋め込みの処理に特化したデータベースであり、機械学習検索エンジンやレコメンデーションシステムのようなアプリケーションで、本当に複雑なデータ、テキストデータ、動画データなどを表現し比較するために使われます。ええと、たとえばVISはもちろんオープンソースのベクトルデータベースであり、近似最近傍探索、n探索、厳密探索の両方をサポートしています。ええと、それからPine Coneがあり、Facebookによって作成されたATE faceがあり、Annoyなど、ほかにもさまざまなベクトルデータベースがあります。

ええと、ただオープンソースのものはそれほど多くなく、私はVISがとても使いやすいと感じました。では、ここで少し時間を取って、時系列データベースとベクトルデータベースを比較対照したいと思います。両者の違いについて大まかな理解を持てるようにするため、またそれらがどのように機能するのか、ええと、一般的な点についても理解するためです。その話に移る前に、もしベクトルデータベースがどのように機能するのかに詳しくない場合に備えて、少しだけ説明したいと思います。基本的に最初のステップは表現です。つまり、テキストのようなデータであれ、画像であれ、そのデータをベクトルに変換します。そしてテキストの場合、それは各単語、あるいは文を、画像に対する単語の意味に基づいてベクトルに変換する何らかのモデルを使うことを意味するかもしれません。

画像の場合は、エッジや色、テクスチャのような特徴を抽出し、それらをベクトルとして表現することを意味するかもしれません。そして、それらのベクトルをベクトルデータベースに保存します。データを行と列に保存する従来のリレーショナルデータベースとは異なり、ベクトルデータベースはベクトルの非常に高い次元性を扱うよう最適化されています。そして検索をより効率的にするためにインデックスを使用します。つまりデータベースはこれらのベクトルに基づいてインデックスを構築します。

そしてインデックス作成とは、類似したベクトルがデータベースのストレージシステム内で互いに近い位置に配置されるようにベクトルを整理することです。ストレージシステム、ええと、それにはAやnなどの特殊なアルゴリズムが使われます。そして最後に、そのデータに対して検索を実行します。つまり、クエリしようとしているデータに類似したデータを見つけたい場合、たとえば特定の画像に似た画像を見つける場合、顔認識などを考えることができますが、そのクエリデータもベクトルに変換されます。そしてデータベースはそのインデックスを使って、クエリベクトルに最も近いベクトルを素早く見つけます。ここでの近さは距離を測る方法であり、文字どおりユークリッド距離のようなものを使っています。

つまり、ええと、これがベクトルデータベースの仕組みの概要です。ええと、では次に両者の違いについて話しましょう。時系列データベースについては、ええと、これらのユースケースについてはすでに話しました。これはリアルタイム監視のユースケースです。つまり、時間の経過に伴うデータの追跡を見ています。

監視サービスのパフォーマンス、金融市場のトレンド、または環境センサーデータを見ています。ええと、利点のいくつかは、それらが最適化されていることです。時系列データ向けであり、時間にわたってデータをクエリし、非常に大量の連続データを処理できます。効果的に、効果、効果的に、すみません、また、ええと、時間ベースの集計を実行し、データに対して高速スキャンを行って、最小値、最大値、件数、平均などを見つけることができます。また、非常に高速な挿入とクエリも可能にします。ええと、ベクトルデータベースは、非常に異なるユースケースです。

ええと、ご存じのように、類似性検索を実行します。ですから、特定のクエリに類似したアイテムを見つけようとしているシナリオ、画像検索、レコメンデーションシステム、またはコンテンツに基づくドキュメント検索に理想的です。うーん、また機械学習とAIにも使用されます。つまり、非常に複雑なデータモデルを含むアプリケーションで有用で、これらの埋め込みやベクトルがあり、それらを高次元空間で表現して、特にクラスタリングや分類のようなタスクに使います。では次に、時系列データベースで機械学習をどのように使うか、そしてベクトルデータベースで機械学習をどのように使うかについて、少し話したいと思います。時系列データベースでの機械学習には、予測、過去の系列に基づいて将来の値を予測する、といったものが含まれます。

つまり、ご存じのように、売上を予測したり、気象条件を予測したり、うーん、心拍数を予測したり、などです。また、時系列分類のようなことも行うかもしれません。過去の時系列データに基づいてカテゴリやイベントを特定します。たとえば、予知保全のために、機械データに、うーん、異常があるかどうかを分類しようとするような場合です。うーん、それから時系列データにおける異常検知もあります。一般的には、期待される挙動に適合しない異常なパターンを検出しようとすることです。

つまり、サイバー攻撃を示している可能性のあるネットワークトラフィックの急増や、時系列データ内にあるかもしれない何らかの異常を特定します。そして、回帰分析の実行のようなことも頻繁に行います。つまり、時間の経過に伴う変数間の関係をモデル化します。そして、マーケティング支出が売上に与える影響や、さまざまな相関分析などを見ているかもしれません。うーん、そしてベクトルデータベースを用いた機械学習は、類似性検索の実行のようなものです。これはレコメンデーションシステム、データを類似性に基づいてクラスタに整理するクラスタリングに使われ、うーん、顧客セグメンテーションのようなこと、ええと、類似ドキュメントのグループ化、うーん、そして関連商品の発見にも役立ちます。

つまり、レコメンデーションシステムに似たもの、ええと、そして異常検知も同様です。ええと、データまたはベクトルがクラスタの標準からどれだけ逸脱しているかを正確に測定することで、データセット内の外れ値を特定でき、それによって不正取引や通常とは異なるユーザー行動の検出などに役立ちます。うーん、また、最近傍分類のようなこと、あるいは実際には任意の分類も行います。これは、ベクトルデータベースに保存されている最も類似した訓練例に基づいて新しいデータポイントを分類する、K Ns のような、うーん、分類アルゴリズムの非常に一般的な例の1つにすぎません。ですから、ここでまとめると、ベクトルデータベースの場合、ベクトルデータベースと機械学習は、コア要件がベクトル空間内のデータポイント間の関係を理解することであるアプリケーションに最も適しており、時系列とMLの場合は、データが本質的に連続的でタイムスタンプ付きであるアプリケーションに最も適しています。

そしてタスクは、時間の経過に伴うトレンド、変化、異常、予測を理解することを中心に展開します。とはいえ、それらを一緒に使えないという意味ではありません。そこで、皆さんに共有したいのは、ええ、試せるいくつかのプロジェクトのようなもので、特に1つは実際に時系列データをベクトル化することに関するものです。そうすることで、novisのようなものと一緒に使えますし、一般的に、時系列を、ええ、Novisと一緒に使えるいくつかのユースケースについて話したいと思います。まず最初にお見せしたいのは、ええと、Pythonクライアントライブラリです。なぜなら、Influx cbに何らかのデータを書き込むのであれば、ええ、特にそれをMel vs.と組み合わせたい場合には、これを使うことを強くおすすめします。なぜなら、その時系列データを実際にベクトルに変換してMelで使えるようにするために、何らかのデータ変換を行う必要があるからです。

ここで行うことは、まずライブラリをインポートし、次にホスト、org id、トークン、データベースを指定し、それらの、ええ、認証情報を提供してクライアントをインスタンス化します。次にデータをクエリします。あるいは同様に、queryメソッドの代わりにwriteメソッドを使って書き込むこともでき、データフレームを、ええ、data frameオプションに渡せば完了です。そしてデータフレームも書き込みます。ええ、しかしこれは、InfluxDBにデータが入った後、そのデータをどのようにクエリして取り出し、Pythonで活用して、時系列データからベクトルを作るために必要なこのデータ変換の一部を行うか、という方法でもあります。そうすれば、Elvisでの類似検索に使うことができます。

ええ、そしてこれがInfluxt b UIの見た目です。バケットを作成するのは、ええ、かなり簡単です。バケットは基本的にはデータを保存するデータベースのようなもので、load dataページのbucketsタブに移動し、create a bucketをクリックし、バケットに名前と保持ポリシーを付けます。これは、データがいつ自動的に期限切れになるかを決定します。なぜなら時系列データでは、現在のデータだけが重要であることが多いからです。古いデータは気にしません。

そのため、古すぎるデータを自動的に期限切れにできるようにしたいのです。ですから、その保持データの設定を含めます。例えば30日でも何でも構いません。名前を付けて、createをクリックすれば、バケットができます。ええ、そしてあなたの、ええ、org IDはこのURLのここにあります。これが見つける最速の方法です。なので、私はいつもそこでそれをおすすめしています。

同様にトークンを作成するには、単にトークンを生成できます。カスタムトークンを作成してスコープを設定し、特定のバケットに対して、読み取りか書き込みかはあなた次第ですが、権限を与えることができます。では、ええ、それを踏まえて、時系列をベクトルに変換する方法について話しましょう。このQRコードまたは下のURLをたどることができます。そうすると、GitHub上のこの、ええ、community influx community organizationに移動します。

GitHub上のInflux Community Organization on GitHub createには、さまざまな技術スタックをInfluxDBと一緒に使う方法について、さまざまな例がたくさん含まれています。ですから、単に時系列予測や異常検知を行うこと、あるいはさまざまな、ええ、技術スタックとInfluxDBを使うことに興味があるなら、ここに来ることを強くおすすめします。ここは私たちのクライアントライブラリが保守されている場所でもありますが、私たちは、ええ、例えば株価トラッカーデモを作成するようなプロジェクトも持っています。これは、ええ、私の、ええ、同僚のOSHがちょうど作ったもので、ええ、株価データを追跡し、それに対してリアルタイム分析を行うためのものです。Grafanaの例もたくさんあります。

私たちは、ええ、飲料製造会社と、そのすべての衛生管理およびボトリング com ボトリング、ええ、ボトリング、ロボットではなく、ボトリングを模倣するフェイクファクトリーも持っています。わあ、今ちょっと脳が止まりました。すべてのボトリング、ええ、機械です。ありがとうございます。ええ、すべてのボトリングと衛生管理の機械、ええ、ほぼ実在の顧客から直接、ええ、ほぼ実スケールで再現したものです。

それで、これはまた別のクールな製品で、私たちが持っているプロジェクトです。ええと、他にも、私のお気に入りのプロジェクトには、たとえば、MQTT の始め方や、そこにあるさまざまなシミュレーターがあります。ええと、最近、別のプロジェクトを作りました。これは、ええと、Kafka と Faust を使って、連続撹拌槽型反応器の PID コントローラーをシミュレートする方法を再現するものです。ええと、これは化学工学や製造で使われる一般的なタイプの化学反応器で、ええと、監視してデジタルツインを作成し、実際にコントローラーを使うためのものです。手短に言うと、時系列で何かをしたい場合や、ええと、そこを深掘りしたい場合には、ここにはチェックする価値のあるさまざまなプロジェクトがたくさんあります。でも今日は MIL プロジェクトについて話しましょう。というのも、それが今日ここにいる目的だからです。ええと、基本的にこれを実行するのは本当に簡単です。

まず、ええと、このディレクトリを、ええと、自分のマシンにクローンします。私はそれをもう済ませています。あとは docker compose を実行するだけです。なので、たぶん、それを共有しますね。Docker compose up を実行して viss のインスタンスを起動し、それから、ええと、新しいタブを作って、単に Jupyter Notebook を実行すれば、その notebook を実際に起動できます。

ちなみに、まだタブノートのままです。オーケー、ありがとうございます。では、正しいタブに移動するために画面を共有します。完璧です。はい。

これがそれを実行するための notebook で、出力をすばやく全部クリアします。完璧です。オーケー、では、基本的にこれでは、あと、十分大きいですか？見えますか？大丈夫ですか？ええ、大丈夫です。まったく問題ありません。オーケー、ありがとうございます。

オーケー。はい。ええと、基本的にこの notebook は、センサーデータを処理するワークフローを示すだけです。実際、ここに戻らせてください。これは、時系列データをベクトル化するための口実として私が作成した、ある種の架空のユースケースです。

ええと、これは時系列データベースとベクトルデータベースの関係をよりよく理解するのに役立ちます。そして、この架空のユースケースの中で、2 つを一緒にどのように使えるかを文脈化するのに役立ちます。ええと、私たちが、都市の交通管理を改善するために、リアルタイムの交通監視とパターン認識を提供するプラットフォームを開発していると想像してみましょう。具体的にやりたいことは、交通状況が匿名に動作しているときに識別するソリューションを作ることです。アノ、アノ、アノ、ああもう、アノ、ありがとう脳、今日は働いていませんね。

朝ですね。今日は自分の脳に対して、異常検知が必要です。そして、実際にどのような種類の交通データ、ええと、どのような種類の異常が存在するのかを判断します。この例では、制限速度、ええと、車両や交通の実際の位置などを influx CB cloud に保存しているかもしれません。そしてそれが実際のセンサーデータで、そこから車両台数や速度などを取得しています。

そして novis では、実際に、以前に異常が確認されたタイミングや、その異常の一部を、ええと、vis に保存しているかもしれません。そうすることで、データが通常の範囲から外れていることを検出したとき、たとえば「ねえ、通常の統計が外れているよ」と言うだけの本当に単純な、ええと、パラメーターを使って、その時系列データの一部を取り出してベクトル化し、Novis で以前に見た異常の一部と比較して、実際にどのタイプの異常があるのかを判断できます。つまり、それは事故なのか、たとえば単なる渋滞なのか、工事なのか、などです。また、時系列データを、通常ベクトルデータベースに保存される他の種類のデータと組み合わせるような、他のユースケースも想像できます。たとえば医療分野を考えることができます。そこでは、おそらく患者のさまざまな要素、心拍数や酸素レベルなどを監視しているかもしれません。

しかし、その後、それを医師のメモに基づくテキストデータや、ええと、患者の長期的な健康状態と組み合わせます。そしてまた、つまり、場合によっては画像、放射線科からのものなども含めて、それらすべてのデータを組み合わせることで、その人の状態や、健康記録と、ええと、他の、他の患者との類似性に基づいて、今後発症する可能性のある病気について予測を行うようにします。ええと、そういうわけで、ノートブックに戻りましょう。はい。これについての架空のユースケースについて少し話しました。

そういうわけで、ええと、このノートブックは実際には実データでのデモを行うものではなく、時系列データをできるだけ早くベクトル化し始めることを目的としています。そのため、私が最初に行うステップは、依存関係をインポートすることだけです。少し待ってください、ここで画面を見失いました。ええと、ここでは Pan を NumPy NumPy として使っています。ええと、つまり、データ操作や数値演算のためです。タイムスタンプを扱い、実際にタイムスタンプを Unix に変換できるように date time をインポートしています。そうすることで、ええと、基本的にタイムスタンプを正規化して、それらを vis に書き込めるようにするためです。というのも、Melva はタイムスタンプ形式をサポートしていないからです。float と integer をサポートしています。

なので、それを使う必要があります。そしてここでは、扱っているデータを理解するために、一部のデータをプロットするだけの目的で map plot lib を使います。そして最後になりますが、viss を使っています。これは viss データベースとやり取りするための Viss クライアントライブラリです。ではまずそれをインポートして、それからここでいくつかの交通データを生成する関数を定義します。先ほど言ったように、これは単に、ランダムな制限速度、車両数、ええと、平均速度データを生成しているだけで、それらのランダム値を含むデータフレームを作成できるようにしています。

そして、ええと、自分でこれを実行している場合には、自分が扱っているデータに似た作業対象を用意できるので、自分でそれを簡単にベクトル化する方法を学べます。具体的には、ここに生成したこれらのタイムスタンプがあります。現在のものです。車両数があり、それが、変動していることがわかりますし、車両速度も同様です。そしてここではすでに、ええと、異常タイプが見えています。というのも、ここでの考え方は、すでにいくつかの分類を行っていて、それを mils に入れているということだからです。ええと、そしてこれは、novis に書き込むかもしれないデータがどのようなものかを示しています。そうすることで、車両数、平均速度、そして場合によっては、ええ、つまり動画データのようなものだけを含む新しいデータが入ってきたときに、それを使って、ええと、類似性検索を実行し、それから、つまり、事故があるのか、あるいは別のタイプの異常があるのかを判断できます。ここにある異常のタイプは3つだと思います。事故、工事、そしてもう1つ、思い出せないものです。

ええと、次に行うのは、データを探索して、それがどのようなものかを確認することです。ええと、ここでは、青い線が車両数を表し、赤い線が異なるタイムスタンプでの平均速度を表しています。そしてこれは、pandas のデータフレームを influx cb に書き込み、クエリする方法でもあります。先ほど、influx cb からデータをクエリする方法について触れましたが、このユースケースではそれを行うと想定しています。クエリして、それからここに直接データ、データフレームを持つことになります。ええと、その代わりに。

ええと、そのやり方は、ええと、ここで pandas を使ってクエリすることになります。しかし書き込む方法は、バケット名を含めて、ええと、record としてデータフレームを直接渡すだけです。データフレームの measurement 名を含めることができます。それは基本的に、テーブルに何という名前を付けたいかを指定するのと同じことです。ええと、私はそれを単に generated data と呼びました。

また、持っている任意のデータフレームのタグ通信を含めることもできます。タグとは、時系列データに関するメタデータを持たせる場所のことです。ただし、これは完全に任意です。これはユーザーが自分のデータを整理するためのものに近いです。そしてデータベース側では関係ないので、本当に気にする必要はありません。それから、タイムスタンプが実際にどの列にあるかを指定できます。ええと、私たちの場合は timestamp 列にあります。あるいは、もしデータフレームでタイムスタンプがインデックスにある場合は、それがデフォルトなので、指定せずにそのまま書くことができます。

そしてそれをクエリするには、SQL からクエリし、たとえば過去 90 日間または 9 時間など、何であれ、そのすべてのデータを選択する、というように書きます。そして query メソッドを使い、そのクエリを渡して、モード pandas を返すと、理想的には anomaly detection 列を除いた、このようなデータが返ってくるはずです。さて、ここまで来たので、実際にいくつかのセンサーのベクトル埋め込みを作成する準備ができました。つまりここから、実際にデータを時間ウィンドウにグループ化し始めます。その目的は、ベクトル埋め込みのために準備することです。

ええと、これから行うのは、ウィンドウ、つまりスライディングウィンドウアプローチを使うことで、24 ステップのウィンドウサイズ、ええと、ウィンドウサイズ 24、ステップサイズ 10 を使います。つまり、各ウィンドウには 24 個のデータポイントが含まれ、次のウィンドウは 10 ポイント後から始まるということです。そして embeddings underscore data frame と呼ばれる新しいデータフレームを出力します。そこには各ウィンドウの開始時刻と終了時刻、対応する平均速度ベクトル、そしてその異常タイプが含まれます。なので、ええと、ここではそれらのウィンドウを定義しているだけです。

そしてここでは、ウィンドウを反復処理し、それぞれについて列の値を抽出しています。そしてここでは、その収集したデータのために新しいデータフレームを作成しています。ええと、それによって、このような埋め込みデータフレームを作成できるようにしています。つまりここでは基本的に、開始時刻と終了時刻を持つ時系列データのスライディングウィンドウとして、ベクトルを持っていることになります。そして今度は、センサー値を正規化する作業があります。センサー値を正規化する目的は、平均速度を取り、一貫した比較分析のために 0 から 1 の間の値にすることです。

つまり基本的に、ベクトル内のすべての値が同一である場合、ええと、正規化結果はすべてゼロのベクトルになります。そうでなければ、各値はベクトル内の最小値と最大値に基づいてスケーリングされます。要するに、正規化されたベクトルとは基本的に、元の値、つまり平均速度を取り、それをベクトル内、ええと、リスト内の最小値から差し引き、それを最大値から最小値を引いた値で割るものです。これにより、リスト内の最小値が 0 になり、最大値が 1 になります。また、ゼロ除算が必要になる場合に備えて、いくつかのエッジケース処理も行います。ええと、でもこれには何の意味があるのでしょうか？基本的に、Viss のようなベクトルや viss のようなベクトルデータベースを扱う場合、正規化は非常に重要です。なぜなら、異なる時間ウィンドウには異なるスケールや異なる平均速度があるかもしれないため、時間ウィンドウを効果的に比較できるようにするためです。

ええと、ここで本当にやろうとしているのは、ある特定の値が普通ではないかどうかを判断することだけではありません。なぜなら、都市のさまざまな場所における交通の様子を、異なる時刻、タイムゾーン、速度制限などをまたいで比較している可能性があるからです。ええと、ですから本当にやりたいのは、時系列データを正規化して、速度や時系列値の絶対値ではなく、実際の形状に注目できるようにすることです。つまり、ベクトルの実際の形状がどのようなものかを比較できるようにするのです。なぜなら本質的に、時系列を取り、その一部を見て、それを多次元空間に入れるとき、その時系列のための多次元形状を作成しているからです。

ええと、正規化しない場合、範囲が大きく異なるベクトルを比較すると、必ずしも意味のある結果は得られません。ですから、これによって検索精度も向上することを期待しています。特に、ユークリッド距離のような距離尺度や検索尺度に依存しているからです。ベクトルが正規化されていない場合、あるベクトル内の非常に大きな値が検索結果に不釣り合いに影響してしまいます。したがって、正規化は、各ベクトルが類似度の計算と演算に均等に寄与することを保証するのにも役立ちます。ええと、そして先ほど述べたように、これは意図的な変動性にも対応しますが、現実世界のあらゆる変動性にも対応します。

ええと、たとえば、交通のある時間帯では、流れが安定していれば変動性が非常に低い場合がありますが、一方で、停止と発進を繰り返す交通の場合は変動性が非常に高くなる場合があります。ですから、ベクトルを正規化することは、こうした違いのバランスを取るのにも役立ちます。そのため、基本的にこの関数を作成して、そこでその計算を行い、ベクトルに対してそれを実行しています。そして今、時系列データがゼロから1のスケールになっていることがわかります。そして最後に、データをタイムスタンプに変換し、タイムスタンプをUnixに変換する必要もあります。

それらをUNIXに変換する必要がある理由は、VISではタイムスタンプを書き込むことができないからです。特に、そうしたクエリで検索を実行するのに役立つ形式が必要です。つまり、基本的にはタイムスタンプをUnixにキャストし、それを整数にキャストしています。これでUnix精度の時刻が得られました。そして今度は、埋め込みデータフレームをエンティティに変換して、実際にそれをZillowに書き込む準備をする必要があります。ええと、基本的にはそのために、データフレーム内のすべての行と列を反復処理しています。

つまり、これがベクトルの実際の見た目で、vector fieldがあり、そこに正規化された時系列データがすべて入っています。また、開始時刻と終了時刻、そして異常タイプもあります。これで、エンティティをZillsに保存する準備ができました。ここではベクトルフィールドを指定しており、それは平均速度値の正規化ベクトルです。開始時刻フィールドと終了時刻フィールドは、各ウィンドウの停止時刻と終了時刻です。

そしてanomaly typeフィールドは異常のタイプになります。ここでは、それらとその型を定義することで、コレクションのスキーマを定義します。次にスキーマコレクションを作成し、コレクションを定義して名前を付け、コレクションがすでに存在するかどうかを確認し、競合がないことを確認します。リポジトリをクローンして初めてdocker containerを起動しただけなら、競合はないはずです。さらに、検索を実行するためのindex parametersも指定します。

そして具体的にはL2を使用します。これはユークリッド距離のquery vectorです。とはいえ、Vissには埋め込み用のほかの種類もたくさんあります。内積もありますし、コサイン類似度もあるので、選択肢があります。ただ、通常ほとんどの人が最初に使うのはユークリッドだと思います。これで、データの挿入が成功したことがわかります。また、example collectionという名前を付けたコレクションを一覧表示して、実際に作成されていることを確認することもできます。

それでは、実際に類似検索を作成または実行する準備ができました。ここでは、ユークリッド距離を使用して、クエリベクトルに最も類似したmil内のベクトルを検索します。つまり、line vectors under to search equals data under to search one vector field。この行は、この検索のクエリベクトルとして使用したいベクトルを指定します。具体的には、先ほど生成されたdata to insertリストから2番目のベクトルを選択して、検索を実行しています。

そして、これは単に以前の averagespeed の平均を表しています。したがって、すでにコレクションに書き込んだものと同じベクトルをクエリとして使用したため、文字どおり同じ値を見ているということがわかります。ですから非常に納得できます。距離がゼロであるため、実際に類似度検索が期待どおりに機能していることを確認できます。ええと、そして同様に、その直後に来たベクトルや時系列データについては、より高い距離がいくつかあります。

そして、それらの ID のいくつかも一覧表示して返しているので、検索したいくつかのベクトルの比較をグラフ化できます。返ってきた上位 3 つの結果ですが、ええと、検索ベクトルが同じであることがわかります。最初のベクトルと重なっています。なぜなら同じベクトルだからです。ですから当然、ええと、同じベクトルが返ってきます。検索が正しく実行され、最も類似度が近いものが同じものだったからです。そして、類似しているとして返された他の、ええと、時系列データもいくつか見えます。

そして、時系列のトレンドがある種似ている領域が確かにあることがわかります。もちろん、例えば検索ベクトルとベクトル 2 の間の類似性の一部を定量化するために平均絶対誤差を計算できます。ええと、実行すると、ええと、実際にはかなり高い平均絶対誤差が得られます。これは、返されている 2 番目に類似した結果についてです。そして、え、なんで、なぜそんなに高いの、と思うかもしれません。でも思い出していただきたいのですが、私たちは完全にランダムなデータを生成していました。ですから、これも実は確認になっています。というのも、ランダムデータに対して類似度検索を行っている場合、同様に類似したデータが返ってくることは統計的に非常に起こりにくいはずだからです。

つまり、本来そうなるべきではなく、ランダムであるはずなので、類似したデータが返ることは想定されていません。したがって、これは二重の意味で確認になっています。1 つ目の値、つまりクエリしているものと同じ最初のベクトルは、距離ゼロを返しています。そしてランダムな他のものは、平均絶対誤差を返しています。ええと、それはかなり高いです。これは、それらがランダムデータであるため類似していないことを示しています。

このような本当にシンプルな、ええと、チュートリアルでは、時系列データをベクトルに変換し、自分で試して感覚をつかむ方法を説明しました。代わりに、実際にはご自身の時系列データを含めてから、いくつかの類似度検索を実行し、データ全体のトレンドに実際にどのような類似性があるかを確認することをお勧めします。ええと、そして時系列データの形状のいくつかを実際に効果的に収集し、ええと、ほぼ分類することができるようになります。そして最後に、重要な手順として、もしそのコレクションを今後使い続けないのであれば、持っているすべてのコレクションを削除し、ええと、データベースから切断するのがよいです。はい、つまりこれが、その方法についてのデモの本質です。

そして簡単にご紹介しますが、これはちょっとした参考情報として、InfluxDB でできる他の楽しいプロジェクトです。これによって、時系列に取り組む気持ちが少し促されたり、インスピレーションを得られたりするかもしれません。ええと、これは Saving the Holidays と呼ばれていて、基本的には HI MQ を MQTT データと quicks とともに使用し、工場フロアの機械データを見て予知保全を行う例です。そして、このプロジェクトの面白いところは、hugging face も活用しており、実際のユースケース向けにこのプロジェクトとこのアーキテクチャを、ええと、スケールできることです。これはすべてローカルで実行できますが、同じアーキテクチャを簡単に、ええと、ご自身のプロジェクトに利用できます。ええと、そして、複雑な、ええと、異常を nns で分類する手順も含まれています。ええと、これは分類のためにベクトルデータベースでも使用されています。

つまり、ある種クールな重なり合いなんです。重なり合い。ええ、このプロジェクトについてはすでに話したので、そこは詳しくは触れません。ええ、それに実際、時間が少なくなってきているので、皆さんが質問できる時間を取りたいと思います。ですので、ここで終える前に、いくつかのリソースについてだけお話しします。

まず最初に、influx data for cloud にサインアップすることをお勧めしたいです。無料のクラウドトライアルがありますし、ここで UI がどのようなものかをお見せしました。Python や他のさまざまな方法で、どんなデータでもとても簡単に書き込み始めることができます。ええ、それからブログもあります。これは、学び方としてウェビナーではなくブログを好む方にとって、とても優れたリソースです。GitHub org org influx community にあるほぼすべてのプロジェクトについてブログがあります。ですので、いつでもそこを見て、私たちのブログで対応するブログ記事を見つけることができます。

私たちのドキュメントは素晴らしいです。また、Influx University やコミュニティ Slack、INFORMS もあり、皆さんが持つかもしれない質問をするための素晴らしいリソースです。時系列と Influx db に関するあらゆることについてです。ということで、ここで場をお譲りして、質問はありますか？まずはありがとうございました。ああ、実際とても興味深かったです。

クールなデモもありがとうございました。今のところ質問が2つあります。ええ、1つ目は一般的なものですが、通常、埋め込みモデルを使って埋め込みを生成し、それをベクトルデータベースに保存して、類似検索や時系列データに使います。そのプロセスはどのようにカバーされていますか？少し時間をかけて説明していただけますか？ええ、私は個人的には、それを生成するために埋め込みモデルを使ったことはありません。これは、埋め込みモデルの代わりに使えるもののようなものだと思います。

ええ、うん。埋め込みモデルは、多くの場合、はるかに複雑な非構造化データに使われると思います。ええ、動画やテキストのようなものがあり、そのような複雑な抽出を実行する必要があるものですね。でも、ええ、これは私が時系列に特化して見つけたものです。うん。

では、ええ、時系列については、実際には埋め込みモデルを直接必要としないと言えるわけですね？はい、私は、つまり使ったことがないので確かではありません。はい。はい。なるほど、いいですね。もう1つ質問があったのですが削除されました。

ええ、でも私にも1つあります。まず、私の友人はとても喜ぶと思います。彼は geo AI とベクトル検索を使ってタンパク質を作っていて、研究室を持っているようなんです。そして influx を使えば、たとえばラボで問題があるときに検出できるように見えます。ええ、なので彼にそのことを伝えてみるかもしれません。あ、質問が戻ってきました。列についてですが、もし、ええ、数値のエントリがある場合は問題ないはずですが、エントリがテキストの場合はどうなりますか？はい、その場合は、ええ、そのテキストに特化して埋め込みモデルを使い、それらを組み合わせる必要があると思います。

わかりました。それでは私のほうから1つ質問します。flux 内で検出や予測だけを行う場合、データ処理には他にどのようなツールを使えますか？ああ、もちろんです。ええ、実際に戻って、それらのいくつかについてお話しできます。ええ、ではちょっと待ってください。

スライドに少しコメントするために、1秒だけください。ああ、いや、スライドを失いました。はい、私も失いました。ありがとうございます。私たちはさまざまなタスクをたくさん推奨しています。

最初の、あるいはツールとして、ええ、InfluxDB に特化したものの1つは、ええ、quicks です。これは Kafka の上にすべて構築されたストリーミングプラットフォームで、データ処理用です。そして、ええ、Python と UI ですべて抽象化されています。なので、実際に Kafka の設定を心配する必要はありません。ええ、ただし非常にスケーラブルです。クラウド版があり、ええ、そして、ええ、コミュニティエディションもリリースしています。

ええと、そしてそれが、この、ええと、プロジェクト全体の基になっているものです。ええと、MQTTブローカーからデータを取得するためにMQTT用のソースプラグインを使うためにQuicksを使い、同時に、ええと、利用します。Quicksにはhugging face用のプラグインもあるので、使いたい任意の機械学習モデルを適用できます。ええと、majもあります。彼らは自分たちをAirflowのオープンソース代替だと考えていて、これも非常に使いやすいオープンソースのETLツールです。ええと、そして同じ組織内には、たとえばHalf Space Treesを使ってInflux CBとMajで異常検知を行う方法の例がいくつかあります。

なので、それも自分で試してみることができます。ええと、AWS Fargateのようなものもあります。ええと、まあ、やりたいどんな種類のタスクスケジューリングにもそれを使うことができます。ええと、私が想像するには、それはむしろマイクロバッチングやダウンサンプリング、あるいは代わりにマイクロバッチ予測を作成するような用途向けでしょう。ええと、しかし繰り返しになりますが、自分でそれを試すことができます。そしてBite Waxも別の代替案です。

これはデータ処理パイプラインに使われる、もう一つのオープンソースツールです。ええと、実はそのリンクは含めていなかったのですが、ブログを見て、ええと、そして、まあ、bite WaxとInflux ccbを検索するか、ここを見れば、ええと、Influx CCBとBite Waxを使ってデータ処理を行うためのプロジェクトも見つけることができます。ええと、それからKafkaとFaustを一緒に使うこともおすすめできます。Faustも、ええと、オープンソースで、コミュニティによってメンテナンスされています。ええと、でもそれを使えば、まあ、やりたいどんな種類のストリーム処理でもでき、含めたいどんな種類の異常検知や予測でも含めることができます。そして、ええと、一般的に、今テック界で、機械学習とAIで明らかに起きている楽しいことの一つに、ええと、LLMがあります。

そしてそれは、言語モデルを時系列専用に使う人々を除外するものではありません。その場合、単語の代わりに時系列をトークン化します。ええと、そしてこれを行うさまざまなモデルがたくさんあります。ええと、Googleにも一つあります。ええと、Kronosがあります。ええと、今は5つくらい別のものがあって、その名前を全部は思い出せません。ええと、tiny Fixer LLMもその一つです。ええと、Auto Labにも一つあります。

しかし基本的に、それらは調べてみると本当に面白いものです。なぜなら、それらはゼロショット予測を提供するからです。つまり、自分のデータをまったく学習させる必要がなく、hugging faceからその重みを単純に借りて、自分の時系列データに適用し、それから予測を得るだけでよいということです。ええと、つまり、予測に関する知識や専門性がまったくなくてもよい、という感じです。それらを使ううえで唯一難しい部分は、実際に使うことです。なぜなら、非常に特定の環境を必要とし、デプロイ方法や、ええと、使い方に関するドキュメントがあまり多くないからです。そんなところです。いいですね。

ありがとうございます。そしてもう一つ質問があります。ええと、とても興味深いものです。ええと、これは暗号資産の予測に役立つでしょうか？どう思いますか？何の？何の？暗号資産？ええと、暗号資産 Crypto。Bitcoinとか何かの予測です。ああ、ええと、つまり私は、あるいは金融予測全般という意味なら、そうですね、ええ、つまりそれが、ええと、時系列LLMの背景にある考え方だと思います。ええと、それらを見ると、また、それらは、もし多変量解析を行っているなら、本当にうまく機能します。

つまり、株価トレンドやNLP、そしてさまざまな時系列データをまとめて見ている場合、そこでそれらは本当に力を発揮します。短期の単変量時系列予測をしようとしている場合は、そこでは統計的手法にまだ優位性があります。しかし、今ではこれらのモデルの一部を使って、ええと、ただ予測することができるという事実は、つまり、どんな種類の時系列データでも非常に正確に予測できるモデルがあるというのは本当にすごいことです。うん。十分に良いウィンドウを与えて、データが何らかの季節性を示していれば。うん。

ええと、それは、あらゆる種類のドメインや、あらゆる異なるタイプの時系列で機能します。なので、本当に有望に見えます。そして、時系列の分野では、機械学習手法が統計的手法を一貫して上回る段階に間違いなく到達しています。ええと、ただし、そうしたものを維持できるチームや能力があるかどうか、そしてそれが自分たちにとって価値があるかどうか、さらにそのメンテナンス全体やドメイン専門知識のコストベネフィット分析と、使いやすく多くのリソースを必要としない統計的手法を使うこととの比較、というような話は、まったく別の問題ですが、mm-Hmm。

そうですね、この2年間で興味深いことが起きています。はい、いいですね。ありがとうございます。それでは締めくくりに最後の質問ですが、ええと、時系列データからの分析結果と Vector search からの結果をどのように組み合わせたのでしょうか？それは両側の一致結果の timestamp に基づいているのでしょうか？おそらくこれはデモのことを指しているのだと思います。それは、時系列の実際の形状に基づいていました。

はい。つまり、データを正規化したときに、その時系列に基づいて多次元の形状を基本的に作成しました。そして、新しい検索、または新しい時系列のうちどれが、Euclidean distance に基づいてその以前の形状に最も似ているかを判断しました。はい。ただし、index に timestamp を含めたので、たとえば「ああ、この anomaly はこの時刻に発生している」と言えるようにしました。

これは、エンドユーザーにとって役立つかもしれない追加情報のようなものです。いいですね。ありがとうございます。ええと、もう質問はないようです。Anai、発表を改めてありがとうございました。

本当に素晴らしかったです。あと、KU もデモに参加していました。ええと、参加してくださった他の皆さんもありがとうございました。録画は数日中に共有します。YouTube にも載ります。ええと、それから私たちのSNSもフォローできます。いずれにせよ、皆さんありがとうございました。

皆さんがどこにいらっしゃっても、素敵な朝、午後、夜をお過ごしください。ByeBye。ありがとうございました。

Meet the Speaker

Join the session for live Q&A with the speaker

Anais Dotis-Georgiou
Lead Developer Advocate at InfluxDB
Anais Dotis-Georgiou is a Developer Advocate for InfluxData with a passion for making data beautiful with the use of Data Analytics, AI, and Machine Learning. She takes the data that she collects, does a mix of research, exploration, and engineering to translate the data into something of function, value, and beauty. When she is not behind a screen, you can find her outside drawing, stretching, boarding, or chasing after a soccer ball.