12 »

カテゴリー: ユニケージ

混ぜるな危険!? ユニケージとxonshの融合

Pocket

はじめに

こんにちは清水です!
この記事は、Xonsh Advent Calendar 2018 – Qiitaの6日目の記事です。

ユニケージとは

個人的な解釈ですがawkで頑張らずともユニケージコマンドを使用することで比較的楽にshell芸ができます。

一例ですがこんなことができます。

cat test.txt

1 2	cat test.txt

shimizu nagano python
kondo kanagawa java
saito kanagawa python
maeda tokyo c
kojima aichi ruby

shimizu nagano python

kondo kanagawa java

saito kanagawa python

maeda tokyo c

kojima aichi ruby

このファイルの2列目の値だけ欲しい。
awkで書くとこんな感じ。

cat test.txt | awk '{print $2}'

1 2	cat test.txt \| awk '{print $2}'

ユニケージコマンド(self)を使用するとこのようにかけます。

cat test.txt | self 2

1 2	cat test.txt \| self 2

僕はまだユニケージ初心者なのでより詳細な情報は以下の記事を参照してください。

xonshとは

Pythonで作られたクロスプラットフォームのUnixライクなシェル言語とコマンドプロンプトです。
Pythonの対話モードとUnixコマンドが合体したみたいなものです。

個人的にshellなるべく書きたくないマンなのでPythonで書けるのは衝撃でした。

pipで入ります。使用するときはターミナルでxonshと打つと起動します。

pip install xonsh

1 2	pip install xonsh

例

$ files = $(ls).split()                                     
$ print(files)
['Applications', 'CRM', 'Desktop', 'Documents', 'Downloads', 'Library', 'Movies', 'Music', 'Pictures', 'Public', 'Users', 'go', 'iCloud', 'Drive（アーカイブ）', 'path', 'pict', 'test.txt']

$ files = $(ls).split()

$ print(files)

['Applications', 'CRM', 'Desktop', 'Documents', 'Downloads', 'Library', 'Movies', 'Music', 'Pictures', 'Public', 'Users', 'go', 'iCloud', 'Drive（アーカイブ）', 'path', 'pict', 'test.txt']

ライブラリも使用できます

$ import pandas as pd
$ df = pd.read_csv('test.csv')
$ df                      
   id            name      from
0   1         shimizu    nagano
1   2           kondo  kanagawa
2   3  saito kanagawa       NaN
3   4           maeda     tokyo
4   5          kojima     aichi

$ import pandas as pd

$ df = pd.read_csv('test.csv')

$ df

id name from

0 1 shimizu nagano

1 2 kondo kanagawa

2 3 saito kanagawa NaN

3 4 maeda tokyo

4 5 kojima aichi

詳しくはこのアドベントカレンダーのリーダーである@vaaaaanquishの記事をご覧ください。

Pythonistaに贈るXonshのススメ

今回紹介すること

今回は謎技術ユニケージとxonshを組み合わせた「ひょっとしたら、これ使えるかもしれない(笑)」的なものを紹介していきます。

selfとのコラボ

先ほど使用したselfコマンド。このコマンドはawk '{print $1 $3}'のように出力したいフィールドを指定することでそのフィールドを表示します。

$ cat test.txt                                                                                                         
shimizu nagano python
kondo kanagawa java
saito kanagawa python
maeda tokyo c
kojima aichi ruby

$ cat test.txt | self 1 3
shimizu python
kondo java
saito python
maeda c
kojima ruby

$ cat test.txt

shimizu nagano python

kondo kanagawa java

saito kanagawa python

maeda tokyo c

kojima aichi ruby

$ cat test.txt | self 1 3

shimizu python

kondo java

saito python

maeda c

kojima ruby

xonshと組み合わせる

lang = $(cat test.txt | self 3).split()
print(lang)
['python', 'java', 'python', 'c', 'ruby']

lang = $(cat test.txt | self 3).split()

print(lang)

['python', 'java', 'python', 'c', 'ruby']

いつ使うかよくわかりませんが、まぁ便利そう(pandas使ってもいいんですけどね)

殺人的なワンライナーも書けます。

$ user = {i.split()[0]: i.split()[1] for i in $(cat test.txt | self 1 3).split('\n')[:-1]}                             $ user
{'kojima': 'ruby',
 'kondo': 'java',
 'maeda': 'c',
 'saito': 'python',
 'shimizu': 'python'}

$ user = {i.split()[0]: i.split()[1] for i in $(cat test.txt | self 1 3).split('\n')[:-1]} $ user

{'kojima': 'ruby',

'kondo': 'java',

'maeda': 'c',

'saito': 'python',

'shimizu': 'python'}

mdateとのコラボ

こののコマンドは開始日から終了日を全てスペース区切りで表示します。
mdate -e <開始日(yyyymmdd)> <終了日(yyyymmdd)>

# 2018年の12月の日付を全て出す
$ mdate -e 20181201 20181231
20181201 20181202 20181203 20181204 20181205 20181206 20181207 20181208 20181209 20181210 20181211 20181212 20181213 20181214 20181215 20181216 20181217 20181218 20181219 20181220 20181221 20181222 20181223 20181224 20181225 20181226 20181227 20181228 20181229 20181230 20181231

# 2018年の12月の日付を全て出す

$ mdate -e 20181201 20181231

20181201 20181202 20181203 20181204 20181205 20181206 20181207 20181208 20181209 20181210 20181211 20181212 20181213 20181214 20181215 20181216 20181217 20181218 20181219 20181220 20181221 20181222 20181223 20181224 20181225 20181226 20181227 20181228 20181229 20181230 20181231

xonshと組み合わせる

$ date_list = $(mdate -e 20181201 20181231).split()
$ print(date_list)                                                                                                     
['20181201', '20181202', '20181203', '20181204', '20181205', '20181206', '20181207', '20181208', '20181209', '20181210', '20181211', '20181212', '20181213', '20181214', '20181215', '20181216', '20181217', '20181218', '20181219', '20181220', '20181221', '20181222', '20181223', '20181224', '20181225', '20181226', '20181227', '20181228', '20181229', '20181230', '20181231']

$ date_list = $(mdate -e 20181201 20181231).split()

$ print(date_list)

['20181201', '20181202', '20181203', '20181204', '20181205', '20181206', '20181207', '20181208', '20181209', '20181210', '20181211', '20181212', '20181213', '20181214', '20181215', '20181216', '20181217', '20181218', '20181219', '20181220', '20181221', '20181222', '20181223', '20181224', '20181225', '20181226', '20181227', '20181228', '20181229', '20181230', '20181231']

split関数がいい感じにスペース区切り文字列を分割してくれるので20181201から20181231までのリストを生成できます。これは割と使えるのでなないかと個人的に思っています

dayslashとのコラボ

説明するよりも見た方が早いです。

$ echo 20181206 | dayslash yyyy/mm/dd  1                                                                               
2018/12/06

$ echo 20181206 | dayslash yyyy/mm/dd 1

2018/12/06

いい感じに/を入れてくれます。 1はフィールド指定です。

xonshと組み合わせる

$ slash_date = []                                                                              
$ for date in date_list: 
.......     slash_date.append($(echo @(date) | dayslash yyyy/mm/dd 1))
$ print(slash_date)                                                      
['2018/12/01\n', '2018/12/02\n', '2018/12/03\n', '2018/12/04\n', '2018/12/05\n', '2018/12/06\n', '2018/12/07\n', '2018/12/08\n', '2018/12/09\n', '2018/12/10\n', '2018/12/11\n', '2018/12/12\n', '2018/12/13\n', '2018/12/14\n', '2018/12/15\n', '2018/12/16\n', '2018/12/17\n', '2018/12/18\n', '2018/12/19\n', '2018/12/20\n', '2018/12/21\n', '2018/12/22\n', '2018/12/23\n', '2018/12/24\n', '2018/12/25\n', '2018/12/26\n', '2018/12/27\n', '2018/12/28\n', '2018/12/29\n', '2018/12/30\n', '2018/12/31\n']

$ slash_date = []

$ for date in date_list:

....... slash_date.append($(echo @(date) | dayslash yyyy/mm/dd 1))

$ print(slash_date)

['2018/12/01\n', '2018/12/02\n', '2018/12/03\n', '2018/12/04\n', '2018/12/05\n', '2018/12/06\n', '2018/12/07\n', '2018/12/08\n', '2018/12/09\n', '2018/12/10\n', '2018/12/11\n', '2018/12/12\n', '2018/12/13\n', '2018/12/14\n', '2018/12/15\n', '2018/12/16\n', '2018/12/17\n', '2018/12/18\n', '2018/12/19\n', '2018/12/20\n', '2018/12/21\n', '2018/12/22\n', '2018/12/23\n', '2018/12/24\n', '2018/12/25\n', '2018/12/26\n', '2018/12/27\n', '2018/12/28\n', '2018/12/29\n', '2018/12/30\n', '2018/12/31\n']

date_listから受け取ったdateをdayslashで/を入れてslash_dateに格納します。\nが入ってしまうのは勘弁。

Jupyter Notebookで使用する

いつものようにJupyter Notebookを使用して新規ファイルを作成しようとしたら,Xonshが入っていることに気付く。
どうやらpip install xonshするだけでJupyterのカーネルに追加されるそうです。

ユニケージコマンドは果たして使用できるのか?

実行できた！どうやらローカルのコマンドも使用できるようです。

ちなみにGoで作成したコマンドも使用できました。

Pocket

GolangでDynamoDB CLIを書く話

ユニケージ
2017年12月4日
KurashimaWataru

Pocket

gopherくん

こんにちは。クラシマです。
ハンズラボ Advent Calendar 2017 4日目の記事です。

もう随分前になりますが、井上がGolang製のDynamoDB用のCLIを探していたことがありました。

ネットストアのセールに向けて行った負荷対策について/ハンズアラボエンジニアブログ

結局見つからなかったのでNode.jsで井上本人が書き、現在もECサイトの本番環境で使っています。
↓それがこちらのbikkeです。
https://github.com/inouet/bikke

10月末くらいから趣味プロジェクトでGolangを書いていたのですが、
井上の記事を思い出したのでDynamoDB用のCLIを書くことにしました。
できあがったものが↓これです。
https://github.com/watarukura/gody

# AWSプロファイルはstg
# itemテーブルからGSI:jan-indexのパーティションキー:janに4937751121103を指定でqueryする
# 出力はヘッダ付きで空白区切りテキスト(ssv)とし、出力するフィールドはjanとnameに絞る
gody query \
--profile stg \
--table item \
--pkey 4937751121103 \
--index jan-index \
--format ssv \
--header \
--field jan,name
=>
name jan
つぼキーク 4937751121103

# AWSプロファイルはstg

# itemテーブルからGSI:jan-indexのパーティションキー:janに4937751121103を指定でqueryする

# 出力はヘッダ付きで空白区切りテキスト(ssv)とし、出力するフィールドはjanとnameに絞る

gody query \

--profile stg \

--table item \

--pkey 4937751121103 \

--index jan-index \

--format ssv \

--header \

--field jan,name

name jan

つぼキーク 4937751121103

自分でCLIのツールを書くのは初めてなので三歩進んで二歩下がりながら進めています。
個人的にJSONを手で書くのが苦痛なので、JSONをオプションに使わない、というのがコンセプトです。
まだlist/get/query/scanしかできないので、put/update/deleteができるようになったら本番環境で使えないか検証したいところです。
put/updateのオプションをどうするか、今も悩んでいます。
テストもあまり書けてないですし・・・。
趣味プロジェクトから業務プロジェクトに反映するにはもう少し時間がかかりそうです。

Golang、いいですね！
低レイヤーの知識がないと速いプログラムが書けない、というところも魅力です。
日頃はPHPを書いていて、ポインタやバッファを気にすることはなくて、この辺りの扱いはさっぱりです。
今のところも並行処理的な機能をほぼ使ってないので、速くなる余地が随分残っている気がします。
あとは、JSONの扱いが楽なのがモダンな言語という感じがします。
弊社、ユニケージ開発により大量のBashスクリプトが稼働していますが、JSONの扱いは特に困るところです。
DynamoDBをデータストアの1st Choiceにするプロジェクトはそれなりにあるので、
そこでJSONを経由せずにDynamoDBを扱えるようになると、楽ができる部分は結構増えます。
ECサイト以外でも、ハンズラボ全体で使えるツールになるといいなぁと夢想しています。

AWS LambdaのGolangサポートも発表されましたし、今後ますますGolangを使うシーンが増えそうです。
折よく、開発に使っていたGoLandも販売開始になりました。
PHPStormユーザがGolangを書くならGoLandで決まりですね！

ハンズラボ Advent Calendar 2017 の5日目は、青木さんです。

Golangの学習には以下の書籍とサイトに大変お世話になりました。
この場を借りてお礼申し上げます。

スターティングGo言語
通勤路で読むのにちょうどよい内容でした。コラムでGolangのポインタについて「C言語との互換性のためにある」という見解で、使わなくても書けそうだなーと気が楽になりました。
Treasure 2017 の研修資料は Go を学ぶのに最高だった
GASでSlackBotを書く趣味プロジェクトが一段落して次を探していたときに、こちらの記事を読んでGolangの学習を始めました。
Go入門　Treasure2017版
A Tour of Goに挫折していたのでこのスライドを見て再挑戦でした。ajito.fmに出てるsuzukenさんだ！と気づいたのはちょっと後になってからです。
Go言語でAWSのサービスを使ってみる ~SQS・DynamoDBを試す~
aws-sdk-go、扱いが辛そうで躊躇していたところ、こちらの記事記載のaws-sdk-go-wrapperをみてwrapper-wrapperなら書けそう！と思えました。
GoでAWS SDKを叩くCLIツールを作ってリリースするまでの流れ(aws-sdk-go+cobra+viper+gox+ghr)
flagパッケージだけではサブコマンドのあるCLIを作るのは辛そうだったので、こちらの記事を読んでCLIフレームワークにcobraを使いました。
Golangのコマンドライブラリcobraを使って少しうまく実装する
テスト書いてないまま「テスト駆動開発」を読んでいて不安が増してきたため、テストの書き方を参考にさせていただきました。

※ アイキャッチのGopherくんの原著作者はRenée Frenchさんです。

Pocket

ハンズラボが採用しているユニケージという謎テクノロジーについて第4回

Pocket

　謎テクノロジー第4回目です。多分これで最後ですね。

このままでは季刊な連載になってしまうので、ちょっと真面目にやります。

1 2	このままでは季刊な連載になってしまうので、ちょっと真面目にやります。

季刊どころではなく年報レベルになりました。モチベモチベ。

　前回は、ユニケージの具体例を、仮想アプリケーションをもとに説明しました。
今回は、

ぼくのかんがえたさいきょうのくらうどあーきてくちゃ
クラシックユニケージのpros/cons

について議論します。

　またクソ長くなってしまったのですが、想定読者層はそれでも読んで下さるようなエンスーな方々なので、
特に気にせず参ります。

ぼくのかんがえたさいきょうのくらうどあーきてくちゃ
- ぼくのかんがえたさいきょうのくらうどあーきてくちゃの特徴
  - Elastic Beanstalk SQS worker や EMR でやるようなところをユニケージで構築
  - とりあえず集計検索系を RedShift に
- くらうどあーきてくちゃまとめ
クラシックユニケージのpros/cons
- pros
- cons
連載のまとめ

続きを読むハンズラボが採用しているユニケージという謎テクノロジーについて第4回

Pocket

ハンズラボが採用しているユニケージという謎テクノロジーについて第3回

Pocket

謎テクノロジー第3回目です。
このままでは季刊な連載になってしまうので、ちょっと真面目にやります。
折角 AWS Summit でこれまでを読んで下さった方が増えたみたいなので、
重い腰を上げます。
実際には今は腰ではなく、肩と二の腕がひどいことになっています。
Day 1 の池澤あやかさんの好きな言語をスマホ振って応援アプリのせいだ……ｗ
このアプリについては Codezine 様の以下の連載をご覧下さい。

池澤あやかさんにお願い！ AWS Summit Tokyo 2015「デベロッパーカンファレンス」を盛り上がるアプリを一緒につくってください！
私はC#推しで2台のスマホで死ぬほど振った結果死にました。

さておき。

前回までで、ユニケージとはそもそも何であるかという点と、ユニケージのごく初歩的な処理の具体例について書きました。
今回は、単体のスクリプト内のデータフローではなく、もう少し広くシステム内で、ユニケージのデータがどのように流れていくか、について記述します。

データフロー
- データのレベル
- ここまでのまとめ
- 理解のための具体例
テキストファイル + DSLコマンドのユニケージを超えて
- 最近の流れ
- データのレベル概念を汎化する
- ぼくのかんがえたさいきょうのくらうどあーきてくちゃ
次回以降の内容

データフロー

データのレベル

ユニケージは半角スペース区切りのテキストファイルとしてファイルを保存することを、これまでに述べました。
しかし、RDBMSのようにDDLで予め宣言されるようなスキーマもインデックスもビューもキー制約も無く、
実務レベルでどのようにテキストファイル内のデータを駆使しているかについては、あまりイメージが湧かないと思います。
ここでは、ユニケージにおけるデータのレベル概念を説明し、
実際の系においてどのようにデータが処理されていくかが理解してもらえることを目指します。

ユニケージにおいては、系に存在するデータは、レベル1から5
の5階層のいずれかに属します。
この5階層データを順に説明します。

以下、
ユニケージ形式 : 半角スペース区切りのテキストファイル(UTF-8)
と定義します。

レベル1

アプリケーションにより submit されたデータ(WebアプリやAPI等)や、ユニケージで構築されたシステム外から取得したデータ。
JSON, XML, CSV, および画像ファイルや Excelファイルなどの blob をはじめ、任意の形式を想定する。
全てのデータを永続的にストックし、決して削除してはならない。

レベル2

レベル1データをユニケージ形式に変換したもの。
変換処理は各々のシステムに応じた頻度のバッチ処理で行われる。
- 多くは cron にて分単位から日単位で登録された、レベル2データ作成バッチにより行われる。
- Excel データであれば、Apache POI をラップしたコマンドにより変換をする。
- さすがに画像はテキストへの変換はしないが、リサイズやサムネイル相当画像生成は必要ならば実施する。
基本的には細かいロジックを挟まずに1ファイルずつ対応するように変換する。
- ただし階層構造のあるJSONやXMLのようなデータは、ユニケージ形式といえどキー設計された表形式データであるのは RDBMS と全く同じなので、プライマリキー相当のフィールドにより、1ファイルだが複数レコードとすることもある。
データを削除しても原理的にはレベル1から復元可能だが、基本的には削除しない。

レベル3

レベル2データのテーブル群から、必要なデータを結合して整理されたデータ。
- 5W1H で整理したデータにせよ、といわれる。
変換処理についてはレベル3と同様、各レベル3テーブルごとの頻度で個別の生成バッチが実行される。
業務系の基盤になるデータで、[日月年] で集計することになるようなデータをもとにして設計する。
ユニケージの通常利用でもっとも重要なデータ階層で、このデータは別のシステムからの参照も想定する。
データを削除しても原理的にはレベル2から復元可能だが、基本的には削除しない。

レベル4

レベル3データ群をもとに、個々のWebアプリケーションからの使用を想定し作成するデータ。
RDBMS では、ビューやインデックスに対応する概念といえる。
- アプリケーションの高速化の為に作成されるため、レベル3を随時参照するならばこのレベルのデータは不要。
このレベルのデータのみ、完全な破棄とレベル3データからの再生成が許可される。

レベル5

ユニケージのシステム外にアプリケーションから出力されるデータ
アプリケーションログ、ユーザがダウンロードした Excel 帳票, ファイル連携する外部システムに送信したファイル、などがある。

また、これらのデータのレベル概念において、重要な原理は、
データの生成フローはレベル1から5の方向の一方向のみ
ということです。

ここまでのまとめ

表にまとめると以下の様になります。

レベル	概要	例	削除
レベル1	入力生データ	submit されたデータ、JSON, XML, CSV	不可
レベル2	生データを素直に変換したデータ		原則不可
レベル3	業務ごとに使いやすいように整理したデータ	商品詳細データ、日×店別の売上トランザクションやサマリ	あまりしない
レベル4	アプリケーション高速化用データ	画面表示に必要なレベル3を結合・非正規化したデータ、検索画面用インデックスファイル	可
レベル5	外部出力データ	アプリケーションログ、外部システム連携CSV, ユーザダウンロードExcel帳票(動的)	原則不可

ここまででも、実際にどのようにこれらデータが参照されるのか、
今一つイメージが湧かないかもしれませんので、具体例で考えてみましょう。

理解のための具体例

具体的な小さなアプリケーションを想定して、例を考えます。
以下に仕様を記述します。
特に主語が無い場合、主語はユーザ、とします。

商品のマスタ一覧を、検索条件を指定して参照することができる。
商品のマスタ一覧のCSV出力を、検索後の一覧画面のUIからダウンロードすることができる。
個別の商品のマスタの詳細について、マスタ一覧画面から商品詳細画面に遷移することで、これを参照することができる。
個別の商品のマスタの詳細について、参照と同様のフローで商品詳細画面に遷移し、この情報を変更することが出来る。
商品詳細画面におけるデータ更新は、POST リクエストにて行い、更新内容をBody にあらかじめ定義されたスキーマのJSON で記述する。

このアプリケーションで登場するデータを以下に列挙します。
簡単のため、正規化は第1正規化のみ行った位のデータが主であると考えて下さい。

データ名	概要	レベル
商品詳細マスタ	商品の詳細データ。商品名から価格、説明、画像URIなど全てを含む	レベル3
商品一覧	マスタ一覧画面の検索用。商品詳細マスタから作成。	レベル4
商品検索結果出力	マスタ一覧画面の検索結果のCSV出力	レベル5
商品詳細更新生データ	商品詳細においてユーザが更新操作時にリクエストに含まれる、 JSON形式の1商品詳細の更新データ	レベル1
商品詳細更新データ	商品詳細更新生データをユニケージ形式に変換したデータ。商品詳細マスタと同一のフィールドと主キー定義を持つ。	レベル2
商品画像	商品画像の実体ファイル	レベル1

以上をもとに、このアプリケーションでデータがどのように参照・更新されるかをまとめると、以下の様になります。

マスタ一覧の参照時、事前作成済みの商品一覧ファイルを検索条件に基づいて join系コマンド、grep や awk でフィルタすることで、ユーザの求める検索結果を表示させる。
- レベル4データの参照のみ
マスタ一覧の参照時、CSV出力のアクションにより、検索結果と同一のフィルタがされた商品検索結果のCSV出力がダウンロードされる。
- レベル4データからレベル5データを随時作成。
マスタ一覧から商品詳細画面に遷移して、商品詳細情報を参照する。
- レベル4データからレベル3データのキーを取得し、これを指定してレベル3を1件取得し、商品詳細画面を構成。
商品詳細画面で商品詳細情報を更新する。
- 画面の状態から商品詳細情報に相当するレベル1データのJSON文字列を作成し、POST する。
商品詳細情報更新後、マスタ一覧に更新が反映される。
- レベル1データの POST 時に、サーバサイドでレベル1データはレベル2 データに変換されて保存される。
- さらにLV3データ、LV4データと順番にバッチ処理で、タイムラグがありつつも更新される。
商品詳細情報更新後、同一画面にて更新が反映される。
- 前述の更新時のレベル2データとレベル3データを両方参照し、更新日時が最も新しいものを採用し、画面を構成する。
- ユニケージでは、このような随時更新されすぐに再参照されるデータの整合性担保に関してはいくつかの方法が示されているが、筆者はこれ(関連レベルデータのうちupdate最新日時のデータを採用)が一番わかりやすいと考える。
- いずれにしても厳密なトランザクションや整合性に関しては、ロック処理を別途実装する必要がある。
- 同一レコードに対する更新操作が短時間に大量に発生(厳密ではないが、10[req/(sec * record)] 以上を想定)するシステムでは、そのロック処理も限界があるので、そもそもユニケージは向かないと考える。この話は別途。

長くなりましたが、ユニケージのデータフローについて、少し感覚が掴めて頂けたのではないでしょうか。
むしろ筆者はこれを書いていて理解の整理が進みましたｗ

テキストファイル + DSLコマンドのユニケージを超えて

データのレベル概念を汎化する

ですが、前述の例で出したようなデータのレベルの考え方を、
マネージドサービスのデータストアにテーブルやキー単位で与え、キューなどを組み合わせることで、
ユニケージと同等のデータフローと整合性を持って、完全にスケールするシステムが作れるのではないかと考えています。
これをクラシックなユニケージから大きく離れず、
一定のレベルでシンプルに実現したのが、
弊社田部井を中心として実現した、S3をデータストアとして、
クラシックなユニケージで実現したポイントソリューションシステムでしょう。
S3をDB利用ショッピングセンター向けポイントシステム概要
第三者の視点での評価として、このアーキテクチャは
AWS様のAPN Architecture of the Year 2014
にて、クラスメソッド様の紅白歌合戦事例に次ぐ評価を頂いています。
AWS Partner SA ブログ: APN Architecture of the Year 2014のご報告

ぼくのかんがえたさいきょうのくらうどあーきてくちゃ

ユニケージのデータ整合性やロックのつらみに関しては、
他のNoSQLなアーキテクチャにおけるそれと類似している部分がかなりあるので、
ユニケージのデータフローに関してメタにとらえて再構築することで、
他のNoSQL環境において解決できる問題も出てくるのでは無いかと考えています。

AWSのサービスでいうと、本記事の言及範囲では、
SQS, Kinesis, EMR, RedShift, S3, Lambda, CloudSearch, DynamoDB & DynamoDB Stream(はよ)
あたりを組み合わせて使う事で、クラシックユニケージではないがその思想を借りた、
整合性は数秒単位でそれなりだが、完全にスケールして集計もできる、
NoSQL中心システムが構築可能ではないかと考えています。

これに関してはだいぶ前から考えていたのですが、
AWS 公式のDynamoDB Deep Dive スライドの最後から2枚目の、DynamoDBリファレンスアーキテクチャでほぼ私の言いたいことは示されてしまっていたり、
Deep Dive: Amazon DynamoDB
Cassandra を中心としたアーキテクチャとも類似点があり、データストアの特性が類似していればアーキテクチャも類似するものなのかな、と思いました。
Devsumi2013【15-e-5】NoSQLの野心的な使い方～Apache Cassandra編～
ワークスアプリケーションズ様のRDBMSを使用しないERPである、
HUEの設計事例のお話を伺いましたが、これも抱える問題や解決方法について類似しているように思えました。
Sessions / JJUG CCC 2015 Spring（4月11日開催）AB-1 社長が脱RDBと言い出して困りましたが、開き直って楽しんでいる話 | 日本Javaユーザーグループ

Cassandra などでも絶対スケールするシステムは作れると思うのですが、
なんだかんだ強いDBAの様な人や、Cassandra はじめミドルのお守りが高いレベルで出来る人、
アプリケーション開発者の大きな負担、
もしくはそれを和らげるDTOなどの整備が出来る優秀なエンジニアを一定量確保することが必要そうに思えることを考慮すると、
AWSがある程度使えて、普通のソフトウェア設計が普通にちゃんとできて、
普通に実装もちゃんとできる、というレベルの、
普通にいるちょっと優秀なレベルのアプリケーションエンジニアが数人いれば、
この絶対スケールするシステム、少し楽観的に見てますが、ミドルを自ら管理するコストを抱えずに、なんとか作れそうな気がしてきます。
# 私が作るとは言っていない(ひどい)

次回以降の内容

今回単語レベルでばーっと書いた、
DynamoDBリファレンスアーキテクチャの fork のようなメタユニケージスケールしまくるアーキテクチャの図をもう少し熟考して作ってきます。

また、上記と絡めて、
– クラシックユニケージのpros/cons
– AWSフルマネージドなメタユニケージではそれがどのように変わるか
について議論したいと考えています。

Pocket

ハンズラボが採用しているユニケージという謎テクノロジーについて第2回

ユニケージ
2015年2月23日
ハンズラボ

Pocket

謎テクノロジー第2回目です。
諸事情によりだいぶ時間が空いてしまいました。色々と厳しい。

今回は簡単なサンプルコードを用いて、もう少し突っ込んでユニケージの処理例について解説します。
繰り返しになりますが、この連載での記述は全て筆者の見解であります。と、念押し。
# しかしまた長くなってしまった……
# 削ったり分割したかったけど、いい加減アウトプットしたかったのでひとまずこれで。

コード例

フィールド選択での例

前述の様に、ユニケージ開発手法では、原則半角スペースをセパレータとするフラットファイルをデータストアとして用います。
セパレータが半角スペースであることについては賛否両論有りますが、

シェルスクリプトが半角スペースを引数の区切りとして使っている
ユニケージコマンドの補助として多用するawkのデフォルトセパレータも半角スペース

であるので、それなりに合理的ではあると考えます。

簡単な具体例として、あるファイルの特定の列のみ選択する操作について説明します。
以下のファイルをサンプルとします。

# 商品コード 発売日 商品名 販売価格
cat item_basic_info
item_1 20150204 商品1 1944
item_2 20150202 商品2 10800

# 商品コード発売日商品名販売価格

cat item_basic_info

item_1 20150204 商品1 1944

item_2 20150202 商品2 10800

このファイルから商品コードと販売価格のみを出力する場合は、
self コマンドを用いて以下のように行います。

# 商品コード 販売価格
self 1 4 item_basic_info

# 商品コード販売価格

self 1 4 item_basic_info

item_1 1944
item_2 10800

item_1 1944

item_2 10800

上記と同じファイルをスクリプト内で読み込み、等価な標準出力を行うPHPのコードを以下に記します。

<?php
foreach (new SplFileObject('item_basic_info') as $line) {
    $fields = explode(" ", $line);
    echo @"{$fields[0]} {$fields[3]}";
}

<?php

foreach (new SplFileObject('item_basic_info') as $line) {

$fields = explode(" ", $line);

echo @"{$fields[0]} {$fields[3]}";

}

もうちょっといい感じにできるとは思うのですが、
単にフラットファイル丸ごと開いて数列を選択して出力するだけでも冗長な感じです。
# 強引だ……

ユニケージコマンドセットには、概ねこの程度の粒度のコマンドがたくさんあるのですが、
実務的には概ね数十程度(筆者の感覚では50以下)のコマンドの組み合わせにて、アプリケーションを記述しています。

また、前述の様に、ユニケージコマンドだけでは行いにくい処理を行う場合は、だいたいawkを使う事になります。
前述の self コマンドの例と等価なawkを使用したワンライナーは、書くまでもないかも知れませんが、

awk '{print $1, $4;}' item_basic_info

1 2	awk '{print $1, $4;}' item_basic_info

となります。
フラットファイルの行の集合に対して、各々フィルタ処理を行って目的の出力を得る、という処理が中心のユニケージに対して、
awkは枯れている上に、短いフィルタ処理を書く為には簡潔に書けるので、ユニケージ開発には重宝します。
# ただし、awkはなるべく使うな、というふわっとした規約もあったりします……
# 商用版ユニケージコマンドはほぼ全てpure Cで書かれているので、awkでコマンドの組み合わせに相当する処理を記述すると比較して十分に遅くなってしまうので……

ごく簡単な集計での例

前述の商品マスタを用いて、さらに販売実績に関する簡単な集計の例を示します。
以下の様な販売実績のファイルがあるとします。

# 販売日 商品コード 販売店コード 販売数
cat item_sales
20150201 item_1 001 15
20150201 item_1 002 4
20150201 item_1 003 7
20150201 item_2 001 2
20150201 item_2 002 1
20150201 item_2 003 6
20150202 item_1 001 12
20150202 item_1 002 3
20150202 item_1 003 6
20150202 item_2 001 3
20150202 item_2 002 2
20150202 item_2 003 5

# 販売日商品コード販売店コード販売数

cat item_sales

20150201 item_1 001 15

20150201 item_1 002 4

20150201 item_1 003 7

20150201 item_2 001 2

20150201 item_2 002 1

20150201 item_2 003 6

20150202 item_1 001 12

20150202 item_1 002 3

20150202 item_1 003 6

20150202 item_2 001 3

20150202 item_2 002 2

20150202 item_2 003 5

上記の販売実績から、店舗と販売日問わず商品毎の販売合計金額を算出する場合は、以下の様にします。

sort -k2 -s item_sales |
join1 key=2 item_basic_info - |
# 1:販売日 2:商品コード 3:発売日 4:商品名 5:販売価格 6:販売店コード 7:販売数
lcalc '$2, $5 * $7' |
# 1:商品コード 2:商品毎の販売合計金額
sm2 1 1 2 2
# 1:商品コード 2:販売合計金額

sort -k2 -s item_sales |

join1 key=2 item_basic_info - |

# 1:販売日 2:商品コード 3:発売日 4:商品名 5:販売価格 6:販売店コード 7:販売数

lcalc '$2, $5 * $7' |

# 1:商品コード 2:商品毎の販売合計金額

sm2 1 1 2 2

# 1:商品コード 2:販売合計金額

item_1 50544
item_2 9720

item_1 50544

item_2 9720

join1コマンドは、指定したキーにて、2つのファイルまたはファイルと標準入力に対して、内部結合を行うものです。
ユニケージコマンドでのキー指定は、極一部の例外を除き、事前にそのキーにてソートされている必要があります。
lcalcコマンドは、基本的な算術演算をawkのようなシンタックスの式で、
36桁の10進数で加減乗除と四捨五入・丸め操作を行うものです。
sm2コマンドは、第1,2引数で集計範囲キーを指定し、第3,4引数の範囲の値の総和を個別に取るものです。

また、店毎のある日の総販売実績は以下の様にして求められます。

sort -k2 -s item_sales |
join1 key=2 item_basic_info - |
# 1:販売日 2:商品コード 3:発売日 4:商品名 5:販売価格 6:販売店コード 7:販売数
lcalc '$1, $6, $2, $5 * $7'
# 1:販売日 2:販売店コード 3:商品コード 4:商品毎の販売合計金額
sort -k1,2 -s |
sm2 1 2 4 4
# 1:販売日 2:販売店コード 3:ある日のある店の総販売実績

sort -k2 -s item_sales |

join1 key=2 item_basic_info - |

# 1:販売日 2:商品コード 3:発売日 4:商品名 5:販売価格 6:販売店コード 7:販売数

lcalc '$1, $6, $2, $5 * $7'

# 1:販売日 2:販売店コード 3:商品コード 4:商品毎の販売合計金額

sort -k1,2 -s |

sm2 1 2 4 4

# 1:販売日 2:販売店コード 3:ある日のある店の総販売実績

20150221 001 31320
20150221 002 8856
20150221 003 20088
20150222 001 26568
20150222 002 7992
20150222 003 17064

20150221 001 31320

20150221 002 8856

20150221 003 20088

20150222 001 26568

20150222 002 7992

20150222 003 17064

集計したいキーと集計したい値だけに着目し、コマンドを作用させれば求める値が得られる、というのは、単純な算術演算だけ行うようなロジックにおいては、他にケアするべきことが少なくなるのでよいです。

ログ集計

簡易なWebサーバのステータス集計など、ログ集計も可能です。
例えば、以下の様なフォーマットのログのみが /var/log/httpd/access_log に出力されている場合、

time:2015-02-22 00:04:04 +0900  domain:localhost        host:10.5.103.183       server:10.5.32.9        method:GET      path:...         status:200      size:341        response_time:15222830

1 2	time:2015-02-22 00:04:04 +0900 domain:localhost host:10.5.103.183 server:10.5.32.9 method:GET path:... status:200 size:341 response_time:15222830

1時間毎のステータスコードを以下の様に集計出来ます。

cat /var/log/httpd/access_log |
egrep -o 'time:[0-9-]+ [0-9:]+|status:[0-9]+' |
tr " " "_"  |
yarr -2 |
self 1.1.18 2 |
sort |
count 1 2

cat /var/log/httpd/access_log |

egrep -o 'time:[0-9-]+ [0-9:]+|status:[0-9]+' |

tr " " "_" |

yarr -2 |

self 1.1.18 2 |

sort |

count 1 2

time:2015-02-21_04 status:200 180
time:2015-02-21_05 status:200 771
time:2015-02-21_06 status:200 908
...
time:2015-02-21_17 status:200 3015
time:2015-02-21_17 status:304 30
time:2015-02-21_17 status:404 1
...
time:2015-02-22_00 status:200 112

time:2015-02-21_04 status:200 180

time:2015-02-21_05 status:200 771

time:2015-02-21_06 status:200 908

...

time:2015-02-21_17 status:200 3015

time:2015-02-21_17 status:304 30

time:2015-02-21_17 status:404 1

...

time:2015-02-22_00 status:200 112

yarrコマンドは、指定列数になるようにファイルの行を横に展開するものです。
countコマンドは、指定キーにマッチする行の数をカウントするものです。
ログ集計がシェルスクリプトで、下手すればワンライナーで完結するので、あまりアプリケーションコードを書かない方のインフラエンジニアの方やデータ分析官の方にも重宝するのではないでしょうか。
yarr,count共にOpen版に含まれているので、こういった作業をすることがあるならば導入しておくと便利です。

まとめ

普通のプログラミング言語よりも、手続き的な処理が少なく、データに対する操作が主になっている様子を掴んでもらえたと思います。
例示したように、1つのプログラムで、前述の例の様なパイプライン処理で作成した複数のデータを、一時ファイルに置きつつさらに操作して、最終的に求める出力を得ます。
求める出力は、DBのビューに相当するデータであったり、HTMLテンプレートにはめ込むデータであったり、バッチ処理により更新されたテーブルであったりしますが、基本的な手法はほぼ変わりません。
アプリケーションコードが殆どデータに対する宣言的操作だけでできている、と言えます。
基本的には無名のフィールドに対して操作を連続して行い、操作中にフィールド構成がよく変化するので、変化ある毎にフィールド内容を正しくコメントすることは必須です。
これを正しく行っていないと、人間非可読なコードがあっという間に出来上がります。
しかしながら当然あり得るツッコミとしては、コメントが多すぎて可読性がひどいのでは、というのがあります。
これに関しては、また次回以降……

第1回に対するネット上の声Q&A的なもの

エゴサ力を駆使したところ、第1回公開後のネット上の声が思ったよりあったので、勝手に回答します。
ソースは必要があれば正しくURLを引用しますが、晒す感じになってしまいそうなので、意図を歪めない範囲で省略した文に対してインライン回答する形式にします。

プログラマ視点で引き続き解説を

そのようにしていきます。
ビジネス中心の話はビジネスおじさんに任せればよいのです。
小耳に挟んだところによると、色々な所から人を集めて推進するようなプロジェクトでもユニケージ案件は一定数存在するようなので、そこに突っ込まれた普通のエンジニアにとっても有益なものになるようにしたいです。
また、公にされている情報がビジネス的な話ばかり目立って存在して、技術寄りの話が少ないテクノロジーというのは、はっきり言ってエンジニア視点からは胡散臭さマシマシとなり、それ自身にとって不幸だと思うので、引き続きこのくらいのスタンスでやっていきます。

考え方が関数型言語っぽい

せやな。
……などというとマサカリが四方八方から飛んできそうです。
その上で言うと、

データ構造が2次元配列だけの、シンプルなデータ構造で
しかもデータソースでもアプリケーション中でも出力でも構造が殆ど変わらない
- 所詮はフィールド数が多いだけの、テーブルに出力する一覧画面や帳票リプレースものなアプリケーションが多い。
- 更新系も、所詮表形式データの編集に過ぎないものが多い。

最も抽象度の低い宣言型プログラミング、とも言えるかも知れません。
そろそろ強いマサカリが怖いのでこの辺で……。

これについては、より知見の深い、シェルスクリプト高速開発手法入門で皆様ご存じの上田先生にもご意見を賜りたく。
シェル芸とHaskellの対応を考える | 上田ブログ

エンドユーザーコンピューティングとしてはmuch better Excel。ファイルシステムというドキュメント型KVSの上に実現するための知見の集合？

確かにExcel/Accessによるエンドユーザたこつぼシステムの代替である側面はあります。

ユニケージコマンドがフラットファイル処理に特化しているので、ファイルシステム上のフラットファイルに、という感じではありますが、
ユニケージにはデータの階層構造の概念があり、それが実現できればファイルシステム上のフラットファイルでなくとも、ユニケージ的なものは出来そうです。
例えば、AWSやAzure,GCPなどのクラウドのマネージドサービスにて、各々のデータ階層のデータストアとしての役割や、データ操作の役割を割り当てる、など考えられます。
単純にファイル置き場をS3にして実現したシステムの事例については、
既に当社の田部井による事例紹介が公開されています。
フラットファイルを用いないユニケージ的な考え方については、
ユニケージのデータの階層構造を説明する時に、考えながらあわせて触れたいと思います。

また、等価なコードはだいたいの言語で書けるはずなので、言語もシェルスクリプトである必要はないと思います。

# 個人的にはシェルスクリプトはあまり好きではないし、追加・削除したコード量的にも、一生のうちに書いてよいシェルスクリプトの閾値を超えた気持ちになっているので、おなかいっぱいです。
# あとシェルスクリプトは他の言語に比べて簡単かというと、そうでもない。
# ユニケージコマンドやそれに類するコマンド群がなければ、アプリケーション記述用言語としては初心者に全くおすすめできません。

RDBMSを使用しない理由が不明確

これは確かにそうです。
私はユニケージガチ勢ではないので、普通の言語や普通のRDBMSや普通の分散環境がはまるケースなら普通にそれでやればいいと思います。
適材適所、ユースケースにはまれば採用すればよい。

その上で、エンドユーザーコンピューティング的な視点だけで言うと、
諸々の実行環境やミドルウェアの設定・依存関係に悩まされず、ユーザが脱Excel|Accessして、
自社のデータを自分の手で素データからガンガン取り回すという経験を最速でやれるのは、ユーザ企業にとって、自社を動かすシステムのブラックボックス度を軽減させるという点で、重要な事と考えています。
システムを作ることから離れすぎた・放棄したユーザ企業が、SIerに上手に仕事を投げられなくなり、
ダメなSIの発生率が上がっていそう(ダメSIの定義が出来ていないので妄想みたいなものですが)という気がしますので。
もっと言えば、SIに限らずWeb制作などの、一定以上の専門性を要するものの外注などにも、発注側の過度の “わかってなさ” が良くない事態を招くこともあると思います。
# 自分が何をわかってないかをわかってない人と仕事をするのはつらいです。

システムの物理的実体がRDBMSを使っているかどうかなどの適材適所とは、また別の軸の話となってしまいました。
とりあえず、バージョンや設定に依存するミドルウェアやコンパイラ・インタプリタが事実上ほぼ無いと言える(一応Apache httpd とbash、ユニケージコマンドに依存するが)というのは、
ユーザ企業出身エンジニアにとっては、余計なことを考えず自社のデータのことだけを考えればよい、という点が良いのではないか、と考えています。
筆者はハンズのプロパーではないので、他のプロパーの人たちを見て、という意味です。
エンジニアとしての練度が上がり、業務だけでなく技術に対する理解力もついてくれば、
なんでもユニケージでなく、ケースによって最適なアーキテクチャをエンジニアが選定して推進していけばよいのではないでしょうか。

あんまビジネスの話したくないけどそれっぽい話をしてしまった。あかん。

シェルスクリプトでJSON操作できるコマンドが必要では

ユニケージコマンドには存在しないのですが、一定の範囲では間に合ってますｗ
例えば、

key val
key2 val2
arr1 1 array_hash_key1 array_hash_val1
arr1 1 array_hash_key2 array_hash_val2
arr1 2 array_hash_key1 array_hash_val3
arr1 2 array_hash_key2 array_hash_val4

key val

key2 val2

arr1 1 array_hash_key1 array_hash_val1

arr1 1 array_hash_key2 array_hash_val2

arr1 2 array_hash_key1 array_hash_val3

arr1 2 array_hash_key2 array_hash_val4

みたいな入力を食わせると、

{
  "key": "val",
  "key2": "val2"
  "arr1": [
    {
      "array_hash_key1": "array_hash_val1",
      "array_hash_key2": "array_hash_val2"
    },
    {
      "array_hash_key1": "array_hash_val3",
      "array_hash_key2": "array_hash_val4"
    }
  ],
}

{

"key": "val",

"key2": "val2"

"arr1": [

{

"array_hash_key1": "array_hash_val1",

"array_hash_key2": "array_hash_val2"

{

"array_hash_key1": "array_hash_val3",

"array_hash_key2": "array_hash_val4"

}

みたいなJSONを吐くコマンドは2年以上前から社内に存在してます。
上記のような、
キー名値
が連続したファイルを読みこんでjson_encodeするPHPのスクリプトを外部コマンドとして作成し、使用していました。
# しかしシェルスクリプトでJSONパーサ書くとかぞっとする……。
また、AWSのCLIを使用する際などは、jqコマンドを使用してレスポンスをパースしています。

シェルスクリプトでJSONを操るのは、少なくとも弊チーム(EC・アプリ系)は色々あって卒業しました。
色々、については、書く機会があればそのうち書きます。

次回以降の内容

次回は、ユニケージのデータ階層構造の概念について、を予定しています。
可能であれば、クラウドマネージドサービスとの対応を考えてみるところまでやってみたいと思います。
pros/cons については、次々回以降に、ここまでの記述で書いたこと、察せそうなことをまとめる形でやっていく予定です。

第3回はこちら

Pocket

12 »

カテゴリー: ユニケージ

混ぜるな危険!? ユニケージとxonshの融合

はじめに

ユニケージとは

xonshとは

今回紹介すること

selfとのコラボ

mdateとのコラボ

dayslashとのコラボ

Jupyter Notebookで使用する

ユニケージコマンドは果たして使用できるのか?

GolangでDynamoDB CLIを書く話

ハンズラボが採用しているユニケージという謎テクノロジーについて第4回

目次

ハンズラボが採用しているユニケージという謎テクノロジーについて第3回

目次

データフロー

データのレベル

レベル1

レベル2

レベル3

レベル4

レベル5

ここまでのまとめ

理解のための具体例

テキストファイル + DSLコマンドのユニケージを超えて

最近の流れ

データのレベル概念を汎化する

ぼくのかんがえたさいきょうのくらうどあーきてくちゃ

次回以降の内容

ハンズラボが採用しているユニケージという謎テクノロジーについて第2回

目次

コード例

フィールド選択での例

ごく簡単な集計での例

ログ集計

まとめ

第1回に対するネット上の声Q&A的なもの

次回以降の内容