Aiti Tribe ライブクラスの第 6 話: Lean Data Analysis - 自社に BAT と同じ分析機能を持たせる方法

どの企業も大規模で包括的なビッグデータ プラットフォームの構築を望んでいますが、実践により、持続可能なビッグデータ プラットフォームはリーン データ分析理論を通じて徐々に確立されることが証明されています。リーンデータ分析の理論は、最小限のビジネスクローズドループを確立し、データ分析プラットフォームを徐々に検証および拡張し、最終的に BAT と同じデータ分析機能を実現することです。その中で、コアテクノロジーとビジネス分析の目標は、成長を続けるにつれてさまざまな課題に直面することになります。本日、iResearch CTO Guo Wei 氏は、エンタープライズ ビッグデータ プラットフォーム構築におけるリーン コンストラクションの考え方と、月間アクティブ ユーザー数 5 億 2,000 万人のビッグデータ分析プラットフォーム構築の成長プロセスについて語りました。

主な共有内容は以下のとおりです

1. リーンデータ分析 2. 一般的なリーンデータ分析のシナリオ 3. ビッグデータ技術フレームワークの反復と拡張 4. ビッグデータプラットフォームへのユーザーリーン分析

みなさんこんにちは。iResearch の CTO である Guo Wei です。今日はここで皆さんと共有できることをとても嬉しく思います。誰もがそこから何かを得られることを願っています。本日の私の講演のタイトルは、「Lean Data Analysis - 自社に BAT と同じ分析機能を持たせる方法」です。

​​

簡単に自己紹介をさせてください。

​​

Guo Wei 氏は 2016 年に CTO として Analysys に入社しました。彼はAnalysys技術チームを結成し、Analysysビッグデータ収集、プラットフォーム、データマイニングなどの技術アーキテクチャとシステムを完成させました。彼はAnalysysハイブリッドクラウドを構築し、Analysys SDKをアップグレードし、Analysys Miaosuanリアルタイムコンピューティングプラットフォームをゼロからリリースしました。現在、Analysys ビッグデータ プラットフォームは、1 日あたり 30T のデータ、252 億件のレコードを処理し、月間アクティブ ユーザー数は 5 億 2,000 万人に達しています。
郭偉氏は北京大学を卒業しました。 Analysys に入社する前は、Lenovo Research Institute のビッグデータ ディレクター、Wanda E-commerce Data Department のゼネラルマネージャーを務めていました。また、CICC、IBM、Teradata でビッグデータ分野の重要な役職を歴任しました。彼は、ビデオ、スマート WIFI、その他のビッグデータのソフトおよびハードデータ統合テクノロジーを含む、ビッグデータの最先端の研究について独自の洞察力を持っています。

​​

1. リーンデータ分析<br> まず、リーンデータ分析のアイデアの起源であるリーンスタートアップについてお話ししましょう。リーン スタートアップは、シリコンバレーの起業家エリック ライズ氏が 2012 年 8 月に著書「The Lean Startup」で初めて提唱しました。
3 つの重要なポイント: 最小限の実行可能な製品 (MVP)、顧客からのフィードバック、迅速な反復。

リーンデータ分析とは何ですか?
リーン分析の核心は、最小のビジネスのクローズドループから始めて、毎回ビジネス効果のクローズドループを形成し、ビジネス目標を達成し、その後、ビッグデータ分析コンテンツの次のステップを拡張したり、関連システムを構築したり、関連プラットフォームを構築したりすることです。
• 意思決定者が「ビッグデータプロジェクトを構築したい」と言うのではなく、厳しい目標を設定するのではなく、最小限の実行可能な製品を最適化します。
• エンドユーザーとビジネスとの足並みを揃えるのではなく、「まずプラットフォーム、次にビジネス」
• ビジネスループを閉じてビッグデータのデータ分析を形成する（「経営陣はダッシュボードを見る」）
• スピードの向上/変革/革新 - 最大の課題は企業文化の変化にあります。これらのうち、前者を優先する必要があります。データ業界での10年以上の経験から、私は、ビッグデータのために盲目的にビッグデータを追求すべきではないと考えています。たとえビッグデータプラットフォームが構築されたとしても、それは長くは続かないでしょう。無駄のないビッグデータプラットフォームを戦略的に構築する必要があります。

重要なことは3回繰り返す必要があります。ビッグデータのために、ただ漫然とビッグデータを追い求めないでください。たとえビッグデータプラットフォームが構築されたとしても、それは長くは続かないでしょう。無駄のないビッグデータ プラットフォームを戦略的に構築する必要があります。
ただ漫然とビッグデータを追い求めないでください。たとえビッグデータプラットフォームが構築されたとしても、それは長くは続かないでしょう。無駄のないビッグデータ プラットフォームを戦略的に確立する必要があります。

​​

​​

ただビッグデータのために、あてもなくビッグデータを追い求めないでください。たとえビッグデータプラットフォームが構築されたとしても、それは長くは続かないでしょう。無駄のないビッグデータ プラットフォームを戦略的に構築する必要があります。それで、どうやって構築するのでしょうか?個人的には、インターネット/モバイル インターネット ユーザー操作から始めることをお勧めします。この分野の問題点は近年より顕著になっており、ビジネスのクローズド ループも見つけやすくなっているためです。
皆さんもご存知の通り、インターネットが後半に入ってからは、何もせずにアプリを作るだけで大​​量の新規ユーザーを獲得できる時代は終わりました。今では、新規ユーザーを正確に引き付ける効果さえも良くないかもしれません。そのため、これらの既存ユーザーをどのようにさらに運用していくかが、現在では主なビジネス上の要求となっています。

​​

ご覧のとおり、中国の人口増加率はもはや年間数パーセントではなく、毎年数十分の1パーセントずつ増加しています。同様に、モバイルインターネットユーザーの成長も鈍化しています。ですから、今は新しいものをどうやって手に入れるかではなく、どうやってユーザーを維持し、収入を増やすかが重要です。

​​

顧客獲得の難しさ、ユーザー維持の難しさ、価値を引き出せないことが、今日のインターネット事業者が直面している 3 つの大きな課題です。

​​

無駄のないデータ分析によるユーザーライフサイクル管理は、顧客獲得時の正確なマーケティング、チャネル ROI の向上、成熟したユーザーの ARPU の増加、ユーザーが離脱したときにさまざまな条件を使用してユーザーを維持するなど、重要なツールです。これには、ユーザーの行動、属性、チャネル特性、ロイヤルティに関するさまざまな分析が必要です。

​​

その中でも、顧客の獲得、維持、変換は、リーンデータ運用の主な要件です。この図には、参考までに実行する必要があるデータ分析のさまざまな指標がリストされています。

​​

ビッグデータによって推進されるビジネス成長のペースをコントロールするにはどうすればよいでしょうか? 4つのステップを実行することをお勧めします。まず、ユーザーとメンバーを社内で統一します（企業自身だけがさまざまなデータを最も明確に把握できるため、この部分は企業自身で整理して完了することをお勧めします）。次に、インターネット ユーザーのライフ サイクル管理プラットフォームを確立するか、外部から購入します。これは、結果を確認する最も早い方法であり、リーン アプローチと一致しています。 3番目に、インターネットと社内システムを接続するためのエンタープライズビッグデータプラットフォームを構築します。 4 番目に、独自のデジタル資産を使用してデータ サービスを確立するか、企業の人工知能プラットフォームをさらにアップグレードします。

2. 一般的なリーンデータ分析シナリオ

以下では、一般的に使用されるリーン データ分析のシナリオをいくつか紹介します。

​​

ユーザーに向き合った無駄のないデータ分析、ユーザーライフサイクル管理の中核となる方法論が AARCE モデルです。各ステップで実行する必要がある分析は多数あります。一般的なシナリオの例を挙げてみましょう。

​​

​​

高品質なチャネルの発見、キーパスのコンバージョンの改善、失われたユーザーの回復、ユーザーの維持とアクティビティの改善は、最も一般的なリーン分析モデルの一部です。

​​

あらゆる企業の運営部門やマーケティング部門にとって、適切なチャネルを見つけてユーザーを開拓することは日々直面する課題です。各チャネルの品質、変換、保持を測定することは、典型的なリーン データ分析のシナリオです。

​​

​​

​​

チャネルを計測する際には、新規追加、維持、誤トラフィック防止の観点からデータ分析を行うことができます。自分で作ったものでも購入したものでも、ほとんどの水路には水が流れています。企業がチャネルコストを節約し、より適切なチャネルを見つけるのを支援することで、経営陣はビッグデータの役割を直接実感できるようになります。私の個人的な経験では、データ分析のビジネスのクローズドループでは、分析がお金に近ければ近いほど、企業の認知を得やすくなります。チャネル開発だけでは不十分で、ユーザーのコンバージョンを向上させることも必要です。以下に、よく使われる指標と方法をいくつか紹介します。

​​

これはすべてのプロダクトマネージャーが直面する問題です。

​​

各主要パスについて、どのユーザーが滞在し、どのユーザーが離脱するかを確認するためにコンバージョン分析が必要です。さらに重要なのは、離脱したユーザーが競合他社へ移ったのか、それとも残ったユーザーが私たちのターゲット顧客なのかを確認することです。

​​

これには、各企業が独自のユーザー ポートレート システムを確立し、失った顧客に関するユーザー行動の包括的な洞察を得ることが必要です。解約に関して言えば、どの企業も、無駄のないビッグデータ分析プラットフォームを構築するときに、解約したユーザーを呼び戻すという典型的な機能を持っています。一般的には、まず解約したユーザーを定義し、解約の理由を分析し、解約マーケティング活動を実施し、マーケティング活動の有効性を評価することが必要です。

​​

​​

​​

​​

​​

​​

​​

すべての活動において、定義したターゲット ユーザーに効果的にリーチできているかどうか、また顧客を効果的に維持できているかどうかを慎重に評価する必要があります。以前、いくつかのシナリオについて簡単に話しました。実際、そのような例はたくさんあります。各実務者は、自社のシナリオに基づいて独自のシナリオを設計する必要があります。

3. ビッグデータ技術フレームワークの反復と拡張

次に、リーンビッグデータ分析で埋めるべき技術的な落とし穴についてお話します。実際、すべてのデータ分析は、収集→受信→計算→クエリ→マイニング→サービスという流れで行われます。

​​

iResearch での私の経験についてお話ししたいと思います。現在、パブリッククラウドとプライベートクラウドが非常に人気があります。しかし、私はパブリッククラウドの拡張性とプライベートクラウドのパフォーマンス保証の両方を兼ね備えた、サプライヤーが提供するハイブリッドクラウドを選択しました。現在、iResearch SDK には月間アクティブ ユーザー数が 5 億 2,000 万人、1 日あたりのアクティブ ユーザー数が 7,800 万人います。このハイブリッド クラウド アーキテクチャは、このような大規模なデータ スケールをサポートし、iResearch の社内アナリストと外部製品の正常な運用を実現するために毎日稼働します。すでに 2 年が経過しているので、基盤となるアーキテクチャに取り組んでいる友人には、ハイブリッド クラウド モデルを試してみることを強くお勧めします。

​​

ハイブリッド クラウドの利点のいくつかを簡単に紹介します。基礎となるアーキテクチャだけでは十分ではありません。このような大量のデータの場合、受信方法は特別な最適化が必要であり、クラウド+端末制御戦略が特に重要になります。適切に実行されない場合、毎日何億ものデバイスが DDoS を形成し、サーバー クラスターがダウンすることになります。

​​

​​

​​

ここでは、データ収集とデータ受信におけるいくつかの戦略的な選択肢と、一般的なデータ収集に必要な技術的フレームワークとモジュールを参考として示します。これらのフレームワークは、月間数億人のアクティブユーザーをサポートできるため、安心してご利用いただけます。時間が迫っているので、ビッグデータの処理とクエリにおける 2 つの最大の落とし穴についてお話しします。

1 つは社内の需要です。特定のラベル特性を持つユーザーを選択して、そのユーザーの行動特性を確認する必要があります。たとえば、1995 年以降に生まれた女性のうち、動画を見るのが好きで、午後 10 時から午後 11 時の間にアプリを開くことが多い上位 5 人を調べます。データストレージの論理構造は非常にシンプルです。 1 つはユーザー タグ テーブル、ユーザー ID、タグ ID です。もう 1 つはユーザー ID、タイムスタンプ、APP 名です。シンプルなアイデアは、参加してから順序付けることです。しかし、iResearch には毎日 21 億 9,000 万件のユーザー ポートレートと 252 億件のユーザー行動があり、これは毎月数千億件の行動に相当することを誰もが知っておく必要があります。これを単純な結合で解決するにはどうすればよいでしょうか?どの企業も同じような状況に遭遇するでしょう。ぜひ参加することをお勧めします!ビッグ データ環境では、問題を解決するために結合を使用しないでください。まず ES を使用してユーザーをフィルタリングし、次にユーザー行動フィルタを垂直方向と水平方向にビットマップに変換し、AND または OR 関係を通じて最大の結果を計算します。興味のある友人は別途話し合うことができます。今日は詳しくはお話しできません。

​​

もう 1 つは、先ほど具体的な例を挙げた、順序付けられたコンバージョン ファネルの問題です。誰もが、商品の閲覧から注文、支払いまでに至るユーザーの数を知りたいと考えています。それは順番通りに行われなければなりません。先に支払いを済ませてから閲覧することはできません。ユーザーの行動は非常に大きくなるため、ビッグデータを使用してこの問題を解決するのは困難です。順序付けられた変換の組み合わせを見つけて数秒以内に返す方法は非常に難しい問題です。少し前に、OLAP コンテストも開催しました。この問題のコンペには多くの素晴らしい人々や企業が参加しました。オープンソースグループで1位になった人も10万元の賞金を獲得した。ここで、参考と研究のために簡単なアイデアを紹介します。 2018年7月からまたこのようなコンテストを開催する予定ですので、どなたでもご参加いただけます。

​​

​​

もちろん、テクノロジーには終わりがなく、私たちが徐々に繰り返していく重要なタイプのテクノロジーがもうひとつあります。

​​

4. ビッグデータプラットフォームへのユーザーリーン分析

***時間が迫っているので、Analysys 内のビッグデータ プラットフォームを簡単に紹介し、皆さんのインスピレーションになればと思います。

​​

データ ストレージに関しては、Analysys は HDFS、Spark、Hive のほか、presto と greenplum も使用します。これらのオープンソースのビッグデータストレージの比較を以下に示します。

​​

ここで強調する必要があるのは、ビッグデータ ストレージ プラットフォームに重点を置くだけでなく、リソース スケジューリング プラットフォームとデータ ガバナンス サービスも同様に重要であるということです。残り時間があまりないので、オフラインでさらに学習するか、過去の記事を検索してください。

​​

***ark.analysys.cn もぜひご覧ください。 iResearch のビッグデータ サービスを体験する際には、ビッグデータ分析は単なるプロセスであり、結果ではないことを強調することが重要です。ビジネスのクローズドループを形成するリーン分析だけが、持続可能な開発への道です。写真は私のWeChatとWeiboです。誰でもフォロー大歓迎です。

以下の質問は51CTO開発者コミュニティの友人からのもので、共有されています

Q: 東営日報-知道：郭先生、現在多くの部署でビッグデータが必要ですが、その概念は比較的漠然としています。技術面でも製品面でも、上司や同僚にわかりやすく説明できる良いアイデアはありますか?
A: iResearch CTO Guo Wei氏: ビッグデータは確かに使いやすいと思います。この記事の前半では、リーン思考についての参考になるものをいくつか紹介したいと思います。ビジネスのクローズドループを見つけ、ビッグデータを使用してどのようなビジネス上の問題を解決したいかを決定する必要があります。最初の 2 つのパートで説明したリーン マネジメントは参考用です。また、2 冊の本もお勧めします。1 冊は「Lean Entrepreneurship」、もう 1 冊は「Lean Data Analysis」です。今日の PPT にあるアイデアの多くも、エリックが私に与えてくれたインスピレーションから恩恵を受けました。

Q: 東営日報-知道：ありがとうございます。私たちは新聞社です。私たちのリーダーたちはビッグデータに非常に興味を持っており、計画を立てるよう私たちに依頼しましたが、私たちは無力です。実は、これは業界の要望でもあります。どの業界にも独自のデータがあり、それをマイニングしてデータ分析に活用することができます。しかし、私たち自身でそのような計画を立てることは困難です。 iResearch にはそのような計画がありますか?

A: iResearch の CTO、Guo Wei 氏: お互いを追加して、具体的なニーズについてプライベート チャットしましょう。

Q: Data-unicorn-Beijing: プライベート展開の場合、二次開発は許可されますか?

A: iResearch CTO Guo Wei氏: もちろんです。

Q: Wang Jun、北京、Hadoop: 現在、HBase+Phoenix を使用して OLTP クエリを実行しています。現在、KB レベルのテーブルと 100,000 レベルのテーブルを結合すると非常に遅くなり、30 秒かかります。これを最適化するにはどうすればよいでしょうか?私は、OLTP には hbase+phoenix を使用し、OLAP には spark 上の hive を使用します。 OLAP のデータが処理された後、クエリのために HBase に格納されます。現在の問題は、OLTP クエリが非常に遅いことです。寸法は固定ではありません。 hbase+phoenixを最適化する方法を教えて頂きたいです。現在の問題は、Phoenix 経由での HBase データのクエリが遅いことです。 kw テーブルを 100,000 テーブルに結合するには 40 秒かかります。これは絶対に受け入れられません。キーは基本的に複数のフィールドの組み合わせです。分析されたデータは hbase に格納され、hbase でクエリを実行する必要があります。

A: iResearch CTO Guo Wei 氏: Hadoop を使用していますか? Greenplum を試してみることをお勧めします。

A: Data-unicorn-Beijing: アプリケーションシナリオを分析してからデータベースを選択することをお勧めします。ディメンションが固定されておらず、高速クエリが必要な場合は、MongoDB が適切な選択肢です。結合などのデータ処理であれば、Hive には明らかな利点があります。あるいは、Hive をストレージに使用し、Presto を呼び出しに使用することもできます (まだあまり成熟しておらず、データ型など多くの隠れた問題があります)。

A: Half Development-Little Star-Guangzhou: これはデータベースのせいにすることはできません。まず、インデックス、SQL 最適化などを除外する必要があります。私の記憶の限りでは、MySQL データのボトルネックは 3kw 程度で、pg はもう少し大きいです。もちろん、where 条件の記述方法によっても異なります。 or、<>、式の左側の計算などの式はインデックスを無効にします。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]