スキーマ移行のデータ定義言語Data definition languages for schema migration

この記事では、Azure Synapse Analytics にスキーマを移行する場合の、データ定義言語 (DDL) の設計上の考慮事項とパフォーマンス オプションについて説明します。This article describes design considerations and performance options for data definition languages (DDLs) when you're migrating schemas to Azure Synapse Analytics.

設計上の考慮事項Design considerations

移行の準備Preparation for migration

既存のデータを Azure Synapse Analytics に移行する準備を行う場合、演習の範囲を明確に定義することが重要です (特に初期移行プロジェクトの場合)。When you're preparing to migrate existing data to Azure Synapse Analytics, it's important to clearly define the scope of the exercise (especially for an initial migration project). 前もって時間を取り、データベース オブジェクトと関連プロセスがどのように移行されるかを理解することで、その後のプロジェクトでの労力とリスクの両方を減らすことができます。The time spent up front to understand how database objects and related processes will migrate can reduce both effort and risk later in the project.

移行するデータベース オブジェクトのインベントリを作成します。Create an inventory of database objects to be migrated. ソース プラットフォームに応じて、このインベントリには次のオブジェクトの一部またはすべてが含まれます。Depending on the source platform, this inventory will include some or all of the following objects:

  • テーブルTables
  • ViewsViews
  • IndexesIndexes
  • 関数Functions
  • ストアド プロシージャStored procedures
  • データ分散とパーティション分割Data distribution and partitioning

これらのオブジェクトの基本情報には、行数、物理サイズ、データ圧縮率、オブジェクトの依存関係などのメトリックが含まれている必要があります。The basic information for these objects should include metrics such as row counts, physical size, data compression ratios, and object dependencies. この情報は、ソース システム内のシステム カタログ テーブルに対するクエリを通じて利用できる必要があります。This information should be available via queries against system catalog tables in the source system. システム メタデータは、この情報の最適なソースです。The system metadata is the best source for this information. 外部のドキュメントは、情報が古くなっており、初期の実装以降にデータ構造に適用された変更と同期していない可能性があります。External documentation might be stale and not in sync with changes that have been applied to the data structure since the initial implementation.

また、クエリ ログから実際のオブジェクトの使用状況を分析したり、作業に役立つ Microsoft パートナーのツール (Attunity Visibility など) を使用したりすることもできます。You might also be able to analyze actual object usage from query logs or use tooling from Microsoft partners, such as Attunity Visibility, to help. 一部のテーブルは、実稼働クエリで使用されなくなったため、移行する必要がない場合があります。It's possible that some tables don't need to be migrated because they're no longer used in production queries.

Azure Synapse Analytics では、データ サイズとワークロードの情報が重要です。これは、適切な構成を定義するのに役立つためです。Data size and workload information is important for Azure Synapse Analytics because it helps to define appropriate configurations. 一例として、必要な同時実行のレベルがあります。One example is the required levels of concurrency. 予想されるデータとワークロードの増加について理解することが、推奨されるターゲット構成に影響を与える可能性があります。また、この情報を活用することをお勧めします。Understanding the expected growth of data and workloads might affect a recommended target configuration, and it's a good practice to also harness this information.

新しいターゲット プラットフォームに必要なストレージを見積もるためにデータ ボリュームを使用するときには、ソース データベースのデータ圧縮率 (圧縮している場合) を理解することが重要です。When you're using data volumes to estimate the storage required for the new target platform, it's important to understand the data compression ratio, if any, on the source database. ソース システムで使用されているストレージの量をそのまま使用すると、サイズ設定の根拠を誤る可能性があります。Simply taking the amount of storage used on the source system is likely to be a false basis for sizing. 監視およびメタデータ情報は、現在のシステムの圧縮されていない生データのサイズ、およびインデックス作成、データ レプリケーション、ログ記録、あるいは他のプロセスのオーバーヘッドを判別するのに役立ちます。Monitoring and metadata information can help you determine uncompressed raw data size and overheads for indexing, data replication, logging, or other processes in the current system.

移行する必要のあるテーブルの圧縮されていない生データ サイズは、新しいターゲット Azure Synapse Analytics 環境で必要とされるストレージを見積もる際に最初に考慮することをお勧めします。The uncompressed raw data size of the tables to be migrated is a good starting point for estimating the storage required in the new target Azure Synapse Analytics environment.

新しいターゲット プラットフォームには、圧縮率とインデックス作成のオーバーヘッドも含まれますが、これらはソース システムとは異なる可能性があります。The new target platform will also include a compression factor and indexing overhead, but these will probably be different from the source system. Azure Synapse Analytics のストレージ価格には、7 日間のスナップショット バックアップも含まれています。Azure Synapse Analytics storage pricing also includes seven days of snapshot backups. 既存の環境と比較すると、これは必要なストレージの全体的なコストに影響を与える可能性があります。When compared to the existing environment, this can have an impact on the overall cost of storage required.

データ モデルのパフォーマンス チューニングは、移行プロセスの終盤まで遅らせ、データ ウェアハウスに実際のデータ ボリュームが存在するようになってから行うことができます。You can delay performance tuning for the data model until late in the migration process and time this with when real data volumes are in the data warehouse. しかし、いくつかのパフォーマンス チューニング オプションはもっと早い段階で実装することをお勧めします。However, we recommend that you implement some performance tuning options earlier on.

たとえば、Azure Synapse Analytics では、小さいディメンション テーブルをレプリケート テーブルとして定義し、大きいファクト テーブルをクラスター化列ストア インデックスとして定義するのが理にかなっています。For example, in Azure Synapse Analytics, it makes sense to define small dimension tables as replicated tables and to define large fact tables as clustered columnstore indexes. 同様に、ソース環境で定義されたインデックスは、新しい環境でインデックスを作成することからメリットが得られる可能性のある列を判断するのに役立ちます。Similarly, indexes defined in the source environment provide a good indication of which columns might benefit from indexing in the new environment. テーブルを読み込む前に最初に定義するときにこの情報を使用すると、プロセスの後半で時間を節約できます。Using this information when you're initially defining the tables before loading will save time later in the process.

Azure Synapse Analytics で使用するデータの圧縮率やインデックス オーバーヘッドは、移行プロジェクトの進行に応じて測定することをお勧めします。It's good practice to measure the compression ratio and index overhead for your own data in Azure Synapse Analytics as the migration project progresses. この測定を基に、将来的なキャパシティ プランニングを行うことができます。This measure enables future capacity planning.

移行を容易にするために複雑さを軽減することで、移行前に既存のデータ ウェアハウスを簡素化できる場合があります。It might be possible to simplify your existing data warehouse before migration by reducing complexity to ease migration. この作業には次のようなものがあります。This effort might include:

  • 未使用のテーブルを移行前に削除またはアーカイブして、使用されていないデータを移行しないようにします。Removing or archiving unused tables before migrating to avoid migrating data that's not used. データを Azure Blob Storage にアーカイブして外部テーブルとして定義すると、そのデータを使用できる状態に維持してコストを削減できます。Archiving to Azure Blob storage and defining the data as an external table might keep the data available for a lower cost.
  • データ仮想化ソフトウェアを使用して物理データ マートを仮想データ マートに変換し、移行する必要があるものを減らします。Converting physical data marts to virtual data marts by using data virtualization software to reduce what you have to migrate. この変換によって機敏性が向上し、総保有コストも削減されます。This conversion also improves agility and reduces total cost of ownership. これは、移行時の最新化と見なすことができます。You might consider it as modernization during migration.

移行演習の目的の 1 つは、基になるデータ モデルを変更することによって、ウェアハウスも最新化することです。One objective of the migration exercise might also be to modernize the warehouse by changing the underlying data model. 一例として、Inmon スタイルのデータ モデルからデータ コンテナー アプローチへの移行があります。One example is moving from an Inmon-style data model to a data vault approach. これは準備フェーズの一部として決定し、その切り替え戦略を移行計画に組み込む必要があります。You should decide this as part of the preparation phase and incorporate a strategy for the transition into the migration plan.

このシナリオで推奨されるアプローチは、最初にデータ モデルをそのまま新しいプラットフォームに移行してから、Azure Synapse Analytics で新しいモデルに切り替えることです。The recommended approach in this scenario is to first migrate the data model as is to the new platform and then transition to the new model in Azure Synapse Analytics. プラットフォームのスケーラビリティとパフォーマンスの特性を活かし、ソース システムに影響を与えずに変換を実行します。Use the platform's scalability and performance characteristics to execute the transformation without affecting the source system.

データ モデルの移行Data model migration

ソース システムのプラットフォームとオリジンによっては、一部またはすべての部分のデータ モデルが既にスター スキーマまたはスノーフレーク スキーマ形式になっている場合があります。Depending on the platform and the origins of the source system, the data model of some or all parts may already be in a star or snowflake schema form. その場合、それはそのまま Azure Synapse Analytics に直接移行できます。If so, you can directly migrate it to Azure Synapse Analytics as is. このシナリオは、実現できる最も簡単で最もリスクの低い移行です。This scenario is the easiest and lowest-risk migration to achieve. 現状のままで行う移行は、前述のデータ コンテナーなどの、基になる新しいデータ モデルへの切り替えを含む、より複雑な移行の最初の段階でもあります。An as-is migration can also be the first stage of a more complex migration that includes a transition to a new underlying data model such as a data vault, as described earlier.

リレーショナル テーブルとビューのセットはすべて、Azure Synapse Analytics に移行できます。Any set of relational tables and views can be migrated to Azure Synapse Analytics. 大規模なデータ セットに対する分析クエリ ワークロードの場合、一般的にスターまたはスノーフレーク データ モデルを使用すると、全体的に最高のパフォーマンスが得られます。For analytical query workloads against a large data set, a star or snowflake data model generally gives the best overall performance. ソース データ モデルがまだこの形式になっていない場合は、移行プロセスを使用してモデルを再エンジニアリングする価値があることがあります。If the source data model is not already in this form, it might be worth using the migration process to reengineer the model.

移行プロジェクトにデータ モデルへの変更が含まれている場合は、新しいターゲット環境でこれらの変更を実行することをお勧めします。If the migration project includes any changes to the data model, the best practice is to perform these changes in the new target environment. つまり、最初に既存のモデルを移行してから、Azure Synapse Analytics の能力と柔軟性を活かし、データを新しいモデルに変換します。That is, migrate the existing model first, and then use the power and flexibility of Azure Synapse Analytics to transform the data to the new model. この方法で実行すると、既存のシステムへの影響を最小限に抑えつつ、Azure Synapse Analytics のパフォーマンスとスケーラビリティを利用して、変更を迅速かつコスト効率よく行うことができます。This approach minimizes the impact on the existing system and uses the performance and scalability of Azure Synapse Analytics to make any changes quickly and cost-effectively.

既存のシステムを複数のレイヤー (データの取り込みまたはステージング レイヤー、データ ウェアハウス レイヤー、レポートやデータ マート レイヤーなど) として移行することができます。You can migrate the existing system as several layers (for example, data ingest/staging layer, data warehouse layer, and reporting or data mart layer). 各レイヤーは、リレーショナル テーブルおよびビューで構成されます。Each layer consists of relational tables and views. これらをすべてそのまま Azure Synapse Analytics に移行することはできますが、Azure エコシステムの特性と機能の一部を活用する方がコスト効率と信頼性が向上する可能性があります。Although you can migrate all these to Azure Synapse Analytics as is, it might be more cost-effective and reliable to use some of the features and capabilities of the Azure ecosystem. 次に例を示します。For example:

  • データの取り込みとステージング: リレーショナル テーブルではなく、ETL (抽出、変換、読み込み) または ELT (抽出、読み込み、変換) プロセスの一部で、並列データの高速読み込みを実現する PolyBase と Azure Blob Storage を併用することができます。Data ingest and staging: You can use Azure Blob storage in conjunction with PolyBase for fast parallel data loading for part of the ETL (extract, transform, load) or ELT (extract, load, transform) process, rather than relational tables.

  • レポート レイヤーとデータ マート: Azure Synapse Analytics のパフォーマンス特性によって、レポート目的やデータ マート用に集計されたテーブルを物理的にインスタンス化する必要がなくなる可能性があります。Reporting layer and data marts: The performance characteristics of Azure Synapse Analytics might eliminate the need to physically instantiate aggregated tables for reporting purposes or data marts. これらをビューとしてコア データ ウェアハウスに実装したり、サードパーティのデータ仮想化レイヤー経由で実装したりすることも可能なことがあります。It might be possible to implement these as views onto the core data warehouse or via a third-party data virtualization layer. 基本レベルでは、履歴データのデータ移行プロセスと、場合によっては増分更新を、この図に示されているように実現できます。At the basic level, you can achieve the process for data migration of historical data and possibly also incremental updates as shown in this diagram:

    最新のデータ ウェアハウスを示す図。

これらの方法や同様の方法を使用できる場合、移行するテーブルの数が減ります。If you can use these or similar approaches, the number of tables to be migrated is reduced. 一部のプロセスは簡略化または除外される可能性があるため、移行ワークロードも減ります。Some processes might be simplified or eliminated, again reducing the migration workload. これらの方法を適用できるかどうかは、個々のユース ケースによって異なります。The applicability of these approaches depends on the individual use case. しかし、一般的な原則は、移行ワークロードを減らし、コスト効率の高いターゲット環境を構築するために、可能な限り、Azure エコシステムの特性と機能を活用することを検討することです。But the general principle is to consider using the features and facilities of the Azure ecosystem, where possible, to reduce the migration workload and build a cost-effective target environment. これは、バックアップまたは復元、ワークフローの管理や監視などの他の機能にも当てはまります。This also holds true for other functions, such as backup/restore and workflow management and monitoring.

Microsoft パートナーから提供されている製品やサービスが、データ ウェアハウスの移行や、場合によってはプロセスの一部の自動化に役立ちます。Products and services available from Microsoft partners can assist in data warehouse migration and in some cases automate parts of the process. 既存のシステムにサードパーティの ETL 製品が組み込まれている場合、ターゲット環境として Azure Synapse Analytics が既にサポートされている可能性があります。If the existing system incorporates a third-party ETL product, it might already support Azure Synapse Analytics as a target environment. 既存の ETL ワークフローは、新しいターゲットの Azure SQL Data Warehouse にリダイレクトできます。The existing ETL workflows can be redirected to the new target Azure SQL data warehouse.

データ マート:物理データ マートと仮想データ マートData marts: Physical or virtual

古いデータ ウェアハウス環境を使用する組織では、その部門やビジネス機能に適切なアド ホック セルフサービス クエリおよびレポート パフォーマンスを提供するデータ マートを作成するのが一般的です。It's a common practice for organizations with older data warehouse environments to create data marts that provide their departments or business functions with good ad hoc self-service query and report performance. データ マートは通常、元のデータの集計されたバージョンを含むデータ ウェアハウスのサブセットで構成されます。A data mart typically consists of a subset of the data warehouse that contains aggregated versions of the original data. この形式 (通常は次元データ モデル) の場合、ユーザーは簡単にデータに対してクエリを実行でき、Tableau、MicroStrategy、Microsoft Power BI などのユーザー フレンドリなツールから受け取る応答の時間が短くなります。Its form, typically a dimensional data model, supports users to easily query the data and receive fast response times from user-friendly tools like Tableau, MicroStrategy, or Microsoft Power BI.

データ マートの使用方法の 1 つは、基になるウェアハウス データ モデルが異なる (データ コンテナーなど) 場合でも、使用可能な形式でデータを公開することです。One use of data marts is to expose the data in a usable form, even if the underlying warehouse data model is something different (for example, data vault). この方法は、3 層モデルとも呼ばれます。This approach is also known as a three-tier model.

組織内の個々の事業単位に個別のデータ マートを使用して、堅牢なデータ セキュリティ体制を実装することができます。You can use separate data marts for individual business units within an organization to implement robust data security regimes. たとえば、関連する特定のデータ マートへのユーザーのアクセスを許可し、機密データを除外、難読化、または匿名化することができます。For example, you can allow user access to specific data marts relevant to them and eliminate, obfuscate, or anonymize sensitive data.

これらのデータ マートが物理テーブルとして実装されている場合は、それらを格納するための追加のストレージ リソースと、それらを定期的にビルドおよび更新するための追加の処理が必要になります。If these data marts are implemented as physical tables, they require additional storage resources to house them and additional processing to build and refresh them regularly. 物理テーブルは、マート内のデータは最後の更新操作時点での最新の状態が保たれているにすぎないため、変動の激しいデータ ダッシュボードには適していない可能性があることを示しています。Physical tables show that the data in the mart is only as current as the last refresh operation, so they may not be suitable for highly volatile data dashboards.

Azure Synapse Analytics などの比較的安価でスケーラブルな超並列処理 (MPP) アーキテクチャの出現とそれらに固有のパフォーマンス特性により、マートを物理テーブルのセットとしてインスタンス化しなくても、データ マート機能を提供できる場合があります。With the advent of relatively cheap scalable massively parallel processing (MPP) architectures such as Azure Synapse Analytics and their inherent performance characteristics, you might be able to provide data mart functionality without having to instantiate the mart as a set of physical tables. これを実現するには、これらの方法のいずれかを使用してデータ マートを効果的に仮想化します。You achieve this by effectively virtualizing the data marts through one of these methods:

  • メイン データウェア ハウスの SQL ビュー。SQL views on the main data warehouse.
  • Azure Synapse Analytics やサードパーティの仮想化製品 (Denodo など) のビューなどの機能を使用する仮想化レイヤー。A virtualization layer that uses features such as views in Azure Synapse Analytics or third-party virtualization products such as Denodo.

このアプローチにより、ストレージと集計処理が簡素化されるか、必要性がなくなります。This approach simplifies or eliminates the need for additional storage and aggregation processing. これにより、移行されるデータベース オブジェクトの全体的な数が減ります。It reduces the overall number of database objects to be migrated.

データ ウェアハウス アプローチのもう 1 つの利点は、大量のデータ ボリュームに対する結合や集計などの操作を実行するための容量です。Another benefit of the data warehouse approach is the capacity to run operations such as joins and aggregations on large data volumes. たとえば、仮想化レイヤー内に集計および結合ロジックを実装し、仮想化されたビューで外部レポートを表示すると、データ ウェアハウスにこれらのビューを作成するために必要な堅牢な処理がプッシュされます。For example, implementing the aggregation and join logic within a virtualization layer and displaying external reporting in a virtualized view push the robust processing required to create these views into the data warehouse.

物理データ マートと仮想データ マートのどちらを実装するかを選択するための主な要素を以下に示します。The primary drivers for choosing to implement physical or virtual data mart implementation are:

  • 機敏性が向上する。More agility. 仮想データ マートの方が、物理テーブルとその関連 ETL プロセスよりも変更しやすい。A virtual data mart is easier to change than physical tables and the associated ETL processes.
  • 仮想化された実装でデータ ストアとデータのコピーが少なくなるため、総保有コストを削減できる。Lower total cost of ownership because of fewer data stores and copies of data in a virtualized implementation.
  • 移行のための ETL ジョブが除外され、仮想化環境のデータ ウェアハウス アーキテクチャが簡素化される。Elimination of ETL jobs to migrate and simplified data warehouse architecture in a virtualized environment.
  • パフォーマンス。Performance. これまでのところ、物理データ マートの方が信頼性が高い。Historically, physical data marts have been more reliable. これを緩和するために、インテリジェントなキャッシュ技法が仮想化製品に実装されるようになっている。Virtualization products are now implementing intelligent caching techniques to mitigate this.

データの仮想化を使用して、移行プロジェクト中に一貫してユーザーにデータを表示することもできます。You can also use data virtualization to display data to users consistently during a migration project.

データ マッピングData mapping

Azure Synapse Analytics のキーと整合性の制約Key and integrity constraints in Azure Synapse Analytics

主キーおよび外部キーの制約は、Azure Synapse Analytics 内では現在適用されていません。Primary key and foreign key constraints are not currently enforced within Azure Synapse Analytics. しかし、NOT ENFORCED 句を使用して、PRIMARY KEY の定義を CREATE TABLE ステートメントに含めることができます。However, you can include the definition for PRIMARY KEY in the CREATE TABLE statement with the NOT ENFORCED clause. これは、サードパーティのレポート製品で、データ モデル内のキーを解釈して最も効率的なクエリを生成するために、テーブルのメタデータを使用できることを意味しています。This means that third-party reporting products can use the metadata for the table to understand the keys within the data model and therefore generate the most efficient queries.

Azure Synapse Analytics のデータ型サポートData type support in Azure Synapse Analytics

一部の古いデータベース システムには、Azure Synapse Analytics によって直接サポートされていないデータ型のサポートが含まれています。Some older database systems include support for data types that are not directly supported within Azure Synapse Analytics. これらのデータ型は、サポートされているデータ型を使用してデータをそのまま格納するか、サポートされているデータ型にデータを変換することによって処理できます。You can handle these data types by using a supported data type to store the data as is or by transforming the data to a supported data type.

サポートされているデータ型の一覧をアルファベット順で以下に示します。Here's an alphabetical list of supported data types:

  • bigint
  • binary [ (n) ]
  • bit
  • char [ (n) ]
  • date
  • datetime
  • datetime2 [ (n) ]
  • datetimeoffset [ (n) ]
  • decimal [ (precision [, scale ]) ]
  • float [ (n) ]
  • int
  • money
  • nchar [ (n) ]
  • numeric [ (precision [ , scale ]) ]
  • nvarchar [ (n | MAX) ]
  • real [ (n) ]
  • smalldatetime
  • smallint
  • smallmoney
  • time [ (n) ]
  • tinyint
  • uniqueidentifier
  • varbinary [ (n | MAX) ]
  • varchar [ (n | MAX) ]

次の表には、現在サポートされていない一般的なデータ型が一覧表示されており、それらを Azure Synapse Analytics に格納するために推奨される方法も示されています。The following table lists common data types that are not currently supported, together with the recommended approach for storing them in Azure Synapse Analytics. Teradata や Netezza などの特定の環境の詳細については、関連するドキュメントを参照してください。For specific environments such as Teradata or Netezza, see the associated documents for more detailed information.

サポートされていないデータ型Unsupported data type 回避策Workaround
geometry varbinary
geography varbinary
hierarchyid nvarchar(4000)
image varbinary
text varchar
ntext nvarchar
sql_variant 列を厳密に型指定された複数の列に分割Split column into several strongly typed columns
table 一時テーブルに変換Convert to temporary tables
timestamp datetime2CURRENT_TIMESTAMP 関数を使用するようにコードを再作成Rework code to use datetime2 and the CURRENT_TIMESTAMP function
xml varchar
ユーザー定義型User-defined type 可能な場合は、ネイティブ データ型に戻すConvert back to the native data type when possible

潜在的なデータの問題Potential data issues

ソース環境によっては、データの移行時に問題の原因となる可能性がある問題がいくつかあります。Depending on the source environment, some issues can cause problems when you're migrating data:

  • 異なるデータベース製品で NULL データが処理される方法には、微妙な違いがあります。There can be subtle differences in the way that NULL data is handled in different database products. 例として、照合順序や空の文字列の処理などがあります。Examples include collation sequence and handling of empty character strings.
  • DATETIMEINTERVALTIME ZONE データと関連する関数は、製品によって大きく異なる場合があります。DATE, TIME, INTERVAL, and TIME ZONE data and associated functions can vary widely from product to product.

これらを徹底的にテストし、ターゲット環境で目的の結果が得られるかどうかを判断してください。Test these thoroughly to determine if the desired results are achieved in the target environment. 移行の演習により、現在、既存のソース システムの一部になっているバグや正しくない結果が明らかになる場合があり、移行プロセスは異常を修正する絶好の機会です。The migration exercise can uncover bugs or incorrect results that are currently part of the existing source system, and the migration process is a good opportunity to correct anomalies.

Azure Synapse Analytics での列の定義に関するベスト プラクティスBest practices for defining columns in Azure Synapse Analytics

古いシステムには、非効率的なデータ型の列が含まれているのが一般的です。It's common for older systems to contain columns with inefficient data types. たとえば、実際のデータ値が CHAR(5) フィールドに収まる場合に、VARCHAR(20) として定義されたフィールドがある可能性があります。For example, you might find a field defined as VARCHAR(20) when the actual data values would fit into a CHAR(5) field. あるいは、すべての値が SMALLINT フィールドに収まる場合に、INTEGER フィールドが使用されている可能性があります。Or, you might find the use of INTEGER fields when all values would fit within a SMALLINT field. データ型が不十分である場合、特に大規模なファクト テーブルでは、ストレージとクエリの両方のパフォーマンスが低下する可能性があります。Insufficient data types can lead to inefficiencies in both storage and query performance, especially in large fact tables.

移行の演習時に、現在のデータ定義を確認し、合理化することをお勧めします。It's a good time to check and rationalize current data definitions during a migration exercise. これらのタスクは、SQL クエリを使用してデータ フィールド内の最大の数値や文字長を検索し、その結果をデータ型と比較することによって自動化できます。You can automate these tasks by using SQL queries to find the maximum numeric value or character length within a data field and comparing the result to the data type.

一般的には、テーブルに対して定義されている行の長さの合計を最小限に抑えることをお勧めします。In general, it's a good practice to minimize the total defined row length for a table. 最適なクエリ パフォーマンスを得るために、前述のように、列ごとに最小のデータ型を使用ですることができます。For the best query performance, you can use the smallest data type for each column, as described earlier. Azure Synapse Analytics で外部テーブルからデータを読み込む場合は、PolyBase ユーティリティを使用することをお勧めします。このユーティリティによって、定義される行の最大長として 1 メガバイト (MB) がサポートされています。The recommended approach to load data from external tables in Azure Synapse Analytics is to use the PolyBase utility, which supports a maximum defined row length of 1 megabyte (MB). 1 MB より長い行を含むテーブルは、PolyBase によって読み込まれません。代わりに、一括コピー プログラムを使用する必要があります。PolyBase won't load tables with rows longer than 1 MB, and you must use the Bulk Copy Program instead.

結合を最も効率的に実行するには、結合の両側の列を同じデータ型として定義します。For the most efficient join execution, define the columns on both sides of the join as the same data type. ディメンション テーブルのキーが SMALLINT として定義されている場合は、そのディメンションを使用するファクト テーブルの対応する参照列も SMALLINT として定義する必要があります。If the key of a dimension table is defined as SMALLINT, then the corresponding reference columns in fact tables using that dimension should also be defined as SMALLINT.

文字フィールドは既定のサイズを大きく定義しないでください。Avoid defining character fields with a large default size. フィールド内のデータの最大サイズが 50 文字の場合は、VARCHAR(50) を使用します。If the maximum size of data within a field is 50 characters, use VARCHAR(50). 同様に、VARCHAR で十分な場合は NVARCHAR を使用しないでください。Similarly, don't use NVARCHAR if VARCHAR will suffice. NVARCHAR の場合、さまざまな言語の文字セットを使用できるように、Unicode データが格納されます。NVARCHAR stores Unicode data to allow for different language character sets. VARCHAR の場合は、ASCII データが格納されるため、スペースが少なくて済みます。VARCHAR stores ASCII data and takes less space.

設計上の推奨事項の概要Summary of design recommendations

不要なオブジェクトやプロセスは移行しないようにします。Don't migrate unnecessary objects or processes. 移行するオブジェクトやプロセスの実際の数を減らすのが適している場合は、ターゲットの Azure 環境の組み込み機能と関数を使用します。Use built-in features and functions in the target Azure environment where appropriate to reduce the actual number of objects and processes to migrate. 移行する物理データ マートの数を減らすかなくして、データ ウェアハウスに処理をプッシュ ダウンするために仮想化レイヤーの使用を検討してください。Consider using a virtualization layer to reduce or eliminate the number of physical data marts that you'll migrate and to push down processing into the data warehouse.

可能な限り自動化し、ソース システムのシステム カタログのメタデータを使用して、ターゲット環境の DDL を生成します。Automate wherever possible, and use metadata from system catalogs in the source system to generate DDLs for the target environment. 可能であれば、ドキュメントの生成も自動化します。If possible, also automate generating documents. WhereScape などの Microsoft パートナーは、自動化を支援するための特別なツールやサービスを提供できます。Microsoft partners such as WhereScape can provide specialized tools and services to assist with automation.

必要なデータ モデルの変更やデータ マッピングの最適化は、ターゲット プラットフォーム上で実行します。Perform any required data model changes or data mapping optimizations on the target platform. Azure Synapse Analytics では、これらの変更をより効率的に行うことができます。You can make these changes more efficiently in Azure Synapse Analytics. この方法により、キャパシティの限界ぎりぎりで既に実行している可能性のあるソース システムに対する影響を軽減できます。This approach reduces the impact on source systems that might already be running close to full capacity.

パフォーマンス オプションPerformance options

このセクションでは、データ モデルのパフォーマンスを向上させるために Azure Synapse Analytics 内で使用できる機能について説明します。This section describes the features available within Azure Synapse Analytics that you can use to improve performance for a data model.

一般的なアプローチGeneral approach

プラットフォームの機能によって、移行されるデータベースのパフォーマンス チューニングが実行されます。The platform's features run performance tuning on the database that will be migrated. このようなパフォーマンス チューニングの例としては、インデックス、データのパーティション分割、およびデータ分散があります。Indexes, data partitioning, and data distribution are examples of such performance tuning. 移行を準備するときに、チューニングを文書化すると、Azure Synapse Analytics ターゲット環境で適用できる最適化を把握して判断できます。When you're preparing for migration, documenting the tuning can capture and reveal optimizations that you can apply in the Azure Synapse Analytics target environment.

たとえば、テーブルに一意でないインデックスが存在する場合、そのインデックスで使用されているフィールドが、フィルター処理、グループ化、または結合に頻繁に使用されていることを示している可能性があります。For example, the presence of a non-unique index on a table can indicate that fields used in the index are used frequently for filtering, grouping, or joining. これは新しい環境でも同様です。そのため、インデックスを作成するフィールドを選択する場合はこのことにご注意ください。This will still be the case in the new environment, so keep it in mind when you're choosing which fields to index there. Teradata や Netezza などの特定のソース プラットフォームの移行の推奨事項については、個別のドキュメントで詳しく説明されています。Migration recommendations for specific source platforms such as Teradata and Netezza are described in detail in separate documents.

ターゲットの Azure Synapse Analytics 環境のパフォーマンスとスケーラビリティを活用して、データ分散などのさまざまなパフォーマンス オプションを試します。Use the performance and scalability of the target Azure Synapse Analytics environment to experiment with different performance options like data distribution. 代替アプローチの中から最適な選択肢を決定します (たとえば、大きなディメンション テーブルにレプリケートを使用するかハッシュ分散を使用するか)。Determine the best choice of alternative approaches (for example, replicated versus hash-distributed for a large dimension table). そのために外部ソースからデータを再読み込みする必要はありません。This doesn't mean that data must be reloaded from external sources. Azure Synapse Analytics では、CREATE TABLE AS SELECT ステートメントを使用し、さまざまなパーティション分割オプションや分散オプションを指定してテーブルのコピーを作成することにより、比較的短時間で簡単に代替アプローチをテストできます。It's relatively quick and easy to test alternative approaches in Azure Synapse Analytics by creating copies of any table with different partitioning or distribution options via a CREATE TABLE AS SELECT statement.

Azure 環境に用意されている監視ツールを使用して、クエリがどのように実行され、どこでボトルネックが発生する可能性があるかを把握できます。Use the monitoring tools provided by the Azure environment to understand how queries are executed and where bottlenecks might be occurring. 監視ダッシュボードや、自動化されたリソース管理とアラート処理を提供するサードパーティの Microsoft パートナーからツールを入手することもできます。Tools are also available from third-party Microsoft partners to provide monitoring dashboards and automated resource management and alerting.

Azure Synapse Analytics の各 SQL 操作と、そのクエリで使用されるメモリや CPU などのリソースは、システム テーブルに記録されます。Each SQL operation in Azure Synapse Analytics and resource, such as memory or the CPU used by that query, is logged into system tables. 一連の動的管理ビューを使用すると、この情報に簡単にアクセスできます。A series of dynamic management views simplifies access to this information.

以下のセクションでは、クエリ パフォーマンスをチューニングするための Azure SQL Data Warehouse 内の主要なオプションについて説明します。The following sections explain the key options within Azure SQL Data Warehouse for tuning query performance. 既存の環境には、ターゲット環境での最適化に役立つ可能性がある情報が含まれます。Existing environments will contain information about potential optimization in the target environment.

一時テーブルTemporary tables

Azure Synapse Analytics では一時テーブルがサポートされており、それらが作成されたセッションでのみ表示されます。Azure Synapse Analytics supports temporary tables that are visible only to the session in which they were created. これらはユーザー セッションの間は存在し、セッションの終了時に自動的に削除されます。They exist for the duration of a user session and are automatically dropped at the end of the session.

一時テーブルを作成するには、テーブル名の先頭にハッシュ文字 (#) を付けます。To create a temporary table, prefix the table name with the hash character (#). 次のセクションで説明されているように、一時テーブルでは、通常のインデックス作成および分散オプションをすべて使用できます。You can use all the usual indexing and distribution options with temporary tables, as described in the next section.

一時テーブルには、以下に示すいくつかの制限があります。Temporary tables have some restrictions:

  • 名前を変更することはできません。Renaming them isn't allowed.
  • 表示やパーティション分割は許可されていません。Viewing or partitioning them isn't allowed.
  • アクセス許可の変更は許可されていません。Changing permissions isn't allowed.

一時テーブルは、通常、ETL または ELT 処理で使用され、一時的な中間結果が変換プロセスの一部として使用されます。Temporary tables are commonly used within ETL/ELT processing, where transient intermediate results are used as part of a transformation process.

テーブル分散オプションTable distribution options

Azure Synapse Analytics は、複数の処理ノードにまたがって並列に実行することによってパフォーマンスとスケーラビリティを実現する、MPP データベース システムです。Azure Synapse Analytics is an MPP database system that achieves performance and scalability by running in parallel across multiple processing nodes.

複数ノード環境で SQL クエリを実行するための理想的な処理シナリオは、ワークロードのバランスを取り、すべてのノードで同じ量のデータが処理されるようにすることです。The ideal processing scenario for running an SQL query in a multinode environment is to balance the workload and give all nodes an equal amount of data to process. このアプローチを使用すれば、クエリを満たすためにノード間で移動する必要があるデータの量を最小限に抑えるか、そのようなデータを除外することができます。This approach also allows you to minimize or eliminate the amount of data that has to be moved between nodes to satisfy the query.

一般的な分析クエリで頻繁に集計が行われ、複数のテーブル間 (ファクト テーブルとディメンション テーブルの間など) で複数の結合が行われるため、理想的なシナリオを実現するのは困難な場合があります。It can be challenging to achieve the ideal scenario because there are often aggregations in typical analytics queries and multiple joins between several tables, as between fact and dimension tables.

クエリの処理方法に影響を与える方法の 1 つは、Azure Synapse Analytics 内の分散オプションを使用して、各テーブルの個々のデータ行が格納される場所を指定することです。One way to influence how queries are processed is to use the distribution options within Azure Synapse Analytics to specify where each table's individual data rows are stored. たとえば、2 つの大きなテーブルがデータ列 CUSTOMER_ID に結合されているとします。For example, assume that two large tables are joined on the data column, CUSTOMER_ID. 結合が実行されるたびに、CUSTOMER_ID 列を通じて 2 つのテーブルを分散すると、確実に結合の各側のデータが同じ処理ノードに併置済みとなるようにすることができます。By distributing the two tables through the CUSTOMER_ID columns whenever that join is performed, you can ensure that the data from each side of the join will already be co-located on the same processing node. この方法を使用すれば、ノード間でデータを移動する必要がなくなります。This method eliminates the need to move data between nodes. テーブルの分散指定は、CREATE TABLE ステートメントで定義されます。The distribution specification for a table is defined in the CREATE TABLE statement.

以下のセクションでは、使用可能な分散オプションと、それらを使用するタイミングに関する推奨事項について説明します。The following sections describe the available distribution options and recommendations for when to use them. 必要に応じて、CREATE TABLE AS SELECT ステートメントを使用し、新しい分散を指定してテーブルを再作成すると、初期読み込み後にテーブルの分散を変更することができます。It's possible to change the distribution of a table after the initial load, if necessary: re-create the table with the new distribution by using the CREATE TABLE AS SELECT statement.

ラウンド ロビンRound robin

ラウンド ロビン テーブル分散は既定のオプションであり、システム内のノード間にデータが均等に分散されます。Round-robin table distribution is the default option and spreads the data evenly across the nodes in the system. この方法は、データの高速読み込みの場合や、ボリュームが比較的少なく、ハッシュの明確な候補がないデータの場合に適しています。This method is good for fast data loading and for data that's relatively low in volume and doesn't have an obvious candidate for hashing. これは、ETL または ELT プロセスの一部としてステージング テーブルに頻繁に使用されます。It's frequently used for staging tables as part of an ETL or ELT process.


前述の例の CUSTOMER_ID などのユーザー定義のキーに適用されたハッシュ アルゴリズムに基づいて、システムによって行がハッシュ バケットに割り当てられます。The system assigns the row to a hash bucket, a task based on a hashing algorithm applied to a user-defined key like CUSTOMER_ID in the preceding example. その後、バケットが特定のノードに割り当てられ、同じ値でハッシュ分散されたすべてのデータ行が同じ処理ノードに存在することになります。The bucket is then assigned to a specific node, and all data rows hash-distributed on the same value end up on the same processing node.

この方法は、キーで頻繁に結合または集計される大きなテーブルの場合に便利です。This method is useful for large tables that are frequently joined or aggregated on a key. 結合する他の大きなテーブルは、可能であれば同じキーでハッシュする必要があります。Other large tables to be joined should be hashed on the same key if possible. ハッシュ キーの候補が複数存在する場合は、最も頻繁に結合されるものを選択します。If there are multiple candidates for the hash key, choose the most frequently joined one.

ハッシュ列に null 値を含めることはできません。また、多くのクエリにより日付でフィルター処理が行われるため、通常は日付ではありません。The hash column shouldn't contain nulls and isn't typically a date because many queries filter on date. ハッシュするキーが CHARVARCHAR ではなく整数値である場合、通常はハッシュの方が効率的です。Hashing is typically more efficient if the key to hash is an integer value instead CHAR or VARCHAR. 少数のキー値がデータ行の大部分を表す場合など、値の範囲が非常に偏っているキーは選択しないようにしてください。Avoid choosing keys with a highly skewed range of values, like when a small number of key values represent a large percentage of the data rows.


テーブルの分散オプションとしてレプリケートを選択すると、クエリ処理の目的で、各コンピューティング ノードにそのテーブルの完全なコピーがレプリケートされます。Choosing replicated as the distribution option for a table will cause a complete copy of that table to be replicated on each compute node for query processing purposes.

この方法は、比較的静的で、等結合によってより大きなテーブルに頻繁に結合される比較的小さなテーブル (通常は 2 GB 未満に圧縮されたもの) に役立ちます。This approach is useful for relatively small tables (typically less than 2 GB compressed) that are relatively static and frequently joined to larger tables via an equi-join. これらのテーブルは、多くの場合、スター スキーマ内のディメンション テーブルです。These tables are often dimensional tables in a star schema.


Azure Synapse Analytics には、レコードを取得するのに必要なリソースと時間を削減するために、大きなテーブルのデータにインデックスを付けるためのオプションが含まれています。Azure Synapse Analytics includes options for indexing data in large tables to reduce the resources and time required to retrieve records:

  • クラスター化列ストア インデックスClustered columnstore index
  • クラスター化インデックスClustered index
  • 非クラスター化インデックスNon-clustered index

どのインデックス オプションからもメリットが得られないテーブルには、HEAP という非インデックス オプションが存在します。A non-indexed option, HEAP, exists for tables that don't benefit from any of the index options. インデックスを使用すると、クエリ時間は短縮できますが、読み込み時間は長くなり、より多くのストレージ スペースが使用されることになります。Using indexes is a trade-off between improved query times versus longer load times and usage of more storage space. 多くの場合、インデックスを使用すると、データ行のごく一部にのみ影響する大きなテーブルに対する SELECTUPDATEDELETEMERGE の操作速度は向上します。また、完全なテーブル スキャンを最小限に抑えることができます。Indexes often speed up SELECT, UPDATE, DELETE, and MERGE operations on large tables that affect a small percentage of the data rows, and they can minimize full table scans.

UNIQUE 制約や PRIMARY KEY 制約が列に定義されると、インデックスが自動的に作成されます。Indexes are automatically created when UNIQUE or PRIMARY KEY constraints are defined on columns.

クラスター化列ストア インデックスClustered columnstore index

クラスター化列ストア インデックスは、Azure Synapse Analytics 内の既定のインデックス作成オプションです。Clustered columnstore index is the default indexing option within Azure Synapse Analytics. 大きなテーブルに対して最適な圧縮とクエリのパフォーマンスが提供されます。It provides the best compression and query performance for large tables. 6,000 万行未満の小さなテーブルでは、これらのインデックスは効率的ではないため、HEAP オプションを使用する必要があります。For smaller tables of fewer than 60 million rows, these indexes aren't efficient, so you should use the HEAP option. 同様に、テーブル内のデータが一時的なもので、ETL または ELT プロセスの一部である場合は、ヒープまたは一時テーブルの方が効率的である可能性があります。Similarly, a heap or a temporary table might be more efficient if the data in a table is transient and part of an ETL/ELT process.

クラスター化インデックスClustered index

強力なフィルター条件に基づいて、大きなテーブルから 1 行または少数の行を定期的に取得する必要がある場合、クラスター化列ストア インデックスよりもクラスター化インデックスを使用する方が効率的な可能性があります。If there's a requirement to regularly retrieve a single row or small number of rows from a large table based on a strong filter condition, a clustered index might be more efficient than a clustered columnstore index. クラスター化インデックスは、各テーブルに 1 つだけ許可されます。Only one clustered index is allowed per table.

非クラスター化インデックスNon-clustered index

非クラスター化インデックスは、フィルター条件に基づいて 1 行または少数の行の取得を高速化できるという点で、クラスター化インデックスに似ています。Non-clustered indexes are similar to clustered indexes in that they can speed up retrieval of single rows or a small number of rows based on a filter condition. 内部的に、非クラスター化インデックスはデータとは別に格納され、1 つのテーブルに対して複数の非クラスター化インデックスを定義できます。Internally, non-clustered indexes are stored separately from the data, and multiple non-clustered indexes can be defined on a table. ただし、インデックスを追加するたびにより多くのストレージが必要になり、データの挿入や読み込みのスループットは低下します。However, each additional index will require more storage and will reduce the throughput of data insert or loading.


ヒープ テーブルの場合、データの読み込み時にインデックスの作成と維持に関するオーバーヘッドは発生しません。Heap tables incur none of the overhead associated with the creation and maintenance of indexes at data load time. これは、ELT プロセスを含む、プロセス中に一時的なデータをすばやく読み込むのに役立ちます。They can help to quickly load transient data during processes, including ELT processes. データがその後すぐに読み取られる場合は、キャッシュも役立ちます。Caching can also assist when the data is read immediately afterward. 6,000 万行未満の場合、クラスター化列ストア インデックスは非効率的であるため、ヒープ テーブルは、行がこの数より少ないテーブルを格納するのにも役立ちます。Because clustered columnstore indexes are inefficient below 60 million rows, heap tables can also help to store tables with rows less than this amount.

データのパーティション分割Data partitioning

エンタープライズ データ ウェアハウスには、ファクト テーブルに数十億行が含まれる場合があります。In an enterprise data warehouse, fact tables can contain many billions of rows. パーティション分割でこれらのテーブルを別々の部分に分割し、クエリ実行時に処理されるデータ量を減らすと、これらのテーブルの維持とクエリを最適化できます。Partitioning is a way to optimize the maintenance and querying of these tables by splitting them into separate parts to reduce the amount of data processed when running queries. テーブルのパーティション分割指定は、CREATE TABLE ステートメントで定義されます。The partitioning specification for a table is defined in the CREATE TABLE statement.

パーティション分割に使用できるフィールドは、テーブルごとに 1 つだけです。You can use only one field per table for partitioning. 多くのクエリは日付または日付範囲でフィルター処理されるため、多くの場合、これは日付フィールドになります。It's frequently a date field because many queries are filtered by a date or date range. 必要に応じて、CREATE TABLE AS SELECT ステートメントを使用し、新しい分散を指定してテーブルを再作成すると、初期読み込み後にテーブルのパーティション分割を変更することができます。You can change the partitioning of a table after initial load, if necessary, by re-creating the table with the new distribution through the CREATE TABLE AS SELECT statement.

クエリを最適化するためのパーティション分割Partitioning for query optimization

大きいファクト テーブルに対するクエリが特定のデータ列によって頻繁にフィルター処理される場合、その列をパーティション分割することにより、クエリを実行するために処理する必要のあるデータ量を大幅に削減できます。If queries against a large fact table are frequently filtered by a certain data column, then partitioning on that column can significantly reduce the amount of data that needs to be processed to perform the queries. 一般的な例としては、日付フィールドを使用して、小さいグループにテーブルを分割することが挙げられます。A common example is to use a date field to split the table into smaller groups. 各グループには 1 日のデータが含まれます。Each group contains data for a single day. 日付でフィルター処理する WHERE 句がクエリに含まれている場合、その日付フィルターに一致するパーティションのみがアクセスされる必要があります。When a query contains a WHERE clause that filters on the date, only partitions that match the date filter need to be accessed.

テーブルの維持を最適化するためのパーティション分割Partitioning for optimization of table maintenance

データ ウェアハウス環境では、詳細なファクト データのローリング ウィンドウを維持するのが一般的です。It's common in data warehouse environments to maintain a rolling window of detailed fact data. 例として、5 年前までさかのぼる販売取引があります。An example is sales transactions that go back five years. 販売日を基にパーティション分割すると、ローリング ウィンドウを過ぎた古いデータの削除がはるかに効率的になります。By partitioning on the sales date, the removal of old data beyond the rolling window becomes much more efficient. 最も古いパーティションを削除する方が、個々のすべての行を削除するよりも速く、リソースの使用量が少なくなります。Dropping the oldest partition is quicker and uses fewer resources than deletions of all the individual rows.


クエリは、Azure Synapse Analytics に送信されると、最初にクエリ オプティマイザーによって処理されます。When a query is submitted to Azure Synapse Analytics, it's first processed by the query optimizer. オプティマイザーによって、クエリを効率的に実行するための最適な内部メソッドが決定されます。The optimizer determines the best internal methods to execute the query efficiently.

オプティマイザーにより、コストベースのアルゴリズムに基づいて使用できるさまざまなクエリ実行プランが比較されます。The optimizer compares the various query-execution plans that are available based on a cost-based algorithm. コストの見積もりの精度は、使用可能な統計に依存します。The accuracy of the cost estimates is dependent on the statistics available. 確実に統計が最新のものであるようにすることをお勧めします。It's a good practice to ensure that statistics are up to date.

Azure Synapse Analytics では、AUTO_CREATE_STATISTICS オプションがオンになっていると、統計の自動更新がトリガーされます。In Azure Synapse Analytics, if the AUTO_CREATE_STATISTICS option is turned on, it will trigger an automatic update of statistics. CREATE STATISTICS コマンドを使用して、手動で統計を作成または更新することもできます。You can also create or update statistics manually via the CREATE STATISTICS command.

コンテンツが大幅に変更されている場合 (日次更新など) は、統計を更新してください。Refresh statistics when the contents have changed substantially, such as in a daily update. この更新は、ETL プロセスに組み込むことができます。This refresh can be incorporated into an ETL process.

データベース内のすべてのテーブルでは、少なくとも 1 つの列に統計が収集される必要があります。All tables in the database should have statistics collected on at least one column. これにより、行数やテーブル サイズなどの基本的な情報を確実にオプティマイザーで使用できるようになります。It ensures that basic information such as row count and table size is available to the optimizer. 統計が収集される必要のある他の列は、JOINDISTINCTORDER BYGROUP BY の処理で指定されている列です。Other columns that should have statistics collected are columns specified in JOIN, DISTINCT, ORDER BY, and GROUP BY processing.

ワークロードの管理Workload management

Azure Synapse Analytics には、混合ワークロードのリソース使用率を管理するための包括的な機能が組み込まれています。Azure Synapse Analytics incorporates comprehensive features for managing resource utilization across mixed workloads. クエリとデータの負荷など、さまざまなワークロードの種類のリソース クラスを作成すると、ワークロードを管理するのに役立ちます。Creating resource classes for different workload types, such as queries versus data load, helps you manage your workload. 同時に実行されるクエリの数と、各クエリに割り当てられているコンピューティング リソースに制限が設定されます。It sets limits on the number of queries that run concurrently and on the compute resources assigned to each query. メモリと同時実行の間にはトレードオフがあります。There's a trade-off between memory and concurrency:

  • より小規模なリソース クラスでは、クエリごとの最大メモリは減りますが、同時実行は増えます。Smaller resource classes reduce the maximum memory per query but increase concurrency.
  • より大規模なリソース クラスでは、クエリごとの最大メモリは増えますが、同時実行は減ります。Larger resource classes increase the maximum memory per query but reduce concurrency.

パフォーマンスに関する推奨事項Performance recommendations

インデックスやデータ分散などのパフォーマンス向上方法を使用して、新しいターゲット環境で同様の方法の候補を評価しますが、Azure Synapse Analytics で必要であることを確認するためにベンチマークを実行します。Use performance improvement methods like indexes or data distribution to gauge candidates for similar methods in the new target environment, but benchmark to confirm that they're necessary in Azure Synapse Analytics. 確実に統計が最新のものであるようにするため、あるいは統計を自動作成することを選択するには、ETL または ELT プロセスに COLLECT STATISTICS ステップを構築します。Build COLLECT STATISTICS steps into ETL/ELT processes to ensure that statistics are up to date, or select to automatically create statistics.

Azure Synapse Analytics で使用できるチューニング オプションと、並列データの高速読み込みを実現する PolyBase などの、関連するユーティリティのパフォーマンス特性を理解します。Understand the tuning options available in Azure Synapse Analytics and the performance characteristics of associated utilities, such as PolyBase for fast parallel data loading. これらのオプションを使用すると、効率的なエンドツーエンドの実装を構築できます。Use these options to build an efficient end-to-end implementation.

Azure 環境の柔軟性、スケーラビリティ、およびパフォーマンスを利用して、データ モデルの変更やパフォーマンス チューニング オプションを適切に実装します。Use the flexibility, scalability, and performance of the Azure environment to implement any data model changes or performance tuning options in place. この作業によって、既存のソース システムへの影響が軽減されます。This effort will reduce the impact on existing source systems.

Azure Synapse Analytics で使用できる動的管理ビューについて理解します。Understand the dynamic management views available in Azure Synapse Analytics. これらのビューによって、システム全体のリソース使用率に関する情報と、個々のクエリの詳細な実行情報の両方が提供されます。These views provide both system-wide resource utilization information and detailed execution information for individual queries.

Azure のリソース クラスについて理解し、それらを適切に割り当てて、混合ワークロードやコンカレンシーを効率的に管理できるようにします。Understand Azure resource classes and allocate them appropriately to ensure efficient management of mixed workloads and concurrency.

Azure Synapse Analytics 環境の一部として仮想化レイヤーを使用することを検討します。Consider using a virtualization layer as part of the Azure Synapse Analytics environment. ビジネス ユーザーやレポート ツールからウェアハウス実装の変更を保護することができます。It can shield changes in the warehouse implementation from business users and reporting tools.

パートナー提供の移行ツールやサービス (Qlik Replicate for Microsoft Migrations、WhereScape、Datometry など) について調査します。Research partner-provided migration tools and services such as Qlik Replicate for Microsoft migrations, WhereScape, and Datometry. これらのサービスを使用すると、移行プロセスの一部を自動化して、移行プロジェクトに関係する経過時間やリスクを軽減できます。These services can automate parts of the migration process and reduce the elapsed time and risk involved in a migration project.