Be ready to big data challenges.
The material was composed based on the performance of Leonid Sokolov, Big Data Architect from GreenM.
Full article https://medium.com/greenm/scalable-data-pipeline-f5d3c8f7a6d9
15. • Use scalable storage: HDFS, SЗ
• Use multiple files
• Use splittable file formats and compression
Format Splittable
CSV Yes*
JSON Yes**
Parquet Yes
Compression Splittable
gzip No
bzip2 Yes
Snappy No
Input Process OutputExtract
Files
• * CSV is splittable when it is a raw, uncompressed file or using a splittable compression format such as BZIP2
• ** JSON has the same conditions about splittability when compressed as CSV with one extra difference.
When “wholeFile” option is set to true (re: SPARK-18352), JSON is NOT splittable.
16. • Use scalable storage: HDFS, SЗ
• Spark on S3: mapreduce.fileoutputcommitter.algorithm.version = 2
• EMR 5.20.0 or later
• Use multiple files (better the same number as in input)
Input Process OutputExtract
20. Map Shuffle Reduce
SELECT * FROM Encounters e JOIN Providers p ON e.ProviderId = p.ProviderId
Input Process OutputTransform
Shuffle Join
Shuffle Map
21. Map Reduce
SELECT * FROM Encounters e JOIN Providers p ON e.ProviderId =p.ProviderId
Input Process OutputTransform
Broadcast Join
Broadcast Collect
22. • Use data partitioning, bucketing, sorting
• Broadcast small tables when joining them to big table
• spark.sql.autoBroadcastJoinThreshold= 10485760 (10 MB, default)
• Use COUNT(key) instead of COUNT(DISTINCT key) if possible
• Drop unused data
• Filter/reduce before join
• Cache Datasets used multiple times
Input Process OutputTransform
Reduce Shuffles
25. Input Process OutputLoad
COPY dm1.FactTable
(
Column1,
Column2,
DateColumnTZ FILLER TIMESTAMPTZ,
DateColumn AS DateColumnTZ AT TIME ZONE 'UTC',
Column4,
...
)
FROM 's3://bucket/prod/datamarts/dm1/FactTable/snapshots/snapshotid=20190418/part-*.orc'
ORC
DIRECT
ABORT ON ERROR;
27. Summary
• Build architecture for scale
• Consider tomorrow’s data volume
• Build with failure in mind
• Understand the risks and be ready to respond
Масштабируемый Data Pipeline.
Данную тему мы разделили на две части, 1й доклад будет посвящен работе непосредственно с данными, 2й доклад проведет ... Он расскажет вам об больше об управелении и администрировании Data Pipeline.
В 1й части речь пойдет больше об архитектуре и алгортимах самих программ и процессов, и совсем немного о технологиях.
Главный смысл этой части я вынес в описание доклада: будь готов к вызовам которые связаны с данными, а конкретно к масштабированию процессов работы с этими данными.
Все любят хранить данные, все работают с ними, кол-во данных растет каждый день и в определенный момент данных становиться достаточно много и мы не успевам обработать их за отведенных промежуток времени и тут как всегда мы начинаем думать о масштабировании.
Все о чем я вам расскажу сегодня это история продукта над котором мы работаем в компании и начало этой истории мы рассказывали вам ровно год назад. Его проводил Антон, он рассказывал об озере данных.
Мы подробнее остановимся здесь, чтобы напомнить вам о чем идет речь. Обсудим какие проблемы мы не решили на тот момент и с какими новыми проблемами столкнулись. Поговорим непосредственно о масштабировании. В этой части я буду приводит реальные примеры проблем с которыми мы сталкивались и как мы их решали.
В конце подведем краткий итог и поговорим о технологиях которые мы использовали.
В предыдущем докладе Антон рассказывал об идеальном и реальном мирах. От том что чаще всего не получается построить идеальню архитектуру по независящим от нас причинам.
Множество процессов которые рождались налету без учета общей архитектуры для компании. Все это привело к сложным процессам и большому набору разно информации которая хранится в различных источниках.
Решением этой проблемы может быть создание озера данных. Наполнение его данными со всех возвожных источнико.
Когда все данные находятся в одном хранилище мы можем построить гибкую архитектуру дальнейших процессов работы с этими данными.
Extract Tranыform Load могут быть реализованы как 1 процесс
Например, программа, которая вычитывает данные из источника, делает трансформацию и затем сохраняет эти данные в другое хранилище данных.
Для того чтобы не запутаться в названих и понимать о каком конкретно процессе идет речь, мы с вами заменим названия процессов нижнего уровня на Input, Process и Output.
C точки зрения архитектуры в данной реализации есть как приемущества так и недостатки с одниночным процессом без сохранения промежуточных результатов.
Перейдем к самому главному в этом докладе – к масштабированию.