首先

• IAサーバ、アプライアンスのストレージ製品を中心にやってた。

 

• ビックデータ関連の仕事が増えたが基礎がない。。。

一から勉強中。

定着にはアウトプット必要だよね。→とりあえずかいてみる

基本知识

• データパイプライン：データ連携をするシステム全体

処理もろもろ

ストリーム処理：受け取ったデータをリアルタイムに処理
バッチ処理：ある程度まとまったデータを効率よく加工
ETL(ELT)：Extract(取り出し) Transforme(加工) Load(読み込み) の略。ELTは順が違う。

データの貯め方

DWH:長期保存用に整理したテーブル。テーブル設計が必要
データレイク：RAWデータをそのまま保存

分析

アドホック分析：その場限りの分析→手作業でデータ集計とか

基本的な流れ

データ集約　→　データマート　→ 可視化

数据的话题

データ格納

列志向がいいらしい：データ集計で考えると扱うデータは数列に絞れる→効率的

テーブルの呼び方

ファクトテーブル：トランザクションのように事実が記録
ディメンジョンテーブルファクトテーブルが参照するマスタ

统计的要诀

• ビックデータの集計 -> 早い段階でファクトテーブルを小さくする

 

• 分散システムの性能を活用するためにデータの偏りをなくす

 

• ->例えばWebページであれば特定のページがアクセスが多いとかある。

 

クエリエンジンには「ベストプラクティス」や「クエリ最適化」といったドキュメントがあるので参考にすると良い。

分布式处理

元件

• 分散ファイルシステム：HDFS

 

• リソースマネージャ：YARN,Mesos

 

• 分散データ処理：MapReduce,Spark

クエリエンジン：Hive,Impara,Presto

哈多普

火花

快速

• (Hiveとちがって)クエリ実行過程でディスク書き込みが発生しない。

 

• 同じキーを持つデータは同じノードに集められる(分散結合)

 

片方のテーブルが小さい場合は全データを各ノードにコピーすることもできる（ブロードキャスト結合）

数据集市的建立方法

• ファクトテーブルが重要

 

• ファクトテーブルの作成方法は２種類

追記
置換

他

サマリーテーブル
スナップショットテーブル
履歴テーブル

ディメンジョンで使うデータは定期的にスナップショットを取っておくと良いらしい(復元が楽〜)
ディメンジョンを追加して非正規化テーブル完成！

大数据的积累

消息传递的权衡

• 性能と信頼性はトレードオフ

 

大量のデータを安定して受け入れる仕組みが必要↓

消息代理

• データを一時的に蓄える中間層のこと

オープンソース：Apache Kafka
クラウド：Amazon Kinesis

プッシュ型：プロデューサがメッセージを送る
プル型：コンシューマがメッセージをもってくる

大数据的管道

工作流程管理工具

• 役割

定期的なタスク実行
異常を検知してその解決を手助けする

タイプ

宣言型：最低限の記述でタスクを定義
スクリプト型：柔軟性