<p>PLAID エンジニア/HUNTER<br>
山内 雅浩<br>
@algas</p>
<h2>概要</h2>
<p>node.js (npm) での依存性解決とパッケージマネージャを <a href="https://docs.npmjs.com/cli/shrinkwrap">shrinkwrap</a> から <a href="https://yarnpkg.com/">yarn</a> へ移行した話。<br>
<a href="https://algas.github.io/npm-to-yarn-slide">プレイド勉強会での発表資料</a> も合わせてご覧ください。</p>
<h3>対象読者</h3>
<ul>
<li>node.js で継続的に開発を行っているエンジニア</li>
<li>npm 依存関係地獄に苦しんでいる同志</li>
</ul>
<h3>結論</h3>
<p>shrinkwrap を捨てて yarn を使いましょう。<br>
ただし production に使うのはちょっと早い。<br>
執筆時点での yarn のバージョンは 0.17.10 です。</p>
<h2>shrinkwrap vs yarn</h2>
<p>(npm) shrinkwrap と yarn を比較してみましょう。</p>
<table>
<tr>
<th>項目名</th>
<th>Node.js</th>
<th>Yarn</th>
</tr>
<tr>
<td>パッケージマネージャ名</td>
<td>npm</td>
<td>yarn</td>
</tr>
<tr>
<td>パッケージファイル</td>
<td>package.json</td>
<td>package.json</td>
</tr>
<tr>
<td>パッケージ指定ファイル</td>
<td>npm-shrinkwrap.json</td>
<td>yarn.lock</td>
</tr>
</table>
<p>yarn を使う利点と欠点は以下のとおりです。</p>
<h3>PROS</h3>
<ul>
<li>インストール処理が高速かつ安定<br>
ネットワークパフォーマンス改善やオフラインモード、リトライの実装がされていてパッケージのインストールが標準の <code>npm install</code> に比べて高速かつ安定に動作します。</li>
<li>依存性解決の向上<br>
複数のパッケージで使われている同じパッケージを1つのインデックスにまとめることでインストールするパッケージ数を減らし、ディスク容量の軽減・インストール速度の向上を実現しています。</li>
</ul>
<h3>CONS</h3>
<ul>
<li>yarn 自体のインストールが必要<br>
他のパッケージよりも先に yarn をインストールしなければなりません。shrinkwrap は npm に標準装備されているのでインストールは必要ありません。</li>
<li><code>npm ls</code> と <code>yarn ls</code> の互換性がない<br>
<code>npm install</code> 済みのパッケージを確認するコマンドである <code>npm ls</code> と <code>yarn install</code> 済みのパッケージを確認する <code>yarn ls</code> に互換性がありません。<code>yarn install</code> が正常にできた環境で <code>npm ls</code> を実施しても OK と返らない場合があります。</li>
<li>yarn 自体の不具合<br>
yarn のバージョンは執筆時点で 0.x であり、正式バージョンである 1.0 以上になっていません。公開されて間もないこともあり、issue が大量に上げられていて yarn 自体の不具合に悩まされることもあります。</li>
</ul>
<h2>node パッケージの追加と削除</h2>
<p>パッケージを追加・削除する方法にはコマンドからインストールするのと、package.json に書いてからインストールする2通りの方法があります。<br>
CIなどのリモート環境では後者の方法で運用する場合もあります。</p>
<ul>
<li>
<p>npm + shrinkwrap の場合</p>
<ol>
<li>コマンドからインストール
<ol>
<li><code>npm install --save new_package</code> or <code>npm uninstall --save new_package</code></li>
<li><code>npm ls</code></li>
</ol>
</li>
<li>package.json からインストール
<ol>
<li>dependencies に new_package を追加/削除する</li>
<li><code>npm update --save</code> (危険)</li>
<li><code>npm ls</code> (失敗しがち)</li>
</ol>
</li>
</ol>
</li>
<li>
<p>yarn の場合</p>
<ol>
<li>コマンドからインストール
<ol>
<li><code>yarn add new_package</code> or <code>yarn remove new_package</code></li>
<li><code>yarn check</code></li>
</ol>
</li>
<li>package.json からインストール
<ol>
<li>dependencies に new_package を追加/削除する</li>
<li><code>yarn upgrade</code></li>
<li><code>yarn check</code></li>
</ol>
</li>
</ol>
</li>
</ul>
<p>shrinkwrap を使った場合には package.json に手動でパッケージを追加すると、それを削除した際に追従できずにエラーが発生することがありますが、yarn を使った場合に同じ作業を行っても問題が発生しません。</p>
<h2>依存関係地獄 (dependency hell)</h2>
<p><code>npm-shrinkwrap.json</code> を使うことで確かに <code>npm install</code> で同じパッケージ群をインストールすることはできるようになります。<br>
この環境に package.json への追加によって新しいパッケージを追加しようとした場合には shrinkwrap は正しく依存関係を更新できません。</p>
<p>以下の手順で依存性解決をすることになります。</p>
<ol>
<li>本体またはサブモジュールの <code>package.json</code> を更新する</li>
<li><code>npm install</code> or <code>npm update --save</code> を実行する</li>
<li>パッケージの更新に失敗する</li>
<li>1.に戻る(依存性解決できるまで繰り返す)</li>
</ol>
<p>結局、問題が解決できずに <code>npm-shrinkwrap.json</code> を削除するしかない状況に陥ることも多くあります。<br>
これが継続的に依存性問題を解決できない理由です。</p>
<h2>依存性解決できない問題</h2>
<p>node.js でデファクトスタンダードになっているパッケージ管理ツールである npm (node package manager) で依存性を解決するのが難しいという問題があります。<br>
現状では shrinkwrap という npm に標準装備されている方法を使ってインストールされるパッケージを固定(バージョン指定のスナップショット)できます。<br>
<code>npm shrinkwrap</code> コマンドでパッケージ指定ファイル <code>npm-shrinkwrap.json</code> を生成することで、他の環境で <code>npm install</code> を実行した際に(依存関係も含めて)同じパッケージがインストールされるようにします。<br>
上記で書いたとおりに shrinkwrap を使えばインストールされるパッケージを固定することはできます。しかし上述の通り、実際に運用してみると shrinkwrap ではパッケージの固定はできても、継続的な依存性解決ができるわけではないことがわかります。</p>
<h2>Yarn の不具合</h2>
<ul>
<li>production install できない<br>
<code>yarn install --production</code> が効かない。つまり devDependencies もインストールされる。<br>
https://github.com/yarnpkg/yarn/issues/761</li>
<li>postinstall を実行してない問題<br>
deep dependencies で preinstall, install, postinstall を実行できてない。<br>
https://github.com/yarnpkg/yarn/issues/2142</li>
</ul>
<h2>自作ツールの紹介</h2>
<p>緩やかに移行したい方へ <code>npm-shrinkwrap.json</code> から <code>yarn.lock</code> を生成するツールを作りました。<br>
https://github.com/algas/shrinkwrap2yarn<br>
使い方は上記リポジトリの README をご参照ください。<br>
動かなかったり不具合を見つけたりした場合には issue, PR をお待ちしております。<br>
自社の製品では~~<code>shrinkwrap.json</code> の作成フローが雑だったので~~結局使いませんでした。</p>
<h2>ハマったこと</h2>
<ul>
<li>npm でのインストールの挙動(サブコマンドの動作など)が把握できなくて、理解するまでにすごく時間がかかりました。</li>
<li>自社の node.js プロジェクトの依存性解決に手間取りました。</li>
<li>うちの package.json はいろんな処理を書きすぎじゃね？</li>
</ul>
<h2>参考文献</h2>
<ul>
<li><a href="https://shift.infinite.red/npm-vs-yarn-cheat-sheet-8755b092e5cc">NPM vs Yarn Cheat Sheet</a></li>
<li><a href="https://yarnpkg.com/en/docs/migrating-from-npm">Migrating from npm</a></li>
</ul>
<h2>まとめ</h2>
<p>今すぐ <code>shrinkwrap</code> を捨てて <code>yarn</code> と旅に(ry</p>
<h2>エンジニア募集中</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


PLAIDエンジニア 山内雅浩 @algas yarn を使って node.js の依存性解決 npm shrinkwrap と yarn との比較

まだ node.js の依存性解決で消耗してるの？ | PLAID engineer blog

まだ node.js の依存性解決で消耗してるの？

<html><head></head><body><p>こんにちは。プレイドの@monoiです。<br>
プレイドでは主に管理画面周りの開発を担当しています。</p>
<p>さて、突然ですがプレイドには最近ある課題が浮上しています。<br>
それはメンバーが増えるに伴って、コミュニケーションの機会がなかなかない人ができてしまうこと。</p>
<p>この課題には多くの会社が頭を悩ませていると思いますが、コミュニケーションと言えば何と言っても<strong>ランチ</strong>ですよね。<br>
普段の業務であまり関わりのない人でも、一緒にランチに行けばそこには<strong>深い友情</strong>が芽生えるかもしれません。</p>
<p>そんなわけで今回は、ランチメンバーをシャッフルしてグループ分けしてくれるSlackbotを、AWS Lambdaを使って作成しました。</p>
<h1 id="目次">目次</h1>
<ul>
<li>プレイドのbot紹介</li>
<li>AWS Lambdaとは？</li>
<li>作る</li>
<li>完成</li>
<li>最後に</li>
</ul>
<h1 id="プレイドのbot紹介">プレイドのbot紹介</h1>
<p>botを作る方法は様々あります。</p>
<p>プレイドにはすでに多くのおもしろいbotがいるので、これらを紹介しつつ、処理方式を検討していきます。</p>
<h2 id="はる子さん">はる子さん</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bf5fcce8-3d22-467e-b818-f7ebe5f594da/hal.png" alt=""></p>
<p>はる子さんは優秀な人事・労務管理botです。<br>
勤務時間を管理してくれたり、社員のプロフィールを教えてくれたりします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/695cb0dc-1c30-41c7-979f-d558d15b6966/----------2016-12-14-16.09.02.png" alt=""></p>
<p>はる子さんは、社内に置いてあるMacBookAirにnode.jsサーバーを立てて動かしています。<br>
以前はiBeaconを使って社員がオフィスにいた時間を把握し、自動で勤務時間を記録してくれる仕組みもありました。（リモート勤務や外出が多い社員の勤務時間をうまく取得できないため、一時休止中。）</p>
<h2 id="KARTEくま">KARTEくま</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dd9c67da-d00d-41c8-ba1a-ba8a53b73e02/cap4.png" alt=""></p>
<p>KARTEくまはCX(Customer Experience)チームをサポートするためのbotです。プレイドが提供しているサービスで、異常な数値が検出されていないか等のチェックを行っています。</p>
<p>Google App Scriptで定期実行し、SlackのIncoming Webhookを叩いています。</p>
<h2 id="karte-hubot &amp; DeployBot">karte-hubot &amp; DeployBot</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6dfe76a1-b314-4ad3-8bd4-fba5e6ab7004/deploy_bot.png" alt=""></p>
<p>日々のデプロイを補助してくれるbotです。<br>
デプロイをするのにいちいちコマンドを叩くのは面倒だ、ということで、Slack上で特定のキーワードを打つとデプロイできるような仕掛けが作られました。</p>
<p>こちらはEC2インスタンス上で動作させています。<br>
karte-hubotは名前の通りgithub社の<a href="https://hubot.github.com/" target="_blank" rel="noreferrer">hubot</a>フレームワークを使っています。</p>
<h2 id="さてどうするか。">さてどうするか。</h2>
<p><strong>完全に余計な手間ですが</strong>、まだ社内で使われていない方法で作ってみたい・・・！</p>
<p>というわけで今回は<strong>AWS Lambda</strong>で作ってみました。</p>
<h1 id="AWS Lambdaとは？">AWS Lambdaとは？</h1>
<p>FaaS（Function-as-a-Service）の一種で、AWS上に関数を置いておき、インスタンスを立ち上げることなくクラウド上でアプリケーションを実行できるサービスです。<br>
CloudWatch（定期実行）や、S3（データがアップロードされたら実行）など様々なAWSのサービスをトリガーにして実行させることができます。<br>
2016年12月現在、Node.js、Python、Java、 C#に対応しています。</p>
<p>実際に処理が行なわれている時間のみしか課金されないため、常時動かす必要のないアプリケーションとは相性がいいです。<br>
お昼の時間しか動かさない今回のbotにはうってつけですね。</p>
<h1 id="作る">作る</h1>
<h2 id="作成するbot">作成するbot</h2>
<p>ランチメンバーを募集してグループ分けしてくれる<strong>ランチくまbot</strong>。</p>
<ul>
<li>12:00に「一緒にランチに行く人募集ー！」と誘いがくる。</li>
<li>13:00に上のメッセージに対してリアクションした人を適度な人数でグループ分けする。</li>
</ul>
<h2 id="slackでBot Userを作る">slackでBot Userを作る</h2>
<p>まず https://slack.com/apps/build からBot Userを作成します。</p>
<p>作成が完了したら、登場させたいchannelにinviteしてあげましょう。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3b37bc27-bb31-4c86-8027-28ca66844a22/----------2016-12-14-18.51.08.png" alt=""></p>
<h2 id="Lambdaのsetup">Lambdaのsetup</h2>
<p>続いて<a href="https://aws.amazon.com/jp/" target="_blank" rel="noreferrer">AWSコンソール</a>からLambda Functionを作成します。</p>
<p>今回は定期実行なので、トリガーはCloudWatch Eventを使います。<br>
「平日12時」に実行の場合、CloudWatchのスケジュールは<code>cron(0 3 ? * MON-FRI *)</code>としてあげればOKです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9e584509-f549-4993-a992-083e09fd7ea7/----------2016-12-14-16.47.42.png" alt=""></p>
<p>「平日12時」のCloudWatch Eventでは<code>{"event_name": "send"}</code>を投げるようにしています。<br>
「平日13時」のEventでは<code>{"event_name": "aggregate"}</code>を投げます。<br>
event_nameによって処理内容をハンドルします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f78cd9a1-3b7b-42a7-b198-ee7ff5133f1a/----------2016-12-14-16.53.12.png" alt=""></p>
<p>また、タイムアウトまでの時間がデフォルトでは3秒になっているのですが、slackのAPIを何度か叩くので念のため10秒にしておきます。</p>
<h2 id="コードを書く">コードを書く</h2>
<p>通常通りローカルでコードを書き、その後zip化してAWSのコンソール画面からアップロードします。<br>
ブラウザ上でもちょっとしたコードを書くことはできますが、モジュールのインストールなどはローカルで行う必要があります。</p>
<p>ボタンひとつでテスト実行することもでき、デバッグも容易です。<br>
もちろんただの関数なので、ローカルでも簡単にテストできます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f963c72b-8523-4763-aef1-004a7f388a37/----------2016-12-15-2.47.08.png" alt=""></p>
<p>Lambda Function内からのみアクセス可能な環境変数をコンソール画面から設定することができます。<br>
例えばCHANNEL名をここで設定できるようにすると、再アップロードせずに投稿先のチャンネルを切り替えられるようになり、テストが非常に楽になります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c4cfced0-5cbc-4561-b729-3488edd2994f/env.png" alt=""></p>
<p>その後は<a href="https://api.slack.com/" target="_blank" rel="noreferrer">SlackAPI</a>を見ながらコードを書き進めていきます。<br>
SlackのAPIは非常に豊富でわかりやすいです。</p>
<h1 id="完成">完成</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18ed12f5-d0df-4398-842c-bd5afb093da5/cap.png" alt=""></p>
<p>まずは自己紹介から入ります。<br>
先ほど紹介したKARTEくまbotの作成者である@akobaさんからも受け入れられたようです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18f9c763-e4d4-4759-9807-54dfb60e1cc3/cap5.png" alt=""></p>
<p>12:00になるとlunchチャンネルにメッセージを投稿し、募集を開始します。<br>
よく分からないリアクションもいっぱい付いてますが、lunch_kumaは余裕で全て受け入れます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c03c1d8e-7a5e-4589-b478-7fe83421136d/cap3.png" alt=""></p>
<p>13:00になるとリアクションをしたメンバーをシャッフル、グループ分けします。<br>
いい感じにグループ分けできました！</p>
<h1 id="最後に">最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくはこちら（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
</body></html>

社内のコミュニケーションを活性化させるため、ランチメンバーをシャッフルしてグループ分けしてくれるSlackbotをAWS Lambdaを使って作成しました！

SlackbotをAWS Lambdaでサクッと作ってみた | PLAID engineer blog

ランチメンバーを自動でグループ分けしてくれるSlackbotをAWS Lambdaでサクッと作ってみた

<p>プレイドの @nashibao です。</p>
<p>弊社では結構<code>BigQuery</code>を使い倒させていただいていて、社内向けのバッチ解析や<code>ChartIO</code>/<code>ModeAnalytics</code>等を介した社外向けのレポーティングとしての利用だけでなく、ABテストなどの集計系では（Query数のコントロールのためにキャッシュは介していますが）ほぼ直接アプリケーションのバックエンドとして利用しています。</p>
<p>またStreaming Insertが思ったより安定しているので、ニアリアルタイムにイベントを反映することができ、<strong>適当なQueryを投げ込んでPBの集計を気軽にやって、数百万使って唖然としてとりあえず寝て忘れる</strong>、みたいなことをしています。</p>
<p>先日も&quot;GCP NEXT World Tour in Tokyo&quot;において、弊社 @makinoy がジョブズばりのプレゼンをさせてもらいました。</p>
<p><a href="http://blog-plaid.com/event/2642/"><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/df784d2b-d07b-4eac-b2d1-afb1e918b464/DSC00529.jpg" alt="gcp"></a><br>
<a href="http://blog-plaid.com/event/2642/">Google Cloud Platform 国内最大のイベント「GCP NEXT World Tour in Tokyo」にプレイドが登壇しました</a></p>
<p>さて、これだけBigQueryを使い込んでいる弊社ですが、仕組みについてはあまり外に出てないため、ほとんど知りません。</p>
<p><a href="http://research.google.com/pubs/pub36632.html">DremelのPaper（2010/VLDB)</a> が6年前に出ていますが、その内容としては非常に単純なQuery Processingのケースのみを扱っていて、<code>シンプルな分割統治型のツリー処理</code> と、<code>独自の省スペースかつ効率的なNested Dataのカラムナ表現</code> の二点を中心に議論されています。論文の最後でも次のように締められています。</p>
<blockquote>
<p>In the future, we plan to cover in more depth such areas as<br>
formal algebraic specification, joins, extensibility mechanisms, etc.</p>
</blockquote>
<p>後半に乗っている<code>Dremel</code>と既存の<code>Google MapReduce/Sawzall</code>（Google 社内のMapReduce実装）とのパフォーマンス比較、キレイに線形にスケールする実験結果は一見の価値があります。ただ、カラムナについて独自のエンコーディング/FBMを使ったアセンブリ手法は、これがポッと作れてしまうGoogleはさすがだなぁ、と思う反面、カラムナにしたらそりゃパフォーマンスは上がるだろうという感じだし、割となんでもござれのHDDベースのMapReduceと比較して分割統治に特化した構造がパフォーマンスが出るのも当然だろ、という気がします。</p>
<p>それよりもむしろ、<code>テラ/ペタサイズのJOINやGroup Byが入り組んだクエリが数秒~数十秒で返ってくる</code>という理解不能な事象について深掘りして欲しい気がします。つまりちょうど<code>Dremel</code>のペーパーの範囲外ですw</p>
<p><a href="https://www.amazon.co.jp/Google-BigQuery-Analytics-Jordan-Tigani-ebook/dp/B00JUUZIZI">Amazon.co.jp: Google BigQuery Analytics 電子書籍: Jordan Tigani …</a></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5438d3eb-fff3-4106-bd6e-4db25c4b588e/583ec39bdd099caa2040f48c::image.png" alt="img"></p>
<p>そしてようやく本題ですが、JOINを含めたQuery Processingについては2014年に出ているこちらの本の方が詳しいので、少し紹介したいと思います。<br>
ちなみにタイトルは（かなり）盛り気味です。</p>
<h1>先に感想</h1>
<p>いくつかポイントがあると思いますが、僕が個人的に思うBigQueryのキモは次の3点です。（ちょっと想像で物を言っているので間違ってたら、、すみませんw）</p>
<ol>
<li>まずまずDisk IOの並列化（並みの並列化じゃない）</li>
<li>スピード重視でメモリとネットワークを酷使する設計（並みの酷使っぷりじゃない）</li>
<li>Slowなところを避ける代わりに出来なきゃ死ぬ設計。やり直せばいいという割り切り（その点逆にMapReduceはすごい）</li>
</ol>
<p>Disk IOを並列化して、読込をボトルネックから解放するのはこれ系では前提感あります。それに加えてネットワークを酷使したり、Hash PartitionによるShufflingなどで、メモリオーバーでabortするリスクをとるポリシーあたりがHadoopを含めたMap Reduce界隈と違うのかな、と感じます。</p>
<h1>基本構造とベーシックなクエリ処理</h1>
<p>基本的な構造としては次のようになっているようです。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/55a1103a-d5c9-4f85-a446-1a0f8faa8ea2/583ec39bdd099caa2040f48b.png" alt="583ec39bdd099caa2040f48b.png"></p>
<p>クエリは<code>Root/Mixer/Slot</code>の順で伝播します。その時Slotのみで解決できないQuery要素に関しては排除されて伝播されます。<code>Slot</code>は実際にStorageレイヤと通信し最初の処理をする<code>Leaf Server</code>のスレッドのことのようです。そして、処理結果がSlot/Mixer/Rootの順で伝播し、それぞれ統治処理が行われます。</p>
<p>例えばJOINやGroup Byが絡まず、単純な分割統治処理のようなケースの場合</p>
<pre><code>SELECT corpus, word, word_count FROM tbl 
  WHERE LENGTH(word) &gt; 4 
  ORDER BY word_count 
  DESC LIMIT 5
</code></pre>
<p>（word_countが最初からaggregationされているという現実にはなさそうなケースですが）単純に同じQueryがSlotに伝播され、それぞれのSlotが返す結果に対してMixerが同じQueryをかければ終了です。</p>
<h1>Small Group By</h1>
<p>次のようにGroup Byがある場合も分割統治型で処理されます。</p>
<pre><code>SELECT corpus, word, SUM(word_count) AS total FROM tbl 
  WHERE ... 
  Group By corpus 
  ORDER BY total 
  DESC LIMIT 5
</code></pre>
<p>まず <code>Order</code>句と<code>LIMIT</code>句を排除してSlotに渡しクエリし、その結果をMixerに渡し、Mixerでは元のクエリをかけて終了です。ただしDistinctなKeyが多い場合メモリに乗り切らずabortします。</p>
<h1>BroadCast Join</h1>
<p>さてJoinですが、単純な場合としてJoinする片方がSlotにバラまけれるサイズであれば分割統治型の繰り返しで対応できます。（BigQueryでは <code>8mb</code>が閾値のようです）。こちらは</p>
<pre><code>SELECT hoge FROM a 
  JOIN 
    (SELECT fuga FROM b) AS c 
  ON a.hoge = c.fuga
</code></pre>
<ol>
<li>サブクエリ<code>SELECT fugue FROM b</code>のみをSlotに配布</li>
<li>Mixerに結果が返される</li>
<li>返された結果をインライン展開して、全体のクエリを配布</li>
<li>Mixerに結果が集められ、Aggregationして終了</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0f92e382-bd5f-4629-b49c-fa7a9c372f90/583ec39bdd099caa2040f48a.png" alt="583ec39bdd099caa2040f48a.png"></p>
<p>一つ面白いのは、例えば5000 Leafあれば 5000 x 8MB = 40GBのネットワークコストをかけている、というところです。</p>
<h1>Shuffled Query（Big Join/Big Group By）</h1>
<p>最後に複雑なケースとして、大規模なJOINと大規模なGroup Byのケースです。MapReduceと同じようにShuffleフェーズを組み合わせて処理をしますが、Merge Sortではなく、単純なHash Partitioningで分散します。つまり100台のLeafで処理していれば、keyに対して100でmodを取り対応する各Leafに配布します。</p>
<p>（元々は <code>JOIN EACH</code>や<code>GROUP EACH BY</code>といった特殊な句が用意されていましたが、自動で判断するようになったようなので、省きます。( <a href="https://cloud.google.com/bigquery/docs/reference/legacy-sql">Query Reference </a> )）</p>
<pre><code>SELECT hoge FROM a 
  JOIN 
    (SELECT fuga FROM b GROUP BY fuga) AS c 
  ON a.hoge = c.fuga
</code></pre>
<ol>
<li><code>b</code>に関するサブクエリをLeafに配布する。（例えば100Leaf）</li>
<li><code>fuga</code>を100個にHash Partitioning（<code>shuffle</code>）し、Leaf間でデータを交換する</li>
<li>Leafでサブクエリを実行しMixerに終了したかどうかだけを返す（データは返さない）</li>
<li>次に<code>a</code>に関するクエリをLeafに配布する（例えば500Leaf）</li>
<li><code>hoge</code>を500個にPartitionしLeaf間でデータを交換する</li>
<li>さらに3のデータも500個にPartitionし、Leaf間でデータを交換する（この処理がどこに挟まるかちょっと書いてなくて想像で書いてます）</li>
<li>Shard上でJOINのクエリを実行し、Mixerに結果を返す</li>
<li>Mixerで統合し終了</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6e7a1ef9-4119-4d18-8b8c-dba18a848b52/583ec39bdd099caa2040f489.png" alt="583ec39bdd099caa2040f489.png"></p>
<p>大きな注意としては、どでかいデータでHashが偏ると乗り切らずAbortする、という点です。</p>
<h1>最後に</h1>
<p>先に書いた感想と同じですが、割と古典的というか泥臭いやり方でShuffleを実装したりしているところ、ネットワーク/メモリを酷使し、合わないものはAbortするところなど、失敗を許容する代わりにパフォーマンスを出す設計が重要なように思います。</p>
<p>もう少しMapReduce界隈との設計思想の違いについても想いを馳せてみたかったんですが、図を作っていたら力尽きた感じがあるので、議論したい方は是非ともPlaidの社内勉強会等に来てください！</p>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit.html">プレイドの採用ページ</a>か、<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


プレイドで使い倒しているBigqueryの内部構造について徹底解剖してみました！