Treasure Data に「date
」というカラム(スキーマ)を持つテーブルが存在していて、そいつを Hive のクエリで検索しようとしたらうまくいかずに悩んでいた。
% td query -d DB -w -P high "SELECT date FROM table LIMIT 10"
td table:show
でテーブルの情報を見ても、date
というスキーマは定義されていたし、なんでこのクエリが失敗するのかが最初は理解できなかった。
で、「Apache Hiveにハマり続けている毎日 01:23」という記事を見つけて解決。date
も Hive の予約語に含まれるので、バッククォートで括れば良いとのこと。
ということで、こういうクエリにすることで解決した。バッククォートにバックスラッシュを付けているのは、シェル用のエスケープであって、クエリでは「`date`」とするのが正しい。
% td query -d DB -w -P high "SELECT \\`date\\` FROM table LIMIT 10"
ちなみに、Presto でのクエリでは、このエスケープは不要だった。エスケープ以外のクエリは、Hive の場合とほぼ同じ(この例は単純だからね)で、このようになる。
% td query -d DB -w -P high -T presto "SELECT date FROM table LIMIT 10"
しっかし、Presto は速いな。初回のクエリでは時間がかかったけど、これは、たぶん、Treasure Data 側でテーブルのデータをメモリに読み込む処理が走ったからだと思う。それが終わった二回目以降のクエリは超絶速い。さすがインメモリ・データベースだ。
コマンドを叩いた瞬間は、ほんの少しだけ起動処理で待たされるけど、結果が出るのは本当に一瞬。これは、いわゆる「ライフ・チェンジング」な代物だね。今までの Hive での使い方とは全く違う考え方で利用すべきだと思う。これはヤバイよ、ヤバイ。
「大量のデータの中から意味のあるデータを探し出す」という行為では、いろいろなクエリを試行錯誤で叩いてみるという作業が必要なわけだけど、Presto のこの反応性の良さは、この行為にぴったりマッチする。
オレ自身は、まだそこまでデータ分析能力があるわけじゃないので、多角的な視点でのクエリを叩ける訳じゃない。でも、この「待ち時間が減る」ということで、何度もいろいろ試せるようになるのはありがたい。
いやー、なんかひさびさにシビれる技術に触れたなぁー。これを簡単に使える Treasure Data のサービスも素晴らしい。
この日記を書いているときに、改めて前述の記事を読んだら、ちゃんと Treasure Data の FAQ に Hive の予約語のことが書かれていた。
ドキュメントはそれなりに読んでいるんだけど、まだまだ抜けている知識はあるし、身についていないなぁ。