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

1. 株式会社インサイトテクノロジー
田畑 堅
レプリケーションを使用したデータ分析基盤
構築のキモ（事例つき）

2. Agenda
1. データ分析基盤の構築
2. Attunity Replicateのご紹介
3. DEMO
4. 国内事例/ハマりポイント

3. 1.データ分析基盤の構築

4. 1. データ分析基盤の構築
ソースデータベース ターゲットデータベース
CSVファイル CSVファイル
①データ抽出
②ファイル転送
③データロード
【課題】
 初期データの抽出、反映方法
 差分データの抽出、反映方法
 データベース毎に異なる構文
 ターゲットにデータ反映するの
にかかる時間(latency)
 対象テーブルの追加・定義変更
 ツール作成時間とコスト
（テスト含む）
単純化すると・・・

5. 1. データ分析基盤の構築
毎回の同期タイミングでデータをどのように同期させるか？
データ量にもよるが、毎回の同期で全データを同期するのは非効率・・・
- 同期に時間が掛かる
- データの鮮度が落ちる
- 同期元のデータベースに負荷がかかる
事前に全件データをロードしておき、差分データのみを定期的に反映させる、
という方式にすれば、上記の問題はクリアできる！！
【課題】差分データをどのようにして取得する？

6. 1. データ分析基盤の構築
ソースデータベース（Oracle） ターゲットデータベース
連携元のデータベースが増えると・・・
ソースデータベース（SQLServer）
ソースデータベース（DB2）
ソースデータベース（MySQL）
【課題】色々な種類のソースDBへの個別対応が必要・・・

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. 1. データ分析基盤の構築
差分データの抽出 / いろいろな種類のデータベースへの対応
課題
 取得時のソースデータベースへの負荷
 データベースによって出力のされ方が異なる・・・
 取得した差分データをターゲットDBに適用できるようにSQL文を構築する
必要がある・・・
 差分データの適用パフォーマンス
 適用データの取得方法
- Commitされたもののみ同期させる？
- 問答無用に同期させる？(Rollbackも同期)
- DDLはどうする？
理論的にはできそうだが、実際にやれるか！？

9. 1. データ分析基盤の構築
ATTUNITY REPLICATEで解決!!
差分データ取得方法の検討
ソースDBへの負荷
ソースDB ⇒ ターゲットDBのデータ連携時間(Latency)
データベース毎に異なる構文への対応
対象テーブルの追加、構成変更に伴う変更対応
ツール作成・テストに要する工数
不要
ニアリアルタイム
不要
不要
削減可能
低い

10. 2. Attunity Replicateのご紹介

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. 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. 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. 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. 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↑
 Memorｙ : 8GB～64GB↑
 Disk : 320GB～500GB
 Network : 1Gbps～10Gbps×2
SOURCE
DATABASE
TARGET
DATABASE
Read Write
Full Load
Change Data Capture

16. データのレプリケーション
Source DB Target DB
EMP
DEPT
SALGRADE
EMP
DEPT
SALGRADE
初期同期
(COPY)
INSERT
UPDATE
DELETE

17. データのレプリケーション
Source DB Target DB
Change
Data
Capture
トランザクションログ
EMP
DEPT
SALGRADE
EMP
DEPT
SALGRADE
Change
Data
Apply
INSERT
UPDATE
DELETE
反映は最大数分程度

18. 3. DEMO

19. SourceDB
TargetDB
SQLServer2016
Oracle 11gR2
デモ環境（その１）
※シンプルな構成

20. SourceDB
TargetDB
SQLServer2016
Oracle 11gR2
デモ環境（その１）
※MySQLを追加！！
MySQL 5..6

21. 4. 国内事例/ハマりポイント

22. 事例1 ランスタッド株式会社 様
課題
 システムのクラウド化
 DB2を使用しているが、参照系の処理時にロックエスカレーションが多発
 新参照系としてAmazon Auroraを使用
 DB2は更新系として稼働を続ける
 データレプリケーションの遅延は2～3分程度に収めたい
 対象データ量は、300GB弱
 DB2 → Auroraへのレプリケーション時のデータ型マッピング、キャラクタセット変換の検
討が大変
対象システム
基幹DB（派遣登録者の管理）

23. ソリューション
採用
CDC Incremental
 Attunity Replicateを使用してリアルタイムにAmazon Auroraへデータ同期
メリット
Aurora側のテーブル設計の工数削減
← Attunityで自動で作成させて結果のチェックのみとした

24. 発生した問題
1. 初回データ同期の開始時にエラーが発生し、データ同期が
開始できない
【発生原因】
DB2 9.7では、CurrentLSN値をDB2のAPIで取得できない為、Attunityでの
同期開始時にDB2のアクティブログ/アーカイブログ情報の取得に失敗し、本事
象が発生しました。
【対応内容】
同期開始前に、DB2でCurrentLSN値を調べてAttunityに設定する。
※Reload時も同様の対応が必要となります
※詳細手順につきましては、別途手順書を提示致します。

25. 発生した問題
2. resume時にエラーが発生し、タスクが再開できない
【発生原因】
Endian Typeの取得ためにアーカイブログ情報を参照しに行った際に、
前項の対応で指定したCurrentLSNに紐づくログを探して、ログが存在しない為
にエラーが発生。タスクの再開ができない。
【対応内容】
Resume時には、動的にアクティブログ/アーカイブログ情報を取得に行く必要
がないため、データベース登録情報に下記パラメータの設定を行う。
(Endian typeの扱いを固定する設定)
endianityMode = SWAP

26. 発生した問題
3. ソース側で追加したテーブルが自動で反映されない
【発生原因】
CDC中にDB2側で行った、CREATE TABLEのDDLがアクティブログに
記録されなかった為。
【対応内容】
以後、テーブル追加の際は、CREATE TABLE文にDATA CAPTURE CHANGES句
をつけてテーブル作成を行う。
※対象のテーブルについては、タスクに手動追加、全データ転送から実行で対応
した

27. 事例2 某電子書籍様
課題
 課金管理情報を使用して分析を行いたい
 課金管理DBに負荷をかけないこと
 データレプリケーションの遅延は2～3分程度に収めたい
 対象データ量は、900GB弱
対象システム
課金管理システム

28. ソリューション
 分析用にTeradataを導入、Attunity Replicateを使用してリアルタイムにデータ同期
採用
CDC Incremental

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. 発生した問題
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. 発生した問題
2. ソースDBのENUM型のカラムのデータがエラーでレプリケ
ーションできない
【発生原因】
MySQL側で、ENUM型カラムのデータに、ENUMで選択可能な値以外のデータが
登録されていた。
※MySQLでは、ver5.6より前はこのような値を登録することができる・・・
※レプリケーション時に、ENUMインデックスを参照したが、該当データの
ENUMインデックスがNULLになっていた為、エラー発生
【対応内容】
Attunity Replicateで、上記のようなデータもレプリケーション出来るように機能
追加してもらった
実際のデータとしてどのようなデータが入っているのかの確認も必要・・・

32. 発生した問題
3. Teradata側で文字列を含むPKエラーでレプリケーションに
失敗
【発生原因】
PKに含まれる文字列型の定義がNOCASESPECIFICになっていた為。
※Attunity Replicateで自動で作成された場合、デフォルトでは、
NOCASESPECIFICになる
【対応内容】
Attunity Replicateの設定の、文字列型のデフォルトの定義をCASESPECIFICに変
更した。
ターゲットDB側のテーブル定義の確認は念のためしてください

33. まとめ
データ分析基盤DBへのデータ連携にAttunity Replicateを使うと
 データ連携用のツール作成/テストの工数が削減でき、
その分、アプリケーション開発/テストに時間を費やせる
 差分データの連携が高速に行える為、鮮度の高いデータを使用する
ことが可能となる
 設定が容易な為、連携対象のテーブルの変更にも簡単に対応可能
 ターゲットDBにテーブルを自動で作成してくれるので、開発時に重
宝する
ただし、安定運用の為には・・・
 ソースDBの連携対象データにどのようなものがあるのか
 ソースDB側でどのような運用（テーブル/データ追加・削除等）がされているのか
の事前チェックが必要

34. 記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。
Copyright 2017 Insight Technology, Inc. All Rights Reserved.