Flume
Оказывается, FlumeJava это то, чего мне так не хватало в Хадуповской реализации Map/Reduce. И говорят, что Cloudera даже сумела прицепить это к Hadoop'у! Собственно, я и сам пытался реализовать это на базе Hadoop'а, но здесь все оказалось гораздо круче и продуманнее.
Если вкратце, то Flume позволяет делать chained map/reduce операции, когда наиболее прозрачным образом результат одной операции является входными данными для другой. Более того, он позволяет реализовывать некоторые высокоуровневые концепции (такие как groupAndCombine), которые потребовали бы целой цепочки map/reduce'ов.
Ну в конечном итоге, разумеется, все сводится к старому доброму map/reduce - в случае Cloudera'овской реализации это происходит на Hadoop'e, у нас (собственно, в оригинальной реализации) это мапится на тот самый MapReduce. В простейшем виде это выглядит где-то вот так:
PCollection values = ...;
PObject pMaxValue = values.combine(MAX_INTS);
PCollection docInfos = ...;
PCollection results = docInfos.parallelDo(
pMaxValue, new DoFn() {
private int maxValue; void setSideInputs(Integer maxValue) {
this.maxValue = maxValue;
}
void process(DocInfo docInfo, EmitFn emitFn) {
// ... use docInfo and maxValue ...
}
},
collectionOf(strings()));
(разумеется, это копипаста из статьи, которую я настоятельно рекомендую прочитать. Если у вас нет доступа к ACM, то напишите мне ;))). Как следствие, теперь можно писать программы, которые обрабатывают сотни терабайт данных, не особо задумываясь о том, как именно они будут запускаться, где и как будут храниться промежуточные данные, и т.п. В некоторых случаях Flume способен даже оптимизировать план выполнения задачи (например, он вполне может свести два parallelDo в один, если по факту они работают на одних и тех же данных, или же один обрабатывает результаты другого и не делает никакой аггрегации, etc).
Разумеется, это никакой не silver bullet, и никто не отменяет того, что инженер должен понимать, что же он собственно делает - инструмент эффективен ровно настолько, насколько эффективно ты его используешь. Но радует, что кто-то мыслит в тех же направлениях что и я ;)
Если вкратце, то Flume позволяет делать chained map/reduce операции, когда наиболее прозрачным образом результат одной операции является входными данными для другой. Более того, он позволяет реализовывать некоторые высокоуровневые концепции (такие как groupAndCombine), которые потребовали бы целой цепочки map/reduce'ов.
Ну в конечном итоге, разумеется, все сводится к старому доброму map/reduce - в случае Cloudera'овской реализации это происходит на Hadoop'e, у нас (собственно, в оригинальной реализации) это мапится на тот самый MapReduce. В простейшем виде это выглядит где-то вот так:
PCollection values = ...;
PObject pMaxValue = values.combine(MAX_INTS);
PCollection docInfos = ...;
PCollection results = docInfos.parallelDo(
pMaxValue, new DoFn() {
private int maxValue; void setSideInputs(Integer maxValue) {
this.maxValue = maxValue;
}
void process(DocInfo docInfo, EmitFn
// ... use docInfo and maxValue ...
}
},
collectionOf(strings()));
(разумеется, это копипаста из статьи, которую я настоятельно рекомендую прочитать. Если у вас нет доступа к ACM, то напишите мне ;))). Как следствие, теперь можно писать программы, которые обрабатывают сотни терабайт данных, не особо задумываясь о том, как именно они будут запускаться, где и как будут храниться промежуточные данные, и т.п. В некоторых случаях Flume способен даже оптимизировать план выполнения задачи (например, он вполне может свести два parallelDo в один, если по факту они работают на одних и тех же данных, или же один обрабатывает результаты другого и не делает никакой аггрегации, etc).
Разумеется, это никакой не silver bullet, и никто не отменяет того, что инженер должен понимать, что же он собственно делает - инструмент эффективен ровно настолько, насколько эффективно ты его используешь. Но радует, что кто-то мыслит в тех же направлениях что и я ;)