【Logservice連載】NYC-Taxi on Log Service

Hi, データエンジニアの大原です。 今回はAlibaba Cloudの国際サイトで提供している Log Service のご紹介、およびNYC-TaxiデータをLog Serviceへ収集し可視化・分析する方法を記載します。 また、SBC Engineers' Blogの性格上、集中連載記事になります。

【Logservice連載】オフラインデータを含めた、様々なデータソースをシームレスに収集するLogServiceのご紹介
【Logservice連載】LogtailでCSVデータを収集するLogService
【Logservice連載】SDKでExcelデータを収集するLogService
【Logservice連載】OSS、AWS S3からCSVデータを収集するLogService
【Logservice連載】SDKでTwitterデータを収集するLogService
【Logservice連載】Logstashでnetflowデータを収集するLogService
【Logservice連載】Google Apps Script(GAS)で株価データを収集し、LogServiceの機械学習で株価予測・異常検知・監視をする
【Logservice連載】NYC-Taxi on Logservice←本記事

f:id:sbc_ohara:20201118125247p:plain

前書き

LogServiceの可能性をこのblogにて記載しました。

Log Service は、リアルタイムデータロギングサービスです。
ログの収集、消費、出荷、検索、および分析をサポートし、大量のログを処理および分析する能力を向上させます。

少し前になりますが、Log Serviceについての資料をSlideShareへアップロードしていますので、こちらも参考になればと思います。

www2.slideshare.net

今回はこれを使ってNYC-TaxiらOpen DataをAlibaba Cloud Log Serviceへ収集、蓄積、可視化してみましょう。

f:id:sbc_ohara:20201224145210p:plain



NYC-Taxiとは

NYC TLCによってオープンデータとして利用可能になった、NYCタクシーの移動データです。 ガイドラインはこちらにてあります。 今回はこのオープンデータを使用して、Log Serviceというデータ分析プロダクトサービスで可視化までのHow to useを記載します。

f:id:sbc_ohara:20201224145301p:plain


Step 1: OSS bucketにてNYC-Taxi Open dataを格納する

NYCのウェブサイトからデータを取得するには、ECS上にてwgetコマンドを使用します。

[root@iZ6we0fgka4d29m38peeuuZ src]# wget https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2019-01.csv
--2020-12-07 15:28:14--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2019-01.csv
......
2020-12-07 15:29:35 (8.17 MB/s) - ‘yellow_tripdata_2019-01.csv’ saved [687088084/687088084]

NYC-Taxi open dataは容量が大きいので、全てのデータを利用する場合は、txtファイル内の全てのファイル名を処理してから wget -i <filenames>.txt を直接実行することをお勧めします。
この方法では、サーバーがtxtファイルに記載されているファイルをすべてダウンロードしてくれるので、一つ一つ手動で処理する必要がなくなります。

[root@iZ6we0fgka4d29m38peeuuZ src]# cat /root/targets.txt
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-01.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-02.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-03.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-04.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-05.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-06.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-07.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-08.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-09.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-10.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-11.csv
https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-12.csv
[root@iZ6we0fgka4d29m38peeuuZ src]# wget -i /root/targets.txt
--2020-12-08 09:53:53--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-01.csv
......
2020-12-08 10:00:05 (6.35 MB/s) - ‘yellow_tripdata_2011-01.csv’ saved [2474554026/2474554026]

--2020-12-08 10:00:05--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-02.csv
......
2020-12-08 10:07:01 (5.98 MB/s) - ‘yellow_tripdata_2011-02.csv’ saved [2604373779/2604373779]

--2020-12-08 10:07:01--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-03.csv
......
2020-12-08 10:15:20 (5.64 MB/s) - ‘yellow_tripdata_2011-03.csv’ saved [2948633344/2948633344]

--2020-12-08 10:15:20--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-04.csv
......
2020-12-08 10:21:23 (7.12 MB/s) - ‘yellow_tripdata_2011-04.csv’ saved [2703310900/2703310900]

--2020-12-08 10:21:23--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-05.csv
......
2020-12-08 10:26:34 (8.80 MB/s) - ‘yellow_tripdata_2011-05.csv’ saved [2860029176/2860029176]

--2020-12-08 10:26:34--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-06.csv
......
2020-12-08 10:31:54 (8.27 MB/s) - ‘yellow_tripdata_2011-06.csv’ saved [2776252237/2776252237]

--2020-12-08 10:31:54--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-07.csv
......
2020-12-08 10:37:08 (8.24 MB/s) - ‘yellow_tripdata_2011-07.csv’ saved [2708392003/2708392003]

--2020-12-08 10:37:08--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-08.csv
......
2020-12-08 10:41:52 (8.20 MB/s) - ‘yellow_tripdata_2011-08.csv’ saved [2432989761/2432989761]

--2020-12-08 10:41:52--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-09.csv
......
2020-12-08 10:47:00 (8.34 MB/s) - ‘yellow_tripdata_2011-09.csv’ saved [2682104748/2682104748]

--2020-12-08 10:47:00--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-10.csv
......
2020-12-08 10:52:31 (8.31 MB/s) - ‘yellow_tripdata_2011-10.csv’ saved [2884780798/2884780798]

--2020-12-08 10:52:31--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-11.csv
......
2020-12-08 10:57:19 (8.86 MB/s) - ‘yellow_tripdata_2011-11.csv’ saved [2668405528/2668405528]

--2020-12-08 10:57:19--  https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2011-12.csv
......
2020-12-08 11:02:14 (8.87 MB/s) - ‘yellow_tripdata_2011-12.csv’ saved [2740546498/2740546498]

FINISHED --2020-12-08 11:02:14--
Total wall clock time: 1h 8m 21s
Downloaded: 12 files, 30G in 1h 8m 14s (7.57 MB/s)
[root@iZ6we0fgka4d29m38peeuuZ src]# ls -ltr
total 31723096
-rw-r--r-- 1 root root 2776252237 Aug 15  2016 yellow_tripdata_2011-06.csv
-rw-r--r-- 1 root root 2708392003 Aug 15  2016 yellow_tripdata_2011-07.csv
-rw-r--r-- 1 root root 2432989761 Aug 15  2016 yellow_tripdata_2011-08.csv
-rw-r--r-- 1 root root 2682104748 Aug 15  2016 yellow_tripdata_2011-09.csv
-rw-r--r-- 1 root root 2884780798 Aug 15  2016 yellow_tripdata_2011-10.csv
-rw-r--r-- 1 root root 2668405528 Aug 15  2016 yellow_tripdata_2011-11.csv
-rw-r--r-- 1 root root 2740546498 Aug 15  2016 yellow_tripdata_2011-12.csv
-rw-r--r-- 1 root root 2474554026 Aug 15  2016 yellow_tripdata_2011-01.csv
-rw-r--r-- 1 root root 2604373779 Aug 15  2016 yellow_tripdata_2011-02.csv
-rw-r--r-- 1 root root 2948633344 Aug 15  2016 yellow_tripdata_2011-03.csv
-rw-r--r-- 1 root root 2703310900 Aug 15  2016 yellow_tripdata_2011-04.csv
-rw-r--r-- 1 root root 2860029176 Aug 15  2016 yellow_tripdata_2011-05.csv

Alibaba Cloudでは、OSSバケットにファイルをアップロードする方法をいくつか提供しています。 ossutilでは、バケットやオブジェクトを管理するためのシンプルなコマンドが用意されています。

[root@iZ6we0fgka4d29m38peeuuZ ~]# wget https://gosspublic.alicdn.com/ossutil/1.7.0/ossutil64
--2020-12-07 15:39:37--  https://gosspublic.alicdn.com/ossutil/1.7.0/ossutil64
Resolving gosspublic.alicdn.com (gosspublic.alicdn.com)... 47.246.4.254, 47.246.4.253
Connecting to gosspublic.alicdn.com (gosspublic.alicdn.com)|47.246.4.254|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10210086 (9.7M) [application/octet-stream]
Saving to: ‘ossutil64’

100%[===================================================================================================================================================================================================>] 10,210,086  13.4MB/s   in 0.7s

2020-12-07 15:39:38 (13.4 MB/s) - ‘ossutil64’ saved [10210086/10210086]

[root@iZ6we0fgka4d29m38peeuuZ ~]# chmod 755 ossutil64
[root@iZ6we0fgka4d29m38peeuuZ ~]# ./ossutil64 config
The command creates a configuration file and stores credentials.

Please enter the config file name,the file name can include path(default /root/.ossutilconfig, carriage return will use the default file. If you specified this option to other file, you should specify --config-file option to the file when you use other commands):
No config file entered, will use the default config file /root/.ossutilconfig

For the following settings, carriage return means skip the configuration. Please try "help config" to see the meaning of the settings
Please enter endpoint:https://oss-ap-northeast-1-internal.Alibaba Cloudcs.com
Please enter accessKeyID:<AccessKeyID for your account>
Please enter accessKeySecret:<AccessKeySecret for your account>
Please enter stsToken:<This option is required only when you use a temporary STS token to access OSS buckets. Otherwise, you can leave this parameter empty.>

ossutilをインストールし設定した後、今回の一連のファイルをアップロードするには、cp <local file path> <destination bucket and file path> コマンドを使うことができます。また、フォルダとしてOSSにアップロードするためにcpコマンドに-rオプションを追加することもできます。

[root@iZ6we0fgka4d29m38peeuuZ ~]# ./ossutil64 cp -r src/ oss://nyc-demo-data/src_csv/
Succeed: Total num: 6, size: 4,097,410,644. OK num: 6(upload 6 files).

average speed 416149000(byte/s)

9.846054(s) elapsed

対象のcsvファイルをすべてOSSのバケット nyc-demo-data に格納します。このデータはボリュームが大きいため、パーティションとして year を使用します。そのため、配下のデータファイルは年単位の名称による各フォルダで区切られています。

f:id:sbc_ohara:20201224151009p:plain

f:id:sbc_ohara:20201224151031p:plain

Alibaba Cloud Log Serviceは、OSSから直接データファイルを読み込むことができます。データ形式は、CSV, JSON, TXT, Parquetのようないくつかの種類をサポートしています。
Log Serviceのデータ格納要件として、データファイルのサイズが2GB以下である必要があるため、元のデータファイルをCSVからParquetに変換してからAlibaba Cloud Log Serviceで利用する必要があります。
(他のガイドラインでも確認できますが、今回はテスト用のParquetファイルをAlibaba Cloud AnalyticDB for MySQLクラスタで生成しています。後日その方法を紹介します。)

f:id:sbc_ohara:20201224151308p:plain

f:id:sbc_ohara:20201224151321p:plain


Step 2: Alibaba Cloud Log ServiceのLogStoreで取得する

Alibaba Cloud Log Serviceプロジェクトには複数のLogStoreがあり、各LogStoreには複数のShardがあります。
今回は、1つの特定のログプロジェクトの下で、異なるLogStoreのNYC-Taxi Open dataを扱うことになります。今度はそれらを1つずつ作成していきます。

f:id:sbc_ohara:20201224151725p:plain

Topページの「Create Project」ボタンをクリックし、以下のようにプロジェクトを作成します。

f:id:sbc_ohara:20201224151823p:plain

f:id:sbc_ohara:20201224151840p:plain

f:id:sbc_ohara:20201224151852p:plain

プロジェクトが正常に作成されると、関連するLogStoreの作成を促すメッセージが表示されます。OKボタンをクリックして、LogStoreを作成します。

f:id:sbc_ohara:20201224151956p:plain

f:id:sbc_ohara:20201224152008p:plain

LogStoreが正常に作成された後、データアクセスの設定を求められます。OKボタンをクリックし、設定処理を入力します。
Alibaba Cloud Log Serviceでは、クラウド製品、運用システム、開発言語やフレームワークなど、ログデータを取得するための様々な方法が定義されています。ここではOSSを選択し、設定ウィザードに入ります。

f:id:sbc_ohara:20201224161741p:plain

RAMの下にAlibaba CloudLogImportOSSRoleが定義されていないとUnauthorizedエラーが出ます。これは、OSSバケット内のリソースにアクセスするために使用されます。エラーメッセージにあるAuthorization URLを介してターゲットロールを作成することができます。

f:id:sbc_ohara:20201224161825p:plain

f:id:sbc_ohara:20201224161836p:plain

f:id:sbc_ohara:20201224161849p:plain

フォームにてデータファイルの情報を記入し、接続テストを行います。前述の通り、生成されたParquetファイルからデータを読み込んでいきます。

f:id:sbc_ohara:20201224161925p:plain

インポート設定をします。

f:id:sbc_ohara:20201224162436p:plain

通常、このステップで定義されたインデックスは、後述の Query と Analysis 文で使用します。このLogStoreはデータを保存するためだけに使用されるので、インデックスの設定は空のままにしておくことができます。 
f:id:sbc_ohara:20201224162627p:plain

データインポートの設定が完了した後、成功画面が表示されます。

f:id:sbc_ohara:20201224162711p:plain

新しく作成されたデータインポートルールは、データインポートメニューに表示されます。

f:id:sbc_ohara:20201224162743p:plain

設定中に 今すぐインポートYES に選択すると、対象のOSSバケットからすぐにデータを読み込んでくれます。約2.5時間(11:40:00 から 14:07:17)かけて 350,017,064行、3.5億レコード のデータがLogStoreへ格納されます。

f:id:sbc_ohara:20201224162928p:plain f:id:sbc_ohara:20201224163005p:plain


Step 3: Alibaba Cloud AnalyticDB for MySQLでのデータ作業

Data Transformation、すなわちデータ変換機能とは、Log Serviceの高可用性とスケーラビリティを実現するフルマネージド機能です。
この機能は、データの標準化、圧縮、配信、集約、再インデックス化などのシナリオで利用できます。

f:id:sbc_ohara:20201224163210p:plain

  • 複数のLogStoreにデータを配布したり、サービスログを例に挙げると、アクセスログ、エラーログ、ソースコードで生成された操作ログなどを1つのファイルに格納している場合があります。このような場合には、データ変換機能(Data Transformation)を利用することができます。このような場合には、データ変換機能(Data Transformation)を利用して、ログデータを異なるLogStoreに分離することができます。
  • 複数のLogStoreからのデータを集約し、異なる販売システムからの受注ログを取得しているが、全体の販売データを元に分析を行う必要がある場合は、オンライン/インストアと再販システムからの受注ログを一緒に「結合」することになります。その間に、ロジックに応じていくつかのカラムを同時に更新する必要があります。

ソースLogStorenyc-dataを作成した後、データ変換とデータ分析のためにデスティネーションLogStorenyc-final-dataを作成しなければならない。上記の手順に従って、別のLogStore nyc-final-data を作成しますが、作成後はデータインポートの設定処理に入らないようにしてください。

f:id:sbc_ohara:20201224163426p:plain f:id:sbc_ohara:20201224163435p:plain

データ変換機能(Data Transformation)のジョブを作成します。

f:id:sbc_ohara:20201225115225p:plain

LOGドメイン特定言語(DSL)は、Log Serviceのデータ処理機能に使用されるPython互換のスクリプト言語です。Pythonをベースに、LOG DSLは200以上の組み込み関数を提供し、データ処理を簡素化します。詳しくはこちらのhelpページが参考になります。

データ変換(Data Transformation)では、以下の2つの作業を行います。
- データインポート機能はフォルダ構造に応じたパーティションを認識しないので、各レコードのソースファイル名に基づいてyearカラムを追加しなければなりません。基本的なロジックは、__tag__:__object__ カラムが ads_parquet/year=2020 で始まっていれば、year:2020 でマークする、というものです。
- NYC-Taxi Open dataでは年が違っても同じテンプレートを使うことはないです。NYCが提供しているデータのリファレンスを見ると、1は "CMT"、2は "VTS "を意味しているが、"null "を含めた、その他の値は "Unknown "として更新する必要があります。

f:id:sbc_ohara:20201225115709p:plain

e_set("vendor_id", "Unknown", mode="fill")
e_switch(e_match("vendor_id", "1"), e_set("vendor_id", "CMT"), 
         e_match("vendor_id", "2"), e_set("vendor_id", "VTS"), 
         e_match("vendor_id", "4"), e_set("vendor_id", "Unknown"))
e_if(str_startswith(v("__tag__:__object__"),"ads_parquet/year=2020"), e_set("year", "2020"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2019"), e_set("year", "2019"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2018"), e_set("year", "2018"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2017"), e_set("year", "2017"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2016"), e_set("year", "2016"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2015"), e_set("year", "2015"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2014"), e_set("year", "2014"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2013"), e_set("year", "2013"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2012"), e_set("year", "2012"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2011"), e_set("year", "2011"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2010"), e_set("year", "2010"), 
     str_startswith(v("__tag__:__object__"),"ads_parquet/year=2009"), e_set("year", "2009"))

上記の記述を入力し、既存のログを1つピックアップし、その下にある「Import Test Data」ボタンをクリックします。特定のログデータがテストデータとして追加されます。

f:id:sbc_ohara:20201225115954p:plain

データテストセクションでは、データで実行する前にデータを修正することができました。ここでは、__tag__:__object__vendor_id を更新してロジックを検証しています。完了したら、データのプレビューボタンをクリックしてスクリプトをテストします。

f:id:sbc_ohara:20201225120038p:plain f:id:sbc_ohara:20201225120047p:plain

以下の通り、スクリプトは __tag__:__object__ の値に基づいて新しいカラム year を追加し、 vendor_id を更新します。
f:id:sbc_ohara:20201225120124p:plain

Tips: 文の中で複数の出力先を定義することができます。e_outpute_coutputの違いは以下の通りです。 - e_outputの場合は、e_outputと同じです。e_output: 指定したLogStoreにログエントリを送信した場合、そのログエントリに対して以下の変換ルールが実行されません。 - e_coutput: LogStoreにログが送られた場合、以下の変換ルールが実行される。指定されたLogStoreにログエントリが送信された場合、以下の変換ルールがまだ` 実行されます。

e_coutput(name="another1", project="nyc-demo", LogStore="nyc-another1-data")
e_output(name="another2", project="nyc-demo", LogStore="nyc-another2-data")

www.alibabacloud.com

先頭に e_coutput を追加すると、スクリプトは元のデータを定義されたLogStoreに送信し、残りのデータも実行します。
この場合、1つのオリジナルレコードは2つのレコードに変換され、1つはオリジナルと同じレコード、もう1つは定義されたロジックに基づいて更新されたレコードとなります。

f:id:sbc_ohara:20201225121112p:plain

f:id:sbc_ohara:20201225121128p:plain

f:id:sbc_ohara:20201225121140p:plain

先頭に e_output を追加すると、スクリプトは元のデータを定義されたLogStoreに送るだけで、残りの文は実行されません。

f:id:sbc_ohara:20201225121224p:plain f:id:sbc_ohara:20201225121237p:plain

スクリプトが要件にマッチしたら、変換ルールとして保存することができます。

f:id:sbc_ohara:20201225121312p:plain

もしAlibaba CloudLogETLRoleが存在しない場合、エラーメッセージが表示されます。エラーメッセージをクリックし、「認証処理」を完了する必要があります。

f:id:sbc_ohara:20201225121350p:plain

f:id:sbc_ohara:20201225121403p:plain

f:id:sbc_ohara:20201225121417p:plain

変換ルール作成ページ( Transformation Rule )に戻り、リンクの更新をクリックして、新しく作成されたETL Roleにチェックを入れます。

f:id:sbc_ohara:20201225121529p:plain

f:id:sbc_ohara:20201225121541p:plain

保存先のLogStoreとしてストレージターゲット情報を追加し、複数のものを追加することもできます。

f:id:sbc_ohara:20201225121620p:plain

変換データセットを定義するために処理範囲を追加します。

f:id:sbc_ohara:20201225121644p:plain

作成後に成功メッセージを取得します。

f:id:sbc_ohara:20201225121709p:plain

LogStoreの送信先データを確認します。

f:id:sbc_ohara:20201225121746p:plain

NYC-Taxi Open data 350,017,064行のデータを変換して転送するのに19.5時間(12月15日 10:50:08〜12月16日 06:25:00)かかりました。これは2つの基本シャード を使用して全てのデータを処理なので、分散の観点からパフォーマンスが良くないです。データ変換機能タスクの処理速度は、ソースとなるシャードの数と変換ルールのロジックと複雑さに依存します。詳しくは、データ変換の基本を参照ください。

www.alibabacloud.com

ほとんどの場合、1 秒間に 1 MB の非圧縮データを 1 MB (85 GB/日) の変換速度で変換するには、1 枚のシャードが必要です。
例えば、1日あたり1TBの速度でソースLogstoreにデータを書き込む場合、ソースLogstoreのシャード数は1024GB/85=12個必要です。しかし、これ以上の枚数を使うとコストが高くなるので、要件と予算に応じて計画を立てる必要があります。詳しくは、Performance GuideCost Optimization Guideを参照ください。

www.alibabacloud.com

www.alibabacloud.com

上記の通り、今回使ったLogStoreは2つのシャードしか持っていないので、最高の性能を発揮できる状態ではなく、関数の表示にしか使われていません。

f:id:sbc_ohara:20201225121828p:plain

f:id:sbc_ohara:20201225121838p:plain

最終的なデータをクエリや分析に使用する前に、キーカラムの検索インデックスを作成する必要があります。データビューのIndex Attributesボタンをクリックして、Modify Menuを選択すると、検索インデックスの管理画面が表示されます。
手動でインデックスを追加するか、ボタンをクリックしてインデックス自動生成機能を使用します。この機能は、既存のログデータを元にインデックスを生成します。また、生成後に更新することも可能です。

f:id:sbc_ohara:20201225122453p:plain f:id:sbc_ohara:20201225122503p:plain

検索インデックスの更新をすると、以下のような警告メッセージが表示されますが、これは「更新操作の後、新しいデータにのみ更新が反映されること」を意味します。

f:id:sbc_ohara:20201225125139p:plain

この場合、テストデータはデータ変換機能(Data Transformation)により既にLogStoreに格納されています。既存のデータに検索インデックスを作成するには、ここで Reindex 関数を利用する必要があります。
データビューのインデックス属性ボタンをクリックし、Reindex Menuを選択すると、再インデックスページが表示されます。

f:id:sbc_ohara:20201225125408p:plain

データ範囲を選択し、再インデックスタスクを作成します。

f:id:sbc_ohara:20201225125435p:plain f:id:sbc_ohara:20201225125448p:plain f:id:sbc_ohara:20201225125458p:plain

検索インデックスが作成されると、データの左に表示されます。また、特定の検索インデックスをクリックしてクイック分析を行うこともできます。例えば、yearvendor_id をクリックして、異なるベンダーと年の比率を求めることができます。

f:id:sbc_ohara:20201225125527p:plain

検索文を確認するには、Count Distinct ValuesGraph Icon をクリックします。下はグラフアイコンのSQL文です。この文では limit100,000 に設定していますが、クイック分析機能では最初の100,000件のデータから結果が得られることも記載されています。

* | select "vendor_id" , pv as PV, pv *1.0/sum(pv) over() as Percentage from( select count(1) as pv , "vendor_id" from (select "vendor_id" from log limit 100000) group by "vendor_id" order by pv desc) order by pv desc limit 10

f:id:sbc_ohara:20201225125605p:plain

正確な結果を得るためには、以下のSQL文を実行する必要があります。
組み込み関数と文法は、<Query Statement>|<Analysis Statement> の組み合わせで表現します。

Query Statement

www.alibabacloud.com

Analysis Statement

www.alibabacloud.com

ML Statement

www.alibabacloud.com

* | select sum(trip_distance) as total_distance, year, vendor_id group by year, vendor_id

これにより、私達はデータの中身を把握するために上記のSQL文を使用することができます。
- 黄色いタクシーの毎年ごとの総走行距離
- 業者ごとの利用割合

f:id:sbc_ohara:20201225130028p:plain

結果ページでは、SQL文は 132,364,745 records のフォーム total 350,017,064 records をスキャンしているだけで、検索結果は 不正確 であることがわかります。
これはシャード数にも原因があります。SQLが複数のカラムから文字列を読み込む場合、各シャードから最大1GBのデータを読み込むことができます。詳細はこちらを参照ください。

helpによると、現在の結果を得るためには 13,149 ms のコストしかかからないです。そのため、データを保存するためにより多くのシャードを使用すれば、最適化されパフォーマンスが大きく向上します。

www.alibabacloud.com

Alibaba Cloud Log Serviceでは、Visual Dashboard機能があります。この機能を利用して、円グラフやチャートを作成します。

f:id:sbc_ohara:20201225135142p:plain

f:id:sbc_ohara:20201225135153p:plain

新規Dashboardへの追加ボタンをクリックして、Visual Dashboardを作成します。

f:id:sbc_ohara:20201225135256p:plain

f:id:sbc_ohara:20201225135308p:plain

f:id:sbc_ohara:20201225135322p:plain

f:id:sbc_ohara:20201225135336p:plain

Dashboardが正常に作成されたら、メニューのDashboardをクリックして確認することができます。

f:id:sbc_ohara:20201225135426p:plain


まとめ

本ガイドラインでは、以下のように記述しています。
- OSS bucketでデータファイルを準備する方法 - Alibaba Cloud Log Service のプロジェクトとLogStoreを作成する方法 - データインポート機能でOSSバケットからLogStoreにデータをロードする方法 - データ変換機能(Data Transformation)でデータを最適化して別のLogStoreに転送する方法 - 検索インデックスの設定を更新する方法 - Reindexタスクで既存データの検索インデックスを更新する方法 - 結果を出すためのQuery文とAnalysis文の使い方 - 検索結果からグラフを生成する方法 - ビジュアルダッシュボードの作成方法 - シャードを作成してコストとパフォーマンスのバランスをとる方法

Log Service(SLS)は、Alibaba Cloudが開発したワンストップのログサービスで、アリババグループのビッグデータシナリオで広く利用されています。Log Serviceを利用することで、社内のデータ収集・処理システムに投資することなく、ログデータの収集・照会・消費を行うことができます。これにより、お客様はビジネスに集中することができ、業務効率を向上させ、ビジネスの拡大を支援することができます。

詳細については、以下の Alibaba Cloud ヘルプマニュアルを参照ください。

www.alibabacloud.com

Special Thanks to Bob, Nancy.

f:id:sbc_ohara:20201225135933j:plain