Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
株式会社インサイトテクノロジー
田畑 堅
レプリケーションを使用したデータ分析基盤
構築のキモ(事例つき)
Agenda
1. データ分析基盤の構築
2. Attunity Replicateのご紹介
3. DEMO
4. 国内事例/ハマりポイント
1.データ分析基盤の構築
1. データ分析基盤の構築
ソースデータベース ターゲットデータベース
CSVファイル CSVファイル
①データ抽出
②ファイル転送
③データロード
【課題】
 初期データの抽出、反映方法
 差分データの抽出、反映方法
 データベース毎に...
1. データ分析基盤の構築
毎回の同期タイミングでデータをどのように同期させるか?
データ量にもよるが、毎回の同期で全データを同期するのは非効率・・・
- 同期に時間が掛かる
- データの鮮度が落ちる
- 同期元のデータベースに負荷がかかる
...
1. データ分析基盤の構築
ソースデータベース(Oracle) ターゲットデータベース
連携元のデータベースが増えると・・・
ソースデータベース(SQLServer)
ソースデータベース(DB2)
ソースデータベース(MySQL)
【課題】色々...
1. データ分析基盤の構築
差分データの抽出
同期対象のテーブルのカラムを参照
データベースの変更履歴は、トランザクションログに保持されている!
全部のテーブルに更新日的なカラムが存在すればOKだが・・・
それらしいカラムがあってもそもそも本当...
1. データ分析基盤の構築
差分データの抽出 / いろいろな種類のデータベースへの対応
課題
 取得時のソースデータベースへの負荷
 データベースによって出力のされ方が異なる・・・
 取得した差分データをターゲットDBに適用できるようにS...
1. データ分析基盤の構築
ATTUNITY REPLICATEで解決!!
差分データ取得方法の検討
ソースDBへの負荷
ソースDB ⇒ ターゲットDBのデータ連携時間(Latency)
データベース毎に異なる構文への対応
対象テーブ...
2. Attunity Replicateのご紹介
Financial Services Manufacturing / Industrials GovernmentHealth Care
Technology / Telecommunications Other Industries
Ente...
Microsoft with OEM and for over 8 Years
Oracle with OEM for over 13 years
IBM with OEM for over 9 years
Amazon (AWS) as a ...
ATTUNITY REPLICATE
 エージェントレス (LUW)
 ブラウザベースのGUIによる簡易設定・監視
 異種データベース間のデータ高速転送・同期
 FULL LOAD(初期コピー)~CDC(変更データ反映)までシームレスに...
RDBMS
Oracle
SQL Server
DB2 LUW
DB2 iSeries
DB2 z/OS
MySQL
PostgreSQL
Sybase ASE
Informix
Data Warehouse
Exadata
Teradata
...
ATTUNITY REPLICATE 構成
Replicate Server
対応OS(64bit)
• Linux Red Hat 6.2 and above
• SUSE Linux 11 and above
• Windows Serve...
データのレプリケーション
Source DB Target DB
EMP
DEPT
SALGRADE
EMP
DEPT
SALGRADE
初期同期
(COPY)
INSERT
UPDATE
DELETE
データのレプリケーション
Source DB Target DB
Change
Data
Capture
トランザクションログ
EMP
DEPT
SALGRADE
EMP
DEPT
SALGRADE
Change
Data
Apply
INSE...
3. DEMO
SourceDB
TargetDB
SQLServer2016
Oracle 11gR2
デモ環境(その1)
※シンプルな構成
SourceDB
TargetDB
SQLServer2016
Oracle 11gR2
デモ環境(その1)
※MySQLを追加!!
MySQL 5..6
4. 国内事例/ハマりポイント
事例1 ランスタッド株式会社 様
課題
 システムのクラウド化
 DB2を使用しているが、参照系の処理時にロックエスカレーションが多発
 新参照系としてAmazon Auroraを使用
 DB2は更新系として稼働を続ける
 データレプ...
ソリューション
採用
CDC Incremental
 Attunity Replicateを使用してリアルタイムにAmazon Auroraへデータ同期
メリット
Aurora側のテーブル設計の工数削減
← Attunityで自動で作成させ...
発生した問題
1. 初回データ同期の開始時にエラーが発生し、データ同期が
開始できない
【発生原因】
DB2 9.7では、CurrentLSN値をDB2のAPIで取得できない為、Attunityでの
同期開始時にDB2のアクティブログ/アーカイ...
発生した問題
2. resume時にエラーが発生し、タスクが再開できない
【発生原因】
Endian Typeの取得ためにアーカイブログ情報を参照しに行った際に、
前項の対応で指定したCurrentLSNに紐づくログを探して、ログが存在しない為...
発生した問題
3. ソース側で追加したテーブルが自動で反映されない
【発生原因】
CDC中にDB2側で行った、CREATE TABLEのDDLがアクティブログに
記録されなかった為。
【対応内容】
以後、テーブル追加の際は、CREATE TAB...
事例2 某電子書籍様
課題
 課金管理情報を使用して分析を行いたい
 課金管理DBに負荷をかけないこと
 データレプリケーションの遅延は2~3分程度に収めたい
 対象データ量は、900GB弱
対象システム
課金管理システム
ソリューション
 分析用にTeradataを導入、Attunity Replicateを使用してリアルタイムにデータ同期
採用
CDC Incremental
発生した問題
1. ソースDBとターゲットDBの日付型データの範囲差異で
レプリケーション出来ないデータがあった
【発生原因】
MySQL側で登録されていた、登録日付のデータが、0000/00/00 00:00:00 が
Teradata側では...
発生した問題
1. ソースDBとターゲットDBの日付型データの範囲差異で
レプリケーション出来ないデータがあった
【発生原因】
MySQL側で登録されていた、登録日付のデータが、0000/00/00 00:00:00 が
Teradata側では...
発生した問題
2. ソースDBのENUM型のカラムのデータがエラーでレプリケ
ーションできない
【発生原因】
MySQL側で、ENUM型カラムのデータに、ENUMで選択可能な値以外のデータが
登録されていた。
※MySQLでは、ver5.6より...
発生した問題
3. Teradata側で文字列を含むPKエラーでレプリケーションに
失敗
【発生原因】
PKに含まれる文字列型の定義がNOCASESPECIFICになっていた為。
※Attunity Replicateで自動で作成された場合、デ...
まとめ
データ分析基盤DBへのデータ連携にAttunity Replicateを使うと
 データ連携用のツール作成/テストの工数が削減でき、
その分、アプリケーション開発/テストに時間を費やせる
 差分データの連携が高速に行える為、鮮度の高...
記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。
Copyright 2017 Insight Technology, Inc. All Rights Reserved.
Upcoming SlideShare
Loading in …5
×

[db tech showcase Tokyo 2017] A15: レプリケーションを使用したデータ分析基盤構築のキモ(事例)by 株式会社インサイトテクノロジー 田畑堅

257 views

Published on

レプリケーションソフトウェアを使用したデータ分析基盤の構築について、嵌った点/必要となる考慮ポイントをユーザ様導入事例をもとに説明します。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

[db tech showcase Tokyo 2017] A15: レプリケーションを使用したデータ分析基盤構築のキモ(事例)by 株式会社インサイトテクノロジー 田畑堅

  1. 1. 株式会社インサイトテクノロジー 田畑 堅 レプリケーションを使用したデータ分析基盤 構築のキモ(事例つき)
  2. 2. Agenda 1. データ分析基盤の構築 2. Attunity Replicateのご紹介 3. DEMO 4. 国内事例/ハマりポイント
  3. 3. 1.データ分析基盤の構築
  4. 4. 1. データ分析基盤の構築 ソースデータベース ターゲットデータベース CSVファイル CSVファイル ①データ抽出 ②ファイル転送 ③データロード 【課題】  初期データの抽出、反映方法  差分データの抽出、反映方法  データベース毎に異なる構文  ターゲットにデータ反映するの にかかる時間(latency)  対象テーブルの追加・定義変更  ツール作成時間とコスト (テスト含む) 単純化すると・・・
  5. 5. 1. データ分析基盤の構築 毎回の同期タイミングでデータをどのように同期させるか? データ量にもよるが、毎回の同期で全データを同期するのは非効率・・・ - 同期に時間が掛かる - データの鮮度が落ちる - 同期元のデータベースに負荷がかかる 事前に全件データをロードしておき、差分データのみを定期的に反映させる、 という方式にすれば、上記の問題はクリアできる!! 【課題】差分データをどのようにして取得する?
  6. 6. 1. データ分析基盤の構築 ソースデータベース(Oracle) ターゲットデータベース 連携元のデータベースが増えると・・・ ソースデータベース(SQLServer) ソースデータベース(DB2) ソースデータベース(MySQL) 【課題】色々な種類のソースDBへの個別対応が必要・・・
  7. 7. 1. データ分析基盤の構築 差分データの抽出 同期対象のテーブルのカラムを参照 データベースの変更履歴は、トランザクションログに保持されている! 全部のテーブルに更新日的なカラムが存在すればOKだが・・・ それらしいカラムがあってもそもそも本当に更新されるのか確認が大変・・・ DB種別 名称 解析方法 Oracle REDOログ(ONLINE/ARCHIVE) Logmnr SQL Server トランザクションログ sys.fn_dblog / sys.fn_dump_dblog PostgreSQL Write Ahead Log - MySQL バイナリログ mysqlbinlog
  8. 8. 1. データ分析基盤の構築 差分データの抽出 / いろいろな種類のデータベースへの対応 課題  取得時のソースデータベースへの負荷  データベースによって出力のされ方が異なる・・・  取得した差分データをターゲットDBに適用できるようにSQL文を構築する 必要がある・・・  差分データの適用パフォーマンス  適用データの取得方法 - Commitされたもののみ同期させる? - 問答無用に同期させる?(Rollbackも同期) - DDLはどうする? 理論的にはできそうだが、実際にやれるか!?
  9. 9. 1. データ分析基盤の構築 ATTUNITY REPLICATEで解決!! 差分データ取得方法の検討 ソースDBへの負荷 ソースDB ⇒ ターゲットDBのデータ連携時間(Latency) データベース毎に異なる構文への対応 対象テーブルの追加、構成変更に伴う変更対応 ツール作成・テストに要する工数 不要 ニアリアルタイム 不要 不要 削減可能 低い
  10. 10. 2. Attunity Replicateのご紹介
  11. 11. Financial Services Manufacturing / Industrials GovernmentHealth Care Technology / Telecommunications Other Industries Enterprise Data Management On Premises | Cloud | Across Platforms Attunity社 概要  1988年創業、データ統合において、20年以上にわたる研究開発と経験  CDC(更新データ捕捉)技術における独立系リーディング企業  米国、英国、イスラエル、日本、香港、台湾、韓国など、全世界的事業規模 65ヶ国で2,000社以上の顧客
  12. 12. Microsoft with OEM and for over 8 Years Oracle with OEM for over 13 years IBM with OEM for over 9 years Amazon (AWS) as a technology partner Teradata as a reseller for Data Warehouse /Hadoop market マイクロソフト、オラクル、IBMやその他の企業から認められ、選ばれた技術
  13. 13. ATTUNITY REPLICATE  エージェントレス (LUW)  ブラウザベースのGUIによる簡易設定・監視  異種データベース間のデータ高速転送・同期  FULL LOAD(初期コピー)~CDC(変更データ反映)までシームレスに連携  データのフィルタリング・加工 【Target】【Source】 SQL Server 2005/2008/2012/2014 MySQL 5.5/5.6 Sybase ASE 12.5/15/15.5/16 IMS PostgresSQL 9.4.2↑(Win) 9.4(Linux)  主要対応環境  ロジカルレプリケーション(データベース同期) Oracle10g/11g/12c
  14. 14. RDBMS Oracle SQL Server DB2 LUW DB2 iSeries DB2 z/OS MySQL PostgreSQL Sybase ASE Informix Data Warehouse Exadata Teradata Netezza Vertica Actian Vector Actian Matrix (SAP / HANA) Hortonworks Cloudera MapR Pivotal Hadoop IMS/DB SQL M/P Enscribe RMS VSAM Legacy Amazon RDS Salesforce Cloud RDBMS Oracle SQL Server DB2 LUW MySQL PostgreSQL Sybase ASE Informix Data Warehouse Exadata Teradata Netezza Vertica Pivotal DB (Greenplum) Pivotal HAWQ Actian Vector Sybase IQ SAP / HANA Hortonworks Cloudera MapR Pivotal Hadoop MongoDB NoSQL Amazon RDS/Redshift/EC2 Google Cloud SQL Azure SQL Data Warehouse Cloud Kafka Message Broker targets sources Oracle SQL DB2 SAP サポートデータベース
  15. 15. ATTUNITY REPLICATE 構成 Replicate Server 対応OS(64bit) • Linux Red Hat 6.2 and above • SUSE Linux 11 and above • Windows Server 2008 • Windows Server 2012 • Windows 7 推奨H/Wスペック  CPU : Quad core ~8core↑  Memory : 8GB~64GB↑  Disk : 320GB~500GB  Network : 1Gbps~10Gbps×2 SOURCE DATABASE TARGET DATABASE Read Write Full Load Change Data Capture
  16. 16. データのレプリケーション Source DB Target DB EMP DEPT SALGRADE EMP DEPT SALGRADE 初期同期 (COPY) INSERT UPDATE DELETE
  17. 17. データのレプリケーション Source DB Target DB Change Data Capture トランザクションログ EMP DEPT SALGRADE EMP DEPT SALGRADE Change Data Apply INSERT UPDATE DELETE 反映は最大数分程度
  18. 18. 3. DEMO
  19. 19. SourceDB TargetDB SQLServer2016 Oracle 11gR2 デモ環境(その1) ※シンプルな構成
  20. 20. SourceDB TargetDB SQLServer2016 Oracle 11gR2 デモ環境(その1) ※MySQLを追加!! MySQL 5..6
  21. 21. 4. 国内事例/ハマりポイント
  22. 22. 事例1 ランスタッド株式会社 様 課題  システムのクラウド化  DB2を使用しているが、参照系の処理時にロックエスカレーションが多発  新参照系としてAmazon Auroraを使用  DB2は更新系として稼働を続ける  データレプリケーションの遅延は2~3分程度に収めたい  対象データ量は、300GB弱  DB2 → Auroraへのレプリケーション時のデータ型マッピング、キャラクタセット変換の検 討が大変 対象システム 基幹DB(派遣登録者の管理)
  23. 23. ソリューション 採用 CDC Incremental  Attunity Replicateを使用してリアルタイムにAmazon Auroraへデータ同期 メリット Aurora側のテーブル設計の工数削減 ← Attunityで自動で作成させて結果のチェックのみとした
  24. 24. 発生した問題 1. 初回データ同期の開始時にエラーが発生し、データ同期が 開始できない 【発生原因】 DB2 9.7では、CurrentLSN値をDB2のAPIで取得できない為、Attunityでの 同期開始時にDB2のアクティブログ/アーカイブログ情報の取得に失敗し、本事 象が発生しました。 【対応内容】 同期開始前に、DB2でCurrentLSN値を調べてAttunityに設定する。 ※Reload時も同様の対応が必要となります ※詳細手順につきましては、別途手順書を提示致します。
  25. 25. 発生した問題 2. resume時にエラーが発生し、タスクが再開できない 【発生原因】 Endian Typeの取得ためにアーカイブログ情報を参照しに行った際に、 前項の対応で指定したCurrentLSNに紐づくログを探して、ログが存在しない為 にエラーが発生。タスクの再開ができない。 【対応内容】 Resume時には、動的にアクティブログ/アーカイブログ情報を取得に行く必要 がないため、データベース登録情報に下記パラメータの設定を行う。 (Endian typeの扱いを固定する設定) endianityMode = SWAP
  26. 26. 発生した問題 3. ソース側で追加したテーブルが自動で反映されない 【発生原因】 CDC中にDB2側で行った、CREATE TABLEのDDLがアクティブログに 記録されなかった為。 【対応内容】 以後、テーブル追加の際は、CREATE TABLE文にDATA CAPTURE CHANGES句 をつけてテーブル作成を行う。 ※対象のテーブルについては、タスクに手動追加、全データ転送から実行で対応 した
  27. 27. 事例2 某電子書籍様 課題  課金管理情報を使用して分析を行いたい  課金管理DBに負荷をかけないこと  データレプリケーションの遅延は2~3分程度に収めたい  対象データ量は、900GB弱 対象システム 課金管理システム
  28. 28. ソリューション  分析用にTeradataを導入、Attunity Replicateを使用してリアルタイムにデータ同期 採用 CDC Incremental
  29. 29. 発生した問題 1. ソースDBとターゲットDBの日付型データの範囲差異で レプリケーション出来ないデータがあった 【発生原因】 MySQL側で登録されていた、登録日付のデータが、0000/00/00 00:00:00 が Teradata側では日付型のレンジ内ではない為、エラー発生。 【対応内容】 Attunity Replicateで、0000/00/00 00:00:00 のデータは、9999/12/31 00:00:00 に変 換する設定を入れて、正常にデータがレプリケーションされるようになった。
  30. 30. 発生した問題 1. ソースDBとターゲットDBの日付型データの範囲差異で レプリケーション出来ないデータがあった 【発生原因】 MySQL側で登録されていた、登録日付のデータが、0000/00/00 00:00:00 が Teradata側では日付型のレンジ内ではない為、エラー発生。 【対応内容】 Attunity Replicateで、0000/00/00 00:00:00 のデータは、9999/12/31 00:00:00 に変 換する設定を入れて、正常にデータがレプリケーションされるようになった。 日付型、数値型はデータベース毎の範囲の確認が必要。 実際のデータとしてどのようなデータが入っているのかの確認も必要・・・
  31. 31. 発生した問題 2. ソースDBのENUM型のカラムのデータがエラーでレプリケ ーションできない 【発生原因】 MySQL側で、ENUM型カラムのデータに、ENUMで選択可能な値以外のデータが 登録されていた。 ※MySQLでは、ver5.6より前はこのような値を登録することができる・・・ ※レプリケーション時に、ENUMインデックスを参照したが、該当データの ENUMインデックスがNULLになっていた為、エラー発生 【対応内容】 Attunity Replicateで、上記のようなデータもレプリケーション出来るように機能 追加してもらった 実際のデータとしてどのようなデータが入っているのかの確認も必要・・・
  32. 32. 発生した問題 3. Teradata側で文字列を含むPKエラーでレプリケーションに 失敗 【発生原因】 PKに含まれる文字列型の定義がNOCASESPECIFICになっていた為。 ※Attunity Replicateで自動で作成された場合、デフォルトでは、 NOCASESPECIFICになる 【対応内容】 Attunity Replicateの設定の、文字列型のデフォルトの定義をCASESPECIFICに変 更した。 ターゲットDB側のテーブル定義の確認は念のためしてください
  33. 33. まとめ データ分析基盤DBへのデータ連携にAttunity Replicateを使うと  データ連携用のツール作成/テストの工数が削減でき、 その分、アプリケーション開発/テストに時間を費やせる  差分データの連携が高速に行える為、鮮度の高いデータを使用する ことが可能となる  設定が容易な為、連携対象のテーブルの変更にも簡単に対応可能  ターゲットDBにテーブルを自動で作成してくれるので、開発時に重 宝する ただし、安定運用の為には・・・  ソースDBの連携対象データにどのようなものがあるのか  ソースDB側でどのような運用(テーブル/データ追加・削除等)がされているのか の事前チェックが必要
  34. 34. 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。 Copyright 2017 Insight Technology, Inc. All Rights Reserved.

×