ablog

不器用で落着きのない技術者のメモ

Redshift の UNLOAD で1ファイルにまとめて出力する

UNLOAD コマンドで PARALLEL OFF オプションをつけると1ファイルにまとめて出力することができる。

unload ('select * from stl_query')
to 's3://redshift-unload/stl_query_' 
iam_role 'arn:aws:iam::123456789012:role/redshift-spectrum-s3-fullaccess'
header
format csv
gzip
parallel off
allowoverwrite;

参考

PARALLEL
デフォルトでは、UNLOAD は、クラスター内のスライスの数に応じて、データを複数のファイルに同時に書き込みます。デフォルトのオプションは ON または TRUE です。PARALLEL が OFF または FALSE の場合、UNLOAD は、ORDER BY 句が使用される場合はそれに従って絶対的にソートされた 1 つ以上のデータファイルに逐次書き込みます。データファイルの最大サイズは 6.2 GB です。したがって、たとえば、13.4 GB のデータをアンロードする場合、UNLOAD は以下の 3 つのファイルを作成します。

UNLOAD - Amazon Redshift

dev.classmethod.jp

Glueジョブのブックマーク

Amazon S3 入力ソースの場合、AWS Glue ジョブのブックマークではオブジェクトの最終更新日時を確認して、どのオブジェクトを再処理する必要があるのかを確認します。入力ソースデータが最後のジョブ実行以降に変更されている場合、ジョブを再度実行すると、ファイルが再度処理されます。

ジョブのブックマークを使用した処理済みデータの追跡 - AWS Glue

注意点としては、S3の場合はファイルを対象としているので、新規追加されたファイルはもちろん対象ですが、ファイルが更新された場合も対象となります。つまりファイル内の1行だけ更新がはいっても入力の対象となりETLして出力されます。つまり更新がなかった行も対象になってしまいます。ですので、ブックマーク利用時は基本的には過去のファイルの更新が行わない使い方が望ましいと思います。

Glueの使い方的な④(ブックマーク) - Qiita

Oracle Database の待機イベントの歴史

Oracle Database の待機イベントは version 7.0 (1991-1992年頃)で初めて実装された。元々は開発チームがベンチマークボトルネックを特定するために実装されたものだった。 Juan Loaiza によると、Mark Porter も関わっていて、主に Keshevan Srinivasan が実装したらしい。Mark Porter は少し前まで AWS の RDS のサービス(開発)チームにいて、AWS Summit Tokyo で Aurora PostgreSQL 互換について講演したりもしています。1999年に Anjo Kolk が YAPP(Yet Another Performance Profiling Method)を発表し、2000 年に Oracle Magazine で紹介され広く使われるようになったようです。 により一般に待機イベントを使ったパフォーマンス分析が行われるようになった。

Oracle Insights: Tales of the Oak Table (Oaktable)

Oracle Insights: Tales of the Oak Table (Oaktable)

  • 作者:Ensor, Dave
  • 発売日: 2004/07/28
  • メディア: ペーパーバック
P.76

Correct Instrumentation Is Key
In the mid 1980s realized that no matter how many counters and ratios they looked at. it was still pure guesswork (hence luck or thereof) whether a person managed to identify and remove the correct (in other words, the biggest) bottleneck of a given application or business unit.
So they instrumented the whole mainframe environment, including DB2, MVS(later OS/390, at present z/OS), and other components. The instrumentation aimed at providing time-based measurements on the session level, and proved so powerful that today, many years later, it's possible to predict within a very small margin what, say, a CPU-upgrade will mean in terms of response time for each application.


FUN FACT The DB2 database code for AIX and Windows were written by different teams with little or no contact to the mainframe coders. Consequently, DB2 on AIX and Windows are not instrumented. Amazing, sad and true.


Around 1991 or 1992 Juan Loaiza and others from Oracle development were forced to instrument the Oracle kernel in the same way. Here's the story, as told to tribute to one of the truly great minds inside Oracle Development.


I think what you are referring to are the wait statistics that were implemented in 7.0. This stuff was developed because we were running a benchmark that we could not get to perform. We had spent several weeks trying to figure out what was happening with no success. The symptoms were clear -- the system was mostly idle -- we just couldn't figure out why.


We looked the statistics and ratios and kept coming up theories, the module was that none of them were right. So we wasted weeks tuning and fixing things that were not the problem. Finally we ran out of ideas and were forced to go back and instrument the code to figure out what the problem was.


Once the waits were instrumented the problem was diagnosed in minutes. We were having "free buffer" waits because the DBWR was not writing blocks fast enough, It's amazing how hard that was to figure out with statistics, and how easy it was to figure out once the waits were instrumented.

The "credit" for this should go to a number of people. I remember that Mark Porter was involved, and Keshevan Srinivasan did most of the actual instrumentation of the code. There were probably others involved but it has been so many years that I don't remember it clearly anymore.


(中略)

It is worth noticing that if any of numerous suggestions from "Guess&Grimacing" sessions held in Oracle Development had helped, the instrumentation of the kernel may never have taken place.
In the mid 1990s Anjo Kolk invented the YAPP method(as he describes in Chapter 4). In the process, he became the first human on Earth to take full advantage of the instrumentation


f:id:yohei-a:20200723194540p:plain
OWI(Oracle Wait Interface)の概要(PDF) | 日本エクセム//データベース, アプリケーションサーバーの見える化で効率化 インフラエンジニアを応援

Oracle Database の SQL トレースの歴史

Oracle Database の SQL トレースは最初は version 5(1986年リリース) で開発者のデバッグのために実装されました。version 5 では undocumented で not supported な機能でしたが、version 6 から documented でユーザーが使える機能になりました。


以下は、2014年頃に @kouji_s_0808 さんに飲んでるときにオススメの本を聞いたら「10年くらい前に読んだ本だけど面白いですよ」と教えてもらった Oracle Insights からの引用です。文中に登場する Juan LoaizaSQL トレースが最初に実装された頃は Oracle kernel のアーキテクトで、現在は Oracle Corporation の Executive Vice President です。

Oracle Insights: Tales of the Oak Table (Oaktable)

Oracle Insights: Tales of the Oak Table (Oaktable)

  • 作者:Ensor, Dave
  • 発売日: 2004/07/28
  • メディア: ペーパーバック
P.164

The History of SQL Trace
Let me switch gears for a while and tell the story of Oracle's SQL trace feature, which would eventually become the extended SQL trace feature used today. The Oracle extended SQL trace feature exists today because, fortunately, Oracle customers aren't the only ones who have to wrestle with Oracle application performance problems. The men and women who build the Oracle kernel fight the same problems too, both in customer situations and in competitive benchmarks. The following quote is from Juan Loaiza, an Oracle kernel architect, and at the time of this writing a vice president at Oracle Corporation(you can read the full story in Chapter 2, where Juan tells of the motives for inventing SQL trace and then extending it to the state in which we know today):


I've always thought that diagnosing performance issues boils down to figuring out where the time is going in the system. If you can attribute the time correctly, then the source of the problem becomes obvious

Certainly our professional community is indebted to Juan Loaiza and his team for giving us the microscope to see how the Oracle kernel is spending all of our user's time.


Version 5

SQL trace is least as old as Oracle version 5, which was released in 1986. The syntax to turn it on and off was simple:

select trace('sql', 1) from dual
select trace('sql', 0) from dual

Apparently, not too many people knew about SQL trace in Oracle version 5, and probably fewer than that actually used it. In an old Oracle internal document called "Optimizing", Oracle described the trace function as follows (quoted verbatim from source):

The Kernel provides a trace function to provide information about internal operations.
The trace function is essentially a debug aid for Software Development

-- It is not documented.
-- it is not supported.
-- [It] will not be a function in ORACLE version 6.


(中略)

Version 6
In Oracle version 6, SQL tracing become a core, documented feature for everyone to use. In version 6, Oracle introduced the syntax that also works in 7, 8, 9, and 10:

alter session set sql_trace=true
alter session set sql_trace=false

80年代後半から90年代の estat/bstat の変更履歴にも jloaiza という名前が残っています。

Oracle Database Connect 2016Oracle ACE の id:wmo6hash さんと @discus_hamburg さんが「Japan Oracle User Group代表者が開発責任者に聞くOracleテクノロジーの今後」というトークセッションで Juan Loaiza に直接質問するという歴史的なワンシーンも有りました。
f:id:yohei-a:20200723182747j:plain

VLDB 2015 で Juan Loaiza が Exadata の話をしている動画などもあります。

1つの Lambda 関数に いくつの SQS から Lambda トリガーとして設定できるか

1つの Lambda 関数にいくつの SQS から Lambda トリガーとして設定できるか。特に意味はない。

for i in {1..1000}
do
	sqs_url=`aws sqs create-queue --queue-name LambdaQueue$(printf "%03d" ${i}) | jq -r '@text "\(.QueueUrl)"'`
	sqs_arn=`aws sqs get-queue-attributes --queue-url ${sqs_url} --attribute-names QueueArn | jq -r '@text "\(.Attributes.QueueArn)"'`
	aws  lambda create-event-source-mapping --event-source-arn  $sqs_arn --function-name sqsTriggerFunction
done


f:id:yohei-a:20200717125221p:plain

1000 以上設定しても、マネジメントコンソール上は 1000 と表示される。

$ aws lambda list-event-source-mappings --function-name sqsTriggerFunction|jq -r '.EventSourceMappings[]|@text "\(.EventSourceArn)"'|wc -l
1489

検証のため S3 バケットへの Put を禁止したバケットポリシー

検証のため S3 バケットへの Put を禁止したバケットポリシーのサンプル。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "deny-put",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::aurora-postgres-activity-stream",
                "arn:aws:s3:::aurora-postgres-activity-stream/*"
            ]
        }
    ]
}