アウトライン

ラインデータ処理機能ログサービスで！現在、プライベートベータで、裁判を歓迎しました。

条件

リージョン：北京、上海、イギリス
現在プライベートベータ、ベータ版のアプリケーション、言及して、又は爪のグループ追加することにより、作業指示を要求することができる11775223を適用するには唐浙江甲斐@ @

この問題を解決します

データ処理業界の痛みのポイント

ドッキングされたときに業界分析上のデータの80％は、構造化データ、データアクセス、分析、配信、各種のデータ処理ニーズや痛みのポイントに費やさ

データ形式の様々なソースを混合、それは様々なフォーマットロガーで混合などのスイッチ、サーバ、コンテナ、および他のプログラムモジュールロギング、ルートファイルによって収集されたデータ、STDOUT、シスログ、ネットワーク、などの単純な抽出に困難であり、ログとしてメッセージフィールドは、各ケースを抽出するタイミングを一致させる必要があります。
1つのシーン、ダイナミックかつ不確実な分野、例えばngnix、のQueryString、HttpCookie、HttpBody情報フィールドには、定期的な自動抽出KV以上を必要とします。
動的データは、データソースJSON形式（例えばCVEデータ、O365監査ログ、等）を含む、動的に計算され、さらに処理ログの複数に分割抽出差し込みフィールド、。
いくつかの従来のログは、機密情報（例えば、暗号鍵、携帯電話番号、内部データベース接続文字列など）が含まれ、除外または抽出中に脱感作することは困難です。
単純なテーブルを使用して、CSV、OSSファイル、RDS、およびデータ強化のための他の外部API。
大量のデータ（例えば、ネットワーク接続データの5分の複数の数に応じて、機械にまとめ）凝集体を実行する必要が

データ処理サービスでの痛みのポイントを記録します

オンライン・データ処理の前に、我々は、ユーザーのログサービスは、すべての段階で、次の痛みのポイントを持っていることがわかりました。

1.データアクセス

シングルソースは、分布を抽出することは困難であり、様々なフォーマットが含まれています。
- スイッチは、サーバは、容器は、モジュールロギング、さまざまなログ形式の混合物である経路、標準出力、システムログ、ネットワーク等を介して収集し、部分的に、例えば、いくつかの基本的なlogtailフィールド、例えばを抽出するため、抽出することができますインポート時に時間などのレベル、IPを、ログが、ログの主なメッセージがあるため、様々なログのミックスの貴重な情報の多くは、抽出することができません
- 所望のターゲットに障害が発生したために、アクセスは、特定のフォーマットを達成することは困難です
特定のコンテンツフォーマットの複雑、困難を抽出します：
- QueryString、またはHttpCookieでngnix例えば文字列、偶数HttpBody情報、フィールドの内容は、フォーマット情報も高い複雑さ、困難の場合に抽出された使い捨て正規表現抽出を使用するための大きな変化。
- 特定の複雑なJSONの再帰の深さ
いくつかの従来のログは、機密情報（例えば、暗号鍵、携帯電話番号、内部データベース接続文字列など）が含まれ、除外または抽出中に脱感作することは困難です。
いくつかのJSONは、複数のログへの分割を処理するために必要なログの数などの情報をログに記録しますが、操作することはできません
このようSDKを使用して、ルールをアップロードするなど他の方法は、Logstashチャネル変換後に他の方法を導入することで解決しようとすると、物事が複雑になり、パフォーマンスデータの収集が遅くなってきました

2.分析

アクセスデータは、ユーザデータは、一般的にSQL、痛み、以下のポイントを使用して処理されます。

SQL複雑で長い、書き込みするのは難しい、壊れやすいとメンテナンスで実装従来のデータ処理：
- 従来の単純なフィールドくし、通常の抽出、濃縮、書くことがとても難しいです
- ソースログわずかな変化の実行エラーが表示されます。
- 難しいロングSQLを修正し、理解し、維持するために、
データや複雑なSQLの大ボリュームは、それが残業しやすいパフォーマンスの低下：
- インデックス計算フィールドのSQL Advantageを失った後
- 時間のかかるGROUPBY後の長い範囲の多数にわたるメトリックデータ
フィールドの長さの計算は2キロバイト以上をサポートしていません。
- 単一フィールドインデックスの2キロバイト、過剰がサポートされていませんが、長いフィールドの有病率は内SQL
その他の高度な機能のサポートは、要件を処理する高度なルールを達成することができません。
- 等の混合形式、ダイナミックフィールド、種々のSQLで達成することができません
- スプリットログは、達成することができない（例えばユーザーエージェント/ SQLパターンとして）固有のロジックを計算します
- カスタム計算は集約をサポートしていません。

3.アーカイブ

OSS、MaxComputeに投稿し、そのコンテンツのフィルタリングやフォーマットの変換をサポートしていません。

4.ドッキング外部システム

など、（例えばDataWorks、FunctionComputeなど）、他のシステムであってもよいが、ログのインポートを構造化してから戻ってサービスにログインするが、全体のプロセスに多くの労力を費やすことを相対的なプログラミング、コンフィグレーション、試運転などの仕事を解決するためにされます。

主支持シーン

シナリオ1 - データの定期的（一から一）

シナリオ2 - データの派遣（多くの）

シナリオ3 - （多くの）のマルチソースコレクション

シナリオ4 - 一般的なシーンデータ処理

提供150いくつかの組み込み関数を機能をカスタマイズするための柔軟性を提供しながら、あなたは、さまざまなシナリオを満たすために（UDF）機能のメイン処理タスクを完了するために、コードを記述する必要はありません。

濾過（フィルタ）：特定のログを除去
スプリット（スプリット）：ログには、より多くなり、
コンバージョン（変換）：フィールド、コンテンツ変換
エンリッチ（エンリッチ）：准外部リソース、豊富なフィールド情報
重合（ロールアップ）（オンラインであると）、特定の寸法の凝集を行うために、ログの量を減らすために
カスタムアクション（オンラインであることを）：なSQLの構文解析モード、操作カスタムAGG、上記のようにカスタムアクション、

優位

迅速かつ容易にアクセス：などlogtailなど様々なチャンネルを通じて、単に短期的なストレージに非インデックス、logstoreにアクセスするための最も簡単な方法を使用します。
より速く、より柔軟な分析クエリ：機械による単純な構文規則に箱から出して、複雑なプロセスを完了するために、かつ迅速に分析をすることができます処理されたデータに基づいてインデックスになり、SQLのこれ以上の長い分析し、非効率的で調整するのが難しいです。
より多くのビジネスシナリオかもしれ：データ処理、カスタム処理により濃縮、我々はさらに、データの値をタップし、より高度なビジネスを構築することができます
より柔軟な送達および生態学尻：より容易の生態学的ニーズに沿ったルールを設定することができ
ワンストップデータ処理プログラム、操作及びメンテナンスフリー、自動拡張を開催

その他の一般的な質問

費用

機械処理サービスおよびネットワークリソースは、現在無料そのものを消費しますが、読み取りおよび書き込みソースlogstore目標logstoreは、通常、標準ロギングサービスに合わせて充電します。
状況によると、あなたはインデックスソースlogstoreを閉じて、短い保持時間を設定することができます。

参照

ようこそスキャンコードは、直接タイムリーとアリクラウドエンジニアにリアルタイムの更新をサポートする公式のネイルグループ（11775223）に参加するには：

オンライン・データ処理：サービスの新機能をログに記録します！（クローズドベータ版）