Uploaded byGreenM
Scalable data pipeline
The document discusses scalable data pipeline challenges and strategies to handle big data, focusing on technologies like AWS and Spark. It highlights the importance of effective data management practices such as partitioning, compression, and choosing the right storage formats to optimize workloads. Additionally, it emphasizes building resilience within architecture to accommodate future data volumes and associated risks.
More Related Content
Scalable data pipeline
- 1. Scalable Data Pipeline Beready to big data challenges with by Leonid Sokolov Big Data Architect at greenm.io
- 2. Agenda • Data LakeMonsters Recap • Scale Distributed Data Processing • Technologies
- 3. Data Lake MonstersRecap
- 4. Data Lake MonstersRecap
- 5. Data Lake MonstersRecap
- 6. Data Lake MonstersRecap
- 7. Data Pipeline Challenges •Complex workflow management • AWS Athena doesn’t scale well
- 8.
- 9.
- 10. Extract Transform Load ExtractTransform Load
- 11. Extract Extract Transform Load TransformLoad Input Process Output Input Process Output Input Process Output
- 12. Input Process OutputExtract Database:Partition by Integer Key
- 13. +1000000 13569933 + ??? ??? Input ProcessOutputExtract 12569933 13680800900000083645ec0c06727066d249cfd01 ffffffcb586df761f63f561d946ac7c5 Database: Partition by Varchar Key
- 14. Input Process OutputExtract Database:Varchar key
- 15. • Use scalablestorage: 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 scalablestorage: 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
- 17. Extract Results 0 10 20 30 40 50 60 70 80 Extract Time(minutes) Before After • EMR 5.20.0 with 10 instances (c4.4xlarge) • Input: 3 Databases (MS SQL), ~400GB (Raw Data) • Output: Parquet(Snappy), ~100GB
- 18. Extract Extract Transform Load TransformLoad Input Process Output Input Process Output Input Process Output
- 19. Input Process OutputTransform Volumeof Data Partitions Data Skew Volume of Data Partitions
- 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 datapartitioning, 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
- 23. Transform 0 10 20 30 40 50 60 Transform Time(minutes) Before After Results •EMR 5.20.0 with 10 instances (c4.8xlarge) • Input: Parquet(Snappy), 50GB • Output: ORC(ZLib), 19GB
- 24. Extract Transform Load InputProcess Output Input Process Output Input Process Output
- 25. Input Process OutputLoad COPYdm1.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;
- 26. Load Results 0 20 40 60 80 100 Load Time(minutes) BeforeAfter • Input: ORC(ZLib), 19GB • Output: Vertica DB (7 Node)
- 27. Summary • Build architecturefor scale • Consider tomorrow’s data volume • Build with failure in mind • Understand the risks and be ready to respond
- 28. Technologies Extract Transform Load EnvironmentAWS, EMR 5.20.0 AWS, EMR 5.20.0 AWS Batch Technology Spark 2.4 Spark 2.4 Vertica Languages Scala + SQL Scala + SQL Python + SQL Input Format Compression MS SQL, MySQL Tables - S3 Parquet Snappy S3 ORC, Parq Zlib, Snappy Output Format Compression S3 Parquet Snappy S3 ORC ,Parquet Zlib, Snappy Vertica Tables Native
Editor's Notes
- #2 Масштабируемый Data Pipeline. Данную тему мы разделили на две части, 1й доклад будет посвящен работе непосредственно с данными, 2й доклад проведет ... Он расскажет вам об больше об управелении и администрировании Data Pipeline. В 1й части речь пойдет больше об архитектуре и алгортимах самих программ и процессов, и совсем немного о технологиях. Главный смысл этой части я вынес в описание доклада: будь готов к вызовам которые связаны с данными, а конкретно к масштабированию процессов работы с этими данными. Все любят хранить данные, все работают с ними, кол-во данных растет каждый день и в определенный момент данных становиться достаточно много и мы не успевам обработать их за отведенных промежуток времени и тут как всегда мы начинаем думать о масштабировании.
- #3 Все о чем я вам расскажу сегодня это история продукта над котором мы работаем в компании и начало этой истории мы рассказывали вам ровно год назад. Его проводил Антон, он рассказывал об озере данных. Мы подробнее остановимся здесь, чтобы напомнить вам о чем идет речь. Обсудим какие проблемы мы не решили на тот момент и с какими новыми проблемами столкнулись. Поговорим непосредственно о масштабировании. В этой части я буду приводит реальные примеры проблем с которыми мы сталкивались и как мы их решали. В конце подведем краткий итог и поговорим о технологиях которые мы использовали.
- #4 В предыдущем докладе Антон рассказывал об идеальном и реальном мирах. От том что чаще всего не получается построить идеальню архитектуру по независящим от нас причинам.
- #5 Множество процессов которые рождались налету без учета общей архитектуры для компании. Все это привело к сложным процессам и большому набору разно информации которая хранится в различных источниках.
- #6 Решением этой проблемы может быть создание озера данных. Наполнение его данными со всех возвожных источнико.
- #7 Когда все данные находятся в одном хранилище мы можем построить гибкую архитектуру дальнейших процессов работы с этими данными.
- #11 Extract Tranыform Load могут быть реализованы как 1 процесс Например, программа, которая вычитывает данные из источника, делает трансформацию и затем сохраняет эти данные в другое хранилище данных.
- #12 Для того чтобы не запутаться в названих и понимать о каком конкретно процессе идет речь, мы с вами заменим названия процессов нижнего уровня на Input, Process и Output. C точки зрения архитектуры в данной реализации есть как приемущества так и недостатки с одниночным процессом без сохранения промежуточных результатов. Перейдем к самому главному в этом докладе – к масштабированию.