大量的IT組織如今都已自己的數(shù)據(jù)架構(gòu)，因為都依賴于傳統(tǒng)的數(shù)據(jù)架構(gòu)。處理多數(shù)據(jù)源已不再新鮮；這些架構(gòu)已經(jīng)連接了多維度的數(shù)據(jù)源例如 CRM 系統(tǒng)，文件系統(tǒng)和其他商用系統(tǒng)。主要運行的關(guān)系型數(shù)據(jù)庫有 Oracle, DB2和Microsoft SQL.
如今，一般的數(shù)據(jù)分析周期是運行一些周期性腳本直接從數(shù)據(jù)庫提取和處理數(shù)據(jù)。這些主要由 ETL工具如 Informatica 或者 Talend. 目標是將這些提煉的數(shù)據(jù)加載到數(shù)據(jù)倉庫用于將來的分析。
不幸的是，這一方法在周期結(jié)束后可能不適合商務(wù)的需要了。這些數(shù)據(jù)流水線可能需要幾個小時，幾天甚至幾周才能完成，但是商務(wù)決策的需求可能已經(jīng)變了。除了處理時間，還有一些數(shù)據(jù)的自然改變使這些架構(gòu)難于處理，例如 數(shù)據(jù)結(jié)構(gòu)重構(gòu)變化導(dǎo)致數(shù)據(jù)模型的重構(gòu)或者數(shù)據(jù)容量導(dǎo)致的伸縮性考慮。
由于不是分布式系統(tǒng)，所以系統(tǒng)擴展比較困難。數(shù)據(jù)庫需要高性能的CPU，RAM和存儲方案，對于硬件的依賴使系統(tǒng)的擴展性部署非常昂貴?，F(xiàn)在大多數(shù)IT組織已經(jīng)切換到基于Hadoop的數(shù)據(jù)架構(gòu)了。實際上，不僅是靈活性和技術(shù)成本，主要目標是一組商用主機分散處理負載，以及攝取海量的不同類型數(shù)據(jù)。
Figure 3-1 給出了這一架構(gòu)的拓撲圖。
Figure 3-1. Hadoop-based data architecture
下面看一下數(shù)據(jù)流水線的涵蓋范圍，包含了哪些技術(shù)，以及這種類型架構(gòu)的通用實踐。
處理數(shù)據(jù)源
如 Figure 3-1所示, 數(shù)據(jù)可以來自各種內(nèi)部或者外部的源，但是大數(shù)據(jù)還可以特殊地來自內(nèi)部應(yīng)用和設(shè)備的日志，例如社交網(wǎng)絡(luò)，開放數(shù)據(jù)，甚至傳感器。以社交網(wǎng)絡(luò)為例，IT組織感興趣的信息數(shù)據(jù)會像洪水般流入，但是其中包含了大量無用的信息。
因此，第一是存儲數(shù)據(jù)，然后對提取的重要信息進行處理。這些數(shù)據(jù)對銷售非常有用，尤其是當運行情感分析的時候，可以感知整個社交系統(tǒng)對產(chǎn)品或品牌的感受。
依賴于提供商，數(shù)據(jù)可能是結(jié)構(gòu)化的，半結(jié)構(gòu)化，或者非結(jié)構(gòu)化的。Listing 3-1 給出了一個半結(jié)構(gòu)化消息的示例.
Listing 3-1. Example of the Semistructured Data of a Tweet
{
"created_at": "Fri Sep 11 12:11:59 +0000 2015",
"id": 642309610196598800,
"id_str": "642309610196598785",
"text": "After a period in silent mode, going back to tweet life",
"source": "<a rel="nofollow">
Twitter for iPhone</a>",
"truncated": false,
"in_reply_to_status_id": null,
"in_reply_to_status_id_str": null,
"in_reply_to_user_id": null,
"in_reply_to_user_id_str": null,
"in_reply_to_screen_name": null,
"user": {
"id": 19450096,
"id_str": "19450096",
"name": "Bahaaldine",
"screen_name": "Bahaaldine",
"location": "Paris",
"description": "",
"url": null,
"entities": {
"description": {
"urls": []
}
},
"protected": false,
"followers_count": 59,
"friends_count": 107,
"listed_count": 8,
"created_at": "Sat Jan 24 15:32:11 +0000 2009",
"favourites_count": 66,
"utc_offset": null,
"time_zone": null,
"geo_enabled": true,
"verified": false,
"statuses_count": 253,
"lang": "en",
"contributors_enabled": false,
"is_translator": false,
"is_translation_enabled": false,
"profile_background_color": "C0DEED",
"profile_background_image_url": "http://pbs.twimg.com/profile_background_
images/454627542842896384/-n_C_Vzs.jpeg",
"profile_background_image_url_https": "https://pbs.twimg.com/profile_background_
images/454627542842896384/-n_C_Vzs.jpeg",
"profile_background_tile": false,
"profile_image_url": "http://pbs.twimg.com/profile_images/448905079673094144/
dz109X55_normal.jpeg",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/448905079673094144/
dz109X55_normal.jpeg",
"profile_banner_url": "https://pbs.twimg.com/profile_banners/19450096/1397226440",
"profile_link_color": "0084B4",
"profile_sidebar_border_color": "FFFFFF",
"profile_sidebar_fill_color": "DDEEF6",
"profile_text_color": "333333",
"profile_use_background_image": true,
"has_extended_profile": false,
"default_profile": false,
"default_profile_image": false,
"following": false,
"follow_request_sent": false,
"notifications": false
},
"geo": null,
"coordinates": null,
"place": null,
"contributors": null,
"is_quote_status": false,
"retweet_count": 0,
"favorite_count": 0,
"entities": {
"hashtags": [],
"symbols": [],
"user_mentions": [],
"urls": []
},
"favorited": false,
"retweeted": false,
"lang": "en"
}
從例子中可以看到，這個文檔是一個JSON，有一組字段，其中字符串的元數(shù)據(jù)來描述tweet。但有些字段非常復(fù)雜；有點數(shù)組有時候是空的，有時候有包含了一個數(shù)據(jù)集合，也有純文本來表示tweet的內(nèi)容。這就需要思考如何存儲這樣的數(shù)據(jù)。把數(shù)據(jù)放到HDFS是不足夠的；必須在技術(shù)的頂層建立一個元數(shù)據(jù)結(jié)構(gòu)來支持數(shù)據(jù)結(jié)構(gòu)的復(fù)雜性。這就是有時需要使用Hive的原因。
當處理海量成分混雜數(shù)據(jù)的時候，社交網(wǎng)絡(luò)是復(fù)雜性的代表。除了數(shù)據(jù)結(jié)構(gòu)，還需要將數(shù)據(jù)分類成邏輯上的子集以便增強數(shù)據(jù)處理的效果?？紤]以情緒分析的例子，從大數(shù)據(jù)集的非結(jié)構(gòu)化數(shù)據(jù)中得到有價值信息的位置來組成數(shù)據(jù)。例如，通用的方法是對數(shù)據(jù)進行時間分片使數(shù)據(jù)處理更加聚焦，比方說一年數(shù)據(jù)中的某個特定周。
也必須注意到要安全地訪問數(shù)據(jù)，多數(shù)采用象 Kerberos 或其他的認證提供者。但是如果數(shù)據(jù)平臺涉及到新的使用場景，首先要處理的是多租戶技術(shù)的安全性。然后，周期性地創(chuàng)建數(shù)據(jù)鏡像以便故障發(fā)生時從中提取。所有這些考慮都是標準的，而且可以幸運地由大量供應(yīng)商提供。這些開箱即用的軟件可以保證，或幫助你實現(xiàn)或者配置管理這些概念。
處理數(shù)據(jù)
當從源到目標的純粹傳輸時，數(shù)據(jù)傳輸時由ETL工具處理。這些工具有 Talend, Pentaho, Informatica, 或者 IBM Datastage ，這是大數(shù)據(jù)項目中最常用的軟件。但還是不夠的，還需要一些補充的工具例如Sqoop 來簡化數(shù)據(jù)導(dǎo)入或?qū)С?。在任何情況下，使用多種工具來攝取數(shù)據(jù)，通用的目標存儲是 : HDFS. HDFS 是一個Hadoop 發(fā)布版的入口; 數(shù)據(jù)需要存儲在這樣的文件系統(tǒng)中，以便于高層應(yīng)用和項目的處理。
當HDFS存儲在數(shù)據(jù)中的時候，然后如何訪問和處理它們呢？
作為一個例子可能是Hive，它在HDFS中創(chuàng)建了一種數(shù)據(jù)結(jié)構(gòu)，可以方便地訪問這些文件。這個結(jié)構(gòu)自身象一個數(shù)據(jù)表。例如, Listing 3-2 展示了一個處理tweet的結(jié)構(gòu)示例。
Listing 3-2. Hive Tweet Structure
create table tweets (
created_at string,
entities struct <
hashtags: array ,
text: string>>,
media: array ,
media_url: string,
media_url_https: string,
sizes: array >,
url: string>>,
urls: array ,
url: string>>,
user_mentions: array ,
name: string,
screen_name: string>>>,
geo struct <
coordinates: array ,
type: string>,
id bigint,
id_str string,
in_reply_to_screen_name string,
in_reply_to_status_id bigint,
in_reply_to_status_id_str string,
in_reply_to_user_id int,
in_reply_to_user_id_str string,
retweeted_status struct <
created_at: string,
entities: struct <
hashtags: array ,
text: string>>,
media: array ,
media_url: string,
media_url_https: string,
sizes: array >,
url: string>>,
urls: array ,
url: string>>,
user_mentions: array ,
name: string,
screen_name: string>>>,
geo: struct <
coordinates: array ,
type: string>,
id: bigint,
id_str: string,
in_reply_to_screen_name: string,
in_reply_to_status_id: bigint,
in_reply_to_status_id_str: string,
in_reply_to_user_id: int,
in_reply_to_user_id_str: string,
source: string,
text: string,
user: struct <
id: int,
id_str: string,
name: string,
profile_image_url_https: string,
protected: boolean,
screen_name: string,
verified: boolean>>,
source string,
text string,
user struct <
id: int,
id_str: binary,
name: string,
profile_image_url_https: string,
protected: boolean,
screen_name: string,
verified: boolean>
)
PARTITIONED BY (datehour INT)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION '/user/username/tweets';
可以看到，tweets 是一個表中的結(jié)構(gòu)，有一個子結(jié)構(gòu)來描述非結(jié)構(gòu)化文檔數(shù)據(jù)源的復(fù)雜性?，F(xiàn)在數(shù)據(jù)安全地存儲在HDFS中了, 由Hive來結(jié)構(gòu)化,準備作為處理和查詢流水線的一部分。作為一個例子, Listing 3-3 展示了所選數(shù)據(jù)哈希標簽的分布.
Listing 3-3. Top Hashtags
SELECT
LOWER(hashtags.text),
COUNT(*) AS hashtag_count
FROM tweets
LATERAL VIEW EXPLODE(entities.hashtags) t1 AS hashtags
GROUP BY LOWER(hashtags.text)
ORDER BY hashtag_count DESC
LIMIT 15;
因為提供了類SQL的查詢語言，通過Hive查詢數(shù)據(jù)非常方便。問題就是查詢時延；基本上等同于一個 MapReduce job的時延. 實際上, Hive 查詢被翻譯成一個MapReduce job執(zhí)行通用的處理流水線，這導(dǎo)致了長時處理。
當需要實時數(shù)據(jù)傳輸時，這就成為了一個問題，例如實時觀察最多哈希標簽的時候。對例如新興的技術(shù)如Spark來說，實時處理海量數(shù)據(jù)不再神秘。不但可以實時處理而且實現(xiàn)簡單。例如, Listing 3-4 展示了如何在MapReduce 中實現(xiàn)一個單詞計數(shù)功能。
Listing 3-4. Word Count in MapReduce (from www.dattamsha.com/2014/09/hadoop-mr-vs-spark-rdd-wordcount-program/)
package org.apache.hadoop.examples;
import java.io.IOException;
import java.util.StringTokenizer;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IntWritable;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Job;
import org.apache.hadoop.mapreduce.Mapper;
import org.apache.hadoop.mapreduce.Reducer;
import org.apache.hadoop.mapreduce.lib.input.FileInputFormat;
import org.apache.hadoop.mapreduce.lib.input.FileSplit;
import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;
import org.apache.hadoop.util.GenericOptionsParser;
public class WordCount {
public static class TokenizerMapper extends
Mapper<Object, Text, Text, IntWritable> {
private final static IntWritable one = new IntWritable(1);
private Text word = new Text();
public void map(Object key, Text value, Context context)
throws IOException, InterruptedException {
StringTokenizer itr = new StringTokenizer(value.toString());
while (itr.hasMoreTokens()) {
word.set(itr.nextToken());
context.write(word, one);
}
}
}
public static class IntSumReducer extends
Reducer<Text, IntWritable, Text, IntWritable> {
private IntWritable result = new IntWritable();
public void reduce(Text key, Iterable<IntWritable> values,
Context context) throws IOException, InterruptedException {
int sum = 0;
for (IntWritable val : values) {
sum += val.get();
}
result.set(sum);
context.write(key, result);
}
}
public static void main(String[] args) throws Exception {
Configuration conf = new Configuration();
String[] otherArgs = new GenericOptionsParser(conf, args)
.getRemainingArgs();
Job job = new Job(conf, "word count");
job.setJarByClass(WordCount.class);
job.setMapperClass(TokenizerMapper.class);
job.setCombinerClass(IntSumReducer.class);
job.setReducerClass(IntSumReducer.class);
job.setOutputKeyClass(Text.class);
job.setOutputValueClass(IntWritable.class);
FileInputFormat.addInputPath(job, new Path(otherArgs[0]));
FileOutputFormat.setOutputPath(job, new Path(otherArgs[1]));
System.exit(job.waitForCompletion(true) ? 0 : 1);
}
}
Listing 3-5 展示了Spark是如何做的 (Python).
Listing 3-5. Word Count in Spark
from pyspark import SparkContext
logFile = "hdfs://localhost:9000/user/bigdatavm/input"
sc = SparkContext("spark://bigdata-vm:7077", "WordCount")
textFile = sc.textFile(logFile)
wordCounts = textFile.flatMap(lambda line:line.split()).map(lambda word: (word, 1)).reduceByKey(lambda a, b: a+b)
wordCounts.saveAsTextFile("hdfs://localhost:9000/user/bigdatavm/output")
這就需要分割架構(gòu)成多個部分來處理特定的需求，一個是批處理，另一個是流處理。
架構(gòu)分割
當處理海量數(shù)據(jù)的時候，Hadoop 帶來了大量的解決方案，但也為資源分配和管理存儲數(shù)據(jù)帶來了挑戰(zhàn)，我們總是希望在保持最小時延的同時而消減成本。和其他架構(gòu)類似，數(shù)據(jù)架構(gòu)滿足了SLA驅(qū)動的需求。因此, 每個job不應(yīng)該均等地消耗每個資源，這就要求或者是可管理的，或者有一個優(yōu)先級系統(tǒng)，或者有相互獨立的架構(gòu)，硬件，網(wǎng)絡(luò)等等。
下面，將討論現(xiàn)代數(shù)據(jù)架構(gòu)如何按照SLA需要來分割不同的使用水平。為了方便解釋 , Figure 3-2.解釋了重新分區(qū)。
Figure 3-2. Modern data architecture
已經(jīng)看到, 架構(gòu)分成如下部分:
長時處理部分
短時處理部分
視圖融合部分
看一下每個部分，并解釋所影響的角色。
批處理
長時處理任務(wù)，或者批處理，是Hadoop的第一代實現(xiàn)，例如MapReduce, Hive, Pig, 等等. 這些jobs 趨向于處理海量數(shù)據(jù)，以及攝取數(shù)據(jù)或者聚合數(shù)據(jù)。使用HDFS作為數(shù)據(jù)的分布和調(diào)度，依賴所使用的發(fā)布版可以通過不同的工具來管控。
一般的, 這些任務(wù)的目標是保持數(shù)據(jù)的聚合計算結(jié)果，以及分析結(jié)果。已經(jīng)說過，批處理是大數(shù)據(jù)開始實現(xiàn)時的頭等公民，因為這是處理數(shù)據(jù)的自然方式：提取或采集數(shù)據(jù)，然后調(diào)度任務(wù)。批處理在完成聚合計算時要花費大量的時間。這些任務(wù)主要滿足商用系統(tǒng)的處理需要而不是處理數(shù)據(jù)流。 批處理非常容易管理和監(jiān)控，這是由于是單次運行，而流式系統(tǒng)需要連續(xù)監(jiān)控?，F(xiàn)在通過 YARN, 也可以管理批處理的資源分配。這種方式，使IT組織可以依賴每個批處理的SLA來分割批處理架構(gòu)。
處理優(yōu)先級
當對待批處理的時候, IT組織希望對操作和處理進行總體控制，例如調(diào)度或優(yōu)先處理某些任務(wù)。和大多數(shù)IT系統(tǒng)類似，一個數(shù)據(jù)平臺同樣開始于一個引導(dǎo)用例，而該用例可能影響到其他組織的其他部分，又要增加更多的用例到這個平臺上。一個簡單的轉(zhuǎn)化就是數(shù)據(jù)平臺變成了多租戶數(shù)據(jù)平臺，依賴不同的使用場景有著很多SLA。
在Hadoop 2.0和基于Yarn的架構(gòu)中，多租戶技術(shù)提供特性是允許用戶訪問同樣的數(shù)據(jù)平臺但在不同集群有著不同的處理能力。YARN 也允許運行非MapReduce應(yīng)用, 所以通過 ResourceManager和YARN 容量調(diào)度器,可以跨應(yīng)用類型來提供任務(wù)的優(yōu)先級。Hadoop 工作負載的分發(fā)由容量調(diào)度器完成。
這種配置優(yōu)雅地安排可預(yù)測的集群資源，給我們安全和充分利用集群。在任務(wù)隊列可以設(shè)置任務(wù)的使用百分比。Figure 3-3 解釋了這一概念。
Figure 3-3. YARN job queue
該示例解釋了三種隊列的不同優(yōu)先級: 高,低 , 和默認. 這可以翻譯成簡單的 YARN 容量調(diào)度器配置，見 Listing 3-6.
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>default,highPriority,lowPriority</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.highPriority.capacity</name>
<value>60</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.lowPriority.capacity</name>
<value>20</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.default.capacity</name>
<value>10</value>
</property>
每個隊列有一個最小的集群容量，而且是彈性的。這意味著如果有空閑資源，這個隊列可以被最小化執(zhí)行。當然，有可能是最大容量
見Listing 3-7.
Listing 3-7. Maximum Queue Capacity
<property>
<name>yarn.scheduler.capacity.root.lowPriority.maximum-capacity</name>
<value>50</value>
</property>
這一配置設(shè)置了容量, 所以一個人提交了一個(例如, 一個 MapReduce job),可以依賴所期望的需求提交到一個特殊隊列，見 Listing 3-8.
Listing 3-8. Submitting a MapReduce Job
Configuration priorityConf = new Configuration();
priorityConf.set("mapreduce.job.queuename", queueName);
通過 YARN 容量調(diào)度器, 批處理在資源管理上非常高效，在工業(yè)界有著大量的應(yīng)用，例如給推薦引擎分配比非重要需求的數(shù)據(jù)處理更多的資源。但是談到了推薦，大多數(shù)IT系統(tǒng) 現(xiàn)在是一短時處理任務(wù)，以及依賴于流架構(gòu)。
流處理
短時處理，或者叫流式處理, 用于攝取高吞吐量數(shù)據(jù). 流處理方案可以處理海量數(shù)據(jù)，而且是高分布，可伸縮，和容錯的。這種架構(gòu)解決了一系列的挑戰(zhàn)。已經(jīng)說過，一個主要目的是處理海量數(shù)據(jù)。盡管以前已經(jīng)有各種流式技術(shù)，但現(xiàn)在是高可用，彈性和高性能的。高性能是應(yīng)對數(shù)據(jù)容量，復(fù)雜性和大小的增長。
如果數(shù)據(jù)容量增長了，這些架構(gòu)能夠無縫集成各種數(shù)據(jù)源和應(yīng)用，例如數(shù)據(jù)倉庫，文件，數(shù)據(jù)歷史，社交網(wǎng)絡(luò)，應(yīng)用日志等等。這需要提供一致性的敏捷API，面向客戶端的API，以及能夠?qū)⑿畔⑤敵龅礁鞣N渠道，例如通知引擎，搜索引擎，和第三方應(yīng)用?；旧?，這樣的技術(shù)有更多實時響應(yīng)的約束。
最后，從流式架構(gòu)中，用戶最想得到的就是實時分析，需求很清楚，組成如下：實時發(fā)現(xiàn)數(shù)據(jù)，更容易地查詢數(shù)據(jù)，主動監(jiān)控事件的閾值以通知用戶和應(yīng)用。
流架構(gòu)首先用在金融領(lǐng)域，這里有著高吞吐量交易的使用場景，但是已經(jīng)擴展到大量其他的使用場景，主要是電子商務(wù)，電信，防偽監(jiān)測，和分析。從而誕生了兩個主要技術(shù)： Apache Spark 和Apache Storm.
這里選擇了Spark，有很好的社區(qū)支持，見Figure 3-4 .
Figure 3-4. Google trends of Apache Spark and Apache Storm
有專門的章節(jié)來描述如何將不同的技術(shù)結(jié)合起來，包括Spark的實時流處理和搜索分析。
Lambda 架構(gòu)的概念
前面談到將數(shù)據(jù)架構(gòu)分成三個部分: 批處理,流處理和服務(wù)架構(gòu). 盡管批處理還是現(xiàn)存IT組織中數(shù)據(jù)架構(gòu)的通用實踐，當還不能滿足大多數(shù)流式數(shù)據(jù)的真正需求，如果需要的話，需要將數(shù)據(jù)存儲在一個面向批處理的文件系統(tǒng)中。部署一個流式架構(gòu)不像IT組織批處理架構(gòu)那么簡單，與之對應(yīng)，流處理架構(gòu)帶來了更多的操作復(fù)雜性，架構(gòu)必須要設(shè)計成吸收無用突發(fā)數(shù)據(jù)以維持較低的響應(yīng)時間。
當感到Hadoop 發(fā)布版部署麻煩的時候，開始的方法是簡化流架構(gòu)以便有相同的處理API等等。
甚至如果SLA不能滿足以及不希望以數(shù)秒或數(shù)分鐘來獲取數(shù)據(jù)，需要消減部署的繁瑣性。在我看來，一個流式架構(gòu)是現(xiàn)代數(shù)據(jù)架構(gòu)的自然演進。它消減了軟件的復(fù)雜性，就像第一代大數(shù)據(jù)架構(gòu)消減了硬件那樣。我們這一架構(gòu)的選擇可能不是通用的，但確實是廣泛使用的，這一技術(shù)棧應(yīng)該可以適應(yīng)90%的使用場景。
lambda 架構(gòu)是兩個世界中的最好品種。數(shù)據(jù)是暫態(tài)的，處理是實時的，可以重新計算和創(chuàng)建在批處理層的部分聚合數(shù)據(jù)，最后在服務(wù)層融化服務(wù)。為例實現(xiàn)這一范式，選擇以下技術(shù):
- Logstash-數(shù)據(jù)攝取和轉(zhuǎn)發(fā)
- Apache Kafka分發(fā)數(shù)據(jù)
- Logtash agent 處理日志
- Apache Spark 流處理
- Elasticsearch 作為服務(wù)層
Figure 3-5介紹了這一架構(gòu).
Figure 3-5. Lambda architecture speed and serving layer
lambda 架構(gòu)通常用于電子商務(wù)網(wǎng)站來實現(xiàn)推薦或者安全分析等不同的目的。例如點擊流數(shù)據(jù)，可以從中提取多重有意義的見解。
一方面,使用長時處理層，處理點擊流，聚合數(shù)據(jù)，與其他數(shù)據(jù)源交叉使用來建立推薦引擎。這個例子中，利用 點擊流數(shù)據(jù)與其他數(shù)據(jù)源包含的人口統(tǒng)計信息的相關(guān)性，在ElasticSearch中構(gòu)建索引視圖。
另一方面, 同樣的數(shù)據(jù)被用來點檢測。實際上，大多數(shù)電子商務(wù)應(yīng)用都會面對安全上的威脅，一種方式是通過流處理層分析用戶的點擊行為而實時地將IP地址放入黑名單。參見 Figure 3-5, 可以使用Spark 處理復(fù)雜的互相關(guān)性，或者運行機器學(xué)習(xí)進程在ElasticSearch 索引前來提取數(shù)據(jù)。
服務(wù)層一般由 Hive處理, 那為什么我們使用ElasticSearch而不是Hive來做近限分析呢？如今，通過新的連接器如ES-Hadoop connector (https://www.elastic.co/products/hadoop), 可以在大多數(shù)場景作為數(shù)據(jù)訪問，查詢的代理，并且使用例如ElasticSearch這樣的實時搜索技術(shù)，它提供更多的能力。
