企業(yè)大數(shù)據解決方案-大數(shù)據企業(yè)架構分析

大數(shù)據企業(yè)架構討論案例研究：智慧交通大數(shù)據實時處理和分析目的：提高城市交通的科學管理和組織服務水平業(yè)務目標?

智能交通數(shù)據的有力支撐?

智能交通公共信息服務的實時傳遞和快速反應的應急指揮?

智能交通業(yè)務聯(lián)動快速應對變化?

可視化事件跟蹤挑戰(zhàn)?

近千萬輛轎車、軌道交通、快速公交系統(tǒng)?

高并發(fā)事件及數(shù)據流的實時處理?

海量非結構化大數(shù)據的組織與分析?

壓力傳感器傳感

?

速度傳感器器

?

生物傳感器?

溫度、濕度……RFID?

射頻天線掃描?

電子標識攝像 ?

高速拍照頭 ?

高清攝像頭3車地雙向實時無線通信網數(shù)傳電臺政府專網InternetGPRS/CDMA/3G/Wi-Fi/WiMax光纖TCP/IP公路可視化綜合信息平臺雷達測速 GIS公共交通運營管理平臺監(jiān)控 車次號識別緊急救援 CBTC旅行時間 路徑識別城市綜合信息管理平臺通信ETCPIS信號BRT公交調度管理電警接處警 卡口交通誘導 信號控制出行者信息系統(tǒng)視頻監(jiān)控智能停車場電子站牌事件檢測用戶服務政府

企業(yè)個人公共感知層/信息采集網絡層/信息傳輸應用層/信息處理水運綜合管理平臺ITS智能交通物聯(lián)網平臺交通行業(yè)信息服務智能交通整體規(guī)劃架構鐵路綜合管理平臺4?深度分析?敏捷開發(fā)?高度擴展性?實時分析結果?大吞吐量?實時準備?所有的數(shù)據源及數(shù)據結構?低延時?高并發(fā)的交易?高度靈活的數(shù)據結構數(shù)據獲取數(shù)據傳輸數(shù)據處理數(shù)據是智能交通的核心數(shù)據獲取數(shù)據傳輸

數(shù)據處理People. Process. Portfolio.Discussion實時事件處理

—

概念圖解業(yè)務場景?

重要車輛監(jiān)控?

交通誘導?

出行者信息?

技術機遇?

實時處理大數(shù)據量?

合并歷史事務和實時事務架構決策?

實時流?

利用現(xiàn)有分析?

最大限度地減少數(shù)據移動實時批處理流（CEP

引擎）警報BPEL?

移動?

信息板?

數(shù)據庫NoSQLHDFS實時分析數(shù)據流實時數(shù)據源CEPRDBMS實時位置NOSQL外部數(shù)據庫黑名單小型機歷史事務備份歷史配置文件RDBMS事務歷史數(shù)據源計算配置文件實時事務（基于消息）Hadoop集群事件處理規(guī)則和結果關聯(lián)和分析

—

概念圖解NoSQLBI平臺與分析業(yè)務機會?

行車路線建議?

信號控制?

交通流量分析技術選擇?

將縮減結果集成到關系數(shù)據庫?

構建另一個環(huán)境?

手動關聯(lián)架構決策?

使用集成元數(shù)據?

使用標準

BI

平臺?

最大限度地減少數(shù)據移動數(shù)據倉庫數(shù)據集市數(shù)據庫中的

分析MapReduceHDFS實時處理和分析

—

邏輯圖解關鍵組件Oracle

大數(shù)據機Oracle

ExalogicOracle

CEP/CoherenceOracle

SOA

SuiteOracle

大數(shù)據連接器Oracle

ExadataOracle

Advanced

AnalyticsOracle

ExalyticsOracle

BIFoundationOracle大數(shù)據機Oracle大數(shù)據連接器Oracle

ExadataOracle

ExalyticsInfiniBandInfiniBandOracleAdvanced

AnalyticsOracle

BIHDFS

和

NoSQLMapReduceCEP/SOACoherence消息流Oracle

ExalogicPeople. Process. Portfolio.Discussion問題?

請為自己公司/單位設計一個大數(shù)據的解決方案。分組討論結束之后，每組派一到兩個代表上來講一下這個方案? A)

公司里存在哪些數(shù)據? 結構化/多結構化/大小/實

時數(shù)據/流式數(shù)據? 公司是否已經應用了非關系型數(shù)據庫? B)那些業(yè)務考慮引入大數(shù)據? C)有了這些大數(shù)據，如何設計公司的大數(shù)據平臺? D)公司數(shù)據的問題或者遠景? 企業(yè)的數(shù)據架構遠景岳‘.＿←..’...＠。同ACL1a:>

.a呂.""S<案例：Facebook數(shù)據倉庫架構Hadoop@Facebook世界上第二大Hadoop集群用于處理

log

和dimension

dataUse

Case? 從大量數(shù)據中產生每天和每小時的匯總.在歷史數(shù)據中執(zhí)行

ad

hocjobs? 事實上作為一個長期的數(shù)據歸檔? 根據特定屬性來查找log,

可用于維護站點的一致性，保護用戶免受垃圾郵件影響13Hadoop

Map/Reduce實時分析

—

真實情況Real

time(msec/sec)Near

real

time(Min/Hours)Batch(Days..)Hadoop/Hive..Not

realtime.

Many

dependencies.

Lots

ofpoints

of

failure.

Complicated

system.

Not

dependableenough

to

hitrealtime

goals

(

Alex

Himel,

EngineeringManager

atFacebook.)“With

the

paths

that

go

through

Hadoop

[at

Yahoo!],

thelatency

isabout

fifteen

minutes.

…

It

will

never

be

truereal-time..”

(Yahoo

CTO

Raymie

Stata)"MapReduce

andother

batch-processing

systems

cannotprocess

small

updates

individually

asthey

rely

on

creatinglarge

batches

for

efficiency,“

(Google

senior

director

ofengineering

Eisar

Lipkovitz)實時分析

—

傳統(tǒng)的分析應用?垂直擴展(Scale-up)數(shù)據庫–使用傳統(tǒng)的SQL數(shù)據庫–使用存儲過程生成事件驅動報表–使用閃存盤，以減少磁盤I/O–使用只讀副本橫向擴展(Scale

Out)只讀查詢?限制：–無法寫擴展–昂貴的成本(HW&SW)實時分析

—

Complex

Event

Processing(CEP)?當數(shù)據到來時立即處理數(shù)據?維護內存數(shù)據窗口?優(yōu)勢：–延遲極低(mS級)–相對低的成本?劣勢：–難于擴展(橫向擴展局限)–不敏捷（查詢必須預生成）–實現(xiàn)非常復雜實時分析

—

In

Memory

Data

Grid?分布式內存數(shù)據網格?橫向擴展(Scale

out)?優(yōu)勢：–

讀/寫可擴展–

適合事件驅動(CEP

style),ad-hoc查詢模式?劣勢：–

相比磁盤，內存成本昂貴–

內存容量有限實時分析

—

No

SQL?使用分布式數(shù)據庫–

Hbase,

Cassandra,

MongoDB?優(yōu)勢：–

讀/寫可擴展–

海量數(shù)據支持–

彈性?缺點：–

讀延遲，實時性差–

弱數(shù)據一致性–

不成熟-非常新的技術Facebook實時分析系統(tǒng)（實時+批量）Memory

GridPTailPuma3Facebook實時分析-

Put

all

together?內存數(shù)據網格?實時處理網格–輕量級事件處理–Map-Reduce–事件驅動