「SugarCRM」＆「Talend」活用セミナーに行ってきた！

５月１５日に、個客はあなたのことを知っていますか?「SugarCRM」＆「Talend」活用セミナーに行ってきた！その内容をメモメモ！

---

■データキュレーションさんの話

・顧客にする為のコンテンツマーケティング
・用語
　　潜在顧客
　　顕在顧客　特定できない
　　見込顧客　コンタクト先が分かる　リード　そのうち客
　　案件顧客　まだ買っていない　パイプライン　いますぐ客
　　顧客　　　買っているカスタマー
　　上顧客　　ロイヤルカスタマー

　　STP
　　（セグメンテーション
　　　ターゲティング
　　　ポジショニング）
　　　　　　　　　リードジェネレーション
　　　　　　　　　　　　　リードナーチャリング
　　　　　　　　　　　　　　　　　　　　カスタマージャーニー（UXから見ると）
　　　　　　　　　　　　　　　　　　　　コンテンツマーケティング
　　　　　　　　　シナリオプランニング

・企業のWebサイトって見たことありますか？
　　→基本的に何か興味が無い限り、Webサイトは来ない

・ランディングページ：誘導したいページ
　　→トップページではない

・シナリオ大事：コンテンツマーケティング
　　順序：シーケンスが重要
　　　　　ハードルを下げる

・消費者行動はモデル化されている
　　　AIDMA
　　　AISAS オンライン
　　　認知段階→感情段階→行動段階

・激変した注意関心（認知段階）の環境
　　　マスマーケティング→マイクロ、One to one

・個客；個人を特定できる客
　　net perception
　　　　できなかったことが安く出来るようになったのは技術のおかげ
　　DMP：デジタルマネジメントプラットフォーム

・見込み顧客リストを
　　　集める：リードジェネレーション
　　　使う　；リードナーチャリング

・見込み顧客リストを集めて使う全体の流れ
　　　製品、サービスについて考える
　　　ターゲット属性について考える・・・ペルソナ
　　　キーワードの開発・・・バックエンド：売りたい製品
　　　フロント製品を決める・フロント製品：撒き餌
　　　ランディングページ・・アクセスさせる
　　　ナーチャリングする

・製品：３つに分かれる
　　　売りたい商品
　　　売れる商品
　　　フロント商品

・見込み顧客をどう集めるか
　　コンテンツマーケティング：価値あるコンテンツを定期的に、段階を踏んで
　　コンテンツをどのように考えればよいか
　　　→カスタマージャーニー
　　　　ペルソナを決めて→タッチポイント→どう思考するか？
　　　　　インサイト・・洞察、アクションの課題
　　　　　　　→解決としてアクション、やるべきことは何か

・コンバージョンレート

・CRM
　　お客さんが分かったときに受注に繋がる
　　マーケティング・オートメーション→データを分析して
　マーケティングDBを作る・・・SFA,CRM

・既存顧客についてよく知る
　見込顧客についてよく知る

・データをどのように活用するかが重要
　課題から考える
　　　データから来ると発散する

---

■SugarCRM

日本市場のCRMに対する意識
　　SaaSによるSFA、リード管理：安定期

１０年前の（期待から幻滅）とどう違うか
　　いままで求められたもの：
　　　　　売上向上
　　　　　営業の標準化
　　　→期待度は高いがすぐに結果でない
　　　　導入まで時間かかる
　　　　現場こんらん

　　今求められているCRM
　　　　短期導入、長期視点
　　　　わかりやすさ、柔軟性

ぱっと顧客が分かるSugarCRM

事例

個をCRM

革新・柔軟・価格
　　GUIによる開発ツール
　　Web　API　制限ない（SOAP,REST)
　　インテグレーション・エコシステム

本格的なワークフロー

SugarCRM、Stitch（すてぃっち）を買収

販売：日本では間接販売（代理店を通す）

---

■Talend

・データ統合
　　手作り
　　ETL
　　Talend

・データインテグレーション→ビッグデータ

・ESB　エンタープライズサービスバス：リアルタイムメッセージ

・Talend Data Service

・マニュアル新しくした

・富士通SSLで販売（代理店）

---

■富士通SSL　２つの事例

事例１：コールセンター
・３００コール、５０席
・通信系
・IP-PBXでIVRに着信する
　　→交換機は、astima CCE(Asteriskベース)
・大幅コストダウン要求（３０％）
　　実物を利用して仕様検討
　　SugarCRMコンポーネント利用

事例２：製薬業　MS（マーケティング・スペシャリスト）
　　→提案型営業
　　　コミュニケーションツール　SugarCRM
　　　MSの行動マネジメント

　

NoSQLのApache Cassandraを知ろう！

（３時間無料セミナー）NoSQLのApache Cassandraを知ろう！に行ってきた！その内容をメモメモ

---

NoSQLのApache Cassandraを知ろう！

Apache CassandraとはIoT向けデータベース

Google BigTable
Amazon DynamoDB
　この論文からＮｏＳＱＬきてる

Apache Cassandra 2010年ごろ盛り上がる
　→facebookが作った
元気なくなる
　→Facebookがやめた
　　実際のところ、インスタグラム、ゲームなどの裏ではつかってる
　　タイムラインでは使っていない
最近盛り返す
　→Appleが大々的に発表　27000台、数十ペタバイト
　　また注目
　→Sony PS4のマイプレイステーションの

内容は変わらない：大量のデータをスケーラブルで
　必要のないときマシン削除できる→クラウド向け
アメリカの小売店：ブラックマンデー
　ＰＯＳメインフレームを使ってた→その日だけ１００％
　Cassandraに変えると・・サーバー倍にして処理

ＤａｔａＳｔａｘ
　Cassandraはオープンソースで無料
　サポートとかをカバーするのがDatastax
　　→Apache Cassandraのディストリビューション
　　　　すぱーく　　
　　　　そらー
　　　　たいたん：グラフＤＢ
　　などをつける

DSE(でーたすたっくえんたーぷらいず）製品
　　Linux→Cassandra
　　RedHat→DSE

レガシーＲＤＢＭＳ　not ビッグデータ？
３つのＶ
　　Volume（量）：桁違いのデータ量
　　Velocity（頻度）：高頻度でのデータの発生
　　Variety（多様性）：様々な種類のデータ
そもそも、ＲＤＢでできるのか？

ＮｏＳＱＬって何？位置づけ

ＯＬＴＰ　　　　ＤＷＨ
ＲＤＢＭＳ　　（ＲＤＢＭＳ）

ExaData ８億をなんだいも・・

　　　　↓
NoSQL　　　　　Hadoop

ＯＬＴＰ　　　　ＤＷＨ
ＲＤＢＭＳ　　（ＲＤＢＭＳ）

ＲＤＢとは違う段階、違うニーズ
ＲＤＢで大変だったところをHadoopで

ＮｏＳＱＬは大量のデータでないと必要ないの？
・・１Ｔ、２Ｔでいいケース：ありま～す
そこを見極めないとデスマーチ

Relational？ NoSQLって何
　　NoSQL＝Not only SQL？
　　データベース≠RDBMS
　　　　OR
　　Post Relationalだとおもっています

オペレーショナルＤＢ　ＶＳ　分析ＤＢ
Operational Database
　２００６
　２００７
　　　ＮｏＳＱＬ

分析ＤＢ
　２００３　Ｈａｄｏｏｐ　Ｇｏｏｇｌｅファイルシステム
　２００４　ＭａｐＲｅｄｕｃｅ

ＤＢで使えるようになるのは７年
ブリティッシュ　Ｇａｓ
　　地に付いたＤＢ

The 451 group.com

RelationalにするかNoSQLにするか

Relational
　　論理データモデル
　　物理データモデル
　　テーブル
　テーブルがあってＳＱＬを作る

Ｗｅｂ系、ゲーム系：毎日スキーマが変わる
ＩｏＴデバイス：各マシンのフォーマットは違う
　　→ＲＤＢだとマスタマネジメント必要
　　→ＮｏＳＱＬ：そのままつっこめ
→渋谷かいわいでＮｏＳＱＬを使う理由
　　そのほうがわかりやすい
→でーたのヂュプリケートがおこる
　　　→データは２重持ちしちゃいなさい

メインフレーム：非正規化
リレーショナル：正規化
ＮｏＳＱＬ：二重もち、大福帳

オペレーショナルデータベース

トラでショナル：ＲＤＢＭＳ
どうでもいいもの
ＩＯＴ：ＲＤＭＳ以外

　　　　↓

全部ＲＤＢＭＳ？

繋がるネット時代の新技術
１９７０年代　階層ＤＢ
１９８０年代　リレーショナル
２０１０移行　コンテンツ・データを中心に

■NoSQLのApache Cassandraを知ろう！
Cassandraとは
Ｇｏｏｇｌｅ
　　スキーマ
　　めむてーぶる
　　こんぱくしょん
　　ＳＳてーぶる
　　こみっとろぐ

Ａｍａｚｏｎ
　　あーきてくちゃ
　　分散
　　レプリケーション
　　ごしっぷ（ぷろとこる）

おもしろいかんがえ
・マスターというのがない→単一障害点がない
・クラウド、オンプレミス共用にできる
・リニアなスケーラビリティ→マスタがないから

It's Always On
・Net Flix
　カオスモンキー：ランダムに殺す
　ＡＷＳのリブート：１００％サービス

ゲーム会社：初日がピーク
　レイテンシーは変わらない

なぜＤＳＥ
　　開発用ドライバー無料
　　ＧＵＩは半分無償半分有償
　有償
　　セキュリティ
　　ＱＡされた
　もう一こ上
　　インメモリー
　　分散エンジン
　　全文検索エンジン
　　エンタープライズ・セキュリティ

あなたはすでにDataStaxを使っているはず
　　ニュースサイト
　　オンラインショッピング
　　　　：
　　　　：

■Cassandraの用語
・Cassandraノード
　　サーバーまたはマシーンまたはバーチャルインスタンス
　　１つのJVMが動く環境
　Cassandraはコモディティサーバーで使うように作られている
　　SANとかでなく
　　マシンは別々→安いサーバーでいい

・クラスター
　＝データベース
　３ノードの１クラスターＤＢといういいかた
　最悪１台のノードで１クラスター→それなら、Mongoのほうが。。
　ＨＡなら、最低３台がいいのでは→クラウド上なら
　オンプレの場合、４台のマシンが１ヶ月しんでも

・データセンター
　　アメリカとＪａｐａｎ：べつべつのところにデータを置く
　　→１クラスターの中でできる
　　Create Tableするときにできる

　論理データセンター
　物理データセンター

・ワークロードでのデータセンターでの分割
　　データセンター３箇所（東京、サンフランシスコ、クラウド）
　　　東京でオペレーション＆分析→遅くなる
　　　３箇所に分析をかける→いままではＥＴＬかゴールデンゲート
　接続先は？
　　アプリケーションを書くときに、どこに接続するか意識して書く
　　ただし、ローカルの場合、ローカルファースト

・クラスタ
　　８台のノード：データ分散して持っている
　　　ケータイ：うらがCassandra→５個コピー

・Cassandraのデータ・パーティション分割の概要
　分散ストラテジ２つ
　　　ランダム→デフォルト
　　　順序指定→偏ってしまう
　レプリケーション係数（ファクター）
　　　１：１台　５：５台
　　クラスターの中で、どっかにもつ

　キーにハッシュをかけてトークンを作る→どこに行くのか決まる

・レプリケーションストラテジー
　　　データセンターのどこのラックに持たせるまで指定できる
　　　→ネットワークトポロジー（あんまり使わないかな・・）
　Create Keyspaceをするときに指定できる

・スニッチ
　　順番を決める

・ゴシップ：ノード間のコミュニケーション
　　「あいつ死んでるらしいぜ！」というのを各マシンへ
　　　→伝えていく

・ロードバランス
　　ラウンド・ロビン
　　データセンター認識ラウンドロビン
　　　　ローカルを先に認識、なかったらリモート

・容量の追加：かんたん

・バーチャルノード(Vnodes,仮想ノード）
　　追加したとき５台に１台ついか　５分の１づつ渡す
　　場所に依存しない

・１つのノードがダウン
　　　→何個に書き込めたら良いのか・・
　　　　調整可能なデータ整合性
　　もし、ＡＬＬとやってしまったら、２フェーズコミットと同じ
　　Ｏｎｅ
　　Ｑｕｏｒｕｍ

・データが一致しないとき
　　タイムスタンプを見て判断
　　ヒントつきハンドオフ→タイムアウト有り
　　リペアで整合性
　　いつかは同期する

・ＡＰＩのコネクターとドライバー

・ＤａｔａＳｔａｘＯｐｓＣｅｎｔｅｒ

■Cassandraスキーマ
・カラム及びその構成要素
・テーブル
・キースペース

概観
・キースペース
　　テーブル：複数の行、パーティションから
　　　パーティション：桁
　　　　　カラム

カラムの構成要素
・カラムはＣａｓｓａｎｄｒａの基本的なデータのタイプ
　　カラム名
　　カラム値
　　タイムスタンプ
　　ＴＴＬ（任意）

カラム名
・必須
・任意の値、任意の型→タイムスタンプをカラム名にしてもＯＫ
・テーブルで一意
・かならず値とともに格納

カラム値
・任意の値、型
・空でもＯＫだが、必須

カラム値のデータ型はバリデータ
カラム名のデータ型はコンパレータ

データ型はいろいろ

カラムのタイムスタンプ
　　６４ビット整数
　　ベストプラクティス
　　　：すべてのクライアントで一貫性のある形で作成
　　必須

カラムのＴＴＬ
　　Insert時に定義
　　期限を整数値で定義（秒単位）

特殊なカラム型
　　カウンター
　　　　加算／減算が可能
　　コレクション
　　　　以下の２つのコレクション型
　　　　　ＳＥＴ：ＣＱＬのコンパレータでソート
　　　　　Ｌｉｓｔ：順序を指定して
　　　　　ＭＡＰ：キーはコンパレータでソート

テーブル（カラム・ファミリー）
・ＲＤＢにおけるテーブルに似ている
　　パーティション（行）の集まり
　　調整可能な整合性
　　非正規化
　　　Ｉ／Ｏの回避
　　　読み取りパスを簡素化するため
　　　静的または動的　　　

静的なテーブル
・ＲＤＢのテーブルに似ている
動的なテーブル
・Wide Rows(横に伸びていく）
パーティションのクエリーに対して応答が得られるように構造化

ＣＱＬ行とストレージ行（パーティション）
キーの構造
　　パーティション（行）キー
　　クラスタ化キー
クラスターか順序
　　何もしなくてもディスク上でカラムをソート
　　順序は変更可能
ソート
　クラスター化カラムはORDER BYの対象にできる

複合パーティションキー
　Initial Token
　先頭トークン値から次のノードのトークン値までが担当になる

静的カラム
１つのパーティションの中で、同じパーティションの全ての行によって共有される特殊なカラム
たとえば、キーに対する名前など

サイズ制限
・テーブルのサイズ上限＝クラスターのサイズ上限
・１つのパーティション→１つのノードに収まる必要アリ
・理論上は２０億まで、カラムをもてます
・カラム値（セル）の最大サイズは２Ｇ（現実派１０Ｍ程度が妥当）
・ヒープサイズ
　　１個テーブルをもつと、１メガバイト→テーブル数を増やさない

キースペース
・テーブル（カラムファミリー）の集合体
・レプリケーションストラテジ設定
・レプリケーション係数を設定

Cassandra Query Language CQL
・ＲＤＢのＳＱＬに似ている

Datastax DevCenter
　　CQL分を作成して実行できる無償のビジュアル・クエリー・ツール

バッチの構文
→一階書き込んで実行
LWT(Lightweight Transaction)IF notができる

■データ・モデリング
クエリーを基準としたデータモデリング
・クエリーから考える：どういったデータを引っ張りたいのか
　　非正規化する
　　データが重複してよい

・ユースケース
　　製品カタログ
　　ＩｏＴ
　　レコメンデーション
　　不正検知

■ショッピングカーと
・ダウンタイムが発生しない
・オンラインの買い物客はスピード大事
・スケールすることも重要
・Cassandraでは、必要な情報を全て１つのテーブルのパーティションに保持する

・利用者はそれぞれ１つまたは複数のショッピングカートを持てる
　　　→ユーザー名とカートの複合パーティション

■ユーザー・アクティビティの追跡
　・挙動にリアルタイムで反応
　・バッチでは遅すぎる

ユーザーアクティビティのモデル
長期の行動データはバッチに持っていける

ユーザーが行った行動のテーブル
　ユーザー名
　時間
　ＴＴＬを入れておく

永続的データ

書き込みは早い

モデルを使う

■ログ収集
・全てのログデータを高速で収集
・ログの生成場所に近いCqassandraを使う
　　複数データセンターの利用
・ダッシュボード、参照など

・データを収集して様々なテーブルに振り分ける
　　・参照用のテーブル
　　・ログ：ダッシュボード

■インデックスの作成
→あんちパターン（できるけど）
・テーブルを使用したインデックス作成
・部分ワード・インデックス
・店番号と商品番号：複合行キー
・ビットマップインデックス
　　　挿入時に可能性を全部入れておく

■サーチ（検索）
・Solrの統合
・非常に高速なパフォーマンス
・solrの自動シャーディング（Cassandraレプリケーションによる）

■アナリティクス
・Hadoopとのインテグレーション
・Spark

■Javaドライバ
・ＣＱＬ３
　　昔のすりふと(Thrift)ベースのＡＰＩよりはるかに早い
　　英語でJavadocあるので見てね！

■まとめ
http://docs.datastax.com/ja/index.html

富士通フォーラムに行ってきた その２

富士通フォーラム行ってきた！のつづき

５月１４日の

インテルと富士通で創るIoTプラットフォームの新しい世界

をメモメモ（ちょこっとだけ）

---

■ご挨拶
インテルのミッション
　ムーアの法則のパワーを活用
　ゴードンムーアのムーアの法則５０周年

様々な機器へイノベーションを！

ビデオ

ダグ・デービス
・指数的に増えてる
ＩｏＴ：違う定義

スマートマニュファクチャリング
　システムの８５％はネットワークに未接続

IoT
　交通／自動車
　農業

ビデオ：ＩｏＴゲートウェイをつかえば・・
→マレーシアにおける稲作

エコシステム

インテルＩｏＴゲートウェイ
車からレコメンド
ワークスタイルの変革、業務システム変革
エコシステム

インテル社との協業

島根富士通の取り組み
・日本品質で日本でがんばってる→見える化
　　Ｉｎｄｕｓｔｏｒｙ４．０
　ナレッジインテグレーション