כיצד להגביר את מהירות הקריאה מ-HBase עד פי 3 ומ-HDFS עד פי 5

ביצועים גבוהים הם אחת הדרישות המרכזיות בעבודה עם נתונים גדולים. במחלקת טעינת הנתונים ב-Sberbank, אנו שואבים כמעט את כל העסקאות לתוך ה-Data Cloud המבוסס על Hadoop ולכן מתמודדים עם זרימות מידע גדולות באמת. באופן טבעי, אנחנו תמיד מחפשים דרכים לשפר את הביצועים, ועכשיו אנחנו רוצים לספר לכם איך הצלחנו לתקן את RegionServer HBase ואת לקוח HDFS, שבזכותם הצלחנו להגביר משמעותית את מהירות פעולות הקריאה.


עם זאת, לפני שעוברים למהות השיפורים, כדאי לדבר על הגבלות שבאופן עקרוני לא ניתן לעקוף אם יושבים על דיסק קשיח.

מדוע HDD וקריאות גישה אקראית מהירה אינם תואמים
כידוע, HBase, ומסדי נתונים רבים אחרים, מאחסנים נתונים בבלוקים בגודל של כמה עשרות קילובייטים. כברירת מחדל זה בערך 64 KB. עכשיו בואו נדמיין שאנחנו צריכים לקבל רק 100 בתים ואנו מבקשים מ-HBase לתת לנו את הנתונים האלה באמצעות מפתח מסוים. מכיוון שגודל הבלוק ב-HFiles הוא 64 KB, הבקשה תהיה גדולה פי 640 (דקה בלבד!) מהנדרש.

לאחר מכן, מכיוון שהבקשה תעבור דרך HDFS ומנגנון מטמון המטא נתונים שלו ShortCircuitCache (מה שמאפשר גישה ישירה לקבצים), זה מוביל לקריאת כבר 1 MB מהדיסק. עם זאת, ניתן להתאים זאת באמצעות הפרמטר גודל.dfs.client.read.shortcircuit.buffer ובמקרים רבים הגיוני להפחית את הערך הזה, למשל ל-126 KB.

נניח שאנחנו עושים את זה, אבל בנוסף, כשאנחנו מתחילים לקרוא נתונים דרך ממשק ה-Java API, כמו פונקציות כמו FileChannel.read ומבקשים ממערכת ההפעלה לקרוא את כמות הנתונים שצוינה, הוא קורא "למקרה" פי 2 יותר , כלומר 256 KB במקרה שלנו. הסיבה לכך היא ש-java אין דרך קלה להגדיר את הדגל FADV_RANDOM כדי למנוע התנהגות זו.

כתוצאה מכך, כדי לקבל את 100 הבתים שלנו, 2600 פעמים יותר נקרא מתחת למכסה המנוע. נראה שהפתרון מובן מאליו, בואו נצמצם את גודל הבלוק לקילו-בייט, נציב את הדגל שהוזכר ונרוויח האצת הארה גדולה. אבל הבעיה היא שעל ידי הקטנת גודל הבלוק פי 2, אנו גם מצמצמים את מספר הבתים הנקראים ליחידת זמן פי 2.

ניתן להשיג רווח מסוים מהגדרת הדגל FADV_RANDOM, אבל רק עם ריבוי השחלות גבוה ועם גודל בלוק של 128 KB, אבל זה מקסימום של כמה עשרות אחוזים:

בדיקות בוצעו על 100 קבצים, כל אחד בגודל 1 GB וממוקם על 10 דיסקים קשיחים.

בואו לחשב על מה אנחנו יכולים, באופן עקרוני, לסמוך במהירות הזו:
נניח שאנו קוראים מ-10 דיסקים במהירות של 280 מגה-בייט/שנייה, כלומר. 3 מיליון כפול 100 בייטים. אבל כזכור, הנתונים שאנו צריכים הם פי 2600 פחות ממה שנקרא. לפיכך, אנו מחלקים 3 מיליון ב-2600 ומקבלים 1100 רשומות בשנייה.

מדכא, לא? זה הטבע גישה אקראית גישה לנתונים ב-HDD - ללא קשר לגודל הבלוק. זוהי המגבלה הפיזית של גישה אקראית ואף מסד נתונים לא יכול לסחוט יותר בתנאים כאלה.

כיצד אם כן מסדי נתונים משיגים מהירויות גבוהות בהרבה? כדי לענות על שאלה זו, בואו נסתכל על מה שקורה בתמונה הבאה:

כאן אנו רואים שבדקות הראשונות המהירות היא באמת כאלף שיאים בשנייה. עם זאת, בנוסף, בשל העובדה שנקרא הרבה יותר ממה שהתבקש, הנתונים מגיעים בסופו של דבר ל-buff/cache של מערכת ההפעלה (לינוקס) והמהירות עולה ל-60 אלף יותר הגונים לשנייה

לפיכך, בהמשך נעסוק בהאצת הגישה רק לנתונים שנמצאים במטמון מערכת ההפעלה או נמצאים בהתקני אחסון SSD/NVMe בעלי מהירות גישה דומה.

במקרה שלנו, אנו נערוך בדיקות על ספסל של 4 שרתים, שכל אחד מהם מחויב באופן הבא:

מעבד: Xeon E5-2680 v4 @ 2.40GHz 64 פתילים.
זיכרון: 730 GB.
גרסת java: 1.8.0_111

וכאן נקודת המפתח היא כמות הנתונים בטבלאות שצריך לקרוא. העובדה היא שאם אתה קורא נתונים מטבלה שממוקמת כולה ב-HBase cache, אז זה אפילו לא יגיע לקריאה מה-buff/cache של מערכת ההפעלה. כי HBase כברירת מחדל מקצה 40% מהזיכרון למבנה שנקרא BlockCache. בעיקרו של דבר זהו ConcurrentHashMap, כאשר המפתח הוא שם הקובץ + היסט של הבלוק, והערך הוא הנתונים בפועל בהיסט הזה.

לכן, כשקוראים רק מהמבנה הזה, אנחנו אנו רואים מהירות מצוינת, כמו מיליון בקשות בשנייה. אבל בואו נדמיין שאנחנו לא יכולים להקצות מאות גיגה-בייט של זיכרון רק לצרכי מסד נתונים, כי יש הרבה דברים שימושיים אחרים שפועלים על השרתים האלה.

לדוגמה, במקרה שלנו, נפח BlockCache ב-RS אחד הוא כ-12 GB. הנחתנו שני RS על צומת אחד, כלומר. 96 GB מוקצים עבור BlockCache בכל הצמתים. ויש הרבה פעמים יותר נתונים, למשל, תנו לזה להיות 4 טבלאות, 130 אזורים כל אחת, שבהן קבצים בגודל 800 מגה-בייט, דחוסים על ידי FAST_DIFF, כלומר. סה"כ 410 GB (זהו נתונים טהורים, כלומר בלי לקחת בחשבון את גורם השכפול).

לפיכך, BlockCache הוא רק כ-23% מנפח הנתונים הכולל וזה הרבה יותר קרוב לתנאים האמיתיים של מה שנקרא BigData. וכאן מתחיל הכיף - כי ברור שככל שפחות כניסות מטמון, כך הביצוע גרוע יותר. אחרי הכל, אם תפספסו, תצטרכו לעשות הרבה עבודה - כלומר. רד לפונקציות מערכת התקשרות. עם זאת, אי אפשר להימנע מכך, אז בואו נסתכל על היבט אחר לגמרי – מה קורה לנתונים בתוך המטמון?

בואו נפשט את המצב ונניח שיש לנו מטמון שמתאים רק לאובייקט אחד. הנה דוגמה למה שיקרה כאשר ננסה לעבוד עם נפח נתונים גדול פי 1 מהמטמון, נצטרך:

1. הצב בלוק 1 במטמון
2. הסר את בלוק 1 מהמטמון
3. הצב בלוק 2 במטמון
4. הסר את בלוק 2 מהמטמון
5. הצב בלוק 3 במטמון

5 פעולות הושלמו! עם זאת, מצב זה לא יכול להיקרא נורמלי; למעשה, אנו מאלצים את HBase לעשות חבורה של עבודה חסרת תועלת לחלוטין. זה כל הזמן קורא נתונים מהמטמון של מערכת ההפעלה, ממקם אותם ב-BlockCache, רק כדי לזרוק אותם כמעט מיד בגלל שחלק חדש של נתונים הגיע. האנימציה בתחילת הפוסט מראה את מהות הבעיה – Garbage Collector יורד מקנה מידה, האווירה מתחממת, גרטה הקטנה בשבדיה הרחוקה והלוהטת מתעצבנת. ואנחנו אנשי ה-IT ממש לא אוהבים כשילדים עצובים, אז אנחנו מתחילים לחשוב מה אנחנו יכולים לעשות בנידון.

מה אם לא תכניס את כל הבלוקים למטמון, אלא רק אחוז מסוים מהם, כדי שהמטמון לא יעלה על גדותיו? נתחיל בהוספת רק כמה שורות קוד לתחילת הפונקציה להכנסת נתונים ל-BlockCache:

  public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
    if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
      if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
        return;
      }
    }
...

הנקודה כאן היא הבאה: offset הוא מיקום הבלוק בקובץ והספרות האחרונות שלו מפוזרות באופן אקראי ושווה בין 00 ל-99. לכן, נדלג רק על אלו שנופלים בטווח שאנו צריכים.

לדוגמה, הגדר cacheDataBlockPercent = 20 וראה מה קורה:

התוצאה ברורה. בגרפים למטה, מתברר מדוע התרחשה האצה כזו - אנו חוסכים משאבי GC רבים מבלי לעשות את העבודה הסיזיפית של הצבת נתונים במטמון רק כדי לזרוק אותם מיד לטמיון של כלבי המאדים:

במקביל, ניצול המעבד עולה, אבל הוא הרבה פחות מהפרודוקטיביות:

ראוי גם לציין שהבלוקים המאוחסנים ב-BlockCache שונים. רובם, כ-95%, הם נתונים עצמם. והשאר הוא מטא נתונים, כגון מסנני Bloom או LEAF_INDEX ו т.д.. הנתונים האלה לא מספיקים, אבל הם מאוד שימושיים, כי לפני גישה ישירה לנתונים, HBase פונה למטא כדי להבין האם יש צורך לחפש כאן יותר ואם כן היכן בדיוק נמצא גוש העניין.

לכן, בקוד אנו רואים תנאי בדיקה buf.getBlockType().isData() ובזכות המטא הזה נשאיר אותו בכל מקרה במטמון.

עכשיו בואו נגדיל את העומס ונחזק מעט את התכונה במכה אחת. בבדיקה הראשונה עשינו את אחוז החיתוך = 20 וה-BlockCache היה מעט לא מנוצל. עכשיו בואו נגדיר את זה ל-23% ונוסיף 100 שרשורים כל 5 דקות כדי לראות באיזו נקודה מתרחשת הרוויה:

כאן אנו רואים שהגרסה המקורית פוגעת כמעט מיד בתקרה בכ-100 אלף בקשות לשנייה. ואילו התיקון נותן תאוצה של עד 300 אלף. יחד עם זאת, ברור שהאצה נוספת כבר לא כל כך "חופשית"; גם ניצול המעבד עולה.

עם זאת, זה לא פתרון אלגנטי במיוחד, מכיוון שאיננו יודעים מראש איזה אחוז מהבלוקים צריך להיות מטמון, זה תלוי בפרופיל העומס. לכן, יושם מנגנון להתאמה אוטומטית של פרמטר זה בהתאם לפעילות פעולות הקריאה.

שלוש אפשרויות נוספו כדי לשלוט בזה:

hbase.lru.cache.heavy.viction.count.count - מגדיר כמה פעמים התהליך של פינוי נתונים מהמטמון צריך לרוץ לפני שנתחיל להשתמש באופטימיזציה (כלומר דילוג על בלוקים). כברירת מחדל זה שווה ל-MAX_INT = 2147483647 ולמעשה אומר שהתכונה לעולם לא תתחיל לעבוד עם הערך הזה. כי תהליך הפינוי מתחיל כל 5 - 10 שניות (זה תלוי בעומס) ו 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 שנים. עם זאת, אנו יכולים להגדיר פרמטר זה ל-0 ולגרום לתכונה לעבוד מיד לאחר ההשקה.

עם זאת, יש גם מטען בפרמטר זה. אם העומס שלנו הוא כזה שקריאות קצרות טווח (נניח במהלך היום) וקריאות ארוכות טווח (בלילה) מפוזרות כל הזמן, אז נוכל לוודא שהפיצ'ר מופעל רק כאשר מתבצעות פעולות קריאה ארוכות.

לדוגמה, אנו יודעים שקריאות לטווח קצר נמשכות בדרך כלל כדקה אחת. אין צורך להתחיל לזרוק בלוקים, למטמון לא יהיה זמן להיות מיושן ואז נוכל להגדיר פרמטר זה שווה, למשל, ל-1. זה יוביל לכך שהאופטימיזציה תתחיל לעבוד רק כאשר ארוך- קריאה פעילה במונח החלה, כלומר. תוך 10 שניות. לפיכך, אם יש לנו קריאה לטווח קצר, אז כל הבלוקים ייכנסו למטמון ויהיו זמינים (למעט אלו שיסולקו על ידי האלגוריתם הסטנדרטי). וכאשר אנו עושים קריאה לטווח ארוך, התכונה מופעלת והיה לנו ביצועים גבוהים בהרבה.

hbase.lru.cache.heavy.eviction.mb.size.limit - מגדיר כמה מגה-בייט נרצה למקם במטמון (וכמובן, לפנות) תוך 10 שניות. התכונה תנסה להגיע לערך זה ולשמור עליו. הנקודה היא כזו: אם נדחוף ג'יגה-בייט למטמון, אז נצטרך לפנות ג'יגה-בייט, וזה, כפי שראינו למעלה, יקר מאוד. עם זאת, אל תנסה להגדיר אותו קטן מדי, מכיוון שהדבר יגרום ליציאה ממצב דילוג הבלוק בטרם עת. עבור שרתים חזקים (כ-20-40 ליבות פיזיות), אופטימלי להגדיר כ-300-400 מגה-בייט. למעמד הביניים (~10 ליבות) 200-300 MB. עבור מערכות חלשות (2-5 ליבות) 50-100 MB עשוי להיות נורמלי (לא נבדק על אלה).

בוא נסתכל איך זה עובד: נניח שהגדרנו hbase.lru.cache.heavy.eviction.mb.size.limit = 500, יש סוג של עומס (קריאה) ואז כל ~10 שניות מחשבים כמה בתים היו פונה באמצעות הנוסחה:

תקורה = סכום בתים משוחררים (MB) * 100 / מגבלה (MB) - 100;

אם למעשה 2000 מגה-בייט פונו, אז תקורה שווה ל:

2000 * 100 / 500 - 100 = 300%

האלגוריתמים מנסים לשמור על לא יותר מכמה עשרות אחוזים, כך שהתכונה תפחית את אחוז הבלוקים המאוחסנים במטמון, ובכך תטמיע מנגנון כוונון אוטומטי.

עם זאת, אם העומס יורד, נניח שרק 200 מגה-בייט יפונו וה-Overhead הופך לשלילי (מה שנקרא חריגה):

200 * 100 / 500 - 100 = -60%

להיפך, התכונה תגדיל את אחוז החסימות המאוחסנות במטמון עד שה-Overhead יהפוך לחיובי.

להלן דוגמה לאופן שבו זה נראה בנתונים אמיתיים. אין צורך לנסות להגיע ל-0%, זה בלתי אפשרי. זה טוב מאוד כאשר הוא בערך 30 - 100%, זה עוזר למנוע יציאה מוקדמת ממצב האופטימיזציה במהלך עליות קצרות טווח.

hbase.lru.cache.heavy.viction.coefficient.heavy - קובע כמה מהר נרצה לקבל את התוצאה. אם אנחנו יודעים בוודאות שהקריאה שלנו היא לרוב ארוכה ולא נרצה לחכות, נוכל להגדיל את היחס הזה ולהשיג ביצועים גבוהים מהר יותר.

לדוגמה, אנו קובעים את המקדם הזה = 0.01. המשמעות היא ש-Overhead (ראה לעיל) יוכפל במספר זה בתוצאה המתקבלת ואחוז הבלוקים המאוחסנים במטמון יקטן. נניח ש-Overhead = 300% ומקדם = 0.01, אז אחוז הבלוקים המאוחסנים במטמון יקטן ב-3%.

היגיון דומה של "לחץ אחורי" מיושם גם עבור ערכי Overhead (חיתוף יתר) שליליים. מכיוון שתנודות קצרות טווח בנפח הקריאה והפינוי תמיד אפשריות, מנגנון זה מאפשר לך להימנע מיציאה מוקדמת ממצב האופטימיזציה. ללחץ האחורי יש היגיון הפוך: ככל שהפריצה חזקה יותר, כך יותר בלוקים נשמרים במטמון.

קוד יישום

        LruBlockCache cache = this.cache.get();
        if (cache == null) {
          break;
        }
        freedSumMb += cache.evict()/1024/1024;
        /*
        * Sometimes we are reading more data than can fit into BlockCache
        * and it is the cause a high rate of evictions.
        * This in turn leads to heavy Garbage Collector works.
        * So a lot of blocks put into BlockCache but never read,
        * but spending a lot of CPU resources.
        * Here we will analyze how many bytes were freed and decide
        * decide whether the time has come to reduce amount of caching blocks.
        * It help avoid put too many blocks into BlockCache
        * when evict() works very active and save CPU for other jobs.
        * More delails: https://issues.apache.org/jira/browse/HBASE-23887
        */

        // First of all we have to control how much time
        // has passed since previuos evict() was launched
        // This is should be almost the same time (+/- 10s)
        // because we get comparable volumes of freed bytes each time.
        // 10s because this is default period to run evict() (see above this.wait)
        long stopTime = System.currentTimeMillis();
        if ((stopTime - startTime) > 1000 * 10 - 1) {
          // Here we have to calc what situation we have got.
          // We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"
          // and can calculte overhead on it.
          // We will use this information to decide,
          // how to change percent of caching blocks.
          freedDataOverheadPercent =
            (int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
          if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
            // Now we are in the situation when we are above the limit
            // But maybe we are going to ignore it because it will end quite soon
            heavyEvictionCount++;
            if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
              // It is going for a long time and we have to reduce of caching
              // blocks now. So we calculate here how many blocks we want to skip.
              // It depends on:
             // 1. Overhead - if overhead is big we could more aggressive
              // reducing amount of caching blocks.
              // 2. How fast we want to get the result. If we know that our
              // heavy reading for a long time, we don't want to wait and can
              // increase the coefficient and get good performance quite soon.
              // But if we don't sure we can do it slowly and it could prevent
              // premature exit from this mode. So, when the coefficient is
              // higher we can get better performance when heavy reading is stable.
              // But when reading is changing we can adjust to it and set
              // the coefficient to lower value.
              int change =
                (int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
              // But practice shows that 15% of reducing is quite enough.
              // We are not greedy (it could lead to premature exit).
              change = Math.min(15, change);
              change = Math.max(0, change); // I think it will never happen but check for sure
              // So this is the key point, here we are reducing % of caching blocks
              cache.cacheDataBlockPercent -= change;
              // If we go down too deep we have to stop here, 1% any way should be.
              cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
            }
          } else {
            // Well, we have got overshooting.
            // Mayby it is just short-term fluctuation and we can stay in this mode.
            // It help avoid permature exit during short-term fluctuation.
            // If overshooting less than 90%, we will try to increase the percent of
            // caching blocks and hope it is enough.
            if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
              // Simple logic: more overshooting - more caching blocks (backpressure)
              int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
              cache.cacheDataBlockPercent += change;
              // But it can't be more then 100%, so check it.
              cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
            } else {
              // Looks like heavy reading is over.
              // Just exit form this mode.
              heavyEvictionCount = 0;
              cache.cacheDataBlockPercent = 100;
            }
          }
          LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +
            "heavy eviction counter: {}, " +
            "current caching DataBlock (%): {}",
            freedSumMb, freedDataOverheadPercent,
            heavyEvictionCount, cache.cacheDataBlockPercent);

          freedSumMb = 0;
          startTime = stopTime;
       }

הבה נסתכל כעת על כל זה באמצעות דוגמה אמיתית. יש לנו את תסריט הבדיקה הבא:

1. בואו נתחיל לעשות סריקה (25 שרשורים, אצווה = 100)
2. לאחר 5 דקות, הוסף ריבוי נקודות (25 שרשורים, אצווה = 100)
3. לאחר 5 דקות, כבה את Multi-gets (נותרת שוב רק סריקה)

אנו מבצעים שתי ריצות, ראשית hbase.lru.cache.heavy.eviction.count.limit = 10000 (מה שלמעשה משבית את התכונה), ולאחר מכן מגדירים limit = 0 (מאפשר זאת).

ביומנים למטה אנו רואים כיצד התכונה מופעלת ומאפסת את ה-Overshoot ל-14-71%. מעת לעת העומס יורד, מה שמפעיל את Backpressure ו-HBase מאחסן שוב בלוקים נוספים.

Log RegionServer
פינוי (MB): 0, יחס 0.0, תקורה (%): -100, מונה פינוי כבד: 0, אחסון במטמון נוכחי DataBlock (%): 100
פינוי (MB): 0, יחס 0.0, תקורה (%): -100, מונה פינוי כבד: 0, אחסון במטמון נוכחי DataBlock (%): 100
פינוי (MB): 2170, יחס 1.09, תקורה (%): 985, מונה פינוי כבד: 1, מטמון נוכחי DataBlock (%): 91 < התחלה
פינוי (MB): 3763, יחס 1.08, תקורה (%): 1781, מונה פינוי כבד: 2, מטמון נוכחי DataBlock (%): 76
פינוי (MB): 3306, יחס 1.07, תקורה (%): 1553, מונה פינוי כבד: 3, מטמון נוכחי DataBlock (%): 61
פינוי (MB): 2508, יחס 1.06, תקורה (%): 1154, מונה פינוי כבד: 4, מטמון נוכחי DataBlock (%): 50
פינוי (MB): 1824, יחס 1.04, תקורה (%): 812, מונה פינוי כבד: 5, מטמון נוכחי DataBlock (%): 42
פינוי (MB): 1482, יחס 1.03, תקורה (%): 641, מונה פינוי כבד: 6, מטמון נוכחי DataBlock (%): 36
פינוי (MB): 1140, יחס 1.01, תקורה (%): 470, מונה פינוי כבד: 7, מטמון נוכחי DataBlock (%): 32
פינוי (MB): 913, יחס 1.0, תקורה (%): 356, מונה פינוי כבד: 8, מטמון נוכחי DataBlock (%): 29
פינוי (MB): 912, יחס 0.89, תקורה (%): 356, מונה פינוי כבד: 9, מטמון נוכחי DataBlock (%): 26
פינוי (MB): 684, יחס 0.76, תקורה (%): 242, מונה פינוי כבד: 10, מטמון נוכחי DataBlock (%): 24
פינוי (MB): 684, יחס 0.61, תקורה (%): 242, מונה פינוי כבד: 11, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 456, יחס 0.51, תקורה (%): 128, מונה פינוי כבד: 12, מטמון נוכחי DataBlock (%): 21
פינוי (MB): 456, יחס 0.42, תקורה (%): 128, מונה פינוי כבד: 13, מטמון נוכחי DataBlock (%): 20
פינוי (MB): 456, יחס 0.33, תקורה (%): 128, מונה פינוי כבד: 14, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 15, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 342, יחס 0.32, תקורה (%): 71, מונה פינוי כבד: 16, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 342, יחס 0.31, תקורה (%): 71, מונה פינוי כבד: 17, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 228, יחס 0.3, תקורה (%): 14, מונה פינוי כבד: 18, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 228, יחס 0.29, תקורה (%): 14, מונה פינוי כבד: 19, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 228, יחס 0.27, תקורה (%): 14, מונה פינוי כבד: 20, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 228, יחס 0.25, תקורה (%): 14, מונה פינוי כבד: 21, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 228, יחס 0.24, תקורה (%): 14, מונה פינוי כבד: 22, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 228, יחס 0.22, תקורה (%): 14, מונה פינוי כבד: 23, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 228, יחס 0.21, תקורה (%): 14, מונה פינוי כבד: 24, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 228, יחס 0.2, תקורה (%): 14, מונה פינוי כבד: 25, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 228, יחס 0.17, תקורה (%): 14, מונה פינוי כבד: 26, מטמון נוכחי DataBlock (%): 19
evicted (MB): 456, יחס 0.17, תקורה (%): 128, מונה פינוי כבד: 27, מטמון נוכחי DataBlock (%): 18 < תוספת גט (אבל הטבלה זהה)
פינוי (MB): 456, יחס 0.15, תקורה (%): 128, מונה פינוי כבד: 28, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 342, יחס 0.13, תקורה (%): 71, מונה פינוי כבד: 29, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 342, יחס 0.11, תקורה (%): 71, מונה פינוי כבד: 30, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 342, יחס 0.09, תקורה (%): 71, מונה פינוי כבד: 31, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 228, יחס 0.08, תקורה (%): 14, מונה פינוי כבד: 32, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 228, יחס 0.07, תקורה (%): 14, מונה פינוי כבד: 33, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 228, יחס 0.06, תקורה (%): 14, מונה פינוי כבד: 34, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 228, יחס 0.05, תקורה (%): 14, מונה פינוי כבד: 35, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 228, יחס 0.05, תקורה (%): 14, מונה פינוי כבד: 36, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 228, יחס 0.04, תקורה (%): 14, מונה פינוי כבד: 37, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 109, יחס 0.04, תקורה (%): -46, מונה פינוי כבד: 37, מטמון נוכחי DataBlock (%): 22 < לחץ אחורי
פינוי (MB): 798, יחס 0.24, תקורה (%): 299, מונה פינוי כבד: 38, מטמון נוכחי DataBlock (%): 20
פינוי (MB): 798, יחס 0.29, תקורה (%): 299, מונה פינוי כבד: 39, מטמון נוכחי DataBlock (%): 18
פינוי (MB): 570, יחס 0.27, תקורה (%): 185, מונה פינוי כבד: 40, מטמון נוכחי DataBlock (%): 17
פינוי (MB): 456, יחס 0.22, תקורה (%): 128, מונה פינוי כבד: 41, מטמון נוכחי DataBlock (%): 16
פינוי (MB): 342, יחס 0.16, תקורה (%): 71, מונה פינוי כבד: 42, מטמון נוכחי DataBlock (%): 16
פינוי (MB): 342, יחס 0.11, תקורה (%): 71, מונה פינוי כבד: 43, מטמון נוכחי DataBlock (%): 16
פינוי (MB): 228, יחס 0.09, תקורה (%): 14, מונה פינוי כבד: 44, מטמון נוכחי DataBlock (%): 16
פינוי (MB): 228, יחס 0.07, תקורה (%): 14, מונה פינוי כבד: 45, מטמון נוכחי DataBlock (%): 16
פינוי (MB): 228, יחס 0.05, תקורה (%): 14, מונה פינוי כבד: 46, מטמון נוכחי DataBlock (%): 16
פינוי (MB): 222, יחס 0.04, תקורה (%): 11, מונה פינוי כבד: 47, מטמון נוכחי DataBlock (%): 16
evicted (MB): 104, יחס 0.03, תקורה (%): -48, מונה פינוי כבד: 47, מטמון נוכחי DataBlock (%): 21 < interrupt gets
פינוי (MB): 684, יחס 0.2, תקורה (%): 242, מונה פינוי כבד: 48, מטמון נוכחי DataBlock (%): 19
פינוי (MB): 570, יחס 0.23, תקורה (%): 185, מונה פינוי כבד: 49, מטמון נוכחי DataBlock (%): 18
פינוי (MB): 342, יחס 0.22, תקורה (%): 71, מונה פינוי כבד: 50, מטמון נוכחי DataBlock (%): 18
פינוי (MB): 228, יחס 0.21, תקורה (%): 14, מונה פינוי כבד: 51, מטמון נוכחי DataBlock (%): 18
פינוי (MB): 228, יחס 0.2, תקורה (%): 14, מונה פינוי כבד: 52, מטמון נוכחי DataBlock (%): 18
פינוי (MB): 228, יחס 0.18, תקורה (%): 14, מונה פינוי כבד: 53, מטמון נוכחי DataBlock (%): 18
פינוי (MB): 228, יחס 0.16, תקורה (%): 14, מונה פינוי כבד: 54, מטמון נוכחי DataBlock (%): 18
פינוי (MB): 228, יחס 0.14, תקורה (%): 14, מונה פינוי כבד: 55, מטמון נוכחי DataBlock (%): 18
פינוי (MB): 112, יחס 0.14, תקורה (%): -44, מונה פינוי כבד: 55, מטמון נוכחי DataBlock (%): 23 < לחץ אחורי
פינוי (MB): 456, יחס 0.26, תקורה (%): 128, מונה פינוי כבד: 56, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.31, תקורה (%): 71, מונה פינוי כבד: 57, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 58, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 59, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 60, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 61, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 62, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 63, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.32, תקורה (%): 71, מונה פינוי כבד: 64, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 65, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 66, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.32, תקורה (%): 71, מונה פינוי כבד: 67, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 68, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.32, תקורה (%): 71, מונה פינוי כבד: 69, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.32, תקורה (%): 71, מונה פינוי כבד: 70, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 71, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 72, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 73, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 74, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 75, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 342, יחס 0.33, תקורה (%): 71, מונה פינוי כבד: 76, מטמון נוכחי DataBlock (%): 22
פינוי (MB): 21, יחס 0.33, תקורה (%): -90, מונה פינוי כבד: 76, אחסון במטמון נוכחי DataBlock (%): 32
פינוי (MB): 0, יחס 0.0, תקורה (%): -100, מונה פינוי כבד: 0, אחסון במטמון נוכחי DataBlock (%): 100
פינוי (MB): 0, יחס 0.0, תקורה (%): -100, מונה פינוי כבד: 0, אחסון במטמון נוכחי DataBlock (%): 100

הסריקות היו נחוצות כדי להציג את אותו תהליך בצורה של גרף של הקשר בין שני קטעי מטמון - יחיד (כאשר בלוקים שמעולם לא התבקשו קודם לכן) ורב (הנתונים "מבוקשים" לפחות פעם אחת מאוחסנים כאן):

ולבסוף, איך נראית פעולת הפרמטרים בצורה של גרף. לשם השוואה, המטמון היה כבוי לחלוטין בהתחלה, לאחר מכן הושק HBase עם שמירה במטמון ועיכוב תחילת עבודת האופטימיזציה ב-5 דקות (30 מחזורי פינוי).

ניתן למצוא את הקוד המלא ב-Pull Request HBASE 23887 ב-github.

עם זאת, 300 אלף קריאות בשנייה זה לא כל מה שניתן להשיג בחומרה זו בתנאים אלה. העובדה היא שכאשר אתה צריך לגשת לנתונים באמצעות HDFS, נעשה שימוש במנגנון ShortCircuitCache (להלן SSC), המאפשר לך לגשת ישירות לנתונים, תוך הימנעות מאינטראקציות ברשת.

פרופיל הראה שלמרות שמנגנון זה נותן רווח גדול, הוא גם הופך בשלב מסוים לצוואר בקבוק, מכיוון שכמעט כל הפעולות הכבדות מתרחשות בתוך מנעול, מה שמוביל לחסימה רוב הזמן.

לאחר שהבנו זאת, הבנו שניתן לעקוף את הבעיה על ידי יצירת מערך של SSCs עצמאיים:

private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
  this.shortCircuitCache[i] = new ShortCircuitCache(…);

ואז עבדו איתם, לא כולל צמתים גם בספרת ההיסט האחרונה:

public ShortCircuitCache getShortCircuitCache(long idx) {
    return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}

עכשיו אתה יכול להתחיל לבדוק. לשם כך, נקרא קבצים מ-HDFS באמצעות אפליקציה פשוטה עם ריבוי הליכי הליכים. הגדר את הפרמטרים:

conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждам
conf.set("dfs.client.short.circuit.num", num); // от 1 до 10

ופשוט תקרא את הקבצים:

FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i < count; i++) {
    position += 65536;
    if (position > 900000000)
        position = 0L;
    int res = in.read(position, byteBuffer, 0, 65536);
}

קוד זה מבוצע בשרשורים נפרדים ונגדיל את מספר הקבצים שנקראו בו זמנית (מ-10 ל-200 - ציר אופקי) ואת מספר המטמונים (מ-1 ל-10 - גרפיקה). הציר האנכי מראה את התאוצה הנובעת מעלייה ב-SSC ביחס למקרה כאשר יש רק מטמון אחד.

כיצד לקרוא את הגרף: זמן הביצוע של 100 אלף קריאה בבלוקים של 64 KB עם מטמון אחד דורש 78 שניות. ואילו עם 5 מטמונים זה לוקח 16 שניות. הָהֵן. יש תאוצה של ~5 פעמים. כפי שניתן לראות מהגרף, ההשפעה אינה בולטת במיוחד למספר קטן של קריאות מקבילות, היא מתחילה למלא תפקיד בולט כאשר יש יותר מ-50 קריאות פתיל. ניתן גם להבחין כי הגדלת מספר SSCs מ-6 ומעלה נותן עליית ביצועים קטנה משמעותית.

הערה 1: מכיוון שתוצאות הבדיקה נדיפות למדי (ראה להלן), בוצעו 3 ריצות והערכים המתקבלים ממוצעים.

הערה 2: רווח הביצועים מהגדרת גישה אקראית זהה, אם כי הגישה עצמה מעט איטית יותר.

עם זאת, יש להבהיר שבניגוד למקרה עם HBase, האצה זו לא תמיד בחינם. כאן אנו "פותחים" את היכולת של המעבד לעשות עבודה יותר, במקום להיתלות על מנעולים.

כאן אתה יכול לראות שבאופן כללי, גידול במספר המטמונים נותן גידול פרופורציונלי בערך בניצול המעבד. עם זאת, יש מעט יותר שילובים מנצחים.

לדוגמה, בואו נסתכל מקרוב על ההגדרה SSC = 3. העלייה בביצועים בטווח היא בערך פי 3.3. להלן התוצאות מכל שלוש הריצות הנפרדות.

בעוד שצריכת המעבד עולה פי 2.8 בערך. ההבדל לא גדול במיוחד, אבל גרטה הקטנה כבר מאושרת ואולי יש לה זמן ללכת לבית הספר וללמוד שיעורים.

לפיכך, תהיה לכך השפעה חיובית על כל כלי שמשתמש בגישה בתפזורת ל-HDFS (למשל Spark וכו'), בתנאי שקוד האפליקציה קל משקל (כלומר התקע נמצא בצד הלקוח של HDFS) ויש כוח מעבד פנוי. . כדי לבדוק, בואו נבדוק איזו השפעה תהיה לשימוש המשולב באופטימיזציית BlockCache וכוונון SSC לקריאה מ-HBase.

ניתן לראות שבתנאים כאלה ההשפעה לא גדולה כמו בבדיקות מעודנות (קריאה ללא כל עיבוד), אבל בהחלט אפשר לסחוט כאן 80K נוספים. יחד, שתי האופטימיזציות מספקות מהירות של עד פי 4.

גם עבור אופטימיזציה זו בוצע יחסי ציבור [HDFS-15202], אשר מוזגה ופונקציונליות זו תהיה זמינה במהדורות עתידיות.

ולבסוף, היה מעניין להשוות את ביצועי הקריאה של מסד נתונים דומה בעל עמודות רחבות, Cassandra ו-HBase.

לשם כך, השקנו מופעים של כלי בדיקת העומס הסטנדרטי YCSB משני מארחים (800 שרשורים בסך הכל). בצד השרת - 4 מופעים של RegionServer ו- Cassandra על 4 מארחים (לא אלו שבהם פועלים הלקוחות, כדי להימנע מהשפעתם). הקריאות הגיעו מטבלאות בגודל:

HBase - 300 GB ב-HDFS (100 GB נתונים טהורים)

Cassandra - 250 GB (מקדם שכפול = 3)

הָהֵן. הנפח היה בערך זהה (ב-HBase קצת יותר).

פרמטרים של HBase:

dfs.client.short.circuit.num = 5 (אופטימיזציה של לקוח HDFS)

hbase.lru.cache.heavy.eviction.count.limit = 30 - זה אומר שהתיקון יתחיל לעבוד לאחר 30 פינויים (~5 דקות)

hbase.lru.cache.heavy.eviction.mb.size.limit = 300 - נפח יעד של אחסון במטמון והדחה

יומני YCSB נותחו והורכבו לגרפים של Excel:

כפי שניתן לראות, אופטימיזציות אלו מאפשרות להשוות את הביצועים של מסדי נתונים אלו בתנאים אלו ולהשיג 450 אלף קריאה בשנייה.

אנו מקווים שמידע זה יכול להיות שימושי למישהו במהלך המאבק המרגש על פרודוקטיביות.

מקור: www.habr.com