compileで通らないのかは理解しなければ。2月になると宣伝する余裕がなさそうなので、今のうちに宣伝しておきます。今回は分散ストリーミングプラットフォームのKafkaの解説同人誌を出す予定です。触ってみるとめちゃくちゃ面白かったので推しポイントをプレゼンするつもりで書いてみる次第です。目次は以下のようなものを考えてます。元々は自分の今いるチームメンバーに知識共有できたらいいなぁと考えていたので、意識的に章を細かく設定しています。Registryも取り上げているのが個人的にはポイントです。他の本ではあまり書いてないのでは?ちなみに目次はオライリーのKafka本のものをベースにしています。この本を読んでいなくても理解できるようになっています!www.oreilly.co.jp対象読者と書かないこと対象読者はアプリ開発者でKafka初学者の想定です。以下の項目は今回の本のスコープから外す予定です。20:22技術書典8でKafka本を出しますTweet広告を非表示にするコメントを書くもっと読む2019-12-312019年の振り返り今年の年末エントリーです。今年は去年以上に色んなことに手を出したので、その振り返りと来年の目標を書きます。https://ponzmild.hatenablog.com/entry/2018/12/31/160746やってきたことお仕事クラウドビジネスを推進する部門にいるので、クラウド漬けでした。言語も使うサービスもクラウドも違っていたので覚えることが多かったのですが、去年よりも使うべきサービスの選択に迷わなくなった印象です。裏で取得してたクラウド資格や書籍の読み漁りが業務でもプラスになっていたと信じたい。Python,Watson個人ワークめぼしいところだと技術書典7のサークル参加が大きな成果でした。今までブログやGitHubでこっそりやっていた技術のアウトプットを、もっと広くの人に見てもらえる場所で、しかも本という形に残るもので表現できたのです。自分の知識が曖昧か学んだいい機会でした。以下自分のワークです。残念ながら去年の体重増量目標の60.0kgは達成できず。結果は+1.2kgの56.2kgでした。2020年にやりたいこと技術書典8実はまた出ます!サークル参加は1日目の2/29です。予定としては前回出したNATS本の改訂版と、NATS/Kafka/RedisのPub/Subメッセージングソフトウェアの比較本を出す予定です。英語力UPTOEIC780点を目指します。昇進にもTOEICのスコアが必要だったのですが、最後に受験したのが2年前だったので、今までの最高点を目標にします。Developer)取ります!ブログ今年のペースを落とさず年24本書きます。体重増やす来年末までに60kgまで増やします。Kafkaに入門しました。Stream(Kafkaのマネージドサービス)にLiteプランが出てきたからです。限られた機能しか操作できないとはいえ、無料で使うのには十分です。今回はJavaでメッセージの送受信を試みます。1年近く前のコードなので非推奨のメソッドやクラスがあります。これらを避けながら改めて自分でも書いてみます。github.com以下、コードになります。1クラスに押し込めているので少しコードが長くなっていますが、200行くらいで書けるもんですね。クラスに設定値を詰める時です。SASLの設定が必要です。書いてみると意外と簡単ですね。FrameworkでもKafkaを扱えるようなので、次はこちらにチャレンジですね。www.baeldung.com以上。何とか乗り切った話です。乗り切るまでの過程も忘れないように覚え書きします。GB単位のデータセットを加工→ファイルダンプするシチュエーションをイメージしてください。使って以下のような考え方で機能実現を試みました。1プロセスのNode.jsバッチアプリケーションで処理する。用いて一括でファイルに書き出す。以下サンプルコードです。}}上記の方法で実行してみると、データセットが500万件を超えたあたりで以下のようなエラーが出るようなりました。これはNode.jsのヒープサイズ上限を超えたオブジェクトを保持すると発生するエラーです。元のデータセットと一緒に加工後のデータも全て保持して倍以上のヒープを消費したことが原因でした。Memoryで落ちることあるのですよ。Memoryで死んだのは、ヒープサイズ上限を超えたオブジェクトを保持したからでした。つけて実行することでヒープサイズの上限を引き上げて解決できます。Node.jsのコアであるV8エンジンのヒープサイズ上限は元々1.7GBとそこそこ大きいサイズを持っていますが、それでも足りない場合の対処方法です。stackoverflow.comですが、自分の場合はプラットフォームの制約から安易にヒープサイズを上げることができなかったのでこの方法は断念。スケールアウト(複数のプロセスで実行)の道が閉ざされてしまったので、アプリの処理をヒープサイズを消費しない省エネな作りに変えて対応することにしました。StreamはNode.jsの標準ライブラリに含まれています。入力のオブジェクトをStreamに読み込むと、Stream内部で持っているバッファに読み込んだ要素を順次溜めていき、閾値まで溜めたらアウトプットにまとめて書き出すことができます。書き込み用のStreamが用意されているため、少しずつ読み込み→加工→書き出しとStreamをつなげることでヒープサイズが枯渇しないようなETLの実装が可能です。今回のユースケースにはピッタリです。最終的には大量データの書き出しは以下のコードで解決できました。chunkをObjectで受け取る。Buffer型を期待するため、TYPE_ERRORで例外を投げる。Transformerを3種類を活用しています。書き込みでそれぞれ責務を分割しながらヒープサイズの消費を押さえて大量データをETLできます。それぞれのStreamはInterfaceとして提供されているので、カスタムのStreamを実装も可能です。上記のコードだとデータセットを加工するTransformクラスを継承したStreamクラスを作成しています。Streamは普段使わないと正体が掴めない代物です。避けて通ってみたものの、触ってみると案外使いやすい便利な標準ライブラリでした。Streamがヒープサイズの消費を押さえた省エネな作りをしていたとしても、OOMを回避できない場面が出てきます。一度に大量のオブジェクトを作ってしまったらStreamに流し込む前にヒープサイズが枯渇してしまいます。実際に数百MB以上のデータセットを扱ったときは、100万件程度でデータセットを分割して加工→ダンプ(追記)する方法とStreamで少しずつ流し込む方法の両方を採用していました。ETLサービスを使って実現したいですね。