なんか完全にコード読み違えた感が・・・ PlainTextのクラスを暗号化版と見間違えたか。寝ぼけてましたかねぇ。
posted at 12:03:39
ツイートの記録を停止しています
このアカウントはTwitter APIの仕様変更の影響でツイートの記録を停止しています。
記録を再開するには、Twilogにログインしてください。
Stats | Twitter歴 4,843日(2010/12/26より) |
ツイート数 26,526(5.4件/日) |
表示するツイート :
なんか完全にコード読み違えた感が・・・ PlainTextのクラスを暗号化版と見間違えたか。寝ぼけてましたかねぇ。
posted at 12:03:39
その上で、実際にコードを見ても自前でByteBufferとSSLEngine用いて通信受け付けるようになっている。バッファキャッシュの恩恵は受けられても、ZeroCopyの恩恵は受けられない構成ですか。FileIOは問題ないが、CPUで限界に来ると。 https://github.com/apache/kafka/blob/1.1.0-rc0/clients/src/main/java/org/apache/kafka/common/network/SslTransportLayer.java…
posted at 12:02:42
完全に読み違えてましたがConsume時にSSL通すとZeroCopy喪失すると。で、この資料のベンチマーク、よく見るとBrokerのCPU使用率、Consumeされる際に爆上がりなんですが・・・やばいですね。 / “Kafka…” http://htn.to/uvJnoJ
posted at 11:59:34
#LINE_DM ここまでいろいろ揃ってますか。REST作るのは普通にあるので、今度作るときに見てみますか。
posted at 21:22:40
「アプリケーションエンジニアのためのApache Spark入門」出版記念セミナー(第一回) https://connpass.com/event/80989/
posted at 21:06:17
スタートアップ感があってよい > 「これは次の障害時に確認できる」 #LINE_DM
Retweeted by Sotaro Kimura
retweeted at 20:43:32
#LINE_DM クラウドに乗ってるので、Kafkaから2重サブスクライブするなり、HDFSのファイルを移すなりしてホスト落としての試験は普通にできそうですが、しなかったのでしょうか。。。微妙に怖いですね
posted at 20:28:50
#LINE_DM ブロッキングで、単一サーバのダウンで全体性能減衰。。。うっ、頭が。TCPに応答ないパターンでないと顕在化しないのでプロセス落としたテストケースで検知できなかった。
posted at 20:18:09
地震があったのか、自分の感覚がおかしいのか、このくらいの地震だと瞬時に判断できないあたりに危うさを感じますねぇ・・・
posted at 08:09:09
いいエンジニア取るなら、まずはいい給与では?
Retweeted by Sotaro Kimura
retweeted at 15:15:39
「アプリケーションエンジニアのためのApache Spark入門」を献本いただきました。ありがとうございます!SparkStreamingにけっこうページが割かれていて個人的にありがたいですね https://pic.twitter.com/h3xFCUnFNb
Retweeted by Sotaro Kimura
retweeted at 18:18:31
My paper on CASPaxos, a simpler than Raft & Multi-Paxos protocol for building replicated state machines, is now on arXiv! The protocol has less moving parts, requires less code to implement, supports membership change and has formal proof - https://arxiv.org/pdf/1802.07000.pdf… https://pic.twitter.com/R3dnboPvdf
Retweeted by Sotaro Kimura
retweeted at 12:11:56
昨日お話しした資料です!
#tdtech
https://speakerdeck.com/toita/treasure-datadegou-zhu-sitadetafen-xi-ji-pan-kofalse1nian-falsezhen-rifan-ri…
Retweeted by Sotaro Kimura
retweeted at 20:31:13
昨日のTech Talkでの資料をアップロードしました。ありがとうございました!
https://www.slideshare.net/lewuathe/user-defined-partitioning-on-plazmadb… #tdtech
Retweeted by Sotaro Kimura
retweeted at 17:11:18
昨日の #tdtech で話したスライドを公開しました / "History of Event Collector in Treasure Data" https://www.slideshare.net/mitsunorikomatsu/td-tecktalk2018evcol…
Retweeted by Sotaro Kimura
retweeted at 14:47:59
昨日のスライド公開しました #tdtech / “Planet-scale Data Ingestion Pipeline: Bigdam” http://htn.to/4FKPjY
Retweeted by Sotaro Kimura
retweeted at 12:52:48
今朝学んだこと。「水分多めにとってジョギングしてると二日酔い解消できる」(駄目人間 ただ、リアルに水分とって休んでるよりは早く引くんですよね。
posted at 09:39:05
@tagomoris なるほど。ありがとうございます。Kafkaだと3重レプリケーションで1かallどちらかのみで使いにくかったりする事情があったりしますので、2というのは丁度いいバランスになりそうですね。
posted at 23:51:43
3重がmaxなので、2つ書けたらレスポンスが返ります https://twitter.com/kimutansk/status/965508538771517441…
Retweeted by Sotaro Kimura
retweeted at 23:49:44
#tdtech エンドポイントはリトライ優先で、重複削除は下流でやることでユーザからの入力を取り落とす度合いを下げていると。
posted at 17:58:03
#tdtech Plazmadb上のファイルは削減はされるものの、Bigdamからの投入時点ではあまり揃っているわけではない? それは別だしですか。
posted at 17:56:09
#tdtech Auroraベースのキューは状態管理とリトライ用ですか。
posted at 17:53:13
#tdtech クラスタ内3重レプリカに反映されるとクライアント側に応答かえる?
posted at 17:49:08
世界中にエッジサーバを設置し、一カ所のデータセンターに効率的に集めてくることができる分散データ収集システム。高信頼・高スループット・低レイテンシ・低転送コストを保証。カッコよくてIoT時代で売れそう。 #tdtech
Retweeted by Sotaro Kimura
retweeted at 17:46:01
#tdtech 端的にAt least onceの共有バッファをどうするか。
posted at 17:42:08
Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp@Guutara
細かいファイル問題(細かいパケット、細かいIOも同じ問題抱えるケースが多いなあ)を聞いている。スループット、アベイラビリティ、コスト、もろもろ。 #tdtech
Retweeted by Sotaro Kimura
retweeted at 17:40:20
#tdtech 全部次期プロダクトが解決してくれるw
posted at 17:26:39
#tdtech TTLを一部設定したら探索が止まってもともとのTTLのも消えにくくなる。これは。。。
posted at 17:21:49
でた detach_process Fluentdの闇の機能…… #tdtech
Retweeted by Sotaro Kimura
retweeted at 17:12:47
#tdtech 辛いっちゃ辛い話ですが、地道に問題解析して淡々と解消している流れはそれはそれで。。。
posted at 17:12:36
#tdtech pig Latin integrationリタイア、本当に心から羨ましい。。。(個人的な怨嗟です
posted at 17:02:24
#tdtech 定常集計のカテゴリわけ、データエンジニアとデータアナリスト、事業担当&マーケと。こういう形で段階的に切れる方が揃っているのは羨ましい所です。。。
posted at 16:37:11
#tdtech こういうフィードバックサイクルをユーザとできるのは貴重な環境ですね
posted at 16:29:01
あえてプアなUIにしといてユースケースを探る打たせて取る的なスタイル、参考にしたい #tdtech
Retweeted by Sotaro Kimura
retweeted at 16:28:00
「この画面、SEだけが使うっていう話だったんで2週間でちゃちゃっと作ったら普通にマーケターの人たちが使うようになっちゃって、使いにくいって言われてる」あるある系の話だ #tdtech
Retweeted by Sotaro Kimura
retweeted at 16:02:18
「TDはシステムはスケーラブルだけど人がまったくスケールしない」 #tdtech
Retweeted by Sotaro Kimura
retweeted at 15:13:55
digdagのオペレータとクエリをパースした結果を元に、AirflowのTreeviewみたいなのを表示できるようにしたい・・・
Retweeted by Sotaro Kimura
retweeted at 15:11:39
#tdtech 人はスケールしない。TDみたいな突き抜けた組織でも、一番厄介な問題は変わらないという感じですかね。。。
posted at 15:10:28
よくあるケースはここにまとまって公開されております https://github.com/treasure-data/workflow-examples… #tdtech
Retweeted by Sotaro Kimura
retweeted at 15:04:49
joker1007 (アルフォートおじさん)@joker1007
やっぱリアルタイムデータを直でDynamoDBには書けんよね。スケールするインメモリDBが必要で、そこに溜めた後にflushする仕組みにしないと駄目か。 #tdtech
Retweeted by Sotaro Kimura
retweeted at 14:57:36
#tdtech dynamoのキャパと価格との戦い。。。そういえば過去結構な利用料金をふっとばした記憶が。
posted at 14:50:04
#tdtech カスタマーテーブルとふるまいテーブル、見事なスタースキーマ。言ってしまうと人を軸にした巨大DWHなわけですか。
posted at 14:41:40
#tdtech Prestoというのがミソですか。メッセージキュー系のコネクタもあるので、リアルタイムにつながる線もある。。。
posted at 14:36:12
今日お話しさせて頂いた資料です
https://speakerdeck.com/smdmts/how-to-growth-the-delish-kitchen-team-to-data-driven-team… #tdtech
Retweeted by Sotaro Kimura
retweeted at 14:33:21
#tdtech デモ画面、JOINの定義見るだけで気が遠くなりそうな。。。これを画面からで出来ればリアルタイムってなかなか無茶な。
posted at 14:32:34
#tdtech 分析の敷居を徹底的にさげる、中間テーブルを作る、KPIの可視化グラフを沢山作ると。実際にこれを地道にやらないと文化は変わりませんよね。。。
posted at 14:10:26
TD、比較的最近ですがリソースプール機能が導入されて、顧客側で使えるリソースを分離・配分して重要な定期クエリに必要なリソースは別途確保できるように。これは運用でまじ重要なやつ。 #tdtech
Retweeted by Sotaro Kimura
retweeted at 13:58:46
24時間以上走り続けるクエリとかちょいちょいありまして、これがクエリエンジンのクラスタメンテナンスにおいて極めて重要な問題が……ぎぎぎ技術的面白さに #tdtech
Retweeted by Sotaro Kimura
retweeted at 13:53:42
#tdtech データが貯まり続けて手も足もでないは、胸にぐっさり刺さるものが。。。
posted at 13:51:13
「TDのお客さんじゃない方どのくらいいらっしゃいますか……あ、多いですね、よかった」よ、よ、よかった……いやまさにだからこそトークをお願いしているのです! よかった! #tdtech
Retweeted by Sotaro Kimura
retweeted at 13:48:52
#tdtech 当然のようにパーティショニング最適化は検討中ですか。この手のワークロードとの調整は面白そうですね。
posted at 13:47:19
まさにその通りで、検証中という段階になっています・・・ https://twitter.com/kimutansk/status/965445133519826945…
Retweeted by Sotaro Kimura
retweeted at 13:44:56
@nora96o やはりそうなりますよね。そのあたりの最適化提案や調整が自動で走ると、デメリットを軽減できそうではあります。既に検討されているとは思いますが
posted at 13:44:48
#tdtech 時間範囲が動的になるということは、ArchivedのPlazma側とのマージなど、色々考えることはありそうですが、その分おもしろそうではあります
posted at 13:39:37
#tdtech パーティショニングで区切れはするのですが、メタデータテーブル肥大化とS3のアクセス数が増えますが、そのあたりのデータの特性毎のメリットデメリットが気になるところですね
posted at 13:37:11
#tdtech 問題発生、情報残ってない、はあるあるで生々しい。。。
posted at 13:10:29
色々コスト試算の結果とかを見てきて、クラウドに乗せるべき・・・はわかりませんが、乗せるべきではないシステム・サービスについては若干見えてきた気はします。 あとは、乗せるべきではないけど乗ってる(という記事がいくつかある)サービスが実際に存続するかを今後定点観測してみますかね。
posted at 11:52:36
Partitionオートスケールと、Tier分割による無期限保存がKafkaやPulsarと比して機能的には勝りますが、実際全保持するかというと、どうなりますかね。同一APIで古いものも読めるいうのは有利な点ではありますが。 http://htn.to/2kKaPV
posted at 10:51:09
KafkaがTransactional投入をサポートしたので、それでExactly onceを実現する内容ですか。データを保存し、PreCommitが全て済んだ後外部Commitをリトライし続けるアプローチですが、Kafka側でA… http://htn.to/5KnVw2
posted at 10:38:15
KafkaやPulsarみたいなメッセージバス系のOSSで、FlinkのコネクタもGitHubにはあると。Weekly読んでるとHDFSへの自動アーカイブとかもあって、それはそれでいいっちゃいいのですが。 / “Streams …” http://htn.to/Q65VpgCa
posted at 10:30:54