データセンターとビジネスセンターの関係（データセンターの実用化入門：デュアルセンター戦略）

データミドルプラットフォーム実践入門: デュアルミドルプラットフォーム戦略

ミドルプラットフォームのアイデアは、アリババが2015年半ばにフィンランドのゲーム会社スーパーセルを訪問した際に提案された。

この会社の名前は知らないかもしれませんが、「クラッシュ・オブ・クラン」など、同社が開発したゲームをプレイしたことがあるかもしれません。同社の年間利益は15億ドルだが、従業員数は200人未満と非常に少なく、ゲームを開発する各小規模チームには6～7人しかいない。

こんなに小さなチームがどうやってこんなに大きなビジネスを成し遂げたのでしょうか?

その理由の 1 つは、ゲーム開発プロセスで使用されるいくつかの共通のゲーム素材とアルゴリズムを整理し、それらをすべての小規模チームにツールとして提供したことです。同じツールセットを使用して、複数の小規模なチームによるゲーム開発をサポートできます。この管理方法は「ミドルプラットフォーム」モデルです。

ミドルプラットフォームは、ビジネスミドルプラットフォームとデータミドルプラットフォームに分かれています。ビジネスミドルプラットフォームは、企業全体の業務全般を担い、あらゆる業務をデジタル化します。データミドルプラットフォームは、ビジネスで生成されたデータに基づいてビジネスにフィードバックし、すべてのデータをビジネスに変えます。

ビジネスミドルプラットフォームは、簡単に言えば、エンタープライズレベルの機能再利用プラットフォームです。たとえば、Taobao には toB と toC の両方の電子商取引製品が多数あります。実際、彼らが使用しているアカウントシステム、トランザクションシステム、マーケティングシステムなどはすべて汎用的な大規模モジュールです。各チームが新しいシステムを開発すると、リソースの重大な無駄遣いになります。そのため、これらの共通システムの開発と各製品ラインの強化を担当する専任チームが存在します。これにより、リソースの再利用が最大化されるだけでなく、各製品ラインのデータを統合することも可能になります。

同様に、各製品ラインにデータ分析および開発の人員を配置すると、リソースの無駄になります。

データミドルプラットフォームは、「収集」「保存」「接続」「利用」という4つの側面の作業を行う必要があります。収集とは、各事業ラインから業務データ、ログデータ、ユーザー行動データなどの有用なデータを収集することです。

ストレージとは、一般的には 3 層モデリング アプローチを使用して、収集されたデータが企業のデータ資産を形成できるように、より科学的な方法でデータを保存することを意味します。接続とは、eコマース ユーザーの閲覧やクリックの行動と支払いビジネス データなど、ユーザーの行動データとビジネス データを接続することです。その目的は、ビジネス担当者と経営陣が接続されたデータを使用して意思決定を行えるようにし、そのデータをビジネスにフィードバックできるようにすることです。

実際のところ、必要な接続はありません。企業にビジネスミドルプラットフォームがあれば、データミドルプラットフォームの作業ははるかに簡単になります。ビジネスミドルプラットフォームでは業務データを一元管理しているため、各製品ラインとの通信が不要となり、通信コストが大幅に削減されます。ビジネスミドルプラットフォームを持たない企業でもデータミドルプラットフォームを構築できますが、追加の手順でさまざまなビジネスラインからデータを収集する必要があります。そのため、ビジネスミドルプラットフォームがあれば、データミドルプラットフォームの構築がより効率的になります。

社内には複数の製品ラインがあり、製品ライン間で再利用可能な機能が多数あります。ミドルプラットフォームは比較的重いモデルであり、人件費も比較的高いため、スタートアップはミドルプラットフォームの構築には適していません。スタートアップ企業は初期段階でビジネスにもっと重点を置くべきです。

最下層はデータストレージ層であり、企業の業務量の大きさに応じて適切なデータベースストレージが選択されます。上位層は、n 個のセンターを含み拡張可能なビジネス ミドル プラットフォームの中核です。エンタープライズ レベルの機能再利用プラットフォームがここに反映されています。ビジネスミドルプラットフォームでは、共通するものを一つずつ開発・展開し、さまざまな製品ラインに提供して利用していただきます。

以下は、ユーザー、製品、取引、支払い、マーケティング センターについての簡単な紹介です。

1) ユーザーセンター

インターネット製品にはすべてユーザーの概念があり、ユーザー モジュールには、登録、ログイン、アカウント管理、基本的なユーザー情報の管理など、再利用できる共通モジュールが多数あります。

ビジネス関連の情報はビジネスミドルプラットフォームに保存されず、さまざまなアプリケーションに分散されます。考えてみれば、昔はすべての製品ラインでログインや登録などの機能を開発する必要がありましたが、これは実際にはリソースの大きな無駄でした。今では、各製品ラインを中間プラットフォームに接続することで同様の機能を実現できるようになり、効率が大幅に向上しました。

2) 製品センター

当社の 3 つの製品ラインを例に挙げてみましょう。

Huanmao Expressは、商品の生産リンクであるパターン作成サービスをデザイナーに提供するプラットフォームです。商品の設計から生産まですべての情報を記録します。 Yiding はターミナル店舗に供給する B2B 取引プラットフォームです。商品のリスト、販売、アフターセールス情報を記録する必要があります。富雲通は商品の物流情報を記録する物流プラットフォームです。商品の生産、販売、輸送まですべてのプロセスを一元管理しており、将来的にはデータミドルプラットフォームをベースとしたデータ分析に非常に役立ちます。

3) トレーディングセンター

支払いが必要な製品には注文が必要です。これには、ユーザーが注文を送信するプロセスである注文生成が含まれます。

注文ステータス管理: 製品ラインごとにステータスが異なります。たとえば、電子商取引製品のユーザーが注文を送信すると、ステータスは未払いになります。お支払いが完了すると、支払済みに変更されます。サプライヤーが商品を出荷すると、ステータスは出荷済みになります。ユーザーが受け取った商品に問題がないことを確認すると、最終的にステータスが完了に変わります。

Huanmao Expressでは、最初に設計者が要件を提出し、その後n社のメーカーが見積もりを作成します。この時点でステータスは「代金受領済み」となります。デザイナーがパターンを作成するサプライヤーを選択すると、生産が開始されます。生産が完了すると、パターンがデザイナーに送られ、すべてのプロセスが完了します。

4) 支払いセンター

支払いセンターは、ほとんどすべてのインターネット センターに必要なモジュールです。利益を上げるためには、オンライン支払いリンクが必要だからです。 Alipay、WeChat、UnionPay などのさまざまな支払いチャネルやその他の支払い方法の接続を処理する必要があります。また、ユーザーが各注文に対していくら支払うべきか、アプリがいくら請求すべきか、サプライヤーがいくらを分配すべきかなど、支払い後の調整にも対処する必要があります。当社では、アカウントのバランスが取れていることを確認するために、毎日チェックされる一連の調整ロジックを用意しています。

5) マーケティングセンター

たとえば、クーポン活動を行う場合、クーポンの発行方法、クーポンの受け取り方、クーポンの使用方法はすべて共通です。

h5 イベントを開催する場合、誰を選べばよいでしょうか?どのような方法で？プッシュ、SMS、公式アカウント、電話などはすべて一般的なモジュールです。マーケティングセンターとデータミドルプラットフォームは密接に連携しています。アクティビティの対象となるユーザーを選択する方法は、データ ミドル プラットフォームによってルールに基づいて計算されます。アクティビティが完了すると、データ ミドル プラットフォームは、アクティビティによって生成されたデータに基づいて、自動アクティビティ効果分析を実行します。

各事業ラインは特定のビジネス データを生成します。例えば、電子商取引の商品では、ユーザーのカートに追加したデータ、お気に入りデータ、注文データなどが、ユーザー数の増加に応じて増加します。このデータのほとんどはビジネス ミドル プラットフォームに保存されます。

ユーザーの閲覧やクリックの動作も記録され、それらはそれに応じて埋め込まれ、通常はログ ファイルの形式で保存されます。ビジネス データベースのデータであっても、ログ ファイルのデータであっても、統合ストレージのためにデータ センターに抽出する必要があります。一般的に、データ エンジニアは、比較的成熟したデータ同期ツールを使用して、ビジネス データベースのデータをデータ センターにリアルタイムで同期し、オフライン ログ データを T-1 形式で抽出し、それらを統合します。

データが抽出された後、通常は元の形式で保存されます。膨大な量のデータを扱う場合、従来の保存方法は実行可能ではありません。

業界では一般的に、運用データ層 (Operational Data Store、ODS)、詳細データ層 (Data Warehouse Detail、DWD)、概要データ層 (Data Warehouse Summary、DWS)、アプリケーション データ層 (Application Data Store、ADS) などの階層型ストレージ方式を採用しており、データをより効率的かつ科学的に整理できます。

さらに、データ指標の正確性を確保するためには、指標の定義、ビジネス能力、技術能力、指標の計算を定義する一連の厳格な仕様が必要です。データミドルエンド製品の開発では、この仕様セットを参照して作業を行う必要があります。これにより、データの精度がより高い程度に保証されます。

データが統合され計算されたので、それを製品やアプリケーションにどのように活用できるでしょうか?

通常、外部サービスはインターフェースの形で提供されます。開発者は、データ製品やさまざまな製品ラインを提供するために、必要に応じて計算されたデータを 1 つずつインターフェイスにカプセル化します。単純なデータクエリ、ユーザーポートレートなどの複雑なデータクエリ、リアルタイムデータクエリの場合、対応するサービスをインターフェースを通じて提供できます。

データ製品は、社内向け、ユーザー向け、販売者向けのいくつかのカテゴリに分かれています。

社内では通常、会社の運営スタッフとリーダーが担当します。運用スタッフは、たとえば、eコマース製品のアクティブユーザー数は減少し続けており、その理由を突き止めるためにどのようにデータを提供できるかなど、詳細なデータにさらに注意を払っています。指導部は全体像のデータにもっと関心を持っている。

例えば、会社の過去1年間の各製品ラインの稼働状況など、一部の大画面製品の製造に適しています。また、ユーザー向けにいくつかのイノベーションを行うこともできます。典型的な例は、商品の推奨です。これにより、人が商品を探すのではなく、商品が人を見つけるようになり、ユーザー エクスペリエンスが向上します。マーチャント向けには、売上データ、店舗データレポートなどに基づく人気トレンドや市況などのデータサービスやeコマース製品を提供できます。

データセンター実習（IV）：製品分析（製品設計）

データセンター実践（パート3）：ユーザー分析（製品設計）

データセンター実践（第2部）：Alibaba OneDataに基づくデータ指標管理システム

データプラットフォームの実践（I）：B2B電子商取引を例に、プロダクトマネージャーの管轄下にあるデータポイントについて説明します。

著者: Wilton (Dong Chaohua)、以前は iFLYTEK に勤務し、現在は R&F Global Commodity Trading Port のビッグデータ プロダクト マネージャーを務めています。 WeChat パブリックアカウント: 世界を変えるプロダクトマネージャー。シンプル、簡潔、そして有用、独創性を重視し、心に響く良い記事を書きましょう。

この記事はもともと @华仔 によって Everyone is a Product Manager に掲載されました。許可なく複製することは禁止します。

タイトル画像は、CC0 プロトコルに基づいて Unsplash から取得したものです。