Презентация со scalaby#13 ~> scala.by

1. Опыт использования spark
Основано на реальных событиях

2. Чтение бинарных логов
• задача - по логам найти тех, кто подбирает пароли
• одна запись лога раскидана на несколько бинарных файлов
• часть бинарных файлов = справочники
• остальные файлы читаются последовательно
• такую задачу можно решать на hadoop
• также можно решать переводом бинарных данных в текстовый формат, но это потери
времени и ресурсов кластера

3. Чтение в hadoop
InputFormat
split
split
split
RecordReader
RecordReader
RecordReader
Record
Record
Record

4. Использование в спарк
• этапы решения
• работа с бинарными файлами в одном потоке
• упаковка логики в inputformat, record reader
• написание mr джоба
• как это всё засунуть в спарк
val fileRDDs = filesToProcess.toArray.map{
file => sc.newAPIHadoopFile[IntWritable, Text, BWLogsInputFormat[IntWritable, Text]](file)}
val rdd = new UnionRDD(sc, fileRDDs)

5. Оптимизация ETL
конвертировать бинлоги в текстовое представление,
не всегда это можно сделать даже используя fuse
и это приведёт к потери времени и ресурсов кластера
бинарные
данные
текстовые данные
обработка

6. Запись с группировкой по
директориям
• проблема: rdd.saveAsTextFile(“/var/blob/result”) сохраняет всё в директорию path
/var/blob/result/part-00000
/var/blob/result/part-00001
• чего хотелось бы: разбить данные по директориям - партицировать по значениям
полей
/var/blob/result/type1/part-00000
/var/blob/result/type1/part-00001
/var/blob/result/type2/part-00000
/var/blob/result/type2/part-00001
/var/blob/result/type3/part-00000
/var/blob/result/type3/part-00001
/var/blob/result/type4/part-00000
/var/blob/result/type4/part-00001

7. N+1 чтение
resultRdd.map {
x =>
x._1 //partition value
}.distinct().collect()/* first read*/.foreach {
part =>
resultRdd.filter(part.equals(_._1))/* N reads*/.saveAsTextFile("path/" + part)
}

8. 1 чтение и много кода
resultRdd.foreachPartition {
p =>
val hdfs = HdfsUtils.setupHdfs(hdfsConf)
val pathToOut = collection.mutable.Map[String, FSDataOutputStream]()
try {
//save to dirs by value
p.foreach(csv => {
val fileName = "%1$s/%2$s/%3$s".format(sortByDateDir, dateValue, exeDirName)
val output = getFileOutput(fileName, pathToOut, hdfs)
output.write(csv._2.toString.getBytes("utf8"))
output.writeBytes(CSV_DELIMITER)
})
} catch {
case t: Throwable => {
log.error("" + t, t)
}
}
pathToOut.foreach(out => {
tryToCloseNTimes(out._2, 5, 2000)
})
}
def getFileOutput(fileName: String, files: collection.mutable.Map[String, FSDataOutputStream], fs: FileSystem): FSDataOutputStream = {
//20 lines of code
}

9. 1 чтение + мало кодировать
class KeyPartitionedMultipleTextOutputFormat extends MultipleTextOutputFormat
[NullWritable, String] {
override def generateFileNameForKeyValue(key: NullWritable, value: String, name:
String): String = {
val elements = value.toString.split(",")
"key%1$s/%2$s".format(elements(1), name)
}
}
val pairRdd = new PairRDDFunctions[NullWritable, String](pairBlob)
pairRdd.saveAsHadoopFile(fs.getUri + config.dstDir, classOf[NullWritable], classOf[String],
classOf[KeyPartitionedMultipleTextOutputFormat], conf = new JobConf(appConf))

10. Скорость и надёжность кафки
• чем хороша кафка
• легко масштабировать
• хорошая скорость чтения записи
• недостатки
• для предсказуемого поведения с оффсетами и равномерностью чтения партиций
лучше использовать низкоуровневый simpleconsumer
• документация - лучше сразу смотреть исходники
• важно не путать её с jms очередями
топик
партиция 1
партиция 2
партиция 3
реплика 1
реплика 2

11. Актуальный сценарий
интеграции
серверное приложение
(C++ python)
логика отправки
данных в кафку кафка
спарк batch & streaming

12. Сценарий с tungsten (POC)
mysql
master
tungsten
spark batch & streamkafka
mysql
master
tungsten
binlog
binlog
серверное приложение
(С++ python)

13. Типичный ETL сценарий
mysql
dump csv + tgz HDFS spark
тут напрягаем
периодически mysql
сервер дампами,
невозможно сделать
журнал
тут скорость
будет хуже чем
у кафка,
удобнее писать
читать кафку
чем hdfs

14. Чтение из Кафки
• создан inputformat для чтение топиков из кафки (по мотивам camus)
• алгоритм работы
• для каждого осчетания топик+партиция создать сплит
• в рамках обработки сплита посмотреть текущие оффсеты записи и поднять
последние оффсеты чтения с hdfs
• выполнить чтение и сохранить новые оффсеты чтения на hdfs
• недостатки
• хранение оффсетов чтения на hdfs
• неравномерная загрузка кластера в случае малого числа партиций или
неравномерной загрузки партиций
• проблема отсутствия лидера партиции на момент старта выгрузки

15. Спарк Стриминг
• приницип работы - создавать рдд на основе принятых данных и обрабатывать их
• позволяет партицировать поток (получать данные на нескольких нодах одновременно)
val allInputs = (0 to numberOfNodes - 1).map {x =>SparkUtils.createStreamPartition(ssc, ...)}
• позволяет работать с окнами = запоминает набор рдд для окна
• для отказоустойчивости есть механизм сохранения снимков рдд
• позволяет сделать ограничитель скорости приёма данных

16. Недостатки Стриминга
• трудно организовать обработку данных без потерь (но для стриминга это не всегда нужно)
• проблема в блок генераторе
• получили данные из потока
• закинули данные в блок генератор на создание рдд
• данные попадают в буффер (для асинхронности и скорости)
• с задержкой по времени данные попадают в рдд
• т.е. при падении есть вероятность потерять содержимое буфера
• есть возможности это обойти при условии возможности перечитать данные из потока
• надо играть настройками генератора рдд чтобы избежать OOM
spark.streaming.blockInterval=100 (в миллисекундах)
канал
сообщений
Генератор РДД
Окно РДД (память + диск)
РДД РДД РДД
Буфер

17. Работа с потоком из кафки
• в поставке спарка есть реализация кафка стрима, но она не устроила
• основана на высокоуровневом апи кафка ридера с его проблемами сохранения
офсетов и равномерностью нагрузки на чтение
• задача где используется
• вычислять качество соединения в 5ти минутных окнах и отображать на карте мира

18. Своя реализация стримера
• оффсеты сохраняются после каждого чтения в hbase
• чтение партиций равномерное в рамках пула потоков
• поддержка партицирования чтения потока
• поддержка механизма метрик в спарке (основан на codahale metrics)
• скорость приёма данных
• отставание

19. Недостатки реализации
• завязан на hbase - надо вынести на уровень апи возможность подсунуть свою реализацию
хранилища
• не реализовано восстановление после падения с учётом потери буфера генератора рдд -
нет необходимости это делать, но возможность есть

20. Проблемы внедрения
• как и во что собрать? как запускать?
• 3 опции
• uberjar + java -jar
• spark-submit --deploy-mode client
• spark-submit --deploy-mode cluster
• как передать конфиги?
• актуально для spark-submit --deploy-mode cluster
• решается через --files /path/to/config.xml
• что делать с ошибками сериализации?
• понять как работает спарк приложение + рефакторинг кода
val rdd = sc.textFile("")
val a = ...
val resultRdd = rdd.map {
x =>
(x, a)
}

21. Всё