TreasureDataのデータリカバリを考える
2104 ワード
不幸な事故により、td-agentでデータを二重に転送してしまった。自分が雑な対応したせいなんですが。
やってしまったものは仕方ないのでリカバリを考える。
treasuredataは指定の条件でレコードを削除ということはできず、１時間ごとのデータ削除である、table:partial_deleteとかいうのがあるっぽいのでこれを使う。
article_impressions テーブルフルバックアップ
td table:export prod_database article_impressions \
--s3-bucket dump-bucket \
--prefix article_impressions/20160721 \
--aws-key-id $AWS_ACCESS_KEY \
--aws-secret-key $AWS_SECRET_ACCESS_KEY \
--file-format json.gz
指定期間レコードを重複除去して抽出
SELECT
DISTINCT pi.time,
pi.application_id,
pi.uuid,
pi.media_id,
pi.placement_id,
pi.article_id,
pi.url,
pi.recommend_article_id,
pi.priority,
pi.manual_priority,
pi.referer,
pi.ua,
pi.device,
pi.lang,
pi.remote_ip_address,
pi.similarity,
pi.manual_similarity,
pi.default,
pi.table_name,
pi.__tag
FROM
article_impressions pi
WHERE
td_time_range(pi.time,
'2016-07-16 00:00:00',
'2016-07-20 17:00:00',
'JST')
ORDER BY
pi.time
JST16日00時〜20日17時のデータを削除
td table:partial_delete uzo_production article_impressions \
--from '2016-07-16 00:00:00 JST' \
--to '2016-07-20 17:00:00 JST'
抽出データを再インポート
td import:auto \
--format csv \
--column-header \
--time-column time \
--auto-create uzo_production.article_impressions \
/Users/tsuruta/77048484.csv
もうやらないように気をつけようと思いつつもばっちりメモ
Author And Source
この問題について(TreasureDataのデータリカバリを考える), 我々は、より多くの情報をここで見つけました https://qiita.com/katsut/items/f4b3de551f2fda4647de著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .