分散コンピューティングにおけるデータ品質に関する講演

[[442615]]

1. 概要

1. データ品質の問題はどこにでもある

基本的に、データを利用するすべての学生は、次のような同様の問題に遭遇しています。

• テーブルが時間通りに生産されない場合、下流に影響を及ぼし、深刻な場合にはオンライン効果にまで影響する可能性があります。
• 一部欠落部分があり、レポートを見てデータが一致していないことがわかりました。
• 統計によると、UV はPV よりも大きいため、恥ずかしいです。
• データ出力が飛躍的に増加し、当初の1,000万件のデータが3,000万件に増加しました。
• フィールド内の列挙値がコメント内の値と一致しておらず、誰もそれを説明できません。
• いくつかのディメンションが欠落しているため、それ以上のデータ分析はできません。
• いくつか分析してみたところ、結果はとんでもないものであることがわかりました。さらに分析してみると、管理に問題があることがわかりました。

• …

上記はすべてデータ品質の問題です。この論文では、データ品質の問題を可能な限り検出して解決する方法を見つけようとしています。

2 データ標準

データ品質について話すときは、データ品質を評価する側面を理解する必要があります。 DAMA UK は、データ品質の 6 つの中核的な側面を提案しています (図 1 を参照)。

注: DAMA International (Data Management Association International) は 1980 年に設立されました。技術およびビジネスの専門家で構成される国際的なデータ管理専門家協会です。いかなるメーカーからも独立した非営利団体として、データ管理の分野における概念とベストプラクティスを世界中で推進し、デジタル経済の理論的かつ実践的な基盤を築くことを目指しています。会員数は全世界で約1万人、世界48カ国に支部が設立されています。

図1 データ品質の次元

• 完全性: 完全性とは、データ テーブル内の行の欠落、フィールドの欠落、コード値の欠落など、欠落しているデータ情報があるかどうかを指します。たとえば、全体的な PV は正しいものの、特定の次元では一部のポイントのみがマークされており、整合性の問題が生じます。不完全なデータの価値は大幅に低下し、これはデータ品質の最も基本的かつ一般的な問題でもあります。一般的な統計SQL: count(not null) / count(*)
• 有効性: 有効性とは、一般的に範囲の有効性、日付の有効性、形式の有効性などを指し、主にデータ レコードの仕様とデータが論理的であるかどうかに反映されます。標準化とは、携帯電話番号は 11 桁の番号でなければならないなど、データが特定の形式を持つことを意味します。ロジックとは、PV は UV 以上でなければならないなど、複数のデータ間に固定された論理関係があることを意味します。
• 精度: 精度とは、データに記録された情報に異常やエラーが含まれているかどうかを指します。最も一般的なデータ精度エラーは文字化けです。第二に、異常に大きいデータや小さいデータも条件を満たしません。精度は、記録エラーの大きさなど、個々のレコードまたはデータ セット全体に適用されます。このタイプのエラーは、最大値と最小値の統計を使用して確認できます。
• 適時性: 適時性とは、データ処理の開始からデータを表示できるまでの時間間隔を指します。適時性はデータ分析自体に大きな影響を与えませんが、データの確立に時間がかかりすぎると、データ分析をタイムリーに実行できず、分析から得られた結論の参照意義が失われる可能性があります。たとえば、リアルタイムのビジネス市場データ、主要なビジネス指標の状態のタイムリーな反映、ビジネス指標の異常な変動の検出、特別な緊急事態への柔軟な対応などには、データのタイムリーな更新と出力が必要です。場合によっては、データは単なる分析ではなく、オンライン戦略のために使用されます。データをタイムリーに生成できないと、オンラインの結果に影響します。
• 一貫性: 一貫性とは、同じ意味を持つ情報が複数のビジネスやシナリオで一貫しているかどうかを指します。一般的には、一貫性のない命名、一貫性のないデータ構造、一貫性のない制約ルールなど、複数ソース データの一貫性のないデータ モデルを指します。データ エンティティの不一致 (データ コーディングの不一致、命名と意味の不一致、分類レベルの不一致、ライフ サイクルの不一致など)。
• 一意性: データセット内でデータが繰り返されない度合い。一意のデータ項目の数と、データ項目の合計数に対する割合。たとえば、count(distinct business key) / count(*) は通常、主キーの一意性を検証するために使用されます。

3 データライフサイクル

図2 データのライフサイクル

• データ アクセス: アップストリーム テーブルまたはその他のデータ ソースからデータにアクセスします。
• データ処理: SQL を記述して、ターゲット データ テーブルを生成します。
• データ出力: スケジュールされたタスクを通じてデータ テーブルを生成します。
• データ アプリケーション: 下流のデータ分析、レポート、およびその他のアプリケーション データ。

上記のリンクのいずれかでデータ品質の問題が発生する可能性があります。データ品質を向上させるには、データアクセス、データ処理、データ出力、データ適用、効果追跡などのプロセス全体を管理する必要があります。全体的な視点が非常に重要です。一つの点にこだわりすぎないことで初めて、全体像が見えてきます。

2. データ品質の問題を解決する方法

データの品質はデータの生命線です。高品質のデータがなければ、すべてのデータ分析、データマイニング、データアプリケーションの有効性が大幅に低下し、完全に間違った結論が導き出されたり、資本損失が発生したりする可能性があります。しかし、データの生成、処理、流通、適用には、業務運営、生産システム、データ システム、データ製品など、上流と下流のリンクが数十個関与し、各リンクでデータ品質の問題が発生する可能性があるため、データ品質の問題は広範囲に及び、管理が困難です。

グループ内の多くのユニットはデータ品質の問題に対する体系的なソリューションを持っており、グループにはデータ品質の問題を解決するための多くのツールもあります。この記事では、そのようなツールの使用方法を詳しく紹介するのではなく、主にデータ開発プロセス中にデータ開発者の経験不足によって発生するデータ品質の問題に焦点を当てます。

図3 データ品質ソリューション

図3に示すように、データ品質の問題をある程度解決するには3つの方法があると思います。

• データ探索
  • 完全性、一貫性、妥当性、正確性、関連性などの問題を明らかにします。
  • データアクセスとデータ出力段階の問題を解決する
• 開発仕様
  • データの適時性、データの一貫性、データの正確性などの問題を発見する
  • データ出力段階の問題を解決する
• データ監視
  • 一貫性、正確性などの問題を回避します。
  • データ生成段階の問題を解決する

1 データ探索

データ探索の定義は一般的に次のようになります: データ探索とは、ソース データを探索してデータ構造、データ コンテンツ、データ関係を理解し​​、データ エンジニアリングの潜在的な問題を特定するプロセスです。

データ探索はデータ品質の分野でのみ使用されるのではありません。データ ウェアハウスの開発とデータ移行には、ソース データの探索が必要です。データ ウェアハウスのすべてのデータ基盤はソース データ (ODS) です。データ ウェアハウスを開発する前に、出力データ ウェアハウスの正確性を確認するためにソース データを調査する必要があります。

質問バンク業務のデータには管理が不足しており、データ構築は主に業務アーキテクチャのいくつかの中間テーブルと結果テーブルに基づいています。開発の初期段階では、データ探索の重要性が認識されていなかったため、データの精度に重大な問題が発生し、データの研究開発で大量のやり直しが発生しました。

DataWorks は、基本情報、データ分布、topN、ヒストグラムなどをカウントできるデータ探索機能を提供します。しかし、何度か試してみましたが、まだ探索段階であり、使いやすさはまだあまり良くありません。

図4 基本的なデータ探索方法

上の図は、データ探索のいくつかの基本的な機能を示しています。

このセクションでは、データ探索の一般的な方法をいくつか紹介します。これは体系的なものではなく、開発プロセス中に発生した問題に対する参考資料としてのみ提供されます。

テーブルプロファイリング

1) 総データ量の調査

データの総量を調査することは、ODS の全体的なデータについての予備的な理解を得ることです。データマップのパーティション情報から確認したり、SQL を記述して計算したりすることができます。

データの総量を調査する場合、毎日の増分データの総量とフルデータの総量（必要な場合）を調査する必要があります。

一般的に、総データ量の調査結果が期待どおりであるかどうかを確認するには、ビジネス関係者または上流のデータ プロバイダーに確認する必要があります。

2) データ生成時間とライフサイクルの調査

データ探索を行う際には、データの生成時間とライフサイクルを探索する必要があります。これは、その後のタスクのスケジュール設定やデータ補充に役立ちます。

列プロファイリング

1) データ分布の調査

データ分布探索はデータ探索の最も重要な部分であり、さまざまな次元でのデータの分布を検出できます。一般的には以下のように書かれています。

 SELECT結果
、カウント（*）
 xxx.テーブル名から
dt = 'xxxxx'の場合 
グループ 結果によって;

2) 列挙値の検出

列挙値探索は、上記のデータ分布探索の特殊なケースであり、特定のディメンションの列挙値が妥当かどうかを探索します。一般的に言えば、SQL は次のようになります。

選択  明確な結果
xxx.テーブル名から
ここで、 dt = 'xxxxx' ;

このタイプのプローブでは、上流で生成された列挙値が 0 と 1 のみであるが、プローブ中に空であることが判明するなど、多くの問題を検出できます。

3) 固有値の検出

場合によっては、上流で生成された一部のフィールドが一意である (必ずしも主キーではない) ため、そのような状況も調査する必要があります。そうしないと、結合を行うときにデータ拡張の問題が発生する可能性があります。 SQL クエリは一般的に次のようになります。

選択   COUNT (アイテムID)
 , COUNT ( DISTINCTアイテムID )
 xxx.テーブル名から
ここで、 dt = 'xxxxx' ;

4) 極値と外れ値の検出

一部の数値については、必要に応じて最大値、最小値、平均値の検索などの極値検出を行うことができます。この方法により、ソース データ内のダーティ データをできるだけ早く検出できます。

また、0、null、空の文字列などの外れ値もチェックします。

列間の調査

1) 関連分野の調査

通常、テーブル内の異なるフィールドは直接関連しています。たとえば、露出フィールドと露出期間の間には相関関係があります。露出がある場合は露出期間が存在する必要があり、露出期間が 0 より大きい場合は露出が存在する必要があります。

または、uv は pv より大きくなければなりません。この方法では、dws テーブルを検証できます。

テーブル間の探索

1) 結合条件の探索

この状況は、クロステーブル探索に属します。異なるテーブルを結合する場合は、結合条件が成功しているかどうかを確認するだけでなく、結合数が期待どおりであるかどうかも確認する必要があります。

質問バンク事業において、システムバグにより下流テーブルの結合条件のデータが約3%結合できませんでした。しかし、初期段階ではこの点に関するデータ調査が行われていなかったため、この問題を発見するまでに長い時間がかかりました。

ビジネス上の目的で 2 つのテーブルを結合する必要がある状況もあります。たとえば、消費テーブル内のすべてのユーザーはユーザー テーブルに表示される必要があり、すべてのコンテンツはコンテンツ ディメンション テーブルに表示される必要があります。

一般的なSQLは次のとおりです。

選択  カウント( DISTINCT a.itemid )
 xxx.yyy_logから
左 参加する（
アイテムIDを選択
xxx.zzzzから
ここでds = '20210916'             
 ）b
 ON a.itemid = b.itemid
ここで、 a.dt = '20210916'  
そして、 b.itemidは  NULL ;

ビジネス探索

1) フィルタリング条件が正しくありません

場合によっては、特定のフィルタリング条件を通じて大量のデータから必要なデータを抽出する必要があります。たとえば、クライアント管理仕様は一貫しており、異なる端末からのユーザーログはすべて 1 つのテーブルにまとめられています。特定のデータのみを分析したい場合は、データをフィルタリングする必要があります。

このフィルタリング条件は、通常、ビジネス側によって提供されます。データ探索フェーズでは、まず条件付きフィルタリングを実行し、フィルタリングされたデータが期待どおりであるかどうかを確認するためにビジネス側とコミュニケーションを取る必要があります。

2) ビジネスにおけるデータ重複問題

テーブルの一意性の検出に属します。この問題は、データが繰り返されるという点で、一意の値の現象に似ています。

違いは、データ プロバイダーが特定の列が一意であると主張していても、一部のビジネス シナリオではデータが一意ではない場合があることです。例えば、ある質問バンクの業務において、異なる手がかりから得られた q_id が矛盾していると業務側から言われ始めました。しかし、q_id は URL から取得され、ビジネスでは実際に重複した URL があったため、重複した q_id がありました。

しかし、別のケースでは、データの重複はビジネス上の理由ではなく、システムのバグによって発生することがよくあります。例えば、ある業務では、一度処理した書籍は再度処理されるべきではないのに、システムのバグにより書籍が複数回処理されてしまうことがあります。

最初のケースでは、モデリング時にビジネスの複雑さを考慮する必要があります。 2 番目のケースでは、有効なデータを見つけて、ダーティ データを削除する必要があります。

3) データファネルの問題

データ リンク内のデータ ファンネルは非常に重要なデータであり、予備的なデータ探索を行うときにもデータ ファンネルに注意を払う必要があります。各レイヤーで破棄されるデータの量（割合）はビジネス側で確認する必要があります。

例えば、あるインバウンドフローで処理されたデータ量と入力されたデータ量の比率、あるいはウェアハウスに入力されたデータ量と入力されたインデックス量の比率に大きな問題がある場合は、上流の業務関係者に連絡して修正する必要があります。

4) ビジネスにおける不合理なデータ配布

「ブラシユーザー」の発見は、不合理なデータ配布の一般的なタイプです。例えば、ユーザーの1日のPVが5,000を超える場合、そのユーザーはブラシユーザーであると推測されます。これらのユーザーを統計から削除し、データの上流を見つけて類似のユーザーを除外する必要があります。

一般的なSQLは次のとおりです。

ユーザーIDを選択
、カウント（*） AS cnt
 xxx.yyyy_logから
ここでdt = '20210913'  
グループ ユーザーID別
cnt > 5000 を持つ;

2 データ開発仕様

上記では、データ探索に関する多くの問題について説明しました。データ探索を慎重に行えば、多くのデータ品質の問題を回避できます。このセクションでは、データ開発フェーズ中に開発者の経験やその他の理由によって発生するデータ品質の問題について説明します。

SQL の記述に関する問題

1) デカルト積はデータの拡張を引き起こす

この問題は、結合条件に一意性チェックがない場合によく発生します。右側のデータは一意ではないため、直積が発生し、データ拡張が発生します。非常に大きなテーブルの場合、データ結果が不正確になるだけでなく、コンピューティングとストレージの無駄も発生します。

単一パーティション内のデータは一意であるが、結合時にパーティション条件が書き込まれず、複数のパーティションが同時に計算され、データが爆発的に増加するという状況もあります。

多くの学生は開発中に何度もこの問題に遭遇しているので、必ず注意してください。

2) 順序が間違った結果につながる場合に参加する

この問題もよくある問題です。 on と where の順序が誤って記述されているため、結果は期待どおりになりません。エラーケースは以下のとおりです。

選択  カウント(*)
 xxx aより
左 参加するyyy b
 ON a.id = b.item_id
ここで、 a.dt = '${bizdate}'  
 AND b.dt = '${bizdate}' ;

上記の SQL では、b.dt が where 条件内にあるため、結合に含まれないデータは除外されます。

3) 内部結合と外部結合の誤った使用

この問題はときどき発生しますが、多くの場合、開発者がビジネスを理解していないか、タイプミスがあり、期待どおりの結果にならないことが原因です。

SQL を書いた後は必ず確認し、可能であれば他の学生に SQL を確認してもらってください。

4) 時間区分は引用符で囲まれている

通常、パーティションは文字列データ型です。ただし、SQL を記述する場合は、パーティションを引用符で囲まなくても正しいデータを照会できます。その結果、一部の学生はパーティションの周囲に引用符を追加することに慣れていません。

ただし、場合によっては、引用符がないと、照会されたデータが間違ってしまうことがあります。したがって、時間の区切りを必ず引用符で囲んでください。

5) テーブル循環依存問題

開発中に、3 つのテーブルが相互に依存しているという問題が発生する場合があります。この状況は比較的まれであり、データ開発フェーズ中に見つけるのは容易ではありません。タスクが送信された後にのみ検出されます。

このような状況を回避するには、いくつかの開発仕様を明確にする必要があります。たとえば、ディメンション テーブルと詳細テーブルの両方を ods テーブルから取得する必要があり、ディメンション テーブルと詳細テーブルは相互に直接依存することはできません。一部の複雑なロジックでは、中間テーブルの形式で再利用を実現できます。

6) 列挙値問題

ETL を実行する場合、特定の列挙値を、はいの場合は 1、いいえの場合は 0 などの文字列に変換する必要があります。

一般的な書き方は、SQL で case when と書くことです。

ただし、この方法は、継続的に増加する列挙値には適していません。そうしないと、新しいコードを追加すると SQL を変更する必要があり、SQL 拡張の問題が発生する可能性があります。

この問題は、コード テーブルと結合して解決することをお勧めします。

パフォーマンスの問題

1) where順序での結合のパフォーマンスの問題

上で、結合における on と where の実行順序の問題に触れましたが、これは結合のパフォーマンスにも関係しています。 on が最初に実行され、where が後で実行されるため、結合する前にデータ量を減らすことをお勧めします。これにより、パフォーマンスも向上します。

（１）左側のテーブル（a）フィールドのデータをフィルタリングしたい場合は、where条件の直後に記述します。この場合、実行順序は次のようになります。まずテーブル a の where 条件でデータをフィルターし、次にテーブル b を結合します。

（２）右側のテーブル（b）フィールドのデータをフィルタリングしたい場合は、on条件の後に記述するか、別のサブクエリを記述してその中にネストし、結合操作を実行する前にテーブルbのデータをフィルタリングできるようにする必要があります。

テーブル b のフィルター条件を where の直後に置くと、実行順序は次のようになります。まずテーブル a のデータをフィルターし、次にそれをテーブル b のすべてのデータと関連付け、最後に Reduce ステージでテーブル b のフィルター条件に従ってデータをフィルターします。このとき、テーブル b のデータ量が多いと、効率が非常に低くなります。したがって、右側の表のデータは、マップ段階で可能な限りフィルタリングする必要があります。

通常、適切なテーブルに対してサブクエリを実行します。

2) 小さな次元のテーブルマップ結合

ハイブで

すべてのテーブルの中に小さいテーブルが 1 つだけある場合は、最大のテーブルが Mapper を通過するときに、小さいテーブルを完全にメモリに格納できます。 Hive はマップ側で接続プロセスを実行できます。これをマップ側結合と呼びます。これは、Hive がメモリ内の小さなテーブルを 1 つずつ一致させることができるため、従来の接続に必要な削減プロセスを省略できるためです。小さなデータ セットの場合でも、この最適化は通常の結合操作よりも大幅に高速になります。削減プロセスを削減するだけでなく、場合によっては Map プロセスの実行ステップも同時に削減できます。記事末尾のリンク 1 を参照してください。

MaxComputeでは

Mapjoin は、Reduce フェーズまで待たずに Map フェーズでテーブル結合を実行するため、大量のデータの転送時間を短縮し、システム リソースの使用率を向上させて、操作を最適化できます。

大きなテーブルと 1 つ以上の小さなテーブルに対して結合操作を実行すると、mapjoin は、指定したすべての小さなテーブルを結合操作を実行するプログラムのメモリにロードし、マップ フェーズでテーブル接続を完了して、結合の実行を高速化します。

文書に記載されている例は次のとおりです。

 /*+ mapjoin(a)を選択*/
 a.ショップ名、
合計価格、
 b.合計価格
sale_detail_sj aからsale_detail bに参加
a.total_price < b.total_priceまたはa.total_price + b.total_price < 500 の場合;

記事末尾のリンク2を参照してください。

3) 大規模ディメンションテーブルのハッシュクラスタリング

インターネット ビッグ データのシナリオでは、一貫性ディメンション テーブルのデータ量は比較的大きく、数億、さらには数十億のレベルに達することもあります。この量のデータを結合するには、多くの場合非常に長い時間がかかり、タスクによっては生成に丸一日かかることもあります。

この場合、実行時間を短縮するために、通常は、結合フェーズのインスタンスの数を増やしたり、結合フェーズのメモリを増やしてスピルを減らしたりすることができます。ただし、インスタンスの数は無制限に増やすことはできません。そうしないと、大規模なシャッフルによりクラスターが過負荷になります。さらに、メモリ リソースも限られているため、パラメータを調整すると、時間と引き換えにリソースを犠牲にすることになり、一時的な解決策に過ぎず、根本的な原因に対処することにはなりません。

ハッシュ クラスタリングとは、簡単に言えば、データを事前にシャッフルしてソートし、データの使用時にデータを読み取って直接計算に参加することです。このモードは、出力後に後続のノードが同じキーに従って複数回結合または集約されるシナリオに非常に適しています。

ハッシュ クラスタリングは MaxCompute に組み込まれており、明示的な指定を必要としないため、非常に便利です。

記事末尾のリンク3を参照してください。

4) データの偏りの問題

Hive/MaxCompute では、MapReduce タスクを実行するときにデータの偏りが発生することがよくあります。これは、1 つまたは複数の削減ノードが非常に低速で実行されることで現れ、タスク全体を完了するのにかかる時間が長くなります。これは、一部のキーの数が他のキーの数よりもはるかに多いためです。これらのキーが配置されている削減ノードによって処理されるデータの量は、他のノードよりもはるかに大きいため、一部のノードは操作を完了できなくなります。

一般的な状況としては、結合の不均一な分散やグループ化の不均一な分散などがあります。

具体的な解決策については、記事末尾のリンク 4 を参照してください。

3 データ監視

データタスクを送信した後、タスクを正しく、タイムリーに監視することも非常に重要です。データ監視に関しては、当グループは問題を解決するための強力な製品を多数提供しており、以下に簡単に紹介します。

データの適時性監視（モサド）

モサド監視とは、ミッションの運用エラーや時間どおりに実行されないことなど、ミッションの運用状況を監視することです。モサドはミッションベースの監視機関であるため、データのリアルタイム出力を監視するのに特に適しています。たとえば、一部のテーブルでは特定の時間に出力を生成する必要があり、出力がない場合はアラームが発行されます。現在、Mossad は Dataworks でのみ利用可能です。

データ品質管理 (DQC)

Mossad のタスクの監視とは異なり、DQC の監視はテーブルとフィールドの監視です。タスクが実行されると、監視条件がトリガーされ、アラームがトリガーされます。

データ品質センター (DQC) は、グループが立ち上げたデータ品質ソリューションです。データのライフサイクル全体にわたってフルリンクのデータ品質保証サービスを提供できます。 DQC を通じて、データ生成と処理リンクにおける業務データの異常を監視し、問題をできるだけ早く発見し、異常なデータによる下流への影響を自動的にブロックして、データの正確性を確保することができます。

DQCは以下の監視を行うことができます

• データ出力行数変動監視
• ビジネス主キーの一意性の監視
• キーフィールドのNULL値の監視
• 集計データの合理性監視

DQC プロセスは次のとおりです。

• ユーザーがルールを設定する
• スケジュールされたタスクを通じて検査タスクをトリガーする
• タスク構成に基づいてサンプルデータを取得する
• 計算に基づいてテスト結果を返す
• ディスパッチャは、テスト結果に基づいて介入をブロックするかどうか（強い依存性、弱い依存性）を決定します。

DQC は非常に強力ですが、その構成は依然として非常に複雑です。また、変動ルールを設定するには観察に長い時間がかかります。特にテーブルやフィールドの数が多い場合は設定作業が膨大になります。あるチームは、DQC 構成を自動的に監視できる Auto-DQC を研究しました。

その他のデータ品質監視プラットフォーム

注目すべき他のデータ品質監視プラットフォームとしては、

• Apache Griffin (eBay オープンソース データ品質監視プラットフォーム)
• Deequ (Amazon オープンソース データ品質監視プラットフォーム)
• DataMan (Meituan Dianping データ品質監視プラットフォーム)

3つの追記

データ品質の問題を解決する特効薬はありません。データ品質管理は単なる概念ではなく、単なるテクノロジーでも、単なるシステムでも、単なる一連の管理プロセスでもありません。データ品質管理は、方法論、テクノロジー、ビジネス、管理を統合したソリューションです。この記事では、現在直面しているデータ品質の問題と解決策を簡単にまとめており、データ品質に関心のある学生とのコミュニケーションをさらに深めたいと考えています。

この記事で紹介したテクノロジーとソリューションの一部は、UC および Quark ビジネスに実装されており、ビジネスのデータ品質が大幅に向上し、より良い成果が得られています。

リンク 1: https://developer.aliyun.com/article/67300

リンク 2: https://help.aliyun.com/document_detail/73785.html

リンク3:

https://developer.aliyun.com/article/665154

https://developer.aliyun.com/article/665246

リンク4: https://developer.aliyun.com/article/60908

【この記事は51CTOコラムニスト「アリババオフィシャルテクノロジー」によるオリジナル記事です。転載については原著者にお問い合わせください。

この著者の他の記事を読むにはここをクリックしてください