Зміст
- Файлова система Google: дослідження великого випадку
- Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя
- Погляд на основні технології
- Як інші великі системи цього досягають?
- Підтримання DFS
Винос:
Розробникам та інженерам потрібно постійно працювати над прискоренням та вдосконаленням послуг на платформах, які вийшли далеко за межі їхніх класичних архетипів 1990-х років.
Не дивлячись на все, що йдеться про величезні центри обробки даних НДА, у яких є газильйони бітів даних про наше приватне життя, є одне, про що не багато говорили, принаймні на CNN. Він включає інженерну проблему, яка з’явилася разом із хмарною технологією, великими даними та вражаючими фізичними центрами зберігання даних, які зараз будуються у всьому світі. Так що це? Ну, незалежно від того, хто управляє однією з ІМ-систем мамонта, що керують цими засобами, існує потреба у програмних системах, які допомагають усім цим даним швидко надходити та виходити з конвеєра. Ця потреба представляє одне з найцікавіших ІТ-питань чи пазлів, з якими стикаються професіонали сьогодні.
Як зазначають багато експертів, сьогодні надзвичайний попит на обробку даних виходить далеко за рамки традиційних підходів. Простіше кажучи, використання простих структур бази даних та інструментів, таких як інтерфейс запитів SQL, не забезпечить достатню потужність або функціональність для подібних систем, що розвиваються за останні кілька років. Архів сучасних великих технологічних компаній потребує надзвичайно масштабованих технологій. Їм потрібні засоби обробки даних, які дозволяють вводити та виводити результати набагато більшого обсягу, ніж те, що може полегшити один сервер. Їм потрібні рішення, які можна швидко підсилити для зростання, рішення, що включають складний рівень штучного інтелекту, рішення, розроблені для легкого управління ІТ-відділом.
Питання полягає в тому, як компанії та державні установи перемагають обмеження традиційного шляху обробки даних? Тут добре погляньте на один дуже перспективний варіант: Програмне забезпечення, яке обробляє великі дані та адміністрування декількох центрів обробки даних.
Файлова система Google: дослідження великого випадку
Приватна технологія, яку Google використовує для доступу до своїх центрів обробки даних, є одним з найкращих прикладів загальних моделей для обробки великих даних та багаторазового адміністрування. Файлова система Google (GFS), розроблена в 2003 році, розроблена для підтримки величезного обсягу швидкісних поправок до систем передачі даних, які є частиною отримання стільки нової інформації на одній платформі і з неї, коли мільйони користувачів клацають на одночасно. Експерти посилаються на це як на розподілену файлову систему та використовують термін "зберігання об'єктів даних" для опису цих дуже складних методів. Насправді ж ці терміни навіть не подряпають поверхню в термінах, що описують те, що працює.
Індивідуально, функції та компоненти, які складають таку систему, як GFS, вже не можуть бути новаторськими, але вони є складними. Багато з них висвітлюються на цьому веб-сайті як відносно нові інновації, які є частиною основи для нової, завжди ввімкненої, завжди підключеної глобальної ІТ-системи. Система на зразок GFS набагато більше, ніж сума її частин: це в основному невидима, але надзвичайно складна мережа, яка кидається таким чином, щоб окремі фрагменти даних перекинулися таким чином, і процес, який, якщо візуально повністю змодельований, буде схожий на хаос. Розуміння того, куди збираються всі дані, вимагає багато енергії та зусиль, оскільки особи, що комплектують бойові станції цих систем, легко визнають.
"Існує занадто багато деталей, які мають глибокий вплив на сфери зручності використання, включаючи зовнішню та внутрішню фрагментацію, оновлення на основі журналу порівняно на місці та рівні послідовності транзакцій, - щоб підбити підсумки способу роботи в одному стислому реченні ", - каже Момчил Михайлов, генеральний директор та співзасновник Sanbolic.
"Розподілена файлова система - це або розподілений агрегатор локальних просторів імен та вільних просторів вузлів-учасників, або локальна файлова система, яка працює на декількох вузлах, що мають доступ до спільного сховища за допомогою компонента розподіленого менеджера блокування", - сказав він.
Керрі Лебель - старший менеджер із продуктів в компанії Automic, компанії, відомої своїми масштабованими платформами автоматизації. Lebel каже, що хоча точно описати DFS як систему, яка просто призначає робочі навантаження серверам, приєднаним до недорогих апаратних засобів, це насправді не розповідає всієї історії.
Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя
Ви не можете покращити свої навички програмування, коли ніхто не піклується про якість програмного забезпечення.
"Те, що у вас в кінці не вистачає, - все це крутий фактор як вони роблять те, що роблять », - сказала Лебель.
Коли ви відійдете від технічних деталей і просто подумайте про основну ідею розподіленої файлової системи, "прохолодний фактор", про який говорить Лебель, очевидний. Ці системи оброблення великих даних замінюють старі системи файлів / папок структурами, які передбачають не лише декілька систем доставки, але і "об'єктно-орієнтований" підхід, де велика кількість одиниць перебирається тут і там, щоб запобігти вузьким місцям.
Подумайте, наприклад, про найсучаснішу систему автодоріг, де сотні тисяч автомобілів не просто перекочуються вниз по багатошаровій прямій, але зачерпнуті в акуратні маленькі притоки листя конюшини або батоги, які крутяться навколо і відправляються до їхніх напрямків на різних об'їздах. З неба все виглядає так само хореографічно, як швейцарський годинник. Ось така візуальна модель, на яку дивляться інженери, коли вони мріють про нові способи маршрутизації інформації навколо обмежень, "натискаючи" на різні рівні багатоярусної схеми утримання даних. Залишаючи осторонь специфікацій, це головна мета системи обробки: утримати ці автономні об'єкти зі своїми вбудованими метаданими, що рухаються з максимальною швидкістю туди, де вони повинні бути, для досягнення цілей узгодженості, задоволення кінцевого користувача або навіть повідомити спостереження чи аналіз вищого рівня.
Погляд на основні технології
Стаття Шона Галлахера, що з’явилася на Ars Technica, розбиває дизайн GFS на дещо більш керовані частини та натякає на те, що знаходиться під аркушем у Google.
GFS починається із надмірної та стійкої до помилок моделі для зчитування та запису даних. Ідея тут полягає в тому, що замість того, щоб записувати конкретне оновлення на один привід, нові системи записують шматки даних у кілька напрямків. Таким чином, якщо один запис провалиться, інші залишаться. Для забезпечення цього один основний компонент мережі виконує обробку даних для інших підпорядкованих підрозділів, повторно агрегуючи дані, коли клієнт "закликає" до нього. Все це стає можливим завдяки протоколу метаданих, який допомагає визначити, де певні оновлення та результати передачі знаходяться в межах більшої системи.
Ще одним дуже важливим аспектом цього є те, як ці дублікати важких систем забезпечують узгодженість даних. Як зазначає Галлахер, дизайн GFS приносить певну послідовність, зберігаючи при цьому атомність, або захищаючи принцип того, як дані оновлюються в декількох одиницях зберігання, щоб збігатися з часом. "Модель спокійної узгодженості" від Google, здається, відповідає основній теорії моделі BASE, яка забезпечує більшу гнучкість у відповідь на більш тривалий термін для забезпечення послідовності.
Як інші великі системи цього досягають?
"Коли буде досягнуто досить великого масштабу, невідповідності чи пошкодження даних стають неминучими", - каже Михайлов. "Отже, першочерговою метою розподілених файлових систем повинна бути можливість здійснювати якомога більше операцій за наявності корупції, забезпечуючи при цьому ефективні методи боротьби з корупцією одночасно". Михайлов також згадує про необхідність збереження продуктивності шляхом ретельного впровадження надмірності.
"Наприклад, створення метаданих (даних про дані) на кожному диску дає можливість цьому диску відновити належну структуру даних, якщо його дзеркальна копія пошкоджена", - сказав Михайлов. "Крім того, рівні RAID можна використовувати для боротьби з помилками зберігання або на агрегаторі файлової системи, або на загальному рівні диспетчера томів."
Обговорюючи іншу модель узгодженості, Лебель фокусується на системі під назвою розподіленою файловою системою Hadoop (HDFS), яку він називає "галузевим фактичним стандартом".
У HDFS, каже Лебель, кожен блок даних повторюється три рази на різних вузлах і на двох різних стелажах. Дані перевіряються в кінці. Помилки надходять до NameNode, обробника даних, який позбавляється від корумпованих блоків та створює нові.
Все це підтримує види "чистих даних", які так важливі для цілісності однієї з цих систем масових даних.
Підтримання DFS
Ще один дуже інший погляд на GFS - це стаття в жовтні 2012 року провідного письменника Стівена Леві. Це набагато легше характеризувати програмний підхід для колективної обробки даних Google зверху вниз.
"Протягом багатьох років, - пише Леві, - Google також створила програмну систему, яка дозволяє їй керувати своїми незліченними серверами так, ніби вони є однією гігантською сутністю. Її внутрішні розробники можуть діяти як майстри ляльок, відправляючи тисячі комп'ютерів для виконання завдання так само легко, як і запуск однієї машини. "
Це також передбачає безліч кіберзабезпечень та екологічного обслуговування, від спеціалізованих тестових груп, які намагаються "зламати" серверні системи, до ретельно контрольованих температур у залах криптовалюти.
Леві також згадує додаткові технології для GFS, такі як MapReduce, інструмент хмарного застосування та Hadoop, аналітичний механізм, який ділиться деякими принципами дизайну з GFS. Ці інструменти по-своєму впливають на те, як розробляються системи обробки великих центрів обробки даних та що, можливо, з’явиться в майбутньому. (Дізнайтеся більше про ці технології в розділі "Еволюція великих даних".)
Михайлов вважає, що MapReduce має потенціал для підтримки дедалі більших систем центрів обробки даних, і говорить про "єдину реалізацію" спільних та агрегованих файлових систем, які могли б "зберігати вузли імен агрегованої файлової системи в спільному кластері з SSD для зберігання" . "
Зі свого боку Лебель бачить відхід від пакетної обробки (підтримується методом Hadoop) до потокової обробки, що наблизить ці операції з даними до реального часу.
"Чим швидше ми зможемо обробити дані та зробити їх доступними для осіб, що приймають рішення, або для наших клієнтів, тим більше буде конкурентної переваги", - каже Лебель, який також пропонує замінити вищевказану термінологію обробки термінами, орієнтованими на кінцевий користувач. Розмірковуючи про "синхронну" діяльність або діяльність, синхронізовану з діями кінцевого споживача, та "асинхронні" дії, які є більш гнучкими в плані впровадження, Лебель каже, що компанії можуть використовувати угоди про домовленості та інші ресурси для визначення того, як буде працювати дана система обслуговування .
У цьому сенсі все це зводиться до того, що розробникам та інженерам потрібно постійно працювати над прискоренням і вдосконаленням послуг на платформах, які вийшли далеко за межі їхніх класичних архетипів епохи 1990-х років. Це означає критично дивитись на механізм даних і пробивати вузькі місця таким чином, щоб підтримувати не тільки зростаюче населення, але й експоненціальну зміну, що відбувається зі швидкістю зламу, яка, як вважають кадри, називають "наступною промисловою революцією". Цілком імовірно, що ті, хто зламає найбільше позицій на цих фронтах, виявляться домінуючими на ринках та в економіках майбутнього.