קל מאוד למצוא את עצמך במצב הזה: יש לך מערכת ניהול, אולי CRM, כמה קבצי אקסל שמסתובבים במייל, ובינתיים מישהו אומר לך שכדי "לעשות ניתוח נתונים רציני" אתה צריך לבחור בין אגם נתונים (data lake) למחסן נתונים (data warehouse). בשלב הזה השיחה עוברת מיד לנושא הטכנולוגיה, אבל הבעיה האמיתית היא אחרת. האם אתה באמת זקוק לארכיטקטורת נתונים חדשה, או שאתה פשוט צריך להפוך את הנתונים שכבר יש לך לקריאים ושימושיים?
עבור חברה קטנה או בינונית, ההבחנה הזו חשובה יותר מהטרמינולוגיה. בחירה שגויה לא רק יוצרת מורכבות טכנית. היא גורמת לפרויקטים ממושכים, לתלות ביועצים, לדוחות שמגיעים באיחור ולהשקעות שמתקשות להתורגם להחלטות טובות יותר. עם זאת, הבחירה שלא לעשות דבר מותירה את החברה במצב של ניווט על סמך ראייה בלבד.
העניין הוא לא ללמוד את שפת הספקים. העניין הוא להבין איזה פתרון מתאים לעסק שלך, לתקציב שלך ולמיומנויות הקיימות בפועל בארגון שלך. כאן תמצא מדריך מעשי שיעזור לך להבין את הדיון בנושא "אגם נתונים" לעומת "מחסן נתונים" מנקודת המבט של מי שצריך לאזן בין עלויות, נגישות ותשואה תפעולית.
הלחץ "לעשות משהו עם הנתונים" הוא כיום מוחשי. הכמויות גדלות, המקורות מתרבים, והמנהלים דורשים תחזיות, לוחות מחוונים והתראות מהירות יותר. בינתיים, עולים על הפרק מונחים שנראים כאילו הם מאלצים אותך לקבל החלטה ארכיטקטונית מיידית.
אך עבור חברות קטנות ובינוניות רבות, דווקא כאן טמון הקושי. משכנעים אותך שהצעד הראשון הוא לבחור בין שני מודלים תשתיתיים, בעוד שלעתים קרובות הבעיה האמיתית היא הרבה יותר קונקרטית: נתונים מפוזרים, פורמטים לא אחידים, דוחות ידניים, ואף אחד שאין לו זמן לסדר את הבלגן.
יש שאלות חשובות אחרות. האם באמת יש לך בעיה בארכיטקטורה? או שמא הבעיה היא בנגישות לנתונים? אם תבחר בפתרון הלא נכון, אתה עלול לממן פרויקט טכני במקום לשפר את השליטה בעסק. אם לא תבחר בשום דבר, תמשיך לקבל החלטות על סמך מידע חלקי.
מי שמנהל עסק קטן או בינוני לא זקוק לשיעור באוניברסיטה. הוא זקוק לקריטריון פשוט כדי להבין מה נחוץ, מה לא, והיכן מסתתר העלות האמיתית.
את ההבדל המשמעותי ביותר ניתן להבין באמצעות שתי תמונות מעשיות מאוד.
מחסן נתונים דומה לספרייה מאורגנת היטב. כל ספר נכנס אליה כשהוא כבר מקוטלג, מסווג ומונח על המדף הנכון. כשאתה מחפש מידע, אתה מוצא אותו במהירות כי הסדר נקבע מראש. אגם נתונים, לעומת זאת, דומה למחסן ענק שאליו מגיעות ארגזים מכל הסוגים. מכניסים לתוכו קבצים מסודרים, יומנים, קבצי PDF, תמונות, ייצוא ממערכת הניהול ונתוני אינטרנט. את הסדר מיישמים לאחר מכן, כשצריך לנתח אותם.
וכאן מגיע הפרט הטכני היחיד שכדאי באמת לזכור.
הבחנה זו משקפת גם את מקורן ההיסטורי. מחסן הנתונים נוצר לצורך ניתוח עסקי של נתונים שעברו ניקוי וארגון, בעוד שאגם הנתונים נוצר מאוחר יותר כדי לאחסן נתונים גולמיים במגוון פורמטים. לכן, מחסן הנתונים מתאים יותר לדיווח ולמדדי KPI, ואילו אגם הנתונים גמיש יותר לצורכי חקירה ולמידת מכונה, כפי שמסביר ניתוח זה על ההבדלים בין מחסן נתונים לאגם נתונים.
מאגר נתונים (warehouse) מתאים לשאלות שכבר ידועות. אגם נתונים (lake) שימושי כאשר ידוע שהנתונים עשויים להכיל ערך, אך עדיין לא ידוע באיזו צורה.
אם המטרה שלך היא לקבל מידע על מכירות, רווחיות, הזמנות, מלאי, עיכובים, ביצועים מסחריים והשוואות חודשיות, מערכת ה-warehouse קרובה יותר מבחינה קונספטואלית לצרכים שלך. היא מספקת לך בסיס אמין לדוחות סטנדרטיים, שאילתות SQL עקביות ונתונים שניתן להסתמך עליהם.
לעומת זאת, אם אתם עובדים עם נתונים מגוונים מאוד, כגון יומני יישומים, קבצי PDF, דוא"ל, טקסטים, תמונות או זרמי נתונים ממכונות, מאגר הנתונים (data lake) מציע חופש רב יותר. צוותי ה-IT יכולים לרכז מקורות נתונים הטרוגניים, בעוד שאנשי הדיווח ממשיכים להעדיף סביבות מובנות לצורך ביצוע שאילתות מהירות ועקביות. במסגרת זו משתלב גם הנושא הרחב יותר של קבלת החלטות מונחות נתונים בעסקים, הדורשת נגישות לנתונים עוד לפני טכנולוגיות מתוחכמות.
בדיון בנושא "אגם נתונים" לעומת "מחסן נתונים", רבים מבלבלים בין גמישות לבין תועלת מיידית.
מאגר נתונים יכול להכיל כמעט הכל. אך עצם ההכללה אינה הופכת את הנתונים לזמינים לניתוח מיידי. מחסן נתונים הוא פחות גמיש מבחינת הזנת נתונים, אך שימושי יותר כאשר נדרשות תשובות מהירות וסטנדרטיות. עבור חברה קטנה ובינונית, להבדל זה יש חשיבות רבה יותר מאשר לתיאוריה. כי הבעיה אינה לאחסן יותר, אלא לקבל החלטות טובות יותר.
שתי חברות עשויות להיעזר באותם נתוני מוצא ולהגיע לתוצאות שונות בתכלית. ההבדל, לרוב, אינו טמון בכמות הנתונים שנאספו, אלא באופן שבו הן מארגנות אותם, מעבדות אותם ומנגישות אותם למקבלי ההחלטות.
| קרִיטֶרִיוֹן | מחסן נתונים | מאגר נתונים |
|---|---|---|
| מבנה נתונים | Schema-on-write, המוגדר לפני הטעינה | Schema-on-read, המוגדר בעת הניתוח |
| סוג הנתונים | בעיקר מסודרים ונקיים | מובנים, חצי-מובנים ולא מובנים |
| תהליך טיפוסי | ETL: קודם כל לעבד, אחר כך לטעון | ELT, טען תחילה ואז הפוך |
| משתמשים טיפוסיים | אנליסט עסקי, פיננסים, ניהול | מהנדס נתונים, מדען נתונים, צוותים טכניים |
| ביצועים צפויים | צפוי יותר עבור BI ודיווח | משתנים רבים יותר, תלויים בשאילתה ובהכנה |
במאגר הנתונים, התהליך הקלאסי הוא ETL: מחלצים את הנתונים, מעבדים אותם ואז מעלים אותם. זה דורש יותר עבודה בהתחלה, אך מקל על התפעול בהמשך. מי שמסתכל על לוח המחוונים רואה שדות עקביים, הגדרות קבועות ומדדי KPI שמשמעותם נשארת זהה בכל המחלקות.
במאגר הנתונים, הזרימה היא לרוב מסוג ELT: תחילה מבצעים חילוץ, לאחר מכן טעינה, ורק בסוף, במידת הצורך, מבצעים עיבוד. גישה זו מעניקה חופש טכני רב יותר, אך דוחה חלק מהעבודה. עבור חברה קטנה או בינונית, דחייה כזו פירושה לרוב הצטברות של משימות, אשר בסופו של דבר נופלות על הצוות ברגע הגרוע ביותר – כלומר, דווקא כאשר נדרשת תגובה מהירה.
כלל אצבע: כאשר מספר אנשים נדרשים לקרוא את אותו המסמך ולקבל החלטות תפעוליות, מבנה שהוגדר מראש לפני העלאת המסמך מפחית טעויות, ויכוחים מיותרים ובזבוז זמן.
מבחינה תפעולית, מחסן נתונים (data warehouse) מתוכנן לשאילתות חוזרות, לדוחות תכופים וללוחות מחוונים הנמצאים בשימוש יומיומי. אגם נתונים (data lake) מתמודד היטב עם כמויות גדולות ופורמטים שונים, אך זמני התגובה וקלות השימוש תלויים במידה רבה באופן שבו הנתונים קוטלגו, הוכנו ונוהלו. השוואה טכנית שפורסמה על ידי CloudOptimo מסכמת היטב את הנקודה הזו: מחסן הנתונים שואף ליציבות, ואגם הנתונים – לגמישות.
עבור חברה קטנה ובינונית, הנושא אינו תיאורטי. כאשר מנהל המכירות פותח את הדוח הבוקר, הוא מצפה למספרים עקביים ולמהירות. לעומת זאת, אם הצוות הטכני נדרש לנתח קבצים, יומני מערכת או מסמכים מסוגים שונים, הוא עשוי להסכים לזמן תגובה ארוך יותר בתמורה לאיסוף נתונים נרחב יותר.
ההבדל המעשי אינו רק טכני. ההבדל הוא במי שמצליח להשתמש בנתונים בלי לבקש עזרה בכל פעם.
מחסן נתונים (data warehouse) המתוכנן כהלכה מקרב את הנתונים לעסקים. אגם נתונים (data lake), כשלעצמו, מקרב אותם לרוב לצוות הטכני. לכן, חברות קטנות ובינוניות רבות מגלות בשלב מאוחר את האמת המטרידה: הצומת האמיתית אינה בין שתי טכנולוגיות, אלא בין מערכת שמנגישה את הנתונים לבין מערכת ששומרת אותם מבלי להפוך אותם להחלטות טובות יותר.
מי שבוחן אפשרויות אלה במסגרת פרויקט מודרניזציה של מערכות המידע צריך לקחת בחשבון גם את המודל התפעולי, ולא רק את מאגר הנתונים. פתרונות הענן לעסקים קטנים ובינוניים עוזרים להבין בדיוק את הנקודה הזו: היכן מסתיימת התשתית והיכן מתחילים העלויות, הכישורים הנדרשים והאחריות השוטפת.
אגם הנתונים מוצג לעתים קרובות כבחירה החסכונית ביותר, מכיוון שהוא מאחסן נתונים גולמיים ומצמצם את העבודה הראשונית. זה נכון רק בחלקו. בהיעדר קטלוג, כללי גישה, שיטת שמות עקבית ובקרות איכות מינימליות, החיסכון הראשוני הופך לבזבוז זמן על חיפוש קבצים, שחזור הגדרות ובדיקת אמינות הנתונים.
לכן, בחברות קטנות ובינוניות רבות, ההשוואה הנכונה אינה "אגם נתונים מול מחסן נתונים" ברמה התיאורטית. השאלה הרלוונטית היא אחרת: האם באמת יש צורך לבנות אחת מהארכיטקטורות המקיפות הללו, או שמא עדיף להתחיל מרמה קלה יותר שתספק תובנות מהירות מבלי להיכנס מיד לכל המורכבות?
עבור חברה קטנה או בינונית, הטעות היקרה ביותר נובעת לעתים קרובות משאלה שלא הוצגה כהלכה: "מה זול יותר – אגם נתונים או מחסן נתונים?". בחברה, החשבון האמיתי מגיע רק אחר כך. הוא מגיע כאשר הנתונים אינם מתקשרים ביניהם, הדוחות מתקלקלים בכל החלפת מערכת ניהול, וכל בקשה עוברת דרך יועצים או מפתחים במקום דרך הצוות שאמור לקבל את ההחלטות.
אחסון הנתונים תופס פחות מקום ממה שנדמה. מה שתופס יותר מקום הן הפעולות שהופכות את הנתונים לאמינים ושימושיים: מודלים, אינטגרציות, הרשאות, בקרת איכות, ניטור, תיקון שגיאות ותמיכה במשתמשים.
הקמת מחסן נתונים דורשת עבודה רבה בתחילת הדרך. יש להגדיר מדדים, לבנות צינורות נתונים, ליישר את המקורות ולשמור על הסדר גם כאשר מתבצעים שינויים במערכות ה-ERP, ה-CRM או בכללי העסק. בתמורה, ההנהלה מקבלת נתונים יציבים יותר, והדיווח נוטה להיות צפוי יותר.
אגם נתונים (data lake) מתחיל לעתים קרובות בהבטחה צנועה יותר. הוא מאפשר לטעון נתונים מסוגים שונים ולדחות חלק מההחלטות המבניות. הבעיה היא שהדחייה לא מבטלת את העבודה. היא רק דוחה אותה למועד מאוחר יותר, שם היא מתבטאת בצורך בקטלוג, אבטחה, עלויות חישוב, כפילויות, גרסאות לא עקביות ובדיקות מתמשכות כדי לברר אילו נתונים אכן אמינים.
הסיכון עבור חברה קטנה או בינונית הוא לשלם פעמיים. פעם אחת כדי לאסוף את הנתונים, ופעם שנייה כדי להפוך אותם סוף סוף לקריאים.
המורכבות האמיתית אינה טכנית. היא תפעולית.
אם כל דוח חדש מצריך התערבות ידנית, אם מנהל הכספים ומנהל המכירות משתמשים בהגדרות שונות לאותו מדד, ואם היזם נאלץ להמתין ימים שלמים עד לקבלת נתון אמין, פרויקט הנתונים כבר גוזל מהרווחיות. גם אם התשתית, על הנייר, נראית מודרנית.
לכן, כדאי לבחון גם את מודל הניהול, ולא רק את הארכיטקטורה. פתרונות הענן לעסקים קטנים ובינוניים עוזרים להבין את ההבדל הזה: מה אתה באמת קונה, כמה תחזוקה נשארת בתוך הארגון וכמה אתה תלוי במומחיות מקצועית בכל חודש.
בשוק האיטלקי, מי שמשקיע בניתוח נתונים מחפש תוצאות מוחשיות. צמצום העבודה הידנית. סגירת עסקאות מהירה יותר. שליטה טובה יותר במכירות, ברווחיות, במלאי ובתזרים המזומנים. לא פלטפורמה מתוחכמת שנשארת בידי מעטים.
זה משנה את הקריטריונים לבחירה. חברה קטנה או בינונית לא צריכה לשאול את עצמה איזו ארכיטקטורה היא המרתקת ביותר או הגמישה ביותר באופן תיאורטי. עליה לשאול את עצמה כמה זמן נדרש כדי להגיע ללוחות מחוונים אמינים, כמה אנשים דרושים לתחזוקתם וכמה מהר הפרויקט מניב ערך.
בתחום הקמעונאות, העלויות הנסתרות מתגלות במהרה. כאשר נתוני המכירות, ההחזרות, המבצעים והמלאי מגיעים ממערכות שונות, די בהגדרה שגויה של "רווח" או "מכירות נטו" כדי לערער את האמון בדוחות. בשלב זה, הבעיה אינה טמונה בבסיס הנתונים שנבחר, אלא בכך שהבעלים חוזר לקבל החלטות באמצעות Excel.
בתחום הפיננסי, מחיר הטעות בולט עוד יותר. דיווח, איזון, בקרה ניהולית וניתוח סטיות מחייבים נתונים עקביים וניתנים למעקב. אם כל ביקורת מעוררת ויכוחים לגבי מקור הנתונים, הפרויקט מאבד את החזר ההשקעה עוד לפני שהסתיים.
לכן, בפועל, חברות קטנות ובינוניות רבות אינן זקוקות לבניית אגם נתונים או מחסן נתונים מלא מאפס. הן זקוקות למערכת קלה יותר, קלה לניהול ומכוונת לקבלת החלטות.
אם אינך מצליח לשמור לאורך זמן על איכות הנתונים, כללי הגישה וההגדרות המוסכמות, הבעיה אינה הבחירה בין אגם נתונים למחסן נתונים. הבעיה היא שרכשת מורכבות לפני שהייתה לך סיבה מוצדקת לכך.
השאלה הנכונה אינה איזו ארכיטקטורה היא "הטובה ביותר" באופן מוחלט. השאלה היא איזו בעיה עליך לפתור מחר בבוקר.
בתחום הקמעונאות, המחסן מתפקד היטב כאשר נדרש לענות תמיד על אותן שאלות תפעוליות:
כך גם בתחום הפיננסי. אם עליך לאחד נתונים מובנים, להכין דוחות תקופתיים, לנתח תיקי השקעות או לנתח מגמות כלכליות על פי קריטריונים קבועים, מחסן הנתונים נותר הבחירה הטבעית.
שיטת ה-Lake מתאימה כאשר החברה שלך אוספת נתונים מגוונים מאוד, ואינך רוצה או אינך יכול להגדיר הכל מראש.
דוגמה מציאותית היא זו של חברת אנרגיה המשלבת:
בהקשר כזה, מחסן נתונים מסורתי מאלץ אותך לתכנן מראש את הקשרים בין מקורות מידע שאולי אינך מכיר עדיין היטב. אגם נתונים מאפשר לרכז את הכל ולהגדיר מבנה רק כאשר הדבר נדרש לצורך ניתוח ספציפי. זהו סוג התרחיש שבו הגמישות של אגם הנתונים באמת יוצרת ערך.
אגם הנתונים אינו בחירה "מודרנית יותר". זו בחירה הגיונית רק כאשר מגוון הנתונים מצדיק את המורכבות שאתה מכניס לארגון שלך.
רוב העסקים הקטנים והבינוניים אינם פועלים בסביבה כזו. הם מתבססים בעיקר על נתונים ממערכות ERP, CRM, מסחר מקוון, חשבונאות, ייצוא CSV ו-Excel. במקרים אלה, הבעיה אינה ניהול קבצי וידאו, יומני יישומים או טקסט חופשי בהיקף נרחב. הבעיה היא להציג נתונים נקיים, עקביים וקריאים גם לאנשים שאינם בעלי רקע טכני.
יש להבהיר כאן את הנקודה: לעתים קרובות אין צורך לא באגם נתונים ולא במחסן נתונים מסורתי.
מה שנדרש הוא דווקא:
ה-Lakehouse מנסה לשלב בין שני העולמות. הוא מבטיח את הגמישות של ה-Lake ואת חלק מהתכונות של ה-Warehouse באותו סביבה. זוהי כיוון מעניין, במיוחד עבור חברות עם עומסי עבודה מעורבים הכוללים BI, AI ומדע נתונים.
אולם עבור חברה קטנה או בינונית, השאלה נותרת זהה: האם באמת יש לך בעיה שמצדיקה את כל זה? אם הצורך שלך הוא להבין טוב יותר את המכירות, הרווחיות, תזרים המזומנים או התחזיות, ייתכן שפתרון היברידי מתוחכם עדיין יהיה יקר מדי ביחס לערך הצפוי.
ה-Data Lakehouse נוצר כדי להתגבר על ההפרדה הנוקשה בין אגם נתונים (lake) למחסן נתונים (warehouse). הרעיון פשוט: לשמור על הגמישות של אחסון נרחב ופתוח, אך להוסיף סדר, ביצועים ויכולות ניתוח הדומות יותר לאלה של מחסן נתונים. טכנולוגיות כמו Databricks ו-Delta Lake מייצגות היטב כיוון זה.
מבחינה תיאורטית, זה רעיון מפתה מאוד. משתמשים באותה מסד נתונים עבור BI, ניתוח מתקדם ולמידת מכונה, ובכך נמנעים משכפול יתר של מידע בין מערכות שונות. עבור ארגונים גדולים, או עבור צוותי נתונים מנוסים, זוהי תשובה הגיונית לאקוסיסטמה שהפכה למורכבת יותר עם הזמן.
בבדיקות הביצועים האקדמיות, ארכיטקטורת ה-Data Lakehouse נמדדת באמצעות מדדים כגון תפוקה, זמן השהיה ועומס-על של מטא-נתונים. הדבר מראה כי ההשוואה למחסן הנתונים אינה רק פונקציונלית, אלא גם קשורה לביצועים, בתרחישים שבהם להבדלים קטנים בביצועים יש השפעה משמעותית, כפי שמודגש במצגת אקדמית זו על בדיקות הביצועים של ה-Data Lakehouse.
בתרגום לשפת העסקים: Lakehouse מספקת פתרונות לארגונים שכבר הגיעו לרמה מסוימת של היקף, מורכבות והתמחות.
אם לא היית באמת זקוק לאגם נתונים ולא למחסן נתונים, סביר להניח שאתה לא זקוק למערכת המשלבת את שניהם.
עבור רוב העסקים הקטנים והבינוניים, השאלה החשובה ביותר אינה "איזו ארכיטקטורה לבחור?", אלא "כיצד אוכל להשיג ניתוחים אמינים מבלי להפוך את פרויקט הנתונים לאתר בנייה תמידי?".
זוהי הדרך השלישית שחסרה בהשוואות רבות בין מאגר נתונים (data lake) למחסן נתונים (data warehouse). אל תבנו תשתית קניינית חדשה. במקום זאת, הוסיפו שכבת ניתוח מעל המערכות שאתם כבר משתמשים בהן, ובכך הוציאו את המורכבות הטכנית מחוץ לתחום הפעילות התפעולי של החברה.
בפועל, הגישה הנכונה ביותר היא זו:
ראיתי לא מעט חברות קטנות ובינוניות שמשקיעות חודשים בהקמת מאגר נתונים מסורתי, ואז כמעט לא משתמשות בו. לא בגלל שהוא נבנה בצורה לא נכונה, אלא משום שאף אחד בחברה לא ידע לבצע בו שאילתות באופן עצמאי. צוואר הבקבוק לא היה מסד הנתונים, אלא הנגישות אליו.
זהו נקודה שלעתים קרובות לא מייחסים לה חשיבות מספקת. ארכיטקטורה מתוחכמת, המחייבת תמיד מתווך טכני, מפחיתה את הערך המעשי של הנתונים. פתרון פשוט יותר, אך כזה שההנהלה יכולה להבין, מביא לעתים קרובות להחלטות טובות יותר ובמהירות רבה יותר.
לכן, חברות רבות מפיקות ערך רב יותר מתוכנת בינה עסקית (BI) המתוכננת היטב לעסקים קטנים ובינוניים מאשר מתוכנה תשתיתית גדולה מדי. התוצאה שהן מחפשות אינה בעלות על מחסן נתונים, אלא הבנה טובה יותר ומהירה יותר של העסק.
התשתית הנכונה היא זו שהצוות שלך מצליח להשתמש בה, לתחזק אותה ולהפוך אותה להחלטות. לא זו שמרשימה במצגת טכנית.
הדיון בנושא "אגם נתונים" לעומת "מחסן נתונים" הוא מועיל, אך עבור חברות קטנות ובינוניות הוא מתחיל לעתים קרובות מהשאלה הלא נכונה. לפני שתבחר בארכיטקטורה, עליך להבין אם אכן קיימת בעיה של היקף ומגוון הנתונים, או שמא מדובר בבעיה נפוצה הרבה יותר: נתונים מפוזרים, דוחות ידניים ונגישות מוגבלת.
מחסן הנתונים נשאר פתרון יעיל כאשר נדרשים דוחות אמינים, מדדי KPI עקביים וביצועים צפויים. אגם הנתונים מתאים כאשר מגוון המקורות מצדיק גמישות רבה יותר ומורכבות גבוהה יותר. ה-lakehouse הוא התפתחות מעניינת, אך לעתים רחוקות הוא הצעד הנכון הראשון עבור ארגון שמעוניין בעיקר בשליטה תפעולית ובתשואה על ההשקעה (ROI).
הבחירה החכמה ביותר אינה הטכנולוגיה המתקדמת ביותר. זו הבחירה המתאימה לבעיה האמיתית, לכישורים הקיימים ולמהירות שבה ברצונך להפוך את הנתונים להחלטות.
אם ברצונך להפוך את נתוני החברה לדוחות, תחזיות ותובנות תפעוליות מבלי להקים תשתית מורכבת, גלה את ELECTE, פלטפורמת ניתוח נתונים מבוססת בינה מלאכותית המיועדת לעסקים קטנים ובינוניים. תוכל להתחיל מהנתונים שכבר יש ברשותך, לצמצם את העבודה הידנית ולהנגיש את הניתוחים לצוות שלך באמצעות גישה יעילה בהרבה.
.svg)
.svg)
.svg)
