Notes on Snowflake’s new paper: Building an Elastic Query Engine on Disaggregated Storage
概要
- ストレージ-メモリ-CPUの分離は最近のコンピュータアーキテクチャのメインテーマだ
- この3つを分離すれば、過大なプロビジョニングをすることなく、それぞれのスケールを達成できる
<中略>
- 1.イントロダクション: 既存のソリューションの問題
- Shared Nothingアーキテクチャでは、過剰なリソースが確保されてしまう
- ノードを追加したときに高コストなreshufflingが必要になる
- 2.デザイン
- Computeノードの、SSDとメモリを合わせてEphemeral Storageと呼び、中間データの置き場所とする
- 4.ストレージアーキテクチャ
- 6. リソースの柔軟性
- マルチテナンシー
- EC2が時間単位の課金から秒単位の課金になったことで、スタンバイノードのプールは、高くつくようになった(なぜかはよくわからない)
- そのため、顧客間でノードを共用するモデルに移行したほうがよい感じになった
- ある顧客のVirtual Warehouseの使用率が低い時、ノードを共有する別のVWが余ったCPU/メモリを使えるようにするのは理にかなっている
- SNOW社はさらに、複数テナントを同一VWに入れられるようにしたいと考えているが、その実現にはこんなチャレンジがある:
- テナント間の独立性を維持したEphemeral Storageのデザインをどうするか
- 誰かがノードを追加したとき、Lazy consistent hashingにより、関係ないテナントまでキャッシュを失ってパフォーマンス低下してしまう
語彙
- leverage: (利益を得るために)利用する
- future direction: 今後の方向性
- make sense: 意味がある。理にかなう
Teradata Table Skew Insight – how it can be misleading
Teradata Table Skew Insight - How It Can Be Misleading | DWHPRO
概要
- Teradataのskewには2種類ある
- PIの問題によるデータ件数の偏り
- 保存されているデータサイズによる偏り
- dbc.tableSizeVの集計では、(PIの問題によるデータ件数の偏りを検出できないので)6割程度のskewしか検出できない
- 例えば、TBBLCが有効な環境の場合、アクセスの多いシリンダだけが未圧縮のままになり、あとは圧縮されるので、件数が全AMPで均一であっても、Diskの使用量にはばらつきが出ることがある
- データ件数の偏りは、HASHAMP/HASHBUCKET/HASHROW関数を組み合わせて、AMPごとのデータ件数をカウントして検出することができる
- TBBLCを使うなら、skewを避けるために、自分のデータがどんな感じでアクセスされているかを、前もって知っておく必要がある
語彙
- uniform: 均一な。
Wolff Responds: Communists Then vs Proud Boys Now
概要
- 1945以降の共産主義者と、いまのプラウドボーイズを比較したい。
- 共産主義者は、戦後突然demonizeされた。
- 大恐慌の1930年代、共産主義者はNew Deal Coalitionの主要メンバーだった。
- 第二次世界大戦では、アメリカとソ連は同盟国であり、アメリカ共産党は同盟を忠実に支えていた。
- 1945年にすべてが変わった。共産主義者はFBIに仕事を追われ、逮捕され、投獄された。マッカーシズムの時代である。
- この迫害の時代は、2015年まで、70年間続いた。
- 共産党員であれば、政府に暴力革命を支持する者であると見なされ、逮捕・投獄される。
- 重要なポイントは、そんな共産党も、プラウドボーイズのようにアメリカ合衆国議事堂を襲撃したことはなかった、ということ。
- 議員や警官を脅したり殺したりしない左派に対する我々の対応がこれほど過酷なのに、暴力による政府転覆を公言する右派に対して、我々は何をしているのか?
語彙
- underscore: [名]アンダースコア。[動]アンダーラインを引く。
- loyal: 忠実な。
- royal: 王室の。
- hound: [名]猟犬。[動]猟犬で狩る。転じて、しつこく追い回す。
- persecution: 迫害。
- deport/deportation: 国外追放/国外追放する。
- be caught up: 巻き込まれる。
- guilt by association:「関係者なので同罪」という非論理的・感情的主張。
- overthrow: (政府などの)転覆。
- onslaught: 猛攻。slaughter(屠殺/する)と関係あるのだろうか?
Understanding the Political Scenario of INDIA,CANADA,JAPAN,CHINA,USA, FRANCE etc (1)
www.youtube.com
旧ソ連からカナダに亡命したジャーナリスト、Yuri Bezmenovによる講演、というかヨタ話。
概要
- ハリウッド映画に出てくるKGBのスパイは、マイクロフィルムを盗んだり橋を爆破したりしているが、そういうのはリアルな活動のせいぜい15%。残りの85%はSubversion(社会的・文化的な破壊活動)である。
- Subversionは西側諸国では違法行為にあたらない。
- Subversionは双方向である。相手が破壊されたがっていない限り、破壊は成功しない。例えばソ連は破壊できない。closedだから。
- Subversionを最初に理論化したのは孫子である。
- 「国家戦略を実現する上で、戦争は最低の方法である。最高の方法は、まったく戦うことなく、敵国のvalueを破壊することである」
- Subversionは4段階からなる。
- 第1段階はdemoralization.
- 人がパーソナリティや価値観を形成するだけの時間、15~20年かけて1世代のモラルを骨抜きにする。
- 「西側の退廃的な文化は全部ソ連の影響だというのか?」と聞かれることがあるが、そういう話ではない。
- demoralizationは柔道ストラテジーだ。敵が自分より大きくて重い時、パンチを正面から受け止めることはできない。代わりにパンチの腕をつかんで、その勢いを利用して壁に叩きつければよい。
- ターゲットが自由主義の場合、そこには多様なムーブメントがある。当然、反社会的勢力も居る。敵の社会が壊れるか危機に陥るまで、それらの勢力を援助すればよい。
- demoralizationの対象は6つ。1)宗教 2)教育 3)社会生活 4)権力構造 5)労使関係 6)法と秩序
Teradata Rollback – Abort as an Emergency Solution
Teradata Rollback - Abort As An Emergency Solution | DWHPRO
概要
- 大量のロールバックはCPUを大量に使うので、システムのパフォーマンスを悪化させる。
- ロールバック対象のテーブルは長時間ロックされる。何日もロックされっぱなしになった事例を知っている。
- (トランザクションをアボートする際に)ロールバック処理を回避する方法は
- 大量の行を削除するならMultiloadを使う。MultiloadはTJを使わないから
- 空テーブルに対して複数のinsert into ... select ... を発行するなら、マルチステートメントにするとTJが使われない
- ロールバックを強制終了すれば、対象のテーブルはinconsistentなままになるのだから、強制終了していいのは 1)終わるのを待つより、リストアしたほうが早いとき 2)対象テーブルが再作成できるワークテーブルのとき
- ロールバックの強制終了方法:
語彙
- middle ground: 中立。中道。
- it renders the affected table unusable: 対象テーブルを使用不可にする。render+O+Cで「OをCにする」。
Prioritizing Your People with Randy Wigginton of Square | Snowflake Inc. (1)
概要
- (どうやってAppleでのキャリアを始めたの?)
- 13歳のときにプログラミングを習って、コンピュータが欲しくなったんだけど、当時は高価で冷蔵庫ぐらいのサイズがあって...
- いろいろ調べたらスタンフォードにコンピュータを自作するサークルがあって、友達に運転させてサークルに顔を出してたんだけど
- その友達がもう運転したくないって言うので、サークルで誰か僕を送迎してくれないかって聞いたら
- スーパーナイスガイのスティーブ・ウォズニャックが運転してくれるようになった。Apple創立の数年前だ
- 私はAppleの最初のプログラマだった。5時に起きて会社で何時間か仕事して、それから高校に行って授業を受けて、そのあとまた会社に行って仕事をした
- ジョブスに呼ばれてMacintoshのプロジェクトでワープロのプログラムを書いた。ワイルドな経験だった。ラッキーだった
- (世界を変えるようなイノベーションを起こすのに必要なものは?)
- 1)original idea 2)great peopleを雇うこと 3)細部へのこだわり。Apple, Square, Snowflakeにはそれがあった
Cloud Data Warehouse Benchmark Redshift vs Snowflake vs BigQuery (3)
概要
- まずパフォーマンスの比較。
- 結果は(BigQueryがちょっと速いが)3つともあまり変わらなかった。
- 「3つとも変わらない」ということは我々のベンチマークがまともなものであったことのサイン。
- 次にコストを比較した。
- Snowflake, Redshiftは時間課金なので単純だが、BigQueryはクエリに課金するのでトリッキー。
- うちの顧客のデータウェアハウスを調べたら、稼働時間中にクエリを実行している割合はわずか20%だった。
- この20%という数字を使って、Snowflake/Redshiftの料金をBigQuery風の課金体系に変換して比較すると、BigQueryが他の2倍ぐらい高価だった。
- これは、BigQueryは止めなさいということではない。あなたの会社のデータウェアハウスが一日の8割の時間でクエリを実行するのであればBQは向いていない、逆に一日の5%しかクエリを流さないのであればBQは最高の選択、という話。
- Snowflake, Redshiftは時間課金なので単純だが、BigQueryはクエリに課金するのでトリッキー。
- AmazonがRedshift vs BigQueryのベンチマークを公開しているが、当然Redshiftの圧勝という結果だった。
- Redshiftのクラスターが巨大だから... これは高価なはず。
- 我々より前に、Periscopeも3製品の比較をしている。
- Taxiベンチマーク。これは非正規化された単一の超巨大テーブルへのクエリを使っている。
- ベンチ取った人は、そういうのがDWHの理想的なシナリオだと思っているとのこと。
- 大事なことは使いやすさ。いまのRedshiftはこの点であとの2つに劣っている。