Шкала апаче: APACHE II – Система оценки и Оценка смертности (Система классификации острых функциональных и хронических изменений в состоянии здоровья II)

Содержание

Шкала APACHE II. Онлайн калькулятор и подробное описание методики.

Тяжелая органная дисфункция подразумевает под собой (анамнестически, до текущей госпитализации):

Критерий Количество баллов
Возраст, лет
<=44 0
45-54 2
55-64 3
65-74 5
>74 6
Тяжелая органная дисфункция или иммуносупрессия в анамнезе
Нет 0
Да, планово оперированные пациенты 2
Да, неоперированные пациенты, оперированные по экстренным показаниям 5
Ректальная температура, °C
>40.9 4
39-40.9 3
38.5-38.9 1
36-38.4 0
34-35.9 1
32-33.9 2
30-31.9 3
<30 4
Среднее артериальное давление, мм Hg
>159 4
130-159
3
110-129 2
70-109 0
50-69 2
<50 4
Частота сердечных сокращений, уд/мин
>179 4
140-179 3
110-139 2
70-109 0
55-69 2
40-54 3
<40 4
Частота дыхания, дых/мин
>49 4
35-49 3
25-34 1
12-24 0
10-11 1
6-9 2
<6 4
Оксигенация (если FiO2 < 0. 5 — используется PaO2, мм Hg; если >= 0.5 — A-a — градиент, мм Hg)
A-a — градиент >499 4
A-a — градиент 350-499 3
A-a — градиент 200-349 2
A-a — градиент <200 (если FiO2 > 0.49) или PaO2 >70 (если FiO2 < 0.5) 0
PaO2 61-70 1
PaO2 55-60 3
PaO2 <55 4
pH артериальной крови
>7.69 4
7.60-7.69 3
7.50-7.59 1
7.33-7.49 0
7.25-7.32 2
7.15-7.24 3
<7.15 4
Натрий сыворотки, ммоль/л
>179 4
160-179 3
155-159 2
150-154 1
130-149 0
120-129 2
111-119 3
<111 4
Калий сыворотки, ммоль/л
>6. 9 4
6-6.9 3
5.5-5.9 1
3.5-5.4 0
3-3.4 1
2.5-2.9 2
<2.5 4
Креатинин сыворотки, мкмоль/л
>300.56 и ОПН 8
176.8-300.56 и ОПН 6
>300.56 и ХПН 4
132.6-176.7 и ОПН 4
176.8-300.56 и ХПН 3
132.6-176.7 и ХПН 2
53.04-132.5 0
<53.04 2
Гематокрит, %
>59.9 4
50-59.9 2
46-49.9 1
30-45.9
0
20-29.9 2
<20 4
Лейкоциты, *109/л
>39. 9 4
20-39.9 2
15-19.9 1
3.0-14.9 0
1.0-2.9 2
<1.0 4
Шкала комы Глазго 15 — оценка комы по Глазго
Бикарбонат, ммоль/л. Применяется, когда невозможно оценить газовый состав крови у пациентов с нормальной оксигенацией.
>52 4
41-52 3
32-40.9 1
22-31.9 0
18-21.9 2
15-17.9 3
<15 4

Что такое шкала APACHE II? | СВЕТ ПОПРАВЬ

Шкала APACHE II, предложенная в 1985, наиболее широко используется в клинических исследованиях, в том числе при оценке эффективности различных методов лечения. Шкала позволяет оценить тяжесть состояния гетерогенных групп. APACHE II состоит из трех компонентов:

  • Оценка физиологического состояния больного (Acute Physiology Score) на основании регистрации 12 клинико-лабораторных показателей. Отклонение стресс-нормы оценивается в баллах от 1 до 4. Эта часть шкалы включает также оценку функционального состояния ЦНС с помощью шкалы комы Глазго (ШКГ).
  • Оценка возраста пациента (от 0 при возрасте до 44 лет до 6 баллов при возрасте более 75 лет).
  • Оценка сопутствующих хронических заболеваний с учетом послеоперационного периода после плановых и экстренных вмешательств. Наличие хронического заболевания печени, поражений сердечно-сосудистой и дыхательной систем, почечной недостаточности или иммунодефицита у больных после плановых операций добавляет 2 балла к общей оценке тяжести, а после экстренных – 5 баллов.

Баллы в каждом из трех разделов суммируются, что дает общую оценку состояния больных.

⠀

Недостатки шкалы АРАСНЕ II.

  1. Невозможность использования до 18-и лет.
  2. Общее состояние здоровья должно оцениваться только у тяжёлых больных, иначе добавление этого показателя ведёт к переоценке.
  3. Отсутствует оценка до поступления в отделение интенсивной терапии, (появилась в шкале APACHE III).
  4. В случае смерти в первые 8 часов после поступления оценка данных не имеет смысла.
  5. У седатированных, интубированных больных оценка по шкале Глазго должна быть равна 15-и (норма), в случае наличия неврологической патологии в анамнезе эта оценка может быть снижена.
  6. При частом повторном использовании шкала даёт несколько более высокую оценку.
  7. Ряд диагностических категорий пропущена (преэклампсия, ожоги и другие состояния), а коэффициент повреждённого органа не всегда даёт точную картину состояния.
  8. При меньшем диагностическом коэффициенте оценка шкалы более значительна.

⠀

В дальнейшем шкала была трансформирована в шкалу APACHE III.

APACHE III была разработана в 1991 году для расширения и совершенствования прогностических оценок APACHE II.

Новая система — APACHE III состоит из 5 компонентов, включая основные и сопутствующие заболевания, 17 параметров оценки физиологического состояния, возраст с учетом времени отбора больных. Шкала намного более трудоемка для практического использования и пока не получила широкого распространения в клинических исследованиях.

Шкала APACHE II » Медвестник

Тяжелая органная дисфункция или иммуносупрессия в анамнезеОтсутствуют Консервативное лечениеПлановое оперативное вмешательствоЭкстренное оперативное вмешательство

Возраст, летболее 75от 65 до 74от 55 до 64от 45 до 54менее 44

Температура, oCболее 41 от 39 до 40.9от 38.5 до 38.9от 36 до 38.4от 34 до 35.9от 32 до 33.9от 30 до 31.9менее 29.9

Среднее артериальное давление, мм рт. ст.более 160от 130 до 159от 110 до 129от 70 до 109от 50 до 69менее 49

Частота сердечных сокращений, уд/минболее 180от 140 до 179от 110 до 139от 70 до 109от 55 до 69от 40 до 54менее 39

Частота дыхания, дых/минболее 50от 35 до 49от 25 до 34от 12 до 24от 10 до 11от 6 до 9менее 5

Натрий сыворотки крови Na+, ммоль/лболее 180от 160 до 179от 155 до 159от 150 до 154от 130 до 149от 120 до 129от 111 до 119менее 110

Калий сыворотки крови К+, ммоль/лболее 7от 6 до 6.9от 5.5 до 5.9от 3.5 до 5.4от 3 до 3.4от 2.5 до 2.9менее 2.5

Гематокрит, %более 60от 50 до 59.9от 46 до 49.9от 30 до 45.9от 20 до 29.9менее 20

Острая почечная недостаточность

Креатинин сыворотки крови, мкмоль/лболее 3.5от 2 до 3.4от 1.5 до 1.9от 0.6 до 1.4менее 0.6

Креатинин сыворотки крови при ОПН, мкмоль/лболее 3.5от 2 до 3.4от 1.5 до 1.9от 0.6 до 1.4менее 0.6

Общее количество лейкоцитов WBC(109/L)более 40от 20 до 39.9от 15 до 19.9от 3 до 14.9от 1 до 2.9менее 1

Глазго151413121110987654менее 3

Оценка газового состава крови доступна?

рН артериальной кровиболее 7.7от 7.6 до 7.69от 7.5 до 7.59от 7.33 до 7. 49от 7.25 до 7.32от 7.15 до 7.24менее 7.15FiO2

Парциальное давление углекислого газа PaO2более 70от 61 до 70от 55 до 60менее 55

Альвеолярно-артериальная разница по кислороду A-aPO2более 500от 350 до 499от 200 до 349менее 200

Бикарбонат сыворотки, ммоль/лболее 52от 41 до 51.9от 32 до 40.9от 22 до 31.9от 18 до 21.9от 15 до 17.9менее 15

Сбросить показания

Интегральные системы в оценке прогноза тяжелой политравмы » Журнал «Интенсивная терапия»

А.И. Ярошецкий 2, Д.Н. Проценко

1,2, О.В. Игнатенко 2, Б.Р. Гельфанд 1

 

1 Российский Государственный медицинский университет

2 Городская клиническая больница №7 г. Москва

 

Резюме

 

Прогнозирование результатов лечения даёт возможность объективного выбора лечебной тактики, оценки эффективности и экономического обоснования целесообразности того или иного метода терапии. Одним из инструментов современного прогнозирования являются разработанные в результате сложного математического анализа интегральные шкалы оценки тяжести состояния (APACHE II, SAPS II, шкала комы Глазго — GCS, SOFA и MODS), которые в течение последних лет используются в отделениях реанимации различного профиля. Целью исследования стала разработка систем прогноза исхода и осложнений тяжелой политравмы. Под наблюдением находились пациенты, поступившие в ОРИТ с тяжелой сочетанной травмой (n=101). Авторами исследования было доказано, что при оценке состояния больного с тяжелой политравмой в первые сутки наиболее высокой разрешающей способностью обладает прогностический индекс MTPI1. Прогноз вероятности летального исхода по шкалам полиорганной дисфункции SOFA, MODS и шкале комы Глазго в динамике у пациентов с тяжелой политравмой возможен с высокой достоверностью, при этом максимальную дискриминационную способность показали такие параметры, как максимальная оценка по шкале SOFA (SOFAmax) и минимальная оценка по шкале комы Глазго (GCSmin).

Вероятность развития госпитальной пневмонии у больных с тяжелой политравмой может быть предсказана на 6-е сутки пребывания в ОРИТ посредством оценки состояния по шкале полиорганной дисфункции MODS.

 

Актуальность проблемы

 

Развитие современной медицины невозможно без внедрения в клиническую практику процесса прогнозирования. Прогнозирование результатов лечения даёт возможность объективного выбора лечебной тактики, оценки эффективности и экономического обоснования целесообразности того или иного метода терапии, а также повышение надёжности планирования ресурсов здравоохранения.

 

Одним из инструментов современного прогнозирования являются разработанные в результате сложного математического анализа интегральные шкалы оценки тяжести состояния (APACHE II, SAPS II, шкала комы Глазго — GCS, SOFA и MODS), которые в течение последних лет используются в отделениях реанимации различного профиля (5-13). Опережающее отражение результатов интенсивного лечения особенно значимо для пациентов с тяжёлой травмой. Данное обстоятельство связано с увеличением числа пострадавших, высокой летальностью и значительной степенью их инвалидизации. Так по данным ВОЗ ежегодно от травм погибает до 2 млн. человек [14]. В России у мужчин в возрасте до 45 лет и у женщин до 35 лет травматические повреждения — главная причина смерти [1, 2, 3, 4]. Оценивая ущерб от тяжелой травмы, необходимо отметить, что по количеству непрожитых лет ущерб от травм значительно превышает таковой от сердечно-сосудистых, онкологических и инфекционных заболеваний вместе взятых [2, 4].

 

Между тем, следует признать, что проблема оценки прогноза исходов и осложнений при тяжелой политравме остается нерешенной: существующие прогностические системы в отделении реанимации разработаны и валидированы на больных хирургического и терапевтического профиля. Кроме того, во многих исследованиях, посвященных прогнозу у пациентов с тяжелой травмой, не использовались интегральные шкалы-системы оценки тяжести состояния.

 

Как показали последние исследования, используемые в реанимационной практике стандартные шкалы оценки тяжести состояния АРАСНЕ II, SAPS II, а также специально разработанные для травматологии шкалы TRISS (Trauma Injury Severity Score) и ISS (Injury Severity Score), RTS — (Revised Trauma Score) не обладают достаточной чувствительностью для прогноза исхода при тяжелой политравме.

 

 

Цель исследования

 

разработка систем прогноза исхода и осложнений тяжелой политравмы для оптимизации лечебной тактики.

 

 

Материал и методы исследования

 

Материалом настоящей работы являются результаты исследований, проведенных в период с 2003 по 2004 годы в отделении реанимации и интенсивной терапии (ОРИТ) Городской клинической больницы ?7 г. Москвы. Под наблюдением находились пациенты, поступившие за этот период времени в ОРИТ с тяжелой сочетанной травмой (n=101). Возраст обследованных больных колебался от 18 до 81 (31,5+15,2), при этом большую часть пациентов (n=91) составляли лица трудоспособного возраста (до 50 лет), преимущественно мужчины (n=72). В группе с множественной травмой 2-е пациентов были с травмой костей таза и трубчатых костей нижних конечностей, 4 — с переломом трубчатых костей верхних конечностей и ребер. В группе пациентов с сочетанной травмой у 53 пациентов наблюдалась тяжелая черепно-мозговая травма (ТЧМТ) и скелетная травма, а у 31 — ТЧМТ с травмой внутренних органов и скелетной травмой. Причиной повреждения в большинстве случаев была автомобильная травма (n=74), у 15 пострадавших причиной поступления в отделение реанимации была противоправная травма, у 10 — кататравма, у двоих — поездная травма. У большинства пациентов в анамнезе не отмечалось хронических заболеваний, 5 пациентов пожилого возраста страдали сахарным диабетом 2 типа, 8 пациентов — ишемической болезнью сердца, двое — хроническим бронхитом.

 

 

Критерии включения в исследование:

  • пострадавшие обоих полов с тяжелой сочетанной травмой в состоянии травматического шока, и (или) нарушениями сознания, и (или) витальных функций;
  • возраст старше 18 лет.

В исследование не включались пострадавшие беременные женщины и пациенты с сопутствующими неизлечимыми заболеваниями в стадии декомпенсации.

 

Тяжесть состояния больных в динамике интенсивной терапии оценивалась по шкалам APACHE II и SAPS II, а наличие и выраженность органно-системной дисфункции — по количественным системам SOFA и MODS.

 

Анализ точности прогноза летального исхода у пациентов после тяжелой травмы производили при помощи рабочих характеристических кривых и разницы между исходными и максимальными значениями шкал органной дисфункции за весь период лечения в ОРИТ. Разработку прогностических индексов выполняли посредством множественной линейной и логистической регрессии, обладающих более высокой разрешающей способностью в прогнозе летального исхода и хорошей калибровкой. Статистическую обработку материала при помощи программы «SPSS 13,0» на персональном компьютере «Toshiba SA50-492», при этом проводили корреляционный анализ и регрессионный анализ, оценку рабочих характеристических кривых (ROC) интегральных шкал-систем чувствительности и специфичности, площади под характеристической кривой (AUROC), а также вычисление критерия согласия Хосмера -Лемешоу (Hosmer-Lemeshow goodness-of-fit, H-L).

 

Для параметрических величин дисперсионный анализ выполнялся с использованием F-критерия, а для непараметрических величин — критерия хи-квадрат (c2) (для таблиц 2 х 2 — в точном решении Фишера).

 

Результаты и их обсуждение

 

Общая летальность в проведенном нами исследовании среди пациентов с тяжелой травмой составила 40,6%. При этом значительно более высокая летальность наблюдалась у мужчин — 48,6%, чем среди лиц женского пола -20,7%; (р=0,008). Вероятнее всего, данный факт связан с социальным статусом значительной части пациентов мужского пола. При изучении летальности в разных возрастных группах отмечена закономерная динамика увеличения летальности с увеличением возраста.

 

Как известно, исходная тяжесть поступления пострадавших вносит значительный вклад в в определение окончательного исхода. Мы провели оценку тяжести состояния в первые сутки по шкале APACHE II и SAPS II у пациентов с тяжелой травмой. При анализе частоты летальных исходов среди пациентов, стратифицированных по группам в зависимости от исходной тяжести состояния по шкале APACHE II, наблюдается четкая линейная зависимость. Не выявлено порогового значения по шкале APACHE II для «скачкообразного» увеличения вероятности летального исхода. «Пороговым» для летальности баллом по APACHE II у пациентов с тяжелой травмой можно считать 15 баллов, так как в группе пострадавших с исходной оценкой по APACHE II 15-19 баллов летальность достигает 38%, то есть практически средних цифр наблюдаемых при тяжелой травме (по литературным данным и данным настоящего исследования).

 

Пострадавшим, поступающим с оценкой по APACHE II 15 баллов и более, ввиду плохого группового прогноза необходима разработка специализированых протоколов стартовой терапии.

 

В группах с исходной оценкой по APACHE II 20-29 баллов число умерших пациентов уже превосходит число выживших (летальность 60-62%), а при исходной тяжести состояния более 30 баллов — летальность близка к 100%. Похожее распределение частот летальности наблюдалось нами и при оценке тяжести состояния пострадавших по шкале SAPS II. Также как и в случае оценки по APACHE II, мы наблюдали линейное нарастание летальности.

 

При дальнейшем анализе было выявлено, что при оценке в первые сутки по динамическим шкалам SOFA, MODS и шкале комы Глазго имеются статистически значимые различия между группами выживших и умерших пациентов (р<0,001; p=0,005; p<0,001, соответственно), что делало обоснованным проведения оценки возможности их использования для прогнозирования исхода в динамике и при составлении прогноза по данным первого дня.

 

Прогнозирование исхода в первые сутки после получения тяжелой травмы

Первыми из факторов, влияющими на прогноз у пациентов с тяжелой травмой, являются возраст и пол. По данным регрессионного анализа каждый прожитый год увеличивал вероятность гибели на 0,856%, а принадлежность пострадавшего к мужскому полу повышала вероятность смерти на 27,9%.

 

В целом, прогноз вероятности гибели по шкалам APACHE II и SAPS II выглядят следующим образом:

 

P = 0,044 + 0,02129APACHE II (баллы)

 

P = 0,035 + 0,01133SAPS II (баллы)

 

где Р — вероятность летального исхода (0 — 100%-ная выживаемость, 1 — 100%-ная летальность).

 

 

Между системами количественной оценки тяжести состояния выявлена прямая сильная корреляционная связь между шкалами APACHE II и SAPS II (r=0,851).

 

Для оценки разрешающей способности шкал APACHE II и SAPS II в отношении прогноза летального исхода мы построили рабочие характеристические кривые (ROC — receiver operator curves) и оценили площади под кривыми (AUROC). Площадь под рабочей характеристической кривой для оценки разрешающей способности шкалы APACHE II в отношении прогнозирования летального исхода составила 0,717 (71,7%) (Рисунок 1). Однако для хорошей разрешающей способности площадь под кривой для шкалы должна быть более 0,9 (90%), при AUROC менее 0,8 прогноз невозможен.

 

Также неудовлетворительные результаты получены при оценке шкал SAPS II, GCS, SOFA и MODS (AUROC = 0,763; 0,794; 0,724; 0,708 соответственно, p<0,001). На характеристических кривых отсутствуют точки разделения, позволяющие выделить «пороговые» значения каждой из шкал для прогноза летального исхода.

 

Таким образом, ни одна из используемых шкал не обеспечивает необходимый качественный прогноз в первые сутки нахождения в ОРИТ и не позволяет использовать их для выработки алгоритма терапии для каждого больного.

 

С целью улучшения прогнозирования летального исхода в первые сутки от момента поступления в ОРИТ при тяжелой травме мы провели многофакторный регрессионный анализ, в который были включены все переменные, имеющие корреляционные связи с вероятностью летального исхода (таблица 1).

 

После проведения анализа оказалось, что к факторам, ухудшающим качество прогнозирования при тяжелой травме в первые сутки, относится оценка по шкалам APACHE II и SAPS II. Пол, возраст, оценка по шкале Глазго в первые сутки и оценки по шкалам SOFA и MODS в первые сутки были включены в регрессионную модель.

 

В результате анализа нами разработан прогностический индекс первых суток тяжелой травмы (Multiple Trauma Prognostic Index 1- MTPI1):

 

MTPI1 = 1,8 — 0,078GCS1 — 0,08MODS1 + 0,01 возраст(годы) + 0,134пол,

 

где GCS1, MODS1 — оценка по шкалам GCS и MODS в первые сутки, индекс для женского пола равен единице, индекс для мужского пола равен 2.

 

 

В итоге, по данным исследования была составлена таблица частот летальных исходов при разных значениях MTPI1 (рисунок 2).

 

Рисунок 1.

Рабочая характеристическая кривая шкалы APACHE II

 

 

 

 

Рисунок 2.

MTPI1 и летальность у больных с тяжелой травмой

 

Таблица 1

 

Корреляционные связи с вероятностью летального исхода в первые сутки

 

Фактор

Коэффициент корреляции Пирсона, r

Степень корреляционной связи

Р

Пол

0,264

Слабая

0,008

Возраст, годы

0,257

Слабая

0,009

APACHE II, баллы

0,339

Средняя

0,001

SAPS II, баллы

0,402

Средняя

<0,001

GCS при поступлении, баллы

-0,512

Средняя

<0,001

SOFA при поступлении, баллы

0,339

Средняя

0,001

MODS при поступлении, баллы

0,278

Слабая

0,005

 

Как видно из гистограммы (Рисунок 1), наибольший рост летальности при оценке по индексу MTPI1 отмечается выше 1,39 баллов (с 14,31% до 57,14%), то есть более, чем в 4 раза. Летальность при оценке по индексу MTPI1 меньше 1,3 составляет менее 10%. Таким образом, величину индекса MTPI1 1,39 баллов с чувствительностью 90% и специфичностью 73% можно считать «пороговой» для выбора стратегии интенсивной терапии, начиная с первых суток лечения. Мы полагаем, что пациенты с оценкой в первые сутки по индексу 1,39 и выше требуют назначения максимальной стартовой терапии.

 

Мы провели оценку чувствительности и специфичности полученного индекса и построили рабочую характеристическую кривую для оценки разрешающей способности индекса MTPI1 в отношении прогнозирования летального исхода. Площадь под кривой для прогностического индекса первых суток тяжелой травмы составила 0,862 (p<0,001), скорректированный r2 = 0,537, а Хосмер-Лемешоу критерий составил 8,775 (р=0,362), то есть разрешающая способность и калибровка этого индекса значительно превосходит применяемые в рутинной практике шкалы APACHE II и SAPS II (0,717 и 0,763, соответственно) (рисунок 3).

 

Рисунок 3.

Рабочая характеристическая кривая для индекса MTPI1

 

 

 

Прогнозирование летального исхода в динамике

Для составления прогноза в динамике мы использовали оценку по динамическим шкалам-системам SOFA и MODS, шкале SIRS, шкале Глазго, а также динамике концентрации натрия плазмы крови и респираторного индекса. При оценке по интегральным шкалам учитывались такие параметры как максимум баллов по шкалам SOFA, MODS и минимум по шкале комы Глазго, а также и разница между максимумом SOFA и MODS и оценкой по шкалам в первые сутки (дельта SOFA и дельта MODS) и между минимумом шкалы Глазго и исходной оценкой по GCS за весь период наблюдения.

 

При анализе содержания натрия в динамике учитывалась максимальная концентрация натрия (максимум натрия) и разница между максимальной концентрацией натрия и исходной концентрацией натрия в плазме крови (дельта натрия).

 

Нами отмечена значительная разница по динамике натрия среди пациентов, поступающих с оценкой по шкале Глазго 9 и менее баллов (чаще всего вследствие тяжелой черепно-мозговой травмы).

 

Выявлено нарастание прогностической значимости динамических шкал SOFA, MODS, шкалы Глазго в течение первых 3-5 дней, которая затем оставалась на одном уровне. Корреляционная связь с летальным исходом шкал SOFA и MODS прямая средней силы, со шкало комы Глазго — обратная средней силы (р=0,001). При этом наибольшая сила связи вероятности летального исхода у пациентов в острый период тяжелой травмы отмечена со шкалой комы Глазго.

 

В дальнейшем нами выполнен анализ летальности в зависимости от максимальной оценки по шкале SOFA за период наблюдения (SOFAmax). Выявлено линейное нарастание летальности: при максимальной оценке по SOFA в динамике менее 6 баллов она составила 5,26%, при оценке более 7 баллов — превышала среднюю для таковой категории пациентов. А при максимальной оценке по шкале SOFA 10 и более баллов летальность может достигать 100%. Разница между максимальной и исходной оценкой по SOFA (дельта SOFA) также демонстрирует линейное нарастание летальности при увеличении дельта SOFA. При этом при дельта SOFA 0-1 летальность составила 22,64%, при 2-4 баллах — 52,94%, а при дельта SOFA в 5 и более баллов 78,57%. Рабочая характеристическая кривая максимальной оценки по шкале SOFA показала хорошую разрешающую способность этого показателя для прогноза неблагоприятного исхода — площадь под кривой составила 0,862.

 

Аналогичные закономерности отмечены при максимальной оценке по шкале MODS и дельте шкалы MODS. При этом при аналогичных частотах неблагоприятного исхода наблюдается меньший разброс максимальной оценки по MODS (от группы 3 и менее баллов, соответствующей группе SOFAmax 5 и менее баллов с р>0,05 до группы 7 и более баллов , соответствующей группам SOFAmax 8, 9 и 10 и более баллов с р>0,05). Выполняя оценку разницы между максимальной и исходной оценками по MODS (дельта MODS) мы получили достоверные различия летальности между группами при изменении дельта MODS на 1 балл, что может иметь значение при оценке эффекта терапии по динамическим шкалам. Кривая ROC максимальной оценки по шкале MODS продемонстрировала худшую дискриминационную способность (AUROC=0,800) для выявления летальных исходов, чем у максимальной оценке по шкале SOFA и индексу MTPI1 (AUROC=0,862).

 

Более выраженные различия по летальности отмечены при минимальной оценке по шкале комы Глазго. В группе с минимальной оценкой по Глазго в 3 балла летальность составила 85,17%. А у всех выживших пациентов — сформировалось персистирующее вегетативное состояние. При минимуме GCS в 4 балла летальность составила 66,67%, при минимуме 5 баллов — 54,31%. При сравнении летальности между группами с минимальной оценкой по Глазго в 5 — 6 и более баллов отмечается значительное («скачкообразное») уменьшение летальности (с 54,31% до 7,12%).

 

Таким образом, в клиническом аспекте, подавляющее большинство пациентов, у которых в процессе наблюдения не развивалось коматозное состояние или развивалась легкая кома (реакция на боль целенаправленная или нецеленаправленная, отсутствие декортикационной ригидности, горметонии или атонии) выжили.

 

Минимальная оценка по шкале Глазго продемонстрировала хорошую разрешающую способность в выявлении летальных исходов при тяжелой травме. При минимальной оценке по шкале комы Глазго 5 баллов и менее, то есть до тех величин, когда наблюдается «скачкообразное» увеличение летальности эта шкала демонстрирует наилучшие данные по чувствительности и специфичности прогнозирования летального исхода среди всех шкал (чувствительность 93%, специфичность 90%, AUROC 0,894), но плохую калибровку. К сожалению, у дельта шкалы Глазго наблюдаются неудовлетворительные значения чувствительности и специфичности для прогнозирования как неблагоприятного, так и благоприятного исходов.

 

Для улучшения прогнозирования в динамике мы провели корреляционный и регрессионный анализы. По данным регрессионного анализа разработан динамический прогностический индекс тяжелой травмы (Multiple Trauma Prognostic Index dyn MTPIdyn):

 

MTPIdyn = 1,56 — 0,069GCS1 — 0,121 MODS1 + 0,005возраст(годы) + 0,0792пол + 0,082SOFAmax,

 

где GCS1, MODS1 — оценка по шкалам GCS и MODS в первые сутки, SOFAmax — максимальная оценка по шкале SOFA за период наблюдения, индекс для женского пола равен единице, индекс для мужского пола равен 2.

 

 

Как видно, динамический прогностический индекс отличается от прогностического индекса первых суток только одним компонентом — максимумом баллов по шкале SOFA.

 

Площадь под кривой ROC составила 0,928, то есть выше, чем у всех тестируемых нами динамических шкал (рисунок 4).

 

Рисунок 4.

Рабочая характеристическая кривая MTPIdyn

 

 

В отличие от данных, полученных в работе Antonelli и J-L.Vincent et al. [5], которые показали, что после 4-х суток от момента травмы только дисфункция респираторной системы определяет прогноз исхода, мы установили весьма незначительное влияние на прогноз данного фактора. С вероятностью летального исхода коррелировали значения по шкалам комы Глазго и SOFA, а после 23 суток — гнойно-септические осложнения.

 

Независимые предикторы летального исхода при тяжелой травме.

При выявлении факторов, коррелирующих с летальным исходом в разных подгруппах пациентов, в качестве независимого предиктора летального исхода выявлено изменение концентрации натрия в плазме крови в динамике.

 

При дальнейшем проведении парного корреляционного анализа обнаружены прямые связи средней силы летальности с максимальной концентрации натрия в плазме крови (Na max) 0,547 и разницы между исходной и максимальной концентрациями натрия в плазме крови (delta Na) 0,506 у всех больных с тяжелой травмой (n=101, p<<0,001). Также выявлены обратные корреляционные связи средней силы между концентрацией натрия в плазме крови и оценкой по шкале комы Глазго.

 

Установлены также корреляционые взаимосвязи между концентрацией натрия в плазме крови и динамическими шкалами, начиная со 2-ых по 11 сутки наблюдения. Со шкалой комы Глазго — обратная связь средней силы (p от 0,01 до <<0,001), со 2-ых по 11 сутки со шкалой SOFA — прямая связь слабая в первые 3-е суток, средней силы с 4-х по 9-е сутки (p от 0, 031 до <<0,001) и с 1-ых по 9-е сутки со шкалой MODS — прямая связь (p от 0,044 до <<0,001).

 

Более сильные связи отмечаются между концентрацией натрия в плазме крови и шкалами Глазго и SOFA, менее выражена сила связи со шкалой MODS. Корреляция между максимальной концентрацией натрия и минимальной оценкой по шкале комы Глазго 0,508 (p<0,001).

 

Оценена разрешающая способность концентрации натрия в плазме крови в динамике. Так, на 2-ой день площадь под характеристической кривой для натрия составила 0,801, критерий Хосмера-Лемешоу 6,2 (р=0,625), а чувствительность и специфичность для концентрации в плазме больше или равной 146 ммоль/л 48% и 100%, соответственно. На 3-й день — AUROC 0,793 (чувствительность 56%, специфичность 90%), а на 5-й день натрий теряет свою значимость AUROC 0,701 (чувствительность 53%, специфичность 47%). Летальность среди тех пациентов с тяжелой черепно-мозговой травмой у кого концентрация натрия в плазме крови на 2-й день превысила 150 ммоль/л составила 85% (n=13, p=0,002), а если концентрация натрия превышала 150 ммоль/л на 3-и сутки после травмы летальность составила 100% (n=11, p<0,001). Летальность среди всех пациентов, у кого концентрация натрия в плазме крови за период наблюдения превысила 150 ммоль/л составила 72,2% (n=26, p=0,001)..

 

Таким образом, увеличение концентрации натрия у пациентов с тяжелой травмой коррелирует с ухудшением состояния по данным объективной оценки по динамическим шкалам, усилением нарушений сознания, значительно ухудшает прогноз и позволяет прогнозировать неблагоприятный исход с удовлетворительными чувствительностью и специфичностью у пациентов с тяжелой травмой.

 

Учитывая важную прогностическую значимость таких факторов, как пол, возраст, исходная оценка по шкале комы Глазго по данным регрессионного анализа и исходная тяжесть по APACHE II по анализу исходов, мы рассчитали отношения шансов (OR) этих параметров для прогнозирования летального исхода.

 

Таблица 2

Отношения шансов для прогноза летального исхода у пациентов с тяжелой травмой

 

Фактор

OR (95% CI)

Мужской пол

3,68 (1,32 — 9,96)

Возраст более 50 лет

2,38 (0,86 — 6,58)

MTPI > 1,4

31,16 (9,35 — 103,77)

Исходная оценка по GCS 9 и менее баллов

10,83 (3,92 — 29,91)

Исходная оценка по APACHE II 15 и более баллов

3,38 (1,45 — 7,78)

 

Как видно из таблицы 2, наибольшие относительные риски летального исхода имеют пациенты с исходной оценкой по индексу MTPI1 1. 4 балла и выше, шкале Глазго 9 и менее баллов, меньшие риски имеют мужчины, лица старше 50 лет и лица с исходной оценкой по шкале APACHE II 15 баллов и более.

 

Прогнозирование легочных осложнений при политравме

Мы исследовали значение шкал оценки тяжести состояния для прогнозирования развития пневмонии при тяжелой политравме в первые сутки. В нашем исследовании пневмония была диагностирована у 58 из 101 пациентов (57,4%). Частота развития пневмонии достоверно повышалась при исходной оценке по APACHE II в диапазоне от 0 до 20 баллов (р=0,05).

 

В основу прогноза развития пневмонии по данным первых суток могут быть положены только данные об увеличении частот развития пневмонии при исходной оценке по шкале APACHE II выше 10 баллов (RR=1,47). Прогнозировать развитие пневмонии в первые сутки после получения тяжелой политравмы по шкалам оценки тяжести состояния невозможно.

 

Тяжесть состояния пациентов, оцененная по шкале MODS в динамике с 3-их по 9-е сутки (p от 0,001 на 6 день, до 0,018 на 9 день) коррелирует с вероятностью развития пневмонии, при этом наибольшую значимость для прогноза пневмонии шкала MODS показала на 6-е сутки от момента травмы.

 

Аналогичная зависимость отмечена при оценке тяжести состояния по шкале SOFA с 4-их по 11-е сутки (p от 0,003 на 6 день, до 0,022 на 11 день), при этом наибольшую значимость для прогноза пневмонии шкала SOFA, как и шкала MODS, показала на 6-е сутки от момента травмы.

 

При оценке по шкале комы Глазго в динамике достоверные различия получены на 5-е и 6-е сутки от момента травмы (F=4,78; p=0,032 и F=4,80; p=0,031, соответственно).

 

Оценка по шкалам комы Глазго, SOFA и MODS на 6-е сутки имеет прогностическое значение в диагностике пневмонии.

 

Удовлетворительную разрешающую способность в диагностике пневмонии у пациентов с тяжелой травмой показала только оценка по шкале MODS на 6-е сутки. Формула для прогноза пневмонии по шкале MODS на 6-е сутки:

 

Прогноз пневмонии на 6-е сутки = 1,479 — 0,075MODS на 6 сутки (баллы).

 

Мы можем предположить с чувствительностью 52% и специфичностью 85%, что пневмония осложнит течение травматической болезни, если на 6-е сутки оценка по шкале MODS равна или более 4 баллов (AUROC=0,758).

 

Клиника ОПЛ/ОРДС, по данным нашего исследования, выявлена у 41 больного (40,6%), при этом отмечено преобладание первичного поражения легких как первопричины развития ОПЛ/ОРДС (26,7%) над неспецифическим вторичным поражением легких при внелегочном ОРДС (13,9%). У больных с тяжелой политравмой пневмония, как правило, сопутствует ОПЛ/ОРДС, при этом пневмония чаще сопутствует «легочному» ОРДС — аспирации, ушибу легких (88,88%), чем «внелегочному» ОРДС (78,57%), при отсутствии клиники ОРДС пневмония диагностирована только в 38,33% случаев (очаговая пневмония без значительного нарушения оксигенирующей функции легких), различия достоверны с р<0,001 (хи-квадрат=22,43).

 

Летальность при развитии ОРДС не отличается от летальности у пациентов без ОРДС (p=0,135). Эти же данные подтверждаются сравнением летальности при развитии ОРДС различной этиологии и отсутствии ОРДС — не получено достоверных различий по летальности (p=0,237), то есть неспецифическое повреждение легких у больных после тяжелой травме при условии адекватного интенсивного лечения является курабельным процессом.

 

Прогнозирование длительности ИВЛ и общей продолжительности лечения в ОРИТ у больных с тяжелой политравмой

 

Нами выведены следующие формулы для прогнозирования длительности ИВЛ у пациентов с тяжелой травмой на 6-е и 16-е сутки на основе интегральной оценки (p<0,001):

 

Длительность ИВЛ (прогноз на 6-е сутки) = 22,298 — 0,873GCS 6

 

Длительность ИВЛ (прогноз на 16-е сутки) =13,999 + 1,949SOFA 16

 

Из проведенных формул видно, что основным фактором, определяющим продолжительность ИВЛ с конца первой недели, является степень поражения ЦНС, а к началу 3-ей недели от момента травмы — развившийся синдром полиорганной недостаточности.

 

Нами разработан прогноз длительности дальнейшего лечения в ОРИТ на основании ежедневной оценки по шкалам органной дисфункции. Наиболее точные результаты прогнозирования получены при включении в модель только шкалы MODS на 16-е сутки от момента травмы (p=0,004):

 

Длительность лечения в ОРИТ (прогноз на 16-е сутки) = 19,937 + 1,575 MODS 16.

 

ROC-анализ выявил удовлетворительную чувствительность и специфичность для прогнозирования сроков лечения в ОРИТ на 16 сутки после тяжелой травмы (AUROC = 0,823).

 

Возможно прогнозирование длительности лечения в ОРИТ при тяжелой травме и на 10-е сутки. В этот временной интервал вермени решающее значение для прогноза имеет степень поражения ЦНС, поэтому в модель включена только шкала комы Глазго (p=0,017), однако AUROC этой модели немного хуже (0,776): Длительность лечения в ОРИТ(прогноз на 10-е сутки) = 25,726 — 0,558 GCS 10.

 

Учитывая хорошую разрешающую способность прогнозирования по индексам MTPI, мы составили прогноз длительности лечения в ОРИТ только для пациентов, которые выживут. Прогноз составлен так же на 10-е и 16-е сутки от момента травмы:

 

Длительность лечения в ОРИТ (прогноз на 10-е сутки) = 29,29 — 0,9 GCS 10.

 

Длительность лечения в ОРИТ (прогноз на 16-е сутки) = 19,267 + 1,517 MODS 16.

 

Корреляции полученных индексов с длительностью лечения в ОРИТ составили 0,556 и 0,596, соотвественно. ROC-анализ выявил хорошую разрешающую способность этих моделей (AUROC=0,840 для прогноза на 10-е сутки и AUROC=0,850 для прогноза на 16-е сутки).

 

Алгоритм антимикробной терапии на основе интегральной оценки состояния больных с тяжелой политравмой в 1-ые сутки госпитализации

 

Интегральные шкалы-системы имеют важное значение в прогнозе исхода, осложнений и длительности лечения в ОРИТ у пациентов с тяжелой политравмой. Однако, с практической точки зрения не менее, а может быть и более важным прикладным значением шкал является возможность применения их для выбора терапии и оценки ее эффективности. Мы попытались применить шкалы для создания алгоритма терапии пациентов с тяжелой травмой с двух позиций: стратификации стартовой терапии в зависимости от исходной тяжести состояния (на примере стартовой антимикробной терапии) и оценки эффекта при помощи шкал SOFA и MODS (на примере маневров «рекрутирования» альвеол).

 

Мы провели сравнительный анализ летальности, частоты нозокомиальных инфекций и длительности лечения в ОРИТ в двух группах пациентов с тяжелой политравмой и исходной оценкой по шкале APACHE II 15 и более баллов. В случае подтвержденной или подозреваемой нозокомиальной инфекции пациенты в группе масимальной антимикробной стартовой терапии (МАТ) (n=16, APACHE II 19,88+3.6) получали меропенем в дозе 3-6 г в сутки (в зависимости от массы тела) в течение 14 суток. В случае микробиологически подтвержденной инфекции MRSA к терапии добавляли ванкомицин в дозе 2 г в сутки. Пациенты в контрольной группе (n=22, APACHE-II 19,90+3.7) с подтвержденной или подозреваемой инфекцией получали стартовую антибактериальную терапию цефалоспорином 3 поколения или фторхинолоном с изменением терапии в соответствии с данными микробиологических исследований. Достоверных различий по исходной тяжести состояния, оцененной по шкале APACHE II выявлено не было (р=0,64). Наблюдаемые данные не соответствовали биномиальному распределению. Сравнительный анализ между группами был выполнен при помощи критерия хи-квадрат. Летальность в группе МАТ составила 6.25% (1/16), в контрольной группе — 50% (11/22), p=0,002. (Рисунок 5).

 

Частота возникновения нозокомиальных инфекций (нозокомиальная пневмония, связанная с ИВЛ, менингит) составила 31.25% (5/16) в группе максимальной стартовой терапии и 91% (20/22) в контрольной группе, p<0,001 (Рисунок 6).

 

Рисунок 5.

Летальность при разных стратегиях стартовой антимикробной терапии

 

 

 

Рисунок 6.

Частота развития тяжелой нозокомиальной инфекции при разных стратегиях стартовой антимикробной терапии

 

 

 

Сравнительный анализ длительности лечения в ОРИТ среди выживших пациентов выявил значительное снижение длительности лечения в ОРИТ в группе максимальной стартовой антибактериальной терапии (19.42+3.2 в группе МАТ и 25.54+11.1 в контрольной группе, p=0,047). Полученные данные об уменьшении летальности, частоты нозокомиальной инфекции и сроков лечения при стратификации стартовой терапии в зависимости от исходной тяжести состояния, оцененной по шкале APACHE II, можно использовать в дальнейшем для выбора стратегии лечения у этой категории пациентов.

 

Оценка эффекта респираторной терапии с помощью шкал органной дисфункции при тяжелой политравме

 

Нами было проведено сравнительное исследование эффективности маневра рекрутирования альвеол на основании изменения оценки по шкалам SOFA и MODS через 24 часа после проведения маневра у 40 пациентов с ОРДС.

 

Рисунок 7.

Изменение оценки по шкале MODS через 24 часа после маневра рекрутирования альвеол

 

 

 

На следующие сутки после проведенного маневра открытия альвеол у пациентов с ОРДС, которым проводили маневр, происходило статистически значимое уменьшение оценки по шкале SOFA, которое составило от -0,10 до -1,23 баллов (-0,44+0,21 балл, р=0,001).

 

Аналогичные изменения происходили при оценке по шкале MODS на следующие сутки после проведения маневров рекрутирования альвеол — у пациентов с ОРДС происходило статистически значимое уменьшение оценки по шкале MODS, которое составило от -0,17 до -1,24 баллов (-0,58+0,18 баллов), р=0,006 (Рисунок 7).

 

Выявлено, что у пациентов с легочным ОРДС отмечается значительно меньшая степень увеличения респираторного индекса на следу

Шкали, тести        || Асоціація анестезіологів Вінницької області


Клінічне ведення пацієнтів з COVID-19. «Жива» клінічна настанова

Модератор рубрики: Олена Сергійчук

Шановні колеги! За основу даної клінічної настанови обрано настанову ВООЗ «Clinical management of COVID-19: interim guidance» (27.05.2020), яка більшою мірою відповідає специфіці медичної допомоги в нашій країні. Клінічна настанова є інформаційним супроводом з найкращої медичної практики протоколу лікування COVID-19 та не повинна розцінюватися як стандарт лікування. Настанова буде доповнюватись відповідно отримання нових доказових даних стосовно медичної допомоги з приводу COVID-19

Читати далі…

Артеріальна гіпертензія вагітних: рекомендації ESC/ESH 2020

Модератор рубрики: Дмитро Папишев

Шановні колеги! Підвищення артеріального тиску в перипартальний період є найчастішим несприятливим серцево-судинним явищем, асоційованим із вагітністю, яке суттєво підвищує імовірність настання небажаних явищ як для матері, так і для плода. Завданням цього документа є аналіз поточної літератури щодо лікування пацієнтів з АГ та надання оновлених рекомендацій клініцисту. Рекомендації також повинні допомогти фахівцям щодо артеріальної гіпертензії (АГ), кардіологам, лікарям інтенсивної терапії, акушерам-гінекологам та анестезіологам надавати відповідну медичну допомогу в перипартальний період, включно з ускладненнями АГ, які зазвичай не охоплюються звичайними рекомендаціями щодо менеджменту АГ у період вагітності.

Читати далі…

Неінтенсивна інфузійна терапія деяких специфічних вагітність-асоційованих станів

Модератор рубрики: Валентина Пелих

Шановні колеги! У вересні 2020 р. за підтримки Національної медичної академії післядипломної освіти імені П.Л. Шупика була організована науково-практична фахова школа-семінар у форматі телемосту «Клінічні рекомендації в практиці акушера-гінеколога». У рамках семінару з доповіддю «Неінтенсивна інфузійна терапія ускладнень вагітності» виступив член-кореспондент НАМН України, д.мед.н., професор, заслужений лікар України, завідувач відділення внутрішньої патології вагітних ДУ «Інститут педіатрії, акушерства і гінекології НАМН України» В.І. Медведь. Пропонуємо ознайомитися з цією доповіддю, опублікованою в: Медицинские аспекты здоровья женщины № 6 (135)’ 2020.

Читати далі…

Телемедицина в період COVID-19: за, проти, утримався. Правові та юридичні аспекти

Модератор рубрики: Андрій Вознюк

Шановні колеги! Через несподівані, раптові обмеження та ризики, викликані поширенням вірусу COVID-19 багато лікарів на своїх сторінках у соціальних мережах встановили заставку «Консультую дистанційно». Однак, на жаль, не всі розуміють, що телемедицина — це не спілкування з друзями за допомогою Viber, Telegram або інших месенджерів. Аби не наражати себе на неприємності, потрібно знати правові засади для застосування телемедицини та дотримуватися встановлених вимог. У цій публікації ви можете ознайомитися, в яких випадках лікар може застосувати телемедицину та в якому саме порядку.

Джерело: УКР. МЕД. ЧАСОПИС, 2 (136), Т. 1 – III/IV 2020 | WWW.UMJ.COM.UA

О.Ю. Юдін. Телемедицина в період COVID-19: за, проти, утримався. Правові та юридичні аспекти

Шановні колеги!

3 березня 2021 року відбулась науково-практична онлайн конференція анестезіологів Вінницької області.

Пропонуємо вашій увазі програму та звіт про конференцію.

 

Програма конференції

Звіт про конференцію

Модератор рубрики: Олександр Дацюк

Шановні колеги! МОЗ України постійно оновлює та корегує свої накази, щодо лікування коронавірусної хвороби. Для Вашої зручності Асоціація анестезіологів України надає для щоденної роботи актуальні на даний час документи. Всі необхідні посилання Ви можете знайти у розділі “Регламентуючі накази МОЗ України з лікування та профілактики COVID-19” вкладки “Освітня платформа COVID-19” головного меню сайту aaukr.org

Вашій увазі нова редакція Протоколу «Надання медичної допомоги для лікування коронавірусної хвороби (COVID-19)» Наказ МОЗ № 3094 від 31 грудня 2020 року

 

Нова редакція Протоколу «Надання медичної допомоги для лікування коронавірусної хвороби (COVID-19)» Наказ МОЗ № 3094 від 31 грудня 2020 року

Пологи в історії акушерства

Модератор рубрики: Валентина Пелих

Шановні колеги! Наразі в Україні лікарів готують у 16 вищих навчальних закладах. Середній медичний персонал навчають в коледжах, медичних училищах і вищих навчальних закладах. Акушерську допомогу надають близько 12000 лікарів акушерів-гінекологів і 40000 медичних працівників середньої ланки. А як це було колись пропонуємо дізнатися з статті Олександра Завидовича «Пологи в історії акушерства». Джерело: Медицинские аспекты здоровья женщины № 7 (104)’ 2016

Читати далі…

Колапс під час вагітності

Модератор рубрики: Дмитро Папишев

Шановні колеги! Частота зупинки серця під час вагітності коливається від: 1/10 000 до 1/30 000 пологів. Більшість смертей трапляється за рахунок гострих ситуацій, в зв’язку, з чим матерям проводиться реанімація і та чи інша інтенсивна терапія. Слід зазначити, що число випадків «непрямої» смерті — внаслідок станів, які можуть виникати або можуть погіршуватися під час вагітності — більше, ніж смертність через акушерські причини. Ряд фізіологічних та анатомічних зміни під час вагітності впливають на проведення реанімації у вагітних. З цим та іншими питаннями пропонуємо ознайомитися в оновленних клінічних рекомендаціях Королівського коледжу акушерів-гінекологів Великобританії (RCJG) 2019 року.

Колапс під час вагітності та у післяпологовому періоді. Green-top Guideline No. 56 (RCOG, 2019)

Сучасна вазопресорна терапія септичного шоку (огляд)

Модератор рубрики: Олена Сергійчук

Шановні колеги! Септичний шок і досі характеризується високою летальністю, що сягає 40%, незважаючи на використання найсучасніших стандартів діагностики та лікування. Вибір конкретного вазоактивного препарату — складне завдання для практикуючого анестезіолога. Тож пропонуємо ознайомитися з оглядом літератури, який включив аналіз 89 рандомізованих контрольованих досліджень, рекомендацій та аналітичних оглядів із баз даних PubMed і Scopus.

Читати далі…

Шановні завідувачі відділеннями та районні анестезіологи!

Річний звіт за 2020 рік має заповнюватися безпосередньо керівником анестезіологічного підрозділу відповідного рівня підпорядкування (районного, міського, обласного) на сайті ААУ www.aaukr.org до 10 лютого 2021 р.

 

Для аналізу моніторингових показників роботи служби Вінницької області просимо надати інформацію до 1 лютого 2021 р. в електронному варіанті на електронну адресу:

  1. — Н.В. Титаренко [email protected]
  2. — О.І. Дацюку [email protected]
З повагою,

експерт за фахом «Анестезіологія та інтенсивна терапія» ДОЗ та реабілітації Вінницької ОДА д.мед.н., проф. О.І. Дацюк

експерт за фахом «Акушерська реанімація» ДОЗ та реабілітації Вінницької ОДА к.мед.н. Н.В. Титаренко

Оновлена форма звіту для області тут


Читати далі…

Шановні колеги!

15 березня 2020 року на сайті МОЗ в зверненні Міністра охорони здоров’я України Іллі Ємця зазначено необхідність негайного перепрофілювання лікарень в інфекційні стаціонари, з урахуванням ситуації. Пропонуємо ознайомитися з алгоритмом дій для підготовки лікарень до приймання та догляду за пацієнтами з коронавірусною хворобою (COVID-19), який пропонує Європейський центр з профілактики та контролю захворюваності (ECDC, лютий 2020 р.).

Переклад документу: О. Соколенко

Підготовка лікарні до COVID-19: рекомендації ECDC, лютий 2020 р.

Шановні колеги!

У зв’язку із подальшим поширенням коронавірусної інфекції у світі, МОЗ інформує про необхідність додаткового навчання у зв’язку з поширенням коронавірусу.

Для цього рекомендовано використовувати наступні онлайн ресурси:

  • Адаптовані матеріали навчального курсу ВООЗ «Респіраторні віруси, що виникають, включаючи новий коронавірус (nCoV)» . Матеріали доступні за посиланням: http://bit.do/covid19_basic
  • Адаптовані матеріали навчального курсу ВООЗ «Надання екстреної допомоги при важкій гострій респіраторній вірусній інфекції (ГРВІ)». Матеріали доступні на платформі дистанційного навчання Центру за посиланням: http://bit.do/covid19_clinical. Інструкція по реєстрації на платформі за посиланням: http://bit.do/covid19_instruction
  • Стандарти медичної допомоги при короновірусній хворобі 2019 (COVID-19). Доступні на сайті МОЗ України за посиланням: http://bit.do/covid19_moz

Програма конференції

НЕКЕРОВАНА АКУШЕРСЬКА КРОВОТЕЧА: причини та алгоритми дій

ОБЕЗБОЛИВАНИЕ В АКУШЕРСТВЕ: SOS-тояние проблемы

Читати далі…

Читати далі…

Читати далі…

Читати далі…

Читати далі…

Читати далі…

Читати далі…

Читати далі…

РУКОВОДСТВО Перитонит. В. С. Савельев, Б. Р. Гельфанд, М. И. Филимонов 2006

Объективная оценка тяжести состояния и прогноза у больных с перитонитом

Применительно к абдоминальному сепсису, обусловленно му распространенным перитонитом, существует корреляция между степенью выраженности ССВР (три признака ССВР — ССВР 3, четыре признака ССВР — ССВР 4, тяжелый сепсис, септический шок) и тяжестью состояния больного, оцененной по общепринятым шкалам оценки тяжести состояния (APACHE II, SAPS, MODS, SOFA) (табл. 9).

Таблица 9

Клиническая характеристика абдоминального сепсиса в зависимости от тяжести синдрома системной воспалительной реакции

Клинический синдром

 

 

Тяжесть состояния, баллы

 

 

APACHE II

SAPS

MODS

SOFA

 

ССВР?3

9,3 ± 3,3

5,4

± 1,5

4,3

± 0,4

3,4

± 0,6

 

 

 

 

 

 

 

 

 

ССВР?4

13,6

± 2,8

8,9

± 1,7

6,3

± 1,2

6,7

± 1,3

 

 

 

 

 

 

 

 

 

Тяжелый сепсис

18,4

± 2,1

13,2

± 1,4

9,3

± 1,6

8,9

± 1,2

 

 

 

 

 

 

 

 

 

Септический шок

21,5

± 2,5

17,6

± 1,3

8,7

± 1,9

8,2

± 1,1

 

 

 

 

 

 

 

 

 

Мангеймский индекс перитонита (MPI)

М. Linder и группа немецких хирургов из города Мангейма (ФРГ) специально разработали для прогнозирования и исхода гнойного перитонита индекс, который первоначально включал 15 параметров. Он был опубликован в 1987 г. и получил назва ние Мангеймского индекса перитонита (Mannheim Peritonitis Index, МИП). Проведенные позже научные исследования позво лили авторам (М. Linder et al., 1992) представить переработан ный индекс, состоящий из восьми факторов риска (табл. 10):

■возраст пациента;

■пол;

■органная недостаточность;

■наличие злокачественного новообразования;

■длительность перитонита до операции более 24 ч;

■распространенный перитонит;

■место первичного очага;

■тип перитонеального экссудата.

Значения МИП могут находиться в пределах от 0 до 47 бал лов. МИП предусматривает три степени тяжести перитонита. При индексе менее 21 балла (I степень тяжести) — леталь ность составляет 2,3%, от 21 до 29 баллов (II степень тяжес ти) — 22,3%, более 29 баллов (III степень тяжести) — 59,1%.

Часть 4. Оценка тяжести состояния, прогноза.

Часть 4. Оценка тяжести состояния, прогноза.

Часть 4. Оценка тяжести состояния, прогноза.

 Previous  Next

  1. Описание существующих оценочно-прогностических систем


Существуют множество оценочно-прогностических шкал из которых к диагностике, объективизации состояния, прогнозированию острого панкреатита можно применить следующие:

          

Госпитализация в ОРИТ при оценке более 8 баллов.
  • Шкала Глазго (Glasgow):

    Критерии:

1.Возраст > 55 лет.

2.Лейкоциты  > 15 * 109/л

3.Сахар крови > 10 ммоль/л

4.Мочевина > 16 ммоль/л

5.РаО2 < 60 мм. Hg

6.Альбумин < 32 г/л

7.Кальций общ. < 2 ммоль/л

Прогноз серьезный, если в течение 48 часов от посупления в стационар выявляются 3 критерия и больше.

Госпитализация в ОРИТ  при наличии более 3 критериев

Фактор риска

Значение

Возраст

Старше 55 лет

Лейкоцитоз

Более 16 000

Лактат дегидрогеназа

Более 400 ед/мл

Аспартат трансаминаза

Более 250 ед/мл

Глюкоза

Более 11 ммол/л

Через 48 часов

 

Снижение гематокрита

Более 10%

Подъем мочевины крови

Более 1,8 ммол/л

Кальций (неионизированный)

Менее 2 ммол/л

ВЕ

Более 4

Оценочный дефицит жидкости

Более 6 л

РаО2

Менее 8 кРа

Количество факторов риска

Летальность (%)

0-2

Менее 1%

3-4

≈15%

5-6

≈40%

Более 6

≈100%

Госпитализация в ОРИТ при наличии более 3 факторов риска

Тяжелый панкреатит развивается с 95% вероятностью при наличии у пациента минимум 2 признаков из основного списка или 1 основного и 2 дополнительных:

СПИСОК  ОСНОВНЫХ ПРИЗНАКОВ  ТЯЖЕСТИ:

  1. Кожные симптомы (гиперемия лица, мраморность, цианоз, экхимозы брюшной стенки).

  2. Геморрагический перитонеальный эксудат.

  3. Частота пульса > 120 или <70\мин.

  4. Гипотензия.

  5. Анурия.

  6. Гемолиз или фибринолиз сыворотки крови.

  7. Абсолютная лимфопения.

       СПИСОК ДОПОЛНИТЕЛЬНЫХ ПРИЗНАКОВ ТЯЖЕСТИ:

  1. Первый по счету приступ панкреатита.

  2. Вторая половина беременности или недавние (до 6 месяцев назад) роды.

  3. Немедленное обращение за медицинской помощью и госпитализация в первые 6 часов заболевания.

  4. Тревожный диагноз направления («перитонит», «острый живот», «острый инфаркт миокарда» и т.п.).

  5. Холодный пот.

  6. Беспокойство и возбуждение.

  7. Распирающие боли в спине.

  1. Госпитализация в ОРИТ, оценка состояния во время пребывания в ОРИТ, перевод из ОРИТ.

  • В ОРИТ госпитализируются все пациенты диагнозом острый панкреатит, которым выставлена тяжелая степень течения (см. выше), не зависимо от этиологической причины.

  • Во время пребывания в ОРИТ проводится оценка состояния по шкалам APACHE-II и SOFA – 1 раз в сутки.
  • Переводятся из ОРИТ в профильное отделение после стабилизации основных витальных функций, при снижении оценки по APACHE-II < 6, SOFA <2
Сайт управляется системой uCoz

Оценка APACHE II — MDCalc

Почему вы разработали систему APACHE?
Когда мы начали [разработку APACHE] в 1970-х, DRG [группы, связанные с диагнозом] только появлялись на сцене, и, очевидно, они были ориентированы на бизнес и финансовые аспекты здравоохранения. Связи с клинической картиной мало. Но люди полагались на DRG как на способ классификации и идентификации пациентов, особенно в отделении интенсивной терапии. Поэтому в то время было важно не столько заново изобрести диагностическую систему, сколько поговорить о том, как пациенты поступают на лечение с разной степенью тяжести.А в то время там действительно ничего не было. Люди использовали бы один анализ крови, например, уровень лактата в крови, а затем выбирали бы порог выше этого или ниже этого. Но определение пороговых значений — это проигрышный метод, когда у вас есть непрерывное измерение, например, лактат в крови.

Затем Брайан Дженнетт создал шкалу комы Глазго и очень преуспел в этом. Но это относилось только к пациентам с травмами головы и в экстренных случаях.

Итак, мы начали изучать роль использования физиологии пациента в отделении интенсивной терапии, а затем разработать комплексную меру тяжести, которая могла бы по крайней мере начать отличать одного пациента от другого лучше, чем DRG.Нас неожиданно хорошо приняли. На нашем первом конгрессе по интенсивной терапии в конце 70-х был необычайный интерес, и мы начали это делать. Мы развили это — у него было большое количество переменных, и даже что-то столь же простое, как уравнения, которые мы разработали для APACHE в то время, вам придется ввести их в компьютер в пятницу вечером и ждать до утра понедельника. Мы имели дело с технологиями, которые все еще не могли обрабатывать большие объемы вычислений. Поэтому мы решили отточить APACHE II, чтобы положить его на одну сторону листа бумаги, и я думаю, что это была самая важная эффективность, которую мы добились.Я помню, у нас был научный сотрудник, который путешествовал по Гималаям, и она была госпитализирована в Куала-Лумпуре, она сказала, что в больнице ничего нет, немного кислорода, нет матрасов. Но там был APACHE II, приклеенный к стене. Итак, мы знали, что есть что-то в простоте использования этого.

Была большая стратегическая дискуссия о том, следует ли нам просто остановиться, а затем просто постоянно обновлять новую базу данных, потому что, как мы теперь знаем, с системами оценки любого типа системы классификации это не похоже на вино, это не так. поправляйся с возрастом.Вам нужна актуальная база данных. APACHE II опубликовал пару лет назад, насколько изменились результаты в отделениях интенсивной терапии по всему спектру, и у нас дела идут лучше, чем раньше, поэтому базы данных много лет назад на самом деле не отражают современные результаты.

Но в то время технологии становились намного лучше, компьютеры начинали работать быстрее, у нас было намного больше компьютерной скорости, и мы предвидели будущее даже в конце 80-х и начале 90-х годов, когда у нас может быть алгоритмический алгоритм. -система, которая автоматически извлекает данные о людях и может помочь им принимать важные решения в зависимости от того, насколько болен пациент, работает ли терапия, как долго пациент должен оставаться в больнице и т. д.Это был последний раз, когда страна до недавнего времени пыталась добиться некоторого прогресса в области интероперабельности в технологиях здравоохранения.

Но тогда мы не знали. Мы с нетерпением ждали будущего, в котором люди будут собирать данные и использовать системы оценки, как они все еще используют MDCalc, и смогут обращаться к компьютеру, как это делают сейчас алгоритмы Google. Он постоянно узнает из базы данных, кто вы, что вы просите и т. Д. И мы действительно думали, что у вас может быть система, которая была бы динамической и основанной на алгоритмах, которая могла бы начать оказывать некоторую поддержку принятия решений, что я и многие другие считали. нужный.

И, конечно же, произошло то, что, короче говоря, за десятилетия, прошедшие с момента публикации APACHE II, лично меня чрезвычайно разочаровало, что мы добились такого небольшого прогресса в продвижении медицинских технологий вперед с возможностью взаимодействия и взаимодействия. с современными компьютерами. В итоге мы не смогли достичь этих очень амбициозных целей. Я думаю, что это продолжается, она хорошо обновляется, и с годами полная система APACHE IV, которая является последней версией с последними алгоритмами и базой данных, на самом деле используется не так часто, как APACHE II.

Итак, оглядываясь назад, если бы мы знали, что будущее будет таким же ограниченным в развитии технологий здравоохранения, я думаю, мы бы сказали, давайте останемся с APACHE II и давайте просто попробуем обновить базу данных, чтобы она была совместимы с современными результатами. Хотя мы разработали такие системы, как APACHE IV, которые намного более чувствительны и обладают гораздо большими возможностями, чем APACHE II, возможность автоматической загрузки этих алгоритмов все еще крайне ограничена. Поэтому, если вы используете APACHE, убедитесь, что вы используете его с базой данных, вашей или чужой, которая использует современных пациентов, чтобы соотношение между оценкой и тем, что происходит с людьми, со временем менялось.Вы можете использовать ту же оценку, но хотите, чтобы в системе были текущие пациенты и их результаты.

Неспособность здравоохранения по какой-либо причине достичь того же уровня технологий, что и банковское дело, розничная торговля и все другие крупные отрасли, будет рассматриваться как главный недостаток современности. Я не хочу комментировать, кто за это отвечает, но у нас есть ряд продуктов, которые исторически начинались в бизнесе, в финансовых офисах, и мы никогда не видели или никогда не хотели развивать способность общаться друг с другом.Это то, с чем мы, к сожалению, застряли.

О людях заботятся врачи, но не существует системы, которая была бы разработана в первую очередь для врачей. В то время как все эти популярные сайты — Google, Amazon, Apple, вы называете их — почему они так популярны? Потому что они получают информацию о том, чего хочет пользователь и что ему нужно. Пользователь — это человек, физическое лицо. Это не учреждение. Если бы только медицина смогла это увидеть и каким-то образом осуществить этот переход от разработки информационной системы для учреждения или практики к разработке ее для людей, которые ее используют.Я этого не видел.

Сравнение шкалы комы APACHE III, APACHE II и Глазго при острой черепно-мозговой травме для прогнозирования смертности и функционального исхода

Цели : В этом исследовании изучается эффективность прогнозирования госпитальной смертности и функционального результата трех различных систем оценки травм головы в отделении нейрохирургической интенсивной терапии (NICU).

Модель Модель : В день госпитализации у каждого пациента были собраны данные для вычисления оценок по острой физиологии, возрасту и хроническому состоянию здоровья (APACHE) II и III, а также по шкале комы Глазго (GCS).Больничная смертность определялась как смерть пациентов перед выпиской из больницы. Ранняя смертность определялась как смерть до 14-го дня после госпитализации. Поздняя смертность определялась как смерть на 15-й день после госпитализации. Функциональный исход оценивался Индексом независимости в повседневной активности (Индекс ADL).

Окружение : 8-местное отделение интенсивной терапии в медицинском центре на 1270 коек в больнице для ветеранов Тайчжун.

Пациенты и участники : Двести неотобранных пациентов с острой черепно-мозговой травмой были включены в наше исследование в течение двух лет подряд.Пациенты младше 14 лет не включались.

Вмешательства : Нет.

Измерения и результаты : Чувствительность, специфичность и правильный результат прогнозирования были измерены методом хи-квадрат в трех системах оценки. Также был получен индекс Юдена. Лучшая точка отсечения в каждой системе оценки определялась индексом Юдена. Разница в индексе Юдена рассчитывалась по Z-баллу.Также учитывалась разница, если значение вероятности было меньше 0,05. Была вычислена площадь под кривой рабочих характеристик приемника (ROC). Затем площадь под ROC каждой системы оценок сравнивалась по Z-баллам. Статистическая значимость имела место, если значение p было меньше 0,05. Для прогнозирования госпитальной смертности наилучшими пороговыми значениями являются 55 для APACHE III, 17 для APACHE II и 5 для GCS. Правильный результат прогноза составляет 82,4% в APACHE III, 78,4% в APACHE II и 81,9% в GCS.Индекс Юдена имеет лучшие точки отсечения: 0,68 для APACHE III, 0,59 для APACHE II и 0,56 для GCS. Площадь под кривой рабочих характеристик приемника (ROC) составляет 0,90 в APACHE III, 0,84 в APACHE II и 0,86 в GCS. Нет статистических различий между APACHE III и II и GCS с точки зрения правильного результата прогноза, индекса Юдена и площади под кривой ROC. Другие физиологические переменные, за исключением GCS в APACHE III и II (AP III-GCS, AP II-GCS), имеют меньшую статистическую ценность при определении смертности от острой черепно-мозговой травмы.Для прогнозирования поздней смертности APACHE III и II дают значительно лучшие результаты в области под кривой ROC, правильном прогнозе и индексе Юдена, чем результаты GCS. Другие физиологические переменные (AP III-GCS и AP II-GCS) играют важную роль в прогнозировании поздней смертности по шкалам APACHE. Для прогнозирования функционального исхода выживших пациентов с острой травмой головы APACHE III дает наилучшие результаты правильного прогнозирования, индекса Юдена и площади под кривой ROC.

Заключение : APACHE III и II не могут заменить роль GCS в случаях острой черепно-мозговой травмы для больничной или ранней оценки смертности. Но для прогнозирования поздней смертности APACHE III и II имеют лучшую точность, чем GCS. Другие физиологические переменные, за исключением GCS в системе APACHE, играют решающую роль в поздней смертности. GCS прост, требует меньше времени и экономичен для пациентов с острой черепно-мозговой травмой для прогнозирования госпитальной и ранней смертности.APACHE III обеспечивает лучший прогноз тяжелой заболеваемости, чем GCS и APACHE II. Таким образом, APACHE III обеспечивает хорошую оценку не только госпитальной и поздней смертности, но и функционального результата.

Запуск Apache Superset в масштабе. Набор рекомендаций и стартовые… | Махди Карабибен | Март 2021 г.

Набор рекомендаций и отправных точек для эффективного запуска Superset в масштабе

Пример панели мониторинга Superset (источник: https://superset.apache.org/gallery/)

Что касается экосистемы Business Intelligence (BI) , проприетарные инструменты были стандартом в течение очень долгого времени.Tableau, Power BI и совсем недавно Looker были наиболее популярными решениями для корпоративных сценариев бизнес-аналитики. Но потом случился Apache Superset.

Разочарованный множеством неудобств, связанных с использованием проприетарного решения бизнес-аналитики (например, несовместимостью с определенными механизмами выполнения запросов и привязкой к поставщику), Максим Бошемин использовал внутренний хакатон Airbnb, чтобы создать инструмент бизнес-аналитики с нуля.

В 2016 году проект был открыт с исходным кодом (первоначально как Caravel), а за последние пять лет превратился в современный Apache Superset, предлагающий разработчикам во всем мире возможности проприетарных инструментов бизнес-аналитики (и многое другое) в виде проекта с открытым исходным кодом.Поэтому неудивительно, что его быстро приняли десятки компаний.

Спустя пять лет после его первоначального выпуска документация по-прежнему ограничена, когда дело доходит до масштабного запуска Superset, даже несмотря на то, что сам инструмент является облачным и предназначен для масштабирования. В этой статье предлагаются некоторые отправные точки и рекомендации, которые могут помочь новым пользователям в этом отношении.

Независимо от того, на какой платформе или облаке вы хотите запустить Superset, если вы планируете масштабируемость, то первым строительным блоком должна быть подготовка вашего пользовательского образа контейнера.Это позволит вам иметь контейнеры Superset, соответствующие вашему варианту использования и которые можно развернуть на всех типах платформ оркестровки (например, ECS или Kubernetes).

Отправной точкой должен быть официальный образ Superset (доступный на DockerHub), а затем в свой Dockerfile вы можете добавить дополнительные зависимости (например, драйверы базы данных) для вашего варианта использования. Например, если мы хотим использовать Redis, файл Dockerfile будет выглядеть так:

 FROM apache / superset: 1.0.1 
 # Мы переключаемся на root 
 USER root 
 # Мы устанавливаем интерфейс Python для Redis 
 RUN pip install redis 
 # Мы снова переключаемся на пользователя `superset` 
 USER superset

Кроме того, вы должны создать superset_config.py , который будет содержать вашу пользовательскую конфигурацию. Благодаря этому вы можете перезаписывать значения в основном файле конфигурации Superset, такие как метод аутентификации или время ожидания запроса.

Мы наконец можем обновить Dockerfile, добавив следующие команды:

 # Мы добавляем файл superset_config.py в контейнер 
 COPY superset_config.py / app / 
 # Мы сообщаем Superset, где его найти 
 ENV SUPERSET_CONFIG_PATH / app / superset_config.py

Это гарантирует, что наша настраиваемая конфигурация будет загружена в контейнер и распознана Superset.Затем вы можете просто добавить шаг CMD в свой Dockerfile, чтобы запустить Superset.

Независимо от того, к каким базам данных вы хотите подключить Superset, если вы планируете запускать его в масштабе, вы определенно не хотите, чтобы он запускал несколько запросов каждый раз, когда кто-то открывает панель управления.

Инструмент предлагает несколько возможностей кэширования, которые нельзя игнорировать. Как минимум, вы должны попытаться кэшировать собственные метаданные Superset и данные различных диаграмм. Таким образом, после того, как мы создадим диаграмму, Superset сохранит свои данные в настроенном нами кеше.В следующий раз, когда кто-то попытается посмотреть на диаграмму после этого (например, через панель управления), Superset мгновенно извлечет данные из кеша, вместо того, чтобы выполнять запрос в реальной базе данных.

Являясь в основном приложением Flask (оно использует фреймворк Flask-AppBuilder), для целей кэширования Superset использует Flask-Cache, который, в свою очередь, поддерживает несколько бэкэндов кеширования, таких как Redis и Memcached.

Если вы также хотите использовать Superset для длительных аналитических запросов, вы можете использовать Celery для настройки асинхронного бэкенда, для которого у вас может быть специальный механизм кэширования результатов запроса.

Неудивительно, что Superset также использует Flask AppBuilder для аутентификации. Он предлагает несколько вариантов аутентификации, таких как OAuth и LDAP, которые можно легко активировать и настроить.

Для масштабируемой архитектуры вам нужно активировать один из методов аутентификации, а затем позволить пользователям выполнять самостоятельную регистрацию на платформе. Для этого вы можете добавить следующие две строки в свой superset_config.py :

 AUTH_USER_REGISTRATION = True 
 AUTH_USER_REGISTRATION_ROLE = "a_custom_default_role"

Один из не очень идеальных аспектов Superset — управление разрешениями. открытый выпуск (открытый около двух лет назад) в его репозитории с подробным описанием различных проблем с текущей реализацией и предложением лучшей альтернативы.

К счастью для нас, разрешения на доступ к данным легко настроить, и проблема скорее связана с разрешениями, связанными с функциями, созданными Flask AppBuilder.

Чтобы избежать необходимости управлять длинным списком разрешений, эффективным подходом может быть клонирование одной из существующих ролей и ее настройка на основе вашего варианта использования, чтобы затем вы могли предоставить эту новую настраиваемую роль по умолчанию своим пользователям.

Благодаря большому сообществу Superset быстро превратился в зрелый и очень законченный проект (версия 1.0 был недавно выпущен). Имея это в виду, это определенно следует рассматривать как жизнеспособный вариант при разработке масштабируемой платформы бизнес-аналитики.

Различные этапы настройки, необходимые для работы в большом масштабе, — это небольшая цена, которую нужно заплатить, если принять во внимание длинный список функций и возможностей. И лучший пример того, насколько мощным он может быть, — это настройка Airbnb и то, как они используют его различные функции (подробно обсуждаемые в сообщении в блоге компании).

Наконец, стоит упомянуть, что Максим Бошемин, создатель Superset, недавно основал Preset — компанию, которая предлагает управляемый облачный сервис для Apache Superset.Если вы предпочитаете минимизировать необходимые усилия по настройке, то выбор Preset может быть более удобным.

Запуск и масштабирование приложения Apache Spark в IBM Cloud Kubernetes Service

Узнайте, как настроить Apache Spark в службе IBM Cloud Kubernetes, отправив образы контейнеров Spark в IBM Cloud Container Registry.

Давайте начнем с рассмотрения задействованных технологий.

Что такое Apache Spark?

Apache Spark (Spark) — это механизм обработки данных с открытым исходным кодом для больших наборов данных.Он разработан для обеспечения вычислительной скорости, масштабируемости и программируемости, необходимых для больших данных, особенно для потоковых данных, графических данных, приложений машинного обучения и искусственного интеллекта (AI).

Аналитический модуль

Spark обрабатывает данные от 10 до 100 раз быстрее, чем альтернативы. Он масштабируется за счет распределения обработки между большими кластерами компьютеров со встроенным параллелизмом и отказоустойчивостью. Он даже включает API-интерфейсы для языков программирования, популярных среди аналитиков и исследователей данных, включая Scala, Java, Python и R.

Краткое знакомство с Kubernetes и IBM Cloud Kubernetes Service

Kubernetes — это платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и службами на нескольких хостах. Он предлагает инструменты управления для развертывания, автоматизации, мониторинга и масштабирования контейнерных приложений с минимальным вмешательством вручную.

IBM Cloud Kubernetes Service — это управляемое предложение для создания собственного кластера вычислительных узлов Kubernetes для развертывания и управления контейнерными приложениями в IBM Cloud.Как сертифицированный поставщик Kubernetes, IBM Cloud Kubernetes Service обеспечивает интеллектуальное планирование, самовосстановление, горизонтальное масштабирование, обнаружение сервисов и балансировку нагрузки, автоматическое развертывание и откат, а также управление секретами и конфигурацией для ваших приложений.

Как Apache Spark работает на Kubernetes

Чтобы понять, как Spark работает в Kubernetes, обратитесь к документации Spark. При запуске приложения Python на Spark происходит следующее:

  • Apache Spark создает модуль драйверов с запрошенными ЦП и памятью.
  • Затем драйвер создает модули-исполнители, которые подключаются к драйверу и исполняют код приложения.
  • Во время работы приложения модули-исполнители завершаются, и в зависимости от нагрузки создаются новые модули. После завершения приложения все модули-исполнители завершаются, а журналы сохраняются в модуле драйвера, который остается в завершенном состоянии:

Предварительные требования

Короче говоря, для завершения этого путешествия вам понадобятся три вещи:

Настроить кластер IBM Cloud Kubernetes Service

В этом разделе вы получите доступ к кластеру IBM Cloud Kubernetes Service и создадите настраиваемую учетную запись службы и привязку кластера.

  1. Чтобы получить доступ к стандартному кластеру IBM Cloud Kubernetes Service, обратитесь к разделу Access вашего кластера. Следуя этим шагам, вы сможете загрузить и добавить файл конфигурации kubeconfig для вашего кластера в существующий kubeconfig в ~ / .kube / config или последний файл в переменной среды KUBECONFIG .
  2. Выполните приведенную ниже команду, чтобы создать учетную запись службы. Чтобы понять, почему нам требуется RBAC, обратитесь к документации по RBAC на Spark:
     $ kubectl create serviceaccount spark
  3. Чтобы предоставить учетной записи службы роль или ClusterRole , вам потребуется RoleBinding или ClusterRoleBinding .Чтобы создать RoleBinding или ClusterRoleBinding , вы можете использовать команду kubectl create rolebinding (или clusterrolebinding для ClusterRoleBinding ). Например, следующая команда создает роль edit ClusterRole в пространстве имен по умолчанию и предоставляет ее учетной записи службы Spark , созданной выше:
     $ kubectl create clusterrolebinding spark-role --clusterrole = edit --serviceaccount = default: spark --namespace = default
  4. Исправьте учетную запись службы Spark, чтобы использовать секрет all-icr-io по умолчанию для извлечения образов из реестра контейнеров IBM Cloud:
     $ kubectl patch -n default serviceaccount / spark -p '{"imagePullSecrets": [{"name": "all-icr-io"}]}'

Отправьте образы контейнеров Spark в частный реестр контейнеров

Начнем с того, что разместим образы контейнеров Spark в нашем частном реестре в IBM Cloud.

  1. В терминале на вашем компьютере перейдите в распакованную папку Spark.
  2. Запустите команду ibmcloud cr login , чтобы зарегистрировать локальный демон Docker в реестре IBM Cloud Container Registry:
  3. Задайте переменную среды для хранения пространства имен реестра контейнеров:
     $ CONTAINER_NAMESPACE =
  4. Чтобы получить реестр контейнеров на основе региона, в который вы вошли, выполните следующую команду, чтобы экспортировать его как переменную среды:
     $ CONTAINER_REGISTRY = $ (ibmcloud cr info | grep "Реестр контейнеров" | awk 'FNR == 1 {print $ 3}')
  5. Создайте образ контейнера:
     $./bin/docker-image-tool.sh -r $ CONTAINER_REGISTRY / $ CONTAINER_NAMESPACE -t latest -p ./kubernetes/dockerfiles/spark/bindings/python/Dockerfile build
  6. Отправьте образ контейнера:
     $ ./bin/docker-image-tool.sh -r $ CONTAINER_REGISTRY / $ CONTAINER_NAMESPACE -t latest -p ./kubernetes/dockerfiles/spark/bindings/python/Dockerfile push

Запустите приложение Spark

Есть два способа запустить приложение Spark в IBM Cloud Kubernetes Service:

  1. Использование искр-подача.
  2. Использование оператора spark-on-k8s.

Искро-подающий путь

  1. Перед запуском spark-submit экспортируйте K8S_MASTER_URL:
     $ K8S_MASTER_URL = $ (ibmcloud ks cluster get --cluster $ CLUSTER_ID --output json | jq --raw-output '.serviceEndpoints.publicServiceEndpointURL')
  2. spark-submit можно напрямую использовать для отправки приложения Spark в кластер Kubernetes. Вы можете сделать это с помощью следующей команды:
    ./ bin / искра-представить \
--master k8s: // $ K8S_MASTER_URL \
--deploy-mode cluster \
--name искра-пи \
--class org.apache.spark.examples.SparkPi \
--conf spark.executor.instances = 2 \
--conf spark.kubernetes.container.image = $ CONTAINER_REGISTRY / $ CONTAINER_NAMESPACE / spark-py: latest \
--conf spark.kubernetes.container.image.pullPolicy = Всегда \
--conf spark.kubernetes.executor.request.cores = 100 м \
локальный: /// opt / spark / examples / src / main / python / pi.ру 500
  3. Получите имя модуля драйвера, выполнив следующую команду:
     $ kubectl get pods -l spark-role = драйвер
  4. Доступ к пользовательскому интерфейсу, связанному с любым приложением, можно получить локально с помощью kubectl port-forward:
     $ kubectl port-forward <имя-модуля-драйвера> 4040: 4040

Пульт управления Spark-on-K8s

Оператор Spark-on-k8s — оператор Kubernetes для управления жизненным циклом приложений Apache Spark в Kubernetes.

  1. Для установки необходим Helm. Следуйте инструкциям, приведенным в репозитории GitHub, чтобы установить оператор в кластере IBM Cloud Kubernetes Service.
  2. Создайте файл YAML — spark-deploy.yaml — со следующим содержимым. Замените заполнители и и сохраните файл:
     apiVersion: "sparkoperator.k8s.io/v1beta2"
вид: ScheduledSparkApplication
метаданные:
имя: pyspark-pi
пространство имен: по умолчанию
спецификация:
расписание: «каждые 10 мин»
#suspend: правда
concurrencyPolicy: Запретить
шаблон:
тип: Python
pythonVersion: «3»
режим: кластер
изображение: " /  / spark-py: latest"
imagePullPolicy: Всегда
imagePullSecrets:
- all-icr-io
mainApplicationFile: local: /// opt / spark / examples / src / main / python / pi.ру
sparkVersion: "3.1.1"
restartPolicy:
тип: Никогда
Водитель:
ядер: 1
coreLimit: «1200 м»
память: "512м"
ярлыки:
версия: 3.1.1
serviceAccount: искра
исполнитель:
ядер: 1
экземпляров: 2
память: «100м»
ярлыки:
версия: 3.1.1
  3. Вы увидите, что приложение Spark запускается каждые 10 минут, вычисляя значение Pi.
  4. Примените spark-deploy.yaml для установки оператора:
     $ kubectl apply -f spark-deploy.yaml
  5. Запустите команду kubectl get pods --watch , чтобы проверить количество запущенных модулей-исполнителей.

Примечание: Чтобы проверить ресурсы Kubernetes, журналы и т. Д., Я бы порекомендовал IBM-kui, гибридную среду разработки из командной строки и пользовательского интерфейса для облачной разработки.

Автомасштабирование

Автоматическое масштабирование модулей и кластера IBM Cloud Kubernetes Service зависит от запросов и ограничений, установленных вами для драйвера Spark и модулей-исполнителей.

С помощью надстройки cluster-autoscaler вы можете автоматически масштабировать рабочие пулы в классическом кластере IBM Cloud Kubernetes Service или кластере VPC, чтобы увеличить или уменьшить количество рабочих узлов в рабочем пуле в зависимости от требований к размеру вашего запланированного рабочие нагрузки. Надстройка cluster-autoscaler Надстройка основана на проекте Kubernetes Cluster-Autoscaler.

Информацию о масштабировании приложений см. В документации IBM Cloud.

Установите надстройку автомасштабирования кластера в кластер с консоли:

  1. На панели мониторинга кластера IBM Cloud Kubernetes Service выберите кластер, в котором вы хотите включить автомасштабирование.
  2. На странице Overview щелкните Add-ons .
  3. На странице Add-ons найдите надстройку Cluster Autoscaler и щелкните Install . Вы также можете сделать то же самое с помощью интерфейса командной строки.

После включения надстройки необходимо отредактировать файл ConfigMap. Пошаговые инструкции см. В документации по автоматическому масштабированию кластера.

Динамическое размещение

При отправке приложения Spark ресурсы запрашиваются на основе запросов, которые вы задаете для драйвера и исполнителя.Благодаря динамическому распределению ресурсов Spark выделяет дополнительные ресурсы, необходимые для выполнения задач в задании. Ресурсы автоматически высвобождаются после того, как нагрузка снизится или задачи будут выполнены.

Чтобы динамическое распределение работало, ваше приложение должно установить два параметра конфигурации: spark.dynamicAllocation.enabled и spark.dynamicAllocation.shuffleTracking.enabled от до true . Для этого выполните следующие действия:

  1. Перейдите в распакованную папку Spark.
  2. В папке conf переименуйте spark-defaults.conf.template в spark-defaults.conf и добавьте следующие настройки среды:
     spark.dynamicAllocation.enabled true
spark.dynamicAllocation.shuffleTracking.enabled true
  3. Сохраните файл конфигурации.
  4. Возможно, вам потребуется создать и отправить образ контейнера, чтобы отразить изменения конфигурации. Поскольку для imagePullPolicy установлено значение Always , новый образ контейнера будет извлечен автоматически.Не забудьте удалить существующие модули драйверов и исполнителей с помощью команды kubectl delete pods --all .

Что дальше?

Вы можете добавить Apache Spark Streaming для приложений PySpark, таких как wordcount, для чтения и записи пакетов данных в облачные сервисы, такие как IBM Cloud Object Storage (COS). Также проверьте Stocator для подключения COS к Apache Spark.

Если у вас есть какие-либо вопросы, не стесняйтесь обращаться ко мне в Twitter или LinkedIn.

Автоматическое масштабирование экземпляров Apache Spark — Azure Synapse Analytics

  • 2 минуты на чтение

В этой статье

Apache Spark для пула Azure Synapse Analytics Autoscale автоматически масштабирует количество узлов в экземпляре кластера вверх и вниз.Во время создания нового пула Apache Spark для Azure Synapse Analytics минимальное и максимальное количество узлов может быть установлено при выборе автомасштабирования. Затем автоматическое масштабирование отслеживает требования к ресурсам нагрузки и масштабирует количество узлов в большую или меньшую сторону. Дополнительная плата за эту функцию не взимается.

Мониторинг показателей

Autoscale постоянно отслеживает экземпляр Spark и собирает следующие показатели:

Метрическая система Описание
Всего ожидающих ЦП Общее количество ядер, необходимое для запуска всех ожидающих узлов.
Всего ожидающей памяти Общий объем памяти (в МБ), необходимый для запуска всех ожидающих узлов.
Всего свободных ЦП Сумма всех неиспользуемых ядер на активных узлах.
Общий объем свободной памяти Сумма неиспользуемой памяти (в МБ) на активных узлах.
Используемая память на узел Нагрузка на узел. Узел, на котором используется 10 ГБ памяти, считается находящимся под большей нагрузкой, чем рабочий с 2 ​​ГБ используемой памяти.

Вышеуказанные показатели проверяются каждые 30 секунд. Autoscale принимает решения о масштабировании и уменьшении на основе этих показателей.

Условия шкалы на основе нагрузки

При обнаружении следующих условий Autoscale выдаст запрос на масштабирование:

Увеличение масштаба В уменьшенном масштабе
Общее количество ожидающих ЦП превышает общее количество свободных ЦП в течение более 1 минуты. Общее количество ожидающих ЦП меньше, чем общее количество свободных ЦП более 2 минут.
Общий объем ожидающей памяти превышает общий объем свободной памяти более 1 минуты. Общий объем незавершенной памяти меньше, чем общий объем свободной памяти более 2 минут.

Для масштабирования служба Azure Synapse Autoscale вычисляет, сколько новых узлов необходимо для удовлетворения текущих требований к ЦП и памяти, а затем выдает запрос на масштабирование для добавления необходимого количества узлов.

Для уменьшения масштаба, в зависимости от количества исполнителей, мастеров приложений на узел и текущих требований к ЦП и памяти, автоматическое масштабирование выдает запрос на удаление определенного количества узлов.Служба также определяет, какие узлы являются кандидатами на удаление, на основе текущего выполнения задания. Операция уменьшения масштаба сначала выводит из строя узлы, а затем удаляет их из кластера.

Начать

Создание бессерверного пула Apache Spark с автоматическим масштабированием

Чтобы включить функцию автомасштабирования, выполните следующие шаги в рамках обычного процесса создания пула:

  1. На вкладке Basics установите флажок Enable autoscale .

  2. Введите требуемые значения для следующих свойств:

    • Мин. количество узлов.
    • Максимальное количество узлов .

Начальное количество узлов будет минимальным. Это значение определяет начальный размер экземпляра при его создании. Минимальное количество узлов не может быть меньше трех.

Лучшие практики

Учитывайте задержку операций увеличения или уменьшения масштаба

Операция масштабирования может занять от 1 до 5 минут.

Подготовка к уменьшению

Во время процесса уменьшения масштаба экземпляра автоматическое масштабирование переводит узлы в состояние вывода из эксплуатации, чтобы на этом узле не могли запускаться новые исполнители.

Выполняемые задания продолжат работу и завершатся. Незавершенные задания будут ждать своего обычного расписания с меньшим количеством доступных узлов.

Следующие шаги

Краткое руководство по настройке нового пула Spark Создание пула Spark

Создание крупномасштабного озера транзакционных данных в Uber с использованием Apache Hudi

От обеспечения точного расчетного времени прибытия до прогнозирования оптимальных маршрутов движения, обеспечение безопасной и бесперебойной транспортировки и доставки на платформе Uber требует надежного, производительного крупномасштабного хранилища и анализа данных.В 2016 году Uber разработал Apache Hudi, среду инкрементной обработки, чтобы обеспечить работу критически важных для бизнеса конвейеров данных с низкой задержкой и высокой эффективностью. Год спустя мы решили открыть исходный код решения, чтобы позволить другим организациям, зависящим от данных, использовать его преимущества, а затем, в 2019 году, мы пошли еще дальше, пожертвовав его Apache Software Foundation. Теперь, почти полтора года спустя, Apache Hudi перешел на проект верхнего уровня в рамках Apache Software Foundation.Отмечая эту веху, мы хотели бы поделиться своим опытом создания, выпуска, оптимизации и повышения уровня Apache Hudi на благо более широкого сообщества Big Data.

Что такое Apache Hudi?

Apache Hudi — это среда абстракции хранилища, которая помогает распределенным организациям создавать озера данных петабайтного масштаба и управлять ими. Используя примитивы, такие как upserts и incremental pull, Hudi привносит потоковую обработку в пакетные большие данные. Эти функции помогают быстрее обрабатывать и получать более свежие данные для наших сервисов с помощью единого уровня обслуживания с задержками данных порядка минут, избегая дополнительных накладных расходов на обслуживание нескольких систем.Помимо гибкости, Apache Hudi может работать в распределенной файловой системе Hadoop (HDFS) или в облачных хранилищах.

Hudi обеспечивает семантику атомарности, согласованности, изоляции и стойкости (ACID) в озере данных. Две наиболее широко используемые функции Hudi — это upserts и инкрементное извлечение, которые дают пользователям возможность поглощать изменения данных и применять их к озеру данных в любом масштабе. Hudi предоставляет широкий спектр подключаемых возможностей индексирования для достижения этой цели, а также собственную реализацию индексации данных.Способность Худи контролировать и управлять макетами файлов в озере данных чрезвычайно важна не только для преодоления именных узлов HDFS и других ограничений облачных хранилищ, но и для поддержания здоровой экосистемы данных за счет повышения надежности и производительности запросов. С этой целью Hudi поддерживает несколько интеграций с механизмами запросов, такими как Presto, Apache Hive, Apache Spark и Apache Impala.

Рис. 1. Apache Hudi принимает журналы изменений, события и инкрементные потоки для обслуживания различных вариантов использования, предоставляя различные представления в таблице.

На высоком уровне Hudi концептуально разделен на 3 основных компонента: необработанные данные, которые необходимо сохранить, индексы данных, которые используются для обеспечения возможности обновления, и метаданные, используемые для управления набором данных. По сути, Hudi поддерживает временную шкалу всех действий, выполняемых на столе в разные моменты времени, которые в Hudi называются мгновениями. Это обеспечивает мгновенный просмотр таблицы, а также эффективную поддержку извлечения данных в порядке поступления. Hudi гарантирует, что действия, выполняемые на временной шкале, являются атомарными и согласованными на основе текущего времени, другими словами, времени, когда в базе данных было внесено изменение.С помощью этой информации Hudi предоставляет различные представления одной и той же таблицы Hudi, включая оптимизированное для чтения представление для быстрой работы в столбцах, представление в реальном времени для быстрого приема данных и инкрементное представление для чтения таблиц Hudi в виде потока журналов изменений, как показано на Рисунке 1 выше.

Hudi организует таблицы данных в структуру каталогов по базовому пути в распределенной файловой системе. Таблицы разбиты на разделы, и в каждом разделе файлы организованы в файловые группы, однозначно идентифицируемые идентификатором файла.Каждая группа файлов содержит несколько файловых фрагментов, где каждый фрагмент содержит базовый файл (* .parquet), созданный в определенный момент времени фиксации / сжатия, а также набор файлов журнала (* .log. *), Которые содержат вставки / обновления для базовый файл, так как базовый файл был создан. Hudi использует Multiversion Concurrency Control (MVCC), при котором действие сжатия объединяет журналы и базовые файлы для создания новых файловых фрагментов, а действие очистки избавляет от неиспользуемых / старых файловых фрагментов для освобождения места в файловой системе.

Hudi поддерживает два типа таблиц: копирование при записи и слияние при чтении.Тип таблицы копирование при записи хранит данные с использованием исключительно столбчатых форматов файлов (например, Apache Parquet). Посредством копирования при записи обновления просто версии и перезаписывают файлы, выполняя синхронное слияние во время записи.

Таблица слияния при чтении хранит данные, используя комбинацию форматов файлов на основе столбцов (например, Apache parquet) и строк (например, Apache Avro). Обновления регистрируются в дельта-файлах, а затем сжимаются для создания новых версий столбчатых файлов синхронно или асинхронно.

Hudi также поддерживает два типа запросов: моментальные снимки и инкрементные запросы. Запросы на моментальные снимки — это запросы, которые делают «моментальный снимок» таблицы для данного действия фиксации или сжатия. При использовании запросов к моментальным снимкам тип таблицы с копированием при записи предоставляет только базовые / столбчатые файлы в последних файловых срезах и гарантирует такую ​​же производительность столбчатых запросов по сравнению с столбцовыми таблицами без Hudi. Копирование при записи обеспечивает замену существующих паркетных таблиц, предлагая при этом вставку / удаление и другие функции.В случае таблиц слияния при чтении запросы моментальных снимков предоставляют данные в режиме, близком к реальному времени (порядка минут), путем слияния базового и дельта-файлов последнего фрагмента файла на лету. Для таблиц с копированием при записи инкрементные запросы предоставляют новые данные, записанные в таблицу с момента данной фиксации или сжатия, обеспечивая потоки изменений для включения инкрементных конвейеров данных.

Использование Apache Hudi в Uber

В Uber мы используем Hudi для различных целей, от предоставления быстрых и точных данных о поездках на платформе Uber, от обнаружения мошенничества до рекомендаций по ресторанам и еде на нашей платформе UberEats.Чтобы продемонстрировать, как работает Hudi, давайте рассмотрим, как мы обеспечиваем актуальность данных о поездках на Uber Marketplace в озере данных, что позволяет улучшить пользовательский интерфейс для пассажиров и водителей на платформе Uber. Типичный жизненный цикл поездки начинается, когда гонщик запрашивает поездку, продолжается по мере продвижения поездки и заканчивается, когда поездка заканчивается и гонщик достигает своего конечного пункта назначения. Основные данные о поездках Uber хранятся в виде таблиц в Schemaless, масштабируемом хранилище данных Uber. Одна запись поездки в таблице поездок может подвергаться множеству обновлений в течение жизненного цикла поездки.До того, как Hudi был реализован в Uber, большие задания Apache Spark периодически переписывали целые наборы данных в Apache HDFS, чтобы поглощать вставки, обновления и удаления вышестоящих онлайн-таблиц, отражая изменения в статусе командировки. Для контекста, в начале 2016 года (до того, как мы создали Hudi), в некоторых из наших крупнейших заданий было задействовано более 1000 исполнителей и обрабатывалось более 20 ТБ данных. Этот процесс был не только неэффективным, но и сложным для масштабирования. Различные команды в компании полагались на быструю и точную аналитику данных для обеспечения высокого качества обслуживания пользователей, и для удовлетворения этих требований стало очевидно, что наши текущие решения не могут масштабироваться для облегчения инкрементальной обработки наших озер данных.Благодаря решению для создания моментальных снимков и перезагрузки для перемещения данных в HDFS эти недостатки просачивались на все конвейеры, включая следующие ETL, потребляющие эти необработанные данные. Мы могли видеть, что эти проблемы только усугубляются с ростом масштабов.

Не имея другого жизнеспособного решения с открытым исходным кодом, мы создали и запустили Hudi для Uber в конце 2016 года, чтобы создать озеро транзакционных данных, которое будет способствовать быстрому и надежному обновлению данных в любом масштабе. Первое поколение Hudi в Uber использовало исключительно таблицу копирования при записи, которая ускоряла обработку заданий до 20 ГБ каждые 30 минут, сокращая количество операций ввода-вывода и увеличение записи в 100 раз.К концу 2017 года все таблицы необработанных данных в Uber использовали формат Hudi, управляя одним из крупнейших озер транзакционных данных на планете.

Рисунок 2. Функция копирования при записи в Hudi позволяет нам выполнять обновления на уровне файлов, значительно повышая свежесть данных.

Улучшение Apache Hudi для Uber — и выше

По мере того как потребности Uber в обработке и хранении данных росли, мы начали сталкиваться с ограничениями функции копирования при записи Hudi, в первую очередь с необходимостью продолжать улучшать скорость отображения и актуальность наших данных.Даже при использовании функции копирования при записи Hudi некоторые из наших таблиц получали обновления, которые распределялись по 90 процентам файлов, что приводило к перезаписи данных размером около 100 ТБ для любой крупномасштабной таблицы в озере данных. Поскольку копирование при перезаписи перезаписывает весь файл даже для одной измененной записи, функция копирования при записи привела к высокому усилению записи и скомпрометированной свежести, вызывая ненужные операции ввода-вывода на наших кластерах HDFS и приводя к ухудшению качества дисков намного быстрее. Более того, большее количество обновлений таблиц данных означало больше версий файлов и резкое увеличение количества файлов HDFS.В свою очередь, эти требования привели к нестабильности именных узлов HDFS и более высоким затратам на вычисления.

Чтобы решить эти растущие проблемы, мы реализовали второй тип таблиц, слияние при чтении. Поскольку слияние при чтении использует данные, близкие к реальному времени, путем слияния данных на лету, мы используем эту функцию осторожно, чтобы избежать затрат на вычисления на стороне запроса. Наша модель развертывания слиянием при чтении состоит из трех независимых заданий, включая задание приема, которое вводит новые данные, состоящие из вставок, обновлений и удалений, и небольшое задание уплотнения, которое асинхронно и агрессивно уплотняет обновления / удаления в небольшом количестве недавних разделы, а также основная работа по уплотнению, которая медленно и неуклонно сжимает обновления / удаляет большое количество старых разделов.Каждое из этих заданий выполняется с разной частотой, при этом второстепенные задания и задания приема выполняются чаще, чем основные, чтобы обеспечить быстрый доступ к данным в его последних разделах в столбчатом формате. С такой моделью развертывания мы можем предоставлять свежие данные в столбцовом формате для тысяч запросов и ограничивать наши затраты на слияние на стороне запроса на недавних секциях. Используя слияние при чтении, мы можем решить все три проблемы, упомянутые выше, и таблицы Hudi становятся практически невосприимчивыми к любому количеству входящих обновлений или удалений в наше озеро данных.Теперь в Uber мы используем возможности Apache Hudi для копирования при записи и слияния при чтении в зависимости от варианта использования.

Рисунок 3. Команда Apache Hudi в Uber разработала стратегию сжатия данных для таблиц слияния при чтении, чтобы часто преобразовывать последние разделы в столбчатый формат, тем самым ограничивая затраты на вычисления на стороне запроса.

Благодаря Hudi, Uber загружает более 500 миллиардов записей в день в наше озеро данных размером 150 ПБ, охватывая более 10 000 таблиц и тысячи конвейеров данных, используя более 30 000 виртуальных ядер в день.Таблицы Hudi обслуживают более 1 миллиона запросов в неделю в наших различных сервисах.

Размышляя об Apache Hudi

Uber открыл Hudi в 2017 году, чтобы предоставить другим преимущества решения, которое принимает и управляет хранилищем данных в любом масштабе, обеспечивая потоковую обработку больших данных. Когда Худи перешел на проект верхнего уровня в рамках Apache Software Foundation, команда по работе с большими данными в Uber размышляла над различными соображениями, которые изначально вдохновили нас на создание Hudi, в том числе:

    • Как мы можем повысить эффективность хранения и обработки данных?
    • Как мы можем гарантировать, что наши озера данных содержат таблицы высокого качества?
    • Как мы можем продолжать предоставлять данные с малой задержкой и эффективно масштабировать по мере роста наших операций?
    • Как унифицировать уровни обслуживания для случаев использования, когда допустима задержка порядка нескольких минут?

Без хорошей стандартизации и примитивов озера данных могут быстро стать непригодными для использования «болотами».Такие «болота» не только требуют много времени и ресурсов для согласования, очистки и исправления таблиц, но также вынуждают отдельных владельцев сервисов создавать сложные алгоритмы для настройки, перетасовки и транзакций, что вносит ненужные сложности в ваш технологический стек.

Как описано выше, Hudi устраняет эти пробелы, помогая пользователям взять под контроль свои озера данных за счет беспрепятственного приема и управления большими наборами аналитических данных через распределенные файловые системы. Создание озера данных — многогранная проблема, требующая инвестиций в стандартизацию данных, методы хранения, методы управления файлами, выбор правильного компромисса производительности между приемом данных и запросом данных и т. Д.Разговаривая с другими членами сообщества Big Data, когда мы создавали Hudi, мы узнали, что такие проблемы широко распространены во многих инженерных организациях. Мы надеемся, что открытый исходный код и работа с сообществом Apache по развитию Hudi в течение последних нескольких лет позволили другим лучше понять их собственные операции с большими данными для улучшения приложений в различных отраслях. Помимо Uber, Apache Hudi используется в производстве в нескольких компаниях, включая Alibaba Cloud, Udemy и Tencent.

Дорога впереди

Рис. 4. Сценарии использования Apache Hudi включают анализ данных и мониторинг состояния инфраструктуры.

Hudi помогает пользователям создавать более надежные и свежие озера данных, обеспечивая высокое качество анализа за счет применения схематизации наборов данных.

У Uber одно из крупнейших в мире озер транзакционных данных дает нам возможность определять уникальные варианты использования Apache Hudi. Поскольку решение проблем и повышение эффективности в таком масштабе может иметь значительное влияние, у нас есть прямой стимул смотреть глубже.В Uber мы уже используем расширенные примитивы Hudi, такие как инкрементное вытягивание, чтобы помочь построить связанные инкрементные конвейеры, уменьшая объем вычислений для заданий, которые в противном случае выполняли бы большое сканирование и запись. Мы настраиваем наши стратегии сжатия для таблиц слияния при чтении в соответствии с нашими конкретными сценариями использования и требованиями. В последние месяцы с тех пор, как мы пожертвовали Hudi фонду Apache, Uber предоставил такие функции, как встроенная служба временной шкалы для эффективного доступа к файловой системе, удаление переименований для поддержки развертываний, дружественных к облаку, и повышение производительности инкрементного извлечения, чтобы упомянуть некоторые из них.

В ближайшие месяцы Uber намерен внести множество новых функций в сообщество Apache Hudi. Некоторые из этих функций помогают снизить затраты за счет оптимизации использования вычислительных ресурсов и повышения производительности приложений для обработки данных. Мы также более подробно рассмотрим, как мы можем улучшить управление хранилищем и производительность запросов на основе шаблонов доступа и требований приложений для обработки данных.

Для получения дополнительной информации о том, как мы планируем достичь этих целей, вы можете прочитать некоторые RFC (включая интеллектуальные метаданные для поддержки индексов столбцов и планирование запросов O (1), эффективную загрузку таблиц в Hudi, индекс записи для молниеносной обработки). fast upserts), предложенный командой Hudi в Uber более широкому сообществу Apache.

После того, как Apache Hudi перешел в проект Apache высшего уровня, мы рады внести свой вклад в амбициозную дорожную карту проекта. Hudi позволяет Uber и другим компаниям проверять будущее своих озер данных на скорость, надежность и транзакционные возможности, используя форматы файлов с открытым исходным кодом, абстрагируясь от многих проблем с большими данными и создавая многофункциональные и портативные приложения для обработки данных.

Apache Hudi — это растущее сообщество с захватывающим, постоянно развивающимся планом развития. Если вы заинтересованы в участии в этом проекте, пожалуйста, подключите здесь .

Confluent представляет масштабирование по запросу для клиентов облака Apache Kafka — TechCrunch

Мы находимся в то время, когда определенные предприятия просят масштабироваться до уровней, о которых они даже не догадывались. Иногда это увеличение использования происходит скачкообразно, что означает, что вы не хотите платить за постоянную дополнительную емкость, которая может не всегда понадобиться. Сегодня Confluent представила новую функцию масштабирования по требованию для своей облачной службы Apache Kafka, которая автоматически масштабируется вверх и вниз по мере необходимости.

Генеральный директор

Confluent Джей Крепс говорит, что эластичность, возможно, является одной из самых важных характеристик облачных вычислений, а возможность масштабирования вверх и вниз — один из основных факторов, которые привлекли организации к облаку. Автоматизируя эту возможность, они избавляют DevOps от одной важной вещи, о которой нужно беспокоиться.

«Эта новая функциональность позволяет пользователям динамически масштабировать Kafka и другие ключевые компоненты экосистемы, такие как KSQL и Kafka Connect. Это ключевая отсутствующая возможность, которую не предоставляет никакая другая служба », — пояснил Крепс.

Он указывает, что это особенно актуально сейчас для людей, работающих на дому. Системы облагаются налогом больше, чем, возможно, когда-либо прежде, и эта автоматическая эластичность пригодится, делая ее более рентабельной и эффективной, чем это было возможно раньше.

«Эти возможности позволяют клиентам добавлять емкость по мере необходимости или уменьшать ее для экономии денег, и все это без предварительного планирования», — сказал он.

Новая функция эластичности в Confluent является частью серии обновлений платформы, известных как Project Metamorphosis, которые Confluent планирует регулярно выпускать в течение этого года.

«В течение оставшейся части года мы будем делать серию выпусков, которые привносят возможности современных облачных систем данных в экосистему Kafka в Confluent Cloud. Мы будем объявлять об одной крупной возможности каждый месяц, начиная с эластичности », — сказал он.

Kreps впервые объявила о Metamorphosis в прошлом месяце, когда компания также объявила о масштабном раунде финансирования в размере 250 миллионов долларов при оценке в 4,5 миллиарда долларов.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *