![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
Gcp dataflow
- 1. Google Cloud Dataflow IgorRoiter, CTO @ DataZone Welcome!
- 2. About CloudZone End-to-end Cloud Solutions •Migration • Security • DevOps • Big Data • DR & more Full Service Package • Consulting • Managed Services • Professional Services Years of Experience Largest partner in Israel Our Goal: To ensure our customers adopt the most advanced technologies at a minimal cost
- 3. What We Do… FinOpsDevOps Well Architected • Architecture schematics • TCO • SOW Full Service Package • Consulting • Managed Services • Professional Services Continues Integration and Deployment
- 4. Our Professional Services Cloud Migration DevOps Disaster Recovery BigData & Bi Analytics Dev &TestSecurity Cost Optimization Cloud Extension
- 5. Customer Success Unit(FinOps) Design for Maximal Cost Reduction Leverage the Power Of the Cloud Find and Eliminate Waste Implement Government Polices Helping you save thousands on your monthly bill! • Billing Analytics • RI Utilization • Data Analytics • Automate Optimization • Asset Management • Consumption Management Cloud Resource ManagementTool
- 6. Hybrid Cloud Solutions •Architecture & deployment of Private Hybrid clouds based on VMware vRA or OpenStack • Configuration Management: Chef, Puppet, Ansible & Salt • Public Cloud DevOps & Automation • OpenShift, Cloud Foundry based, Kubernetes, DCOS and More. Cloud Containers DevOps
- 7. DataZone – AdvancedData Solutions Troubleshooting &Tuning Technological Evaluation Training Services Architecture Review Cost Management End-to-End Implementations DataZone is a leading trusted advisor and integrator for data and search applications Infrastructure Support / DevOps
- 8.
- 9. About Me • Workingas data specialist for last 10 years • SQL Server DBA in past life • Software developer & Architect • CTO @ DataZone from 2015
- 10. Agenda Processing Data Types Bigdata processing trade-offs What is apache beam Google cloud Dataflow managed service Pricing
- 11.
- 12. Data… ...maybe even infinitelybig... 9:008:00 14:0013:0012:0011:0010:002:001:00 7:006:005:004:003:00
- 13. Data… …with unknown delays. 9:008:0014:0013:0012:0011:0010:00 8:00 8:008:00 8:00
- 14. The trade-offs ofBig Data processing Complet eness Lat ency Cost Data Processing Tradeoffs
- 15. Processing DataTypes Batch Processing– Designed for finite datasets (distributed output dataset) MapReduce: SELECT + GROUP BY (distributed input dataset) Shuffle (GROUP BY) Map (SELECT) Reduce (SELECT)
- 16. Processing DataTypes Time-Bound Dataprocessing EventTime - The time at which events actually occurred. ProcessingTime - The time at which events are observed in the system
- 17. Batch Processing ofunbound data – Patterns Fixed window batch by processing time • Fixed windows of X units of time, that divide the data into a smaller finite groups for processing • More suitable for use cases in which the old data is irrelevant and only the current state is important • Issues with data correctness occur due to fact we window by processing time instead of EventTime • Many times we will be required to wait an arbitrary amount of time to close the window and thus delay all next
- 18. Batch Processing ofunbound data – Patterns Session window batch processing • Sessions are defined as periods of activity. • Sessions are usually terminated by inactivity or by closing event. • Main issue with batch processing with sessions: When calculating sessions using a typical batch engine, you often end up with sessions that are split across windows, as indicated by the red marks in the diagram below. • The split amount may be reduced by increasing the window, but that would cost us in increased latency
- 19. Processing DataTypes Streaming Data- Designed with infinite data sets in mind Challenges when dealing with unbound data set • Highly unordered with respect to event times - meaning you need some sort of time-based shuffle in your pipeline if you want to analyze the data in the context in which they occurred • Varying event time skew - meaning you can’t just assume you’ll always see most of the data for a given event time X within some constant epsilon of time Y Challenge: complet eness when processing continuous data 9:008:00 14:0013:0012:0011:0010:00 8:00 8:008:00 8:00
- 20. Streaming processing ofunbound data – patterns Time-agnostic • Time-agnostic processing is used in cases where time is essentially irrelevant, meaning that all relevant logic is data driven • Basic example form of time agnostic processing is filtering, Imagine you’re processing Web traffic logs, and you want to filter out all traffic that didn’t originate from a specific domain
- 21. Streaming processing ofunbound data – patterns Windowing • Types: Fixed windows, Sliding windows, Sessions. • It is possible to window based on EventTime when dealing with streaming engines – While the following requires buffering for late data. • New windowing tools are introduced for late data completeness: Watermarks, triggers • Watermarks – A watermark is a notion of input completeness with respect to event times. A watermark with a value of time X makes the statement: “all input data with event times less than X have been observed.” As such, watermarks act as a metric of progress when observing an unbounded data source with no known end. • Triggers – A trigger is a mechanism for declaring when the output for a window should be materialized relative to some external signal • Accumulation – A set of rules that defines, how window results will be influenced by the use of triggers
- 22. Hybrid approach Historical events Exact historical model Periodic batch processing Approximate real-time model Stream processing system Continuous updates Stateof the art until recently: Lambda Architecture
- 23. The trade-offs ofBig Data processing Streaming or Batch? Com plet eness Lat ency Cost Why not both?
- 24. Apache Beam Before ApacheBeam Batch OR Stream Accuracy OR Speed Simplicity OR Sophistication Savings OR Scalability After Apache Beam Batch AND Stream Accuracy AND Speed Simplicity AND Sophistication Savings AND Scalability Balancing correctness, latency and cost with a unified batch with a streaming model
- 25. What is Apachebeam Apache Beam is a big data processing standard created by Google in 2016. It provides unified DSL to process both batch and stream data, and can be executed on popular platforms like Spark, Flink, and of course Google’s commercial product Dataflow. Beam’s model is based on previous works known as FlumeJava and Millwheel, and addresses solutions for data processing tasks like ETL, analysis, and stream processing. Currently it provides SDK in two languages, Java and Python. This article will introduce how to use Python to write Beam applications
- 26. Apache Beam –Basic framework concepts Pipeline • A Pipeline represents a graph of data processing transformations PCollection • Immutable collection • Could be bound or unbound • Created by: • a backing data store • a transformation from other PCollection • generated • PCollection<KV<K,V>> Transform • Combine small operations into bigger transforms • Standard transform (COUNT, SUM,...) • Reuse and Monitoring
- 27. Google Cloud Dataflow Afully-managed cloud service and programming model for batch and streaming big data processing on Google Cloud. • Fully managed Runner service • Out of the box API support for all google cloud data sources/destinations – pub/sub, Google Cloud Storage, BigQuery, BigTable, Spanner, etc… • Monitoring and UI – Usage of Stackdriver for real-time logs of whole process • Automated Resource Management • Dynamic Work Rebalancing
- 28. Data processing withGoogle Cloud Dataflow What are you computing? How does the event time affect computation? How does the processing time affect latency? How do results get refined?
- 29. Data processing withGoogle Cloud Dataflow What are you computing? • A Pipeline represents a graph of data processing transformations • PCollections flow through the pipeline • Optimized and executed as a unit for efficiency
- 30. Data processing withGoogle Cloud Dataflow Key 2 Key 1 Key 3 1 Fixed 2 3 4 Key 2 Key 1 Key 3 Sliding 1 2 3 5 4 Key 2 Key 1 Key 3 Sessions 2 4 3 1 Aggregating According to Event Time • Windowing divides data into event- time-based finite chunks. • Required when doing aggregations over unbounded data. What Where When How
- 31. Data processing withGoogle Cloud Dataflow What Where When How When in Processing Time? • Triggers control when results are emitted. • Triggers are often relative to the watermark. ProcessingTime Event Time Wat erm ark
- 32. Data processing withGoogle Cloud Dataflow What Where When How How are Results refined? • How should multiple outputs per window accumulate? • Appropriate choice depends on consumer. Firing Elements Speculative 3 Watermark 5, 1 Late 2 Total Observ 11 Discarding 3 6 2 11 Accumulating 3 9 11 23 Acc. & Retracting 3 9, -3 11, -9 11
- 33. Data processing withGoogle Cloud Dataflow
- 34. Pricing • Usage ofthe Cloud Dataflow service is billed per minute on a per job basis. Each Dataflow job will use at least one Cloud Dataflow worker. The Cloud Dataflow service provides two worker types: batch and streaming. There are separate service charges for batch and streaming mode. • Batch worker defaults: 1 vCPU, 3.75GB memory, 250GB PD. • Streaming worker defaults: 4 vCPU, 15GB memory, 420GB PD. • Currently there is no support for pre-emptive machines • The prices bellow are correct for North Virginia at presentation time Dataflow Worker Type vCPU (per Hour) Memory (per GB per Hour) Local storage - Persistent Disk (per GB per Hour) Local storage - SSD based (per GB per Hour) Batch $0.0599200 $0.0038060 $0.0000594 $0.0003278 Streaming $0.0738300 $0.0038060 $0.0000594 $0.0003278
- 35. Igor Roiter, igorro@datazone.io Thankyou! Google Cloud Dataflow
Editor's Notes
- #8 דאטהזון היא יחידת הדאטה של קלאודזון, נועדה להוות מוקד מרכזי לייעוץ, תמיכה ואינטגרציה באוסף כל שירותי הדאטה והדאטה בענן הקיימים אצל לקוחות. דאטהזון הינה פרטנר בלעדי של vendors הNoSQL הגדולים כיום בשוק: MongoDB, StreamSets, Elasticsearch, Couchbase. סיפוק פתרונות וייעוץ בסביבות ענן וonPrem. פתרונות end-to-end לדאטה בסביבות ענן של גוגל, אז'ור וAWS
- #11 סוגים של עיבוד נתונים שכולנו כבר מכירים את חלקם מה הסוגיות הנפוצות ביותר בהתמודדות שלנו עם big data processing
- #12 כאשר אנחנו מדברים על big data processing הכוונה היא להרבה מאד data אפשר לחשוב לדוג' על usecases של מערכות טלקום, אשר מנטרות את הפעילות של הלקוחות שלהם ומוציאות קמפיינים תקופתיים כמו גם אופטימיזציות אישיות ללקוח
- #13 בחלק מהמקרים קליטת ועיבוד הנתונים שלנו הוא תהליך מתמשך ולא נגמר, כלומר stream של נתונים שבו נפעיל לוגיקה תוך כדי הקריאת הנתונים בשביל לקבל תוצאות במהירות הכי גבוהה שניתן, למשל כאשר אנחנו מקבלים קלט של חיישני IOT למיניהם, למשל בניטור פקקים וקביעת מהירות נסיעה דינאמית בכבישים מהירים
- #14 נעבור גם על מקרים שבהם המידע אינו רציף, כלומר מעוקב, למשל באפליקציות האוספות נתונים במכשירים סלולריים שלעיתים נמצאים באיזורים חסרי קליטה. מה שגורם לאותם הנתונים להגיע מאוחר מהצפוי
- #15 בואו נדבר קצת על הפרמטרים המאזנים שנשקול כאשר נבחר את המתודולוגיה לעיבוד נתונים מאסיבי שלמות המידע, כלומר מה נעשה עם מידע אשר צריך להגיע אך עדיין איננו, האם נוותר עליו בחישובים שלנו? האם נעקב את כל שאר הלוגיקה שלנו בשביל לקבל תמונה הכי נכונה (לחזור לדוג' של פלאפון) באופן דומה, נבחן את זמינות תוצאות עיבוד המידע, האם אנחנו חייבים לספק תוצאות בזמן אמת או קרוב לזמן אמת ככל האפשר, למשל במערכות סייבר וניטור. אם לא האם אנחנו נוכל לחשב את המידע נכון ל24 שעות אחורה? תמחור המערך הטכנולוגי אשר יעבד את המידע, האם קצב זרימת הנתונים והעיבוד שלנו קבוע, איזה קלאסטרים נחזיק לביצוע הפעילות, האם כל הקלאסטר יהיה למעלה כל הזמן, תחזוקה שוטפת, התמחור כנראה יהיה גבוה, מספיק בשביל להחזיק את הפעילות הכבדה ביותר המבוצעת על המערכת כאשר נבחן את הפרמטרים הבאים נוכל לקבוע באיזה מתודולוגיה וטכנולוגיה נשתמש לביצוע המשימה
- #16 מידע בעל כמות סופית וידועה מראש, לדוג' קובץ לוג אשר מחולק ברוטיישן לכל יום בנפרד. כל המידע הנדרש לחישוב נגיש עיבוד נתונים כזה ניתן לראות בכל מערכת המבוססת MapReduce, כלומר כתיבת קוד מבוזר אשר מפעיל לוגיקת פילטור, איגוד, פעולות אנליטיות, מעל מערך נתונים מבוזר למשל ApacheHadoop
- #17 בשביל להבין את המשך ההתמודדות שלנו עם מידע שמגיע בצורה רציפה, סטרים, בואו נגדיר 2 סוגים של זמן איוונט טיים – הוא הזמן שבו נוצר האיוונט שמועבר בסטרים הנתונים שלנו, כלומר רגע ביצוע הפעולה או יצירתה בClient, לדוג' מתי המשתמש הקליק על כפתור כלשהו, או מתי חיישן התנועה בכביש גילה מעבר של רכב פרוססינגטיים – הוא הזמן שבו האיוונט המדובר נקלט במערכת העיבוד שלנו, כלומר לדוג' בעיבוד שמטרתו היחידה היא לסכום נתוני שביעות רצון, ללא הצורך בידיעה מתי בוצע השאלון, נוכל להתעלם מהזמן שבו בוצע השאלון ולהתייחס רק לזמן קליטת הנתונים
- #18 בהמשך למתודולוגית הBatch כאשר מדובר על כמות מידע שאינה סופית בטבעה, סטרים נתונים, נדרש לחלק את המידע לחלקי מידע סופיים אשר נוכל להתמודד עם כל אחד מהם בנפרד, פעולה זאת נקרית windowing ויכולה להיות מוכלת בכמה אפשרויות. Windowing לפי processingTime כלומר לפי זמן הגעת המידע למערכת הprocessing, כמו הדוג' הקודמת למשל אם אנחנו סוכמים את כמות הלייקים למנה מסויימת ברשת המסעדות שלנו. כל מה שמעניין אותנו זה הכמות ever אך ברגע שהצורך שלנו דורש התחשבות בeventTime, נוצרת לנו בעיה בביצוע עיבוד נתונים batch כיוון שמידע לעיתים אינו מגיע בסמיכות או בסדר היווצרותו ולכן כאשר נחלק את המידע לחלונות זמן אשר מבוססים חלונות זמן ביצוע לא נוכל לקבל correctness נכון
- #19 קיבוץ המידע בהגדרת session הינה סדרה של פעולות מתמשכות אשר קורות בסמיכות עי משתמש כלשהו. לדוג' סשן שימוש באתר כלשהו, funnel כניסה לאתר gaming... כיוון שאנו מתייחסים לעיבוד batch של המידע, חלוקת החלונות שלנו הינה עדיין לפי הprocessingTime ולכן נקבל מקרים שבהם session יהיה מחולק ליותר מחלון זמן אחד, ולכן לא נוכל לחשב את המידע הכרוך בו בצורה מלאה. פתרון אפשרי: הגדלת זמן החלוקה של החלונות בכדי להקטין את כמות המופעים שבהם סשן יהיה מחולק ליותר מחלון אחד. הבעיה העיקרית עם הגישה הזאת היא שנעקב את עיבוד כל המידע כיוון שהגדלנו את חלון הזמן שלנו ונצטרף לחכות לסיומו (מילוי שלו)
- #20 זרימת נתונים רציפה, סטרים נועדה לעזור לנו להתמודד עם צרכי latency נמוכים, וכמו כן מאפשרת כלים לעבודה עם נתונים אשר מגיעים באיחור ולא בסדר רציף והגיוני כלשהו
- #21 שימוש נפוץ במתודולוגית סטרים הינו פילטור המידע ללא תלות בeventTime, כלומר שלב של processing אשר נועד להכנת המידע לשלב נוסף בצורה המהירה ביותר תוך כדי שהמידע מגיע. דוג' בסיסית היא פילטור access logs לדומיין ספציפי שממנו מגיעים המשתמשים לדוג' בעת תחקור נתונים בזמן אמת של מתקפת סייבר
- #22 הבסיס לעבודה עם סטרים מתחיל גם בחלוקת המידע לחלונות זמן בדומה לתהליך הbatch, ההבדל המרכזי שמבדיל את התהליך הוא הstate הנוכחי של כל חלון ואפשרויות השליטה שלנו בו ומכך האפשרות שלנו לחלק לחלונות זמן לפי הeventTime. חלונות הזמן האפשריים לחלוקה בstreaming data processing הן: חלונות קבועים – כלומר חלונות חלוקה של X זמן לפי זמן החלוקה הנבחר processing vs Event, חלונות זמן חופפים, כך שכל חלון יכיל חלק מהמידע של החלון הקודם, סשנים בדומה לדוג' batch כלים חדשים שנוספו לנו בstream: Watermarks – הגדרת זמן יחסית בדרך כלל מבוססת על אלגוריתמי ניבוי מניסיון שנצבר עם הרצת הפייפ לזמן סגירת החלון שמסמנת את החלון כסגור ואת המידע בו כשלם Triggers – ניתן להגדיר לוגיקה אשר תעדכן את החלון אשר נסגר ע"י הwatermark ולחשבו מחדש עם ערכים שהגיעו באיחור, או לחלופין הגדרה שתבסס את סגירת החלון מעבר ללוגיקת הwatermark Accumulation – מה בעצם נעשה עם חישוב התוצאות מחדש, האם נדרוס תוצאה קודמת, האם נשמור את שתיהן?, האם נחבר ביניהן?
- #23 Lambda Apache flink, FlumeJava MapReduce, Hadoop הפתרון המושלם (עד לא מזמן) – חיבור שתי הגישות לכדי מערכת המאפשרת קבלת נתונים בזמן אמת, כאשר זאת יכולה לא להיות מדויקת ב100% בגלל תרחישי זרימת דאטה בעייתיים שעברנו עליהם + תחקור batch על מידע היסטורי בשביל לתקן את טעויות הstream ובכך להשיג דיוק מושלם בתחקור לאחור בעיות: תחזוקה של 2 פתרונות שונים, בטכנולוגיות שונות.
- #24 אז איך בעצם נוכל לקבל את שתי הגישות במקביל ולפתור את בעית הcomplexity שנוצרה לנו
- #25 אפאצ'י בים הינה טכנולוגיה המבוססת על סטנדרט הDataFlow של גוגל, ונועדה לתת פתרון טכנולוגי ומתודולוגית בניה זהה לפתרונות batch ו stream, כך שתתאפשר הרצה שלנו במקביל, תוך כדי אפשרות שליטה על האיזון שבין latency, completness, ומחיר תפעול ותחזוקה
- #26 אז מזה בעצם אפאצ'י בים?? אפאצ'י בים כאמור הוא framework לכתיבת pipelines באופן זהה לbatch וstream דאטה, כך שאותם הpipelines יוכלו להתבצע בסביבות הרצה שונות, לדוג' Flink, Spark, Direct, Google cloud Dataflow, כלומר על סביבות הרצה שיכולות להיות לוקליות או מוארחות בענן. הframework ניתן ל2 שפות תכנות כאשר העיקרית הינה Java, וקיימת גם גירסת פייטון.
- #27 עקרונות הבנייה העיקריים באפאצ'י בים הינם האובייקטים הבאים: Pipeline מייצג את גרף ההרצה של מקורות המידע, עיבודם, והפלט שלהם, הpipeline הינו בעצם האוביקט שאנחנו נריץ בכדי לבצע את כל הפעולות המוגדרות בתוכו, כאמור ההרצה מבוצעת ע"י מנועי הרצה באפשרויות שונות, כך שכל אחד מהמנועים מכיל שיטות optimization משלו. Pcollection הינו collection נתונים immutable אשר נוצר עי קריאה ממקור מידע רציף כלומר סטרימי או סגור כלומר באצ'י או לחילופין נוצר עי תוצאה של טרנספורמציה כלשהי על pcollection אחר, הייחוד שלו הוא בכך שכל עבודת טרנספורמציה המוכלת עליו ניתנת לביצוע מבוזר, ולכן בביצועים גבוהים מאד Transform הינו פעולה או סדרה של פעולות אשר מבוצעת על Pcollections, יכול להיות כל דבר, כמו איגוד, פילטור, פורמטינג....
- #28 אחד מאפשרויות מנועי ההרצה של Beam אוטומציה וניהול מלא של כל הresources הנדרשים בשביל להריץ beam pipeline באופן אופטימלי, לקבלת הthroughput הגבוה ביותר Pipelines שנכתבים במטרה להיות מורצים עי Google Cloud DataFlow מכילים out of the box תמיכה בכל מוצרי הdata של גוגל לקריאה\כתיבה של נתונים וגם להרצת ג'ובים של ML Dynamic Work Rebalancing - חלוקה אוטומטית של המידע לקבוצות עבודה במערכת מבוזרת - אין צורך בהכנת המידע טרם הביצוע (למשל נתון id שחוזר על עצמו לרוב האובייקטים) מאפשר UI נוח לויזואליות של הpipe וכמו כן סטטיסטיקות בזמן אמת מאפשר גישה ללוגים עי מוצרי לוגינג של גוגל בזמן אמת לדוג' stackdriver
- #29 איך בעצם ניגשים לבנית pipeline: השאלות שאנחנו נשאלים הינם: מה אנחנו מחשבים? האם יש לנו התייחסות וצורך בeventTime בחישובים שלנו האם יש לנו מידע שמגיע מאוחר, ואיך הוא משפיע על זמינות העיבוד שלנו? אם אכן קיים מידע מאוחר, איך הוא משפיע על תוצאות העיבוד שלנו?
- #30 קודם כל אנחנו צריכים להבין מה אנחנו רוצים לחשב, כלומר מה יהיו transform שלנו? האם אנחנו מאגדים מידע לפי קבוצות? האם אנחנו מחשבים lifetime totals? פילטור? הכנת מידע לשימוש במנוע ML? אימון מודל ML מתמשך?
- #31 האם קיימת לנו התייחסות לeventTime, איך נבחר לבצע את חלוקת הwindow שלנו בעת קבלת המידע? מהם חלונות החלוקה הנכונים כלפי העיבוד שאותו ננסה לבצע.
- #32 קביעת watermarks אשר יצביעו לנו על שלמות המידע בחלון הזמן הנבחר וסגירתו להמשך עיבוד וכמו כן מה נעשה עם מידע מאוחר שמגיע לאחר סגירת החלון ע"י. Triggers
- #33 מה בעצם נעשה עם כל אותם המופעים של מידע שמגיע מאוחר ביחס לחלונות הזמן שכבר נסגרו, האם נצבור אותם, האם נחזיק 2 מופעי state לאותו החלון? האם נתעלם ממנו?
- #34 דוג': מטרת הדוג' היא בעצם לבצע Group By Count לסטרים של נתונים בכחול ניתן לראות את חלוקת החלונות למרווחים של 2 דקות בירוק ניתן לראות את הגדרת הWatermarks + Triggers, ההגדרה אומרת, לסגור את החלון להמשך עיבוד לאחר דקה ולעדכן אותו בתנאי שאנחנו מקבלים ערך נוסף כלשהו כמו כן נגדיר חלון יחסי של דקה מהקלט האחרון שלאחריה לא נקבל יותר late firings והחלון יהיה סגור סופית במקרה זה הAccumulation שלנו הינו דיפולטיבי לSUM
- #35 Default machine type is n1, that can be changed --worker_machine_type