數據來源：系統中可以采集到的數據，如用戶數據、業務數據等，也包含系統運行時產生的日志數據等。
數據采集：不同數據源生成數據類型格式存在差異，在數據采集前可能增加數據總線(如京東JBus)對業務進行解耦，Sqoop和Flume是常用的數據采集工具。
Sqoop：用於和關系型數據庫進行交互，使用SQL語句在Hadoop和關系型數據庫間傳送數據，Sqoop使用JDBC連接關系型數據庫。
Flume：一個高可用、高可靠、分布式的海量日志采集、聚合和傳輸的系統。一個Flume代理由三個部分組成：Source、Channel和Sink。Source類似於接受緩沖器，將接收的事件存儲在一個或多個Channel中。Channel被動存儲事件，直到事件被Sink使用。Sink從Channel提取事件將其傳給HDFS或者下一個Flume代理。Flume使用不同的Source接收不同的網絡流，如使用Avro Flume接收Avro(一種數字序列化格式)事件。其支持的流行網絡流如：Thrift、Syslog和Netcat。
數據處理：包含實時的業務邏輯處理以及離線的數據整合存儲等。大數據框架多采用主從(Master/Slave)架構，存在Master單點故障的問題，多采用Zookeeper實現高可用性。
HDFS：分布式文件系統，由NameNode和一定數目的DataNodes組成集群。HDFS中數據通常有三個備份，用戶只需上傳1次數據，通過機架感知和水平復制自動備份數據。HDFS 2.0默認存儲文件大小為128M，適合存儲大文件。
Yarn：新的MapReduce框架。分布式主從架構，並行處理大數據。主要分文Mapper和Reducer兩個階段。Mapper主要對數據進行分類整理，Reducer實現數據的規約匯總。2.0版本中MapReduce存在大量IO操作影響效率，在大數據平台中多用Spark代替。
Spark：通用的大數據分析引擎，功能類似MapReduce。主要包含Spark Core，Spark SQL，Spark Streaming，Spark MLLib(協同過濾、ALS、邏輯回歸等算法庫)，Spark Graphx(圖計算)。
Hive：用於開發SQL類型腳本用於做MapReduce操作的平台，用於處理結構化數據。
Pig：用於開發MapReduce操作的腳本程序語言平台，用於處理結構化和半結構化數據。
Storm：流處理(實時計算)框架，不同於HDFS的批處理方式，Storm通過創建拓撲結構來轉換持續抵達的數據流，實時處理消息並更新數據庫。
數據挖掘：結合業務需求，合理選擇算法模式(包含機器學習)深入分析當前累積的海量數據，挖掘數據背后價值。
大數據應用：通過上述一系列復雜的數據處理，最終通過應用展示數據的價值。如基於系統日志的大數據分析平台，自動快速識別系統運行風險，及時通知相關人員跟進處理。
Apache Flink
Apache Flink是一種可以處理批處理任務的流處理框架。該技術可將批處理數據視作具備有限邊界的數據流，借此將批處理任務作為流處理的子集加以處理。為所有處理任務采取流處理為先的方法會產生一系列有趣的副作用。
這種流處理為先的方法也叫做Kappa架構，與之相對的是更加被廣為人知的Lambda架構(該架構中使用批處理作為主要處理方法，使用流作為補充並提供早期未經提煉的結果)。Kappa架構中會對一切進行流處理，借此對模型進行簡化，而這一切是在最近流處理引擎逐漸成熟后才可行的。
流處理模型
Flink的流處理模型在處理傳入數據時會將每一項視作真正的數據流。Flink提供的DataStream API可用於處理無盡的數據流。Flink可配合使用的基本組件包括：
Stream(流)是指在系統中流轉的，永恆不變的無邊界數據集
Operator(操作方)是指針對數據流執行操作以產生其他數據流的功能
Source(源)是指數據流進入系統的入口點
Sink(槽)是指數據流離開Flink系統后進入到的位置，槽可以是數據庫或到其他系統的連接器
為了在計算過程中遇到問題后能夠恢復，流處理任務會在預定時間點創建快照。為了實現狀態存儲，Flink可配合多種狀態后端系統使用，具體取決於所需實現的復雜度和持久性級別。
此外Flink的流處理能力還可以理解“事件時間”這一概念，這是指事件實際發生的時間，此外該功能還可以處理會話。這意味着可以通過某種有趣的方式確保執行順序和分組。
批處理模型
Flink的批處理模型在很大程度上僅僅是對流處理模型的擴展。此時模型不再從持續流中讀取數據，而是從持久存儲中以流的形式讀取有邊界的數據集。Flink會對這些處理模型使用完全相同的運行時。
Flink可以對批處理工作負載實現一定的優化。例如由於批處理操作可通過持久存儲加以支持，Flink可以不對批處理工作負載創建快照。數據依然可以恢復，但常規處理操作可以執行得更快。
另一個優化是對批處理任務進行分解，這樣即可在需要的時候調用不同階段和組件。借此Flink可以與集群的其他用戶更好地共存。對任務提前進行分析使得Flink可以查看需要執行的所有操作、數據集的大小，以及下游需要執行的操作步驟，借此實現進一步的優化。
優勢和局限
Flink目前是處理框架領域一個獨特的技術。雖然Spark也可以執行批處理和流處理，但Spark的流處理采取的微批架構使其無法適用於很多用例。Flink流處理為先的方法可提供低延遲，高吞吐率，近乎逐項處理的能力。
Flink的很多組件是自行管理的。雖然這種做法較為罕見，但出於性能方面的原因，該技術可自行管理內存，無需依賴原生的Java垃圾回收機制。與Spark不同，待處理數據的特征發生變化后Flink無需手工優化和調整，並且該技術也可以自行處理數據分區和自動緩存等操作。
Flink會通過多種方式對工作進行分許進而優化任務。這種分析在部分程度上類似於SQL查詢規划器對關系型數據庫所做的優化，可針對特定任務確定最高效的實現方法。該技術還支持多階段並行執行，同時可將受阻任務的數據集合在一起。對於迭代式任務，出於性能方面的考慮，Flink會嘗試在存儲數據的節點上執行相應的計算任務。此外還可進行“增量迭代”，或僅對數據中有改動的部分進行迭代。
在用戶工具方面，Flink提供了基於Web的調度視圖，借此可輕松管理任務並查看系統狀態。用戶也可以查看已提交任務的優化方案，借此了解任務最終是如何在集群中實現的。對於分析類任務，Flink提供了類似SQL的查詢，圖形化處理，以及機器學習庫，此外還支持內存計算。
Flink能很好地與其他組件配合使用。如果配合Hadoop 堆棧使用，該技術可以很好地融入整個環境，在任何時候都只占用必要的資源。該技術可輕松地與YARN、HDFS和Kafka 集成。在兼容包的幫助下，Flink還可以運行為其他處理框架，例如Hadoop和Storm編寫的任務。
目前Flink最大的局限之一在於這依然是一個非常“年幼”的項目。現實環境中該項目的大規模部署尚不如其他處理框架那么常見，對於Flink在縮放能力方面的局限目前也沒有較為深入的研究。隨着快速開發周期的推進和兼容包等功能的完善，當越來越多的組織開始嘗試時，可能會出現越來越多的Flink部署。
總結
Flink提供了低延遲流處理，同時可支持傳統的批處理任務。Flink也許最適合有極高流處理需求，並有少量批處理任務的組織。該技術可兼容原生Storm和Hadoop程序，可在YARN管理的集群上運行，因此可以很方便地進行評估。快速進展的開發工作使其值得被大家關注。