ビッグデータの時代において、膨大な量のデータを分析し、価値の高い情報を掘り出して、迅速なビジネス発展を導き、推進することが、データ構築の基本的な能力であり、価値です。

データ駆動型ビジネスでは、包括的、正確、タイムリーで使いやすいデータ ウェアハウスを構築するとともに、アドホック クエリ、データ分析、データ レポート機能を統合した統合データ視覚化プラットフォームを構築して、企業が効率的、便利、正確にデータを取得し、ビジネスの成長を促進できるようにする必要があります。

業界では、データウェアハウスの構築に一般的に階層化モデルを採用しています。ODSからDWD、DWS、ADSへと構築し、ビジネスニーズに合わせてADSレイヤーをカスタマイズします。このモデルでは、複雑で絶えず変化するビジネスシナリオに対応するためにデータ開発チームの参加が必要となり、データ取得時間は開発スケジュールに依存し、カスタマイズされた結果は柔軟性に欠け、頻繁な反復作業が必要となり、ADSレイヤーがデータ開発時間の大部分を占めます。ビジネスが急速に成長し、データ需要が劇的に増加すると、必要な人的コストが上昇し、配信効率が低下します。そのため、R＆Dによるカスタマイズ開発から、生産・運用におけるセルフサービス型データ取得へと移行するための、新しいデータ開発・配信モデルを模索する必要があります。

データ アプリケーションのユーザー ベースが研究開発から生産および運用に移行していることを考えると、データ使用の障壁をさらに下げる必要があり、データ ウェアハウスとデータ視覚化プラットフォームのユーザー エクスペリエンスに対する要求がさらに高くなります。

データウェアハウスのユーザーエクスペリエンスは、直接的なインタラクションを可能にする幅広のテーブルレイヤーに反映されています。理想的な幅広のテーブルは、以下の基準を満たす必要があります。

データ プラットフォームでは、ユーザーのさまざまな SQL 機能、分析習慣、分析方法を考慮し、データの視覚化やデータ コンピューティングのパフォーマンスなどの分野でユーザー エクスペリエンスの要件を満たす必要があります。

上記の考え方に基づき、階層型モデリングの代替としてワイドテーブルモデリングを検討し、TDAプラットフォームを導入しました。データウェアハウスモデルとデータ可視化プラットフォームを組み合わせることで、必要なデータをセルフサービスで取得するための運用・運用サポートが可能になります。

コンテンツエコシステムのBエンドビジネスシナリオは複雑で、トラフィックログ、ビジネスデータ、クラスターデータから派生した300を超えるODSレイヤーテーブルが存在します。データのタイムリーさと使いやすさのバランスを取るために、500を超えるDWD、DWS、ADSテーブルが構築されましたが、その結果、複雑なテーブル系統、冗長な中間テーブル、一貫性のないデータ定義、SQLの複雑さといった問題が発生しました。
上記の課題に対処するため、ワイドテーブルモデリングソリューションを提案します。製品機能と業務シナリオに基づいてテーマを細分化し、各テーマとすべての業務プロセスの細分性を明確に定義し、ODSテーブルに基づいてワイドテーブルレイヤーを直接構築します。ワイドテーブルは、業務に必要なすべてのフィールドをカバーし、アドホック分析やレポートクエリなど、あらゆるデータアプリケーションシナリオをサポートします。

△ データウェアハウスモデリングの進化

ワイドテーブルには複数の上流データソースがあり、データ量も膨大です。そのため、複数の上流データソースの準備時間が異なると、ワイドテーブルの出力時間がボトルネックになる可能性があります。さらに、あらゆるビジネスニーズを可能な限りカバーするために、大量の処理ロジックとリレーショナル計算がカプセル化されているため、コードが複雑になり、メンテナンスとバックトラッキングのコストが非常に高くなります。これらの問題を解決するために、ワイドテーブルモデリングのためのマルチバージョンソリューションが検討され、実装されました。データの適時性の違いに基づいて、ワイドテーブルは複数の計算タスクに分割されます。各タスクはワイドテーブルのフィールドの一部を出力し、設定に従ってデータをマージすることで、最終的に完全なワイドテーブルが生成されます。

上流のデータソースの影響により、異なる日付に出力される同一バージョンの適時性は制御不能です。ワイドテーブル全体の適時性を向上させるには、各バージョンのデータは生成後できるだけ早くワイドテーブルにマージする必要があります。マージ後、下流のプロセスで当該バージョンのフィールドが生成されたことを検出するための依存関係チェックメカニズムを提供する必要があります。

2.1.1 複数のバージョンのマージ

異なるバージョンのデータが生成後できるだけ早くワイドテーブルにマージされ、同じパーティションで2つのマージタスクが同時に実行されることによるデータ破損を回避するために、分散ロックサービスが導入されています。マージの決定は、ロック取得が成功したかどうかに基づいて行われます。全体的なフローチャートは以下のとおりです。

△複数バージョンのマージプロセス

ロックのディメンションはテーブル名と日付パーティションです。ロックが正常に取得されたかどうかは、ロックの状態、タスクの状態、および有効期限に基づいて判断されます。

マルチバージョンマージ方式では、ワイドテーブルマージタスクの汎用性を向上させるため、共通のマージロジックを抽出します。設定ファイルに基づいて、各バージョンのデータから生成されたファイルをワイドテーブルにマージします。設定ファイルは、ファイルアドレス、関連付け条件、関連付けタイプ、およびフィールド情報の複数のセットをカバーしています。各ファイルアドレスは独立したタスクによって生成され、そのデータソースに関連するロジックの実装を担当します。データ品質の変更は、対応するタスクを変更するだけで済むため、メンテナンスコストが低く抑えられます。

2.1.2 下流依存関係

複数バージョンにわたるテーブル内のフィールドは、タイムリーさの差異に基づいてバージョン生成されます。そのため、下流のアプリケーションが準備済みのフィールドをタイムリーに使用し、タイムリーさが求められるデータアプリケーションシナリオのニーズを満たすためには、依存関係チェックメカニズムが必要です。このソリューションは、3つの異なる依存関係チェック手法を提供します。

△ フィールドプローブサービス

• コスト面：従来の階層型データウェアハウスは、レイヤー間の深刻な冗長性に悩まされていました。ワイドテーブルモデリングを採用することで、多数のDWDおよびDWSレイヤーテーブルの作成を回避できます。各トピックには1つまたは2つのワイドテーブルのみが含まれるため、データウェアハウス内のテーブル数は60%、ストレージ容量は30%削減されます。さらに、テーブルの簡素化はデータ処理タスクの削減にもつながります。データクエリも、複数のDWDおよびDWSテーブルを単一のワイドテーブルに結合することで最適化され、大量のシャッフル操作を回避します。アドホッククエリの所要時間は数分から数秒に短縮され、コンピューティングリソースを20%節約できます。

• 品質面：ワイドテーブルは数千に及ぶ豊富なフィールドセットを備え、可能な限り多くのビジネスシナリオをカバーします。そのため、アプリケーション層のデータはワイドテーブル層に完全に収束し、階層型データウェアハウスにおけるテーブルの冗長性や不完全なロジックの沈み込みによる不整合を解消します。ワイドテーブル層に基づく指標管理のための製品側との通信はよりスムーズになり、データの精度も向上します。

• 効率性の観点から：ワイドテーブルモデルは非常に使いやすく、複雑な要件も単一のワイドテーブルで満たすことができます。基本的なSQLスキルがあればすべてのデータを取得できるため、非常に優れたユーザーエクスペリエンスを実現します。

一般的なデータ要件は、アドホックデータ抽出、レポート作成、データ分析の3つのカテゴリーに分類されます。アドホックデータ抽出では、幅広いビジネス範囲と容易なデータ取得を可能にするワイドテーブルモデルを採用することで、制作チームと運用チームはシンプルなSQL構文でデータを取得できます。レポート作成では、データ開発においてADSレイヤーアプリケーションテーブルを構築し、OLAPストレージと同期させた後、Sugarなどのレポートプラットフォームを用いて設定を行う必要があります。データ分析では、制作チームと運用チームはワイドテーブルに基づいて分析データを取得できますが、柔軟で多様な分析結果を保存し、視覚化結果を提供する必要があるため、ユーザーエクスペリエンスが低下します。

ワイドテーブルモデルは、データクエリの複雑さを大幅に簡素化し、セルフサービス型のデータ取得のための基本的な機能を提供します。しかしながら、レポート作成やデータ分析に必要なデータ可視化機能は、生産・運用におけるセルフサービス型データ取得の障害となっていました。この問題を解決するために、TDAデータ可視化プラットフォームが導入されました。このプラットフォームは、データ分析とドラッグアンドドロップによるダッシュボード構築をサポートし、豊富なデータ処理・分析機能を備え、データアプリケーションのニーズにワンストップで対応できるソリューションを提供します。

△セルフサービス方式

このモデルでは、データ開発はテーマ別テーブルの構築、同期、クエリパフォーマンスの最適化を担当し、データ製品チームのメンバーはデータセットの構成を担当し、運用チームのメンバーはデータセットに基づいて視覚化分析とダッシュボード構成を実行してセルフサービス型データアプリケーションを実現します。

ワイド テーブルの構築: ワイド テーブル モデリングのコンセプトに従って、テーマ別のワイド テーブルを構築します。

データ同期：データはHDFSからClickHouseに同期されます。データウェアハウス全体のテーブルの各バージョンが生成されるたびに同期タスクが開始され、データ同期フェーズ中に個別のクエリシナリオのキーがシャッフルされます。

パフォーマンス最適化：クエリ時間を最適化するために、キャッシュと自動ロールアップという2つのメカニズムが導入されました。キャッシュには、ユーザーの最初のクエリのクエリ結果をキャッシュするシナリオと、ユーザーのクエリ履歴に基づいてオフラインタスクを通じてユーザークエリをシミュレートし、その結果でキャッシュを更新するシナリオの2つが含まれます。自動ロールアップは、ユーザーの過去のクエリレコードの特性に基づいて、高頻度ディメンションをターゲットとした投影集計を実行します。現在、数千万のデータポイントを含むクエリシナリオでは、クエリ時間は数秒単位です。

△キャッシュ+自動ロールアップ機構

データウェアハウスのワイドテーブルモデルとデータ可視化プラットフォームを組み合わせることで、データ需要は研究開発におけるカスタム開発から、生産・運用におけるセルフサービス型の取得へと変革しました。データ分析の柔軟性と効率性が大幅に向上し、人件費も削減されました。

1. R&Dサービスの需要は57%減少し、データアプリケーション需要の割合は60%から10%に減少しました。

△必要数量