Skip to main content
Workforce LibreTexts

13.7: Detailed Figure Captions - Chapter 13

  • Page ID
    60923
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\dsum}{\displaystyle\sum\limits} \)

    \( \newcommand{\dint}{\displaystyle\int\limits} \)

    \( \newcommand{\dlim}{\displaystyle\lim\limits} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \(\newcommand{\longvect}{\overrightarrow}\)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\ket}[1]{\left| #1 \right>}\)
    \(\newcommand{\bra}[1]{\left< #1 \right|}\)
    \(\newcommand{\braket}[2]{\left< #1 \vphantom{#2} \right| \left. #2 \vphantom{#1} \right>}\)
    \(\newcommand{\braopket}[3]{\left< #1 \vphantom{#2}\vphantom{#3} \right| #2 \vphantom{#1}\vphantom{#3} \left| #3 \vphantom{#1}\vphantom{#2} \right>}\)
    \(\newcommand{\qmvec}[1]{\mathbf{\vec{#1}}}\)
    \(\newcommand{\op}[1]{\hat{\mathbf{#1}}}\)
    \(\newcommand{\expect}[1]{\langle #1 \rangle}\)
    \(\newcommand{\dfn}[1]{\emph{\textbf{#1}}}\)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    Cloud Analytics Platforms and Real-World Case Studies — Figure Specifications

    Overview

    • Chapter: 13 — Cloud Analytics Platforms and Real-World Case Studies

    • Total Figures Proposed: 8

    • Figure Types Used: Architecture Diagram, Comparison Table, Flowchart, Conceptual Illustration, Infographic


    Figure 13.1.1

    Title: Major Cloud Analytics Service Stacks Compared

    Detailed Caption: A four-row, four-column comparison table organizes the major cloud analytics service stacks by analytics layer across three providers. Column headers — AWS, Azure, and Google Cloud — each carry a simplified provider logo, and row labels down the left margin read Data Lake / Storage, Data Warehouse, Data Processing / ETL, and BI / Visualization. Reading across each row reveals the equivalent service at each vendor: S3 / ADLS Gen2 / Cloud Storage for storage; Redshift / Synapse Analytics / BigQuery for warehousing; Glue + Kinesis / Data Factory + Databricks / Dataflow for processing; and QuickSight / Power BI / Looker for visualization. Navy header bands, teal row highlights, and warm-gold accent borders keep the three-column alignment visually clean. By collapsing nine service names per provider into a single grid, the table transforms what would otherwise require cross-referencing three subsections of prose into an instant side-by-side lookup — students can confirm that Redshift and Synapse and BigQuery are architectural peers, or that QuickSight and Power BI and Looker occupy the same functional layer, without losing their place in the chapter.


    Figure 13.2.1

    Title: Serverless Data Lake Analytics Pipeline Architecture

    Detailed Caption: A five-stage left-to-right pipeline traces how data travels from origin to decision-maker without a single dedicated server. Stage 1, Data Sources, groups three icons — Streaming Apps, On-Prem DBs, and SaaS — representing the heterogeneous feeds that enter a modern analytics estate. Warm-gold arrows carry the data rightward into Stage 2, Ingestion, represented by a funnel labeled Kinesis / Event Hubs. Stage 3, Cloud Data Lake, stacks three horizontal zones — Raw (light gray), Clean (light teal), and Curated (darker teal) — with a gear icon labeled ETL (Glue / Data Factory) bridging the zone transitions. Stage 4, Query & Analytics, splits into two parallel teal boxes: Serverless SQL (Athena / BigQuery) and Data Warehouse (Redshift / Synapse), capturing both ad-hoc and structured query paths. Stage 5, Serving & BI, closes the pipeline with a dashboard icon labeled QuickSight / Power BI / Looker. By labeling every component with the real managed-service names used in the text, the figure converts the abstract concept of "serverless" from a marketing term into a concrete sequence of handoffs where no stage requires a user to provision or maintain compute infrastructure.

    Figure 13.2.2

    Title: Typical Four-Layer Cloud Data Platform Architecture 

    Detailed Caption: The diagram illustrates a linear, left-to-right data pipeline composed of four core layers, with multiple inputs and outputs branching off. Each layer is represented as a tall rectangular box, connected by directional arrows showing data flow. This architecture represents the standard cloud analytics pattern — Ingest → Storage → Processing → Serving — where each layer is a fully managed, decoupled component. Data enters via streaming or batch ingestion, is stored in a scalable lake, transformed by processing engines, and then served out through warehouses, APIs, or exports, enabling self-service analytics across roles.

     

    Figure 13.2.3

    Title: Four-Layer Cloud Data Platform Architecture

    Detailed Caption: Four horizontal layers stack vertically, each anchored by a colored banner that names its role in the universal cloud data platform pattern. The top layer, Data Ingest, shown in navy, splits into two lanes — Batch (files, DBs) and Stream (IoT, events, logs) — illustrating that platforms must accommodate both pull-based and push-based inputs simultaneously. The second layer, Data Storage in teal, centers on a large cylinder labeled Cloud Data Lake / Warehouse with sub-labels Object Storage and Columnar Tables, signaling that physical storage and logical table organization coexist in the same tier. The third layer, Data Processing in a slightly deeper teal, holds three gear icons labeled ETL/ELT, SQL Engines, and Spark / ML, representing the transformation workloads that convert raw material into analytical substance. The bottom layer, Data Serving in warm gold, fans outward to Dashboards & Reports, APIs, and Data Marts — the consumption surfaces that make processed data actionable for different audience types. A vertical bracket on the right labeled Managed Cloud Services spans all four layers, reinforcing the chapter's argument that the platform pattern is vendor-neutral even as its specific implementation differs across AWS, Azure, and Google Cloud.


    Figure 13.3.1

    Title: Cloud Cost Optimization Strategy Matrix

    Detailed Caption: Three vertical columns, each topped by a header icon and title, lay out the primary levers for reducing cloud analytics spend. Column 1, Reserved / Committed Pricing, displays a lock icon and specifies a 1–3 year commitment horizon, a 30–72 % savings range, and the annotation Best for: steady baseline workloads; a green checkmark highlights Predictable costs while a red X flags Inflexible capacity. Column 2, Spot / Preemptible Instances, anchored by a lightning-bolt icon, describes bidding on spare capacity for 70–90 % savings and notes Best for: fault-tolerant batch jobs (ETL, ML training); the checkmark rewards Massive savings and the X warns Can be interrupted. Column 3, Data Storage Tiering, illustrated with a layered-stack icon, enumerates Hot / Warm / Cold / Archive tiers at 68–95 % storage savings for aging or infrequently accessed data; the checkmark endorses Automatic lifecycle rules while the X acknowledges Retrieval latency for cold data. By surfacing savings percentages, qualifying conditions, and trade-off signals inside a single three-panel view, the figure gives students the comparative vocabulary to match cost strategy to workload type rather than applying the cheapest option uniformly — committed pricing is not always cheapest when workloads are bursty, and spot instances are not always risky when jobs are designed for interruption.


    Figure 13.4.1

    Title: Retail Cloud Personalization Pipeline

    Detailed Caption: A compact closed-loop flowchart traces how a retailer converts raw clickstream data into revenue-generating personalization. On the left, a laptop labeled Website and a smartphone labeled Mobile App emit arrows annotated Clickstream & Purchase Data into a cylinder labeled Cloud Data Lake (S3), capturing both structured purchase events and unstructured browsing signals in a single repository. An arrow labeled Training Data exits the lake and enters a central box — ML Recommendation Engine (Amazon Personalize / Recommendations AI) — decorated with a brain-and-gear icon and a small annotation reading Auto-retrains on new data, signaling that the model improves continuously rather than on a fixed schedule. From the engine, a Real-Time API arrow delivers Personalized Product Recommendations to a right-side box, and a return arc labeled Tailored Experience closes the loop back to the Website and Mobile App icons. A warm-gold callout in the lower right reads Result: 10–15% revenue increase, grounding the architectural description in a concrete business outcome. The closed-loop topology makes visible the feedback mechanism that distinguishes a modern ML-powered personalization system from a static rules engine: each recommendation that users accept or ignore becomes new training signal that flows back into the lake and re-enters the model on the next training cycle.


    Figure 13.4.2

    Title: Healthcare Cloud Predictive Analytics Architecture

    Detailed Caption: A left-to-right architecture diagram illustrates the closed clinical loop through which a healthcare cloud analytics platform amplifies physician decision-making. On the far left, a hospital building icon labeled Hospital EHR System carries sub-labels Labs, Vitals, Notes, representing the rich heterogeneous data an academic medical center generates continuously. A Real-Time Data Stream arrow carries this data rightward into a navy-bordered cloud boundary box labeled Cloud Analytics Platform, inside which three sequential components — Data Preprocessing & Standardization, Deep Learning Model (Sepsis Prediction), and Prediction Output & Alert Generation — are connected by teal arrows. A Predictions Written Back arrow exits the cloud box on the right and flows into a computer screen labeled EHR Clinical Dashboard, augmented by an alert-bell icon and the label Clinician Alert, showing that the system's output does not stay inside the cloud but re-enters the clinical workflow where a physician acts on it. Below the cloud box, two shield icons — HIPAA Compliant and Encrypted End-to-End — acknowledge the regulatory and security constraints that govern any health data pipeline. The diagram makes the feedback architecture explicit: the platform is not a one-way analytics export but a two-way integration whose predictions are written back into the same EHR from which their training data was drawn, creating a living clinical decision-support loop.


    Figure 13.4.3

    Title: Manufacturing IoT Predictive Maintenance Pipeline

    Detailed Caption: A branching architecture diagram shows how a manufacturer routes IoT telemetry through Azure's analytics stack to produce both predictive failure scores and operational dashboards. On the far left, three factory machine icons dotted with sensor glyphs emit Telemetry Data arrows that converge on a box labeled Azure IoT Hub, the ingestion gateway that buffers and routes incoming streams at scale. From IoT Hub, the pipeline forks into two parallel paths: an upper path carries data to an Azure Storage / Data Lake cylinder and then to an Azure Synapse / Databricks (Analytics) box for historical analysis and model training; a lower path routes to Azure Functions + ML Models (Failure Prediction) for near-real-time scoring against live sensor readings. Both paths converge on a Power BI Dashboards icon on the right, with a wrench icon below it labeled Maintenance Team Alert indicating that the dashboard's primary consumer acts on predictions rather than merely observing them. Three warm-gold result callout boxes along the bottom — 40% Less Downtime, 30% IT Cost Reduction, 35% Better Forecast Accuracy — translate architectural choices into business outcomes. The dual-path topology captures a design principle that the chapter emphasizes throughout the manufacturing case study: batch training and real-time scoring are complementary workloads that share storage infrastructure but require separate compute paths optimized for their respective latency and throughput requirements.


    Figure 13.5.1

    Title: Cloud Analytics Best Practices Framework

    Detailed Caption: A honeycomb of seven smaller hexagons surrounds a central navy hexagon labeled Cloud Analytics Excellence, each outer cell containing an icon and a two-line label that names one best practice and its core concern. Clockwise from the top: a shield icon for Data Governance (Quality, ownership, access controls); a network icon for Latency & Integration (Hybrid connectivity, compression); a multi-cloud icon for Avoid Vendor Lock-In (Open standards, multi-cloud); a dollar-sign icon for Cost Efficiency (Serverless, auto-scaling, pay-per-use); a lock icon for Security & Compliance (IAM, encryption, least privilege); a gear-and-pipeline icon for Pipeline Reliability (CI/CD, monitoring, orchestration); and a warning-triangle icon for Avoid Anti-Patterns (No monolithic ETL, no silos). All outer hexagons are filled in light teal, and thin warm-gold lines radiate from each cell to the navy center. By placing all seven guidelines on a single canvas and connecting them visually to a shared center, the honeycomb makes the chapter's synthesis argument structural rather than rhetorical — no single practice stands alone, each radiates from the same hub of cloud analytics excellence, and neglecting any one cell leaves a gap in the surrounding ring.


    This page titled 13.7: Detailed Figure Captions - Chapter 13 was last modified on Thu, 17 Sep 2026 19:15:40 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Felix Amoruwa.

    • Was this article helpful?