Айсберг Апач це формат відкритої таблиці для дуже великих аналітичних наборів даних, який фіксує інформацію метаданих про стан наборів даних, коли вони розвиваються та змінюються з часом. Він додає таблиці до обчислювальних механізмів, включаючи Spark, Trino, PrestoDB, Flink і Hive, використовуючи високопродуктивний формат таблиці, який працює так само, як таблиця SQL. Iceberg став дуже популярним завдяки підтримці транзакцій ACID в озерах даних і таким функціям, як еволюція схем і розділів, подорожі в часі та відкат.
Інтеграція Apache Iceberg підтримується в тому числі аналітичними службами AWS Amazon EMR, Амазонка Афіна та Клей AWS. Amazon EMR може створювати кластери з Spark, Hive, Trino та Flink, які можуть запускати Iceberg. Починаючи з Amazon EMR версії 6.5.0, ви можете використовуйте Iceberg із кластером EMR не вимагаючи дії початкового завантаження. На початку 2022 року AWS оголосила про загальну доступність транзакцій Athena ACID на базі Apache Iceberg. Нещодавно випущений Система запитів Athena версії 3 забезпечує кращу інтеграцію з форматом таблиці Iceberg. AWS Glue 3.0 і новіших версій підтримує структуру Apache Iceberg для озер даних.
У цій публікації ми обговорюємо, що клієнти хочуть від сучасних озер даних і як Apache Iceberg допомагає задовольняти потреби клієнтів. Потім ми розглянемо рішення для створення високопродуктивного озера даних Iceberg, що розвивається Служба простого зберігання Amazon (Amazon S3) і обробляти додаткові дані, запускаючи оператори SQL вставки, оновлення та видалення. Нарешті, ми покажемо вам, як налаштувати продуктивність процесу, щоб покращити продуктивність читання та запису.
Як Apache Iceberg відповідає потребам клієнтів у сучасних озерах даних
Все більше клієнтів створюють озера даних зі структурованими та неструктурованими даними для підтримки багатьох користувачів, програм і інструментів аналітики. Існує підвищена потреба в озерах даних для підтримки таких функцій, як бази даних, як транзакції ACID, оновлення та видалення записів, подорожі в часі та відкат. Apache Iceberg розроблено для підтримки цих функцій у економічно ефективних озерах даних розміром у петабайт на Amazon S3.
Apache Iceberg задовольняє потреби клієнтів, збираючи багату інформацію метаданих про набір даних під час створення окремих файлів даних. В архітектурі таблиці Iceberg є три рівні: каталог Iceberg, рівень метаданих і рівень даних, як показано на наступному малюнку (джерело).
У каталозі Iceberg зберігається покажчик метаданих на файл метаданих поточної таблиці. Коли запит на вибірку читає таблицю Iceberg, система запитів спочатку переходить до каталогу Iceberg, а потім отримує розташування поточного файлу метаданих. Щоразу, коли відбувається оновлення таблиці Iceberg, створюється новий знімок таблиці, а покажчик метаданих вказує на файл метаданих поточної таблиці.
Нижче наведено приклад каталогу Iceberg із застосуванням AWS Glue. Ви можете побачити назву бази даних, розташування (шлях S3) таблиці Iceberg і розташування метаданих.
Рівень метаданих має три типи файлів: файл метаданих, список маніфесту та файл маніфесту в ієрархії. У верхній частині ієрархії знаходиться файл метаданих, який зберігає інформацію про схему таблиці, інформацію про розділи та знімки. Знімок вказує на список маніфестів. Список маніфесту містить інформацію про кожен файл маніфесту, який утворює знімок, наприклад розташування файлу маніфесту, розділи, до яких він належить, а також нижню та верхню межі для стовпців розділів для файлів даних, які він відстежує. Файл маніфесту відстежує файли даних, а також додаткові відомості про кожен файл, наприклад формат файлу. Усі три файли працюють в ієрархії, щоб відстежувати знімки, схему, розділення, властивості та файли даних у таблиці Iceberg.
Рівень даних містить окремі файли даних таблиці Iceberg. Iceberg підтримує широкий спектр форматів файлів, включаючи Parquet, ORC і Avro. Оскільки таблиця Iceberg відстежує окремі файли даних, а не лише вказує на розташування розділу з файлами даних, вона ізолює операції запису від операцій читання. Ви можете записати файли даних у будь-який час, але лише зафіксуйте зміни явно, що створить нову версію знімка та файлів метаданих.
Огляд рішення
У цій публікації ми ознайомимо вас із рішенням для створення високопродуктивного озера даних Apache Iceberg на Amazon S3; обробляти додаткові дані за допомогою операторів вставки, оновлення та видалення SQL; і налаштуйте таблицю Iceberg для покращення продуктивності читання та запису. Наведена нижче схема ілюструє архітектуру рішення.
Щоб продемонструвати це рішення, ми використовуємо Відгуки клієнтів Amazon набір даних у відрі S3 (s3://amazon-reviews-pds/parquet/
). У реальному випадку це будуть необроблені дані, які зберігаються у вашому сегменті S3. Ми можемо перевірити розмір даних за допомогою наступного коду в Інтерфейс командного рядка AWS (AWS CLI):
Загальна кількість об’єктів становить 430, а загальний розмір – 47.4 ГіБ.
Щоб налаштувати та перевірити це рішення, ми виконуємо такі кроки високого рівня:
- Налаштуйте відро S3 у керованій зоні для зберігання перетворених даних у форматі таблиці Iceberg.
- Запустіть кластер EMR із відповідними конфігураціями для Apache Iceberg.
- Створіть блокнот в EMR Studio.
- Налаштуйте сеанс Spark для Apache Iceberg.
- Перетворюйте дані у формат таблиці Iceberg і переміщуйте дані до керованої зони.
- Виконуйте запити на вставку, оновлення та видалення в Athena для обробки додаткових даних.
- Виконайте налаштування продуктивності.
Передумови
Щоб слідувати цьому покроковому керівництву, ви повинні мати Обліковий запис AWS з Управління ідентифікацією та доступом AWS (IAM) роль, яка має достатній доступ для надання необхідних ресурсів.
Налаштуйте сегмент S3 для даних Iceberg у керованій зоні у вашому озері даних
Виберіть регіон, у якому ви хочете створити сегмент S3, і вкажіть унікальне ім’я:
Запустіть кластер EMR для виконання завдань Iceberg за допомогою Spark
Ви можете створити кластер EMR з Консоль управління AWS, Amazon EMR CLI або Набір хмарних розробок AWS (AWS CDK). У цій публікації ми розповімо вам, як створити кластер EMR з консолі.
- На консолі Amazon EMR виберіть Створити кластер.
- Вибирати Додаткові параметри.
- для Конфігурація програмного забезпечення, виберіть останню версію Amazon EMR. Станом на січень 2023 року останньою версією є 6.9.0. Для Iceberg потрібен випуск 6.5.0 і вище.
- Select JupyterEnterpriseGateway та Іскритися як програмне забезпечення для встановлення.
- для Редагувати налаштування програмного забезпеченнявиберіть Введіть конфігурацію І введіть
[{"classification":"iceberg-defaults","properties":{"iceberg.enabled":true}}]
. - Залиште інші налаштування за замовчуванням і виберіть МАЙБУТНІ.
- для апаратні засоби, використовуйте налаштування за замовчуванням.
- Вибирати МАЙБУТНІ.
- для Назва кластера, введіть назву. Ми використовуємо
iceberg-blog-cluster
. - Залиште інші налаштування без змін і виберіть МАЙБУТНІ.
- Вибирати Створити кластер.
Створіть блокнот в EMR Studio
Зараз ми розповімо вам, як створити блокнот у EMR Studio з консолі.
- На консолі IAM, створити роль служби EMR Studio.
- На консолі Amazon EMR виберіть Студія ЕМР.
- Вибирати ПОЧАТИ.
Команда ПОЧАТИ сторінка з’явиться в новій вкладці.
- Вибирати Створити студію у новій вкладці.
- Введіть назву. Ми використовуємо iceberg-studio.
- Виберіть ту саму VPC і підмережу, що й для кластера EMR, і групу безпеки за замовчуванням.
- Вибирати AWS Identity and Access Management (IAM) для автентифікації та виберіть роль служби EMR Studio, яку ви щойно створили.
- Виберіть шлях S3 для Резервне копіювання робочих областей.
- Вибирати Створити студію.
- Після створення Studio виберіть URL-адресу доступу до Studio.
- На інформаційній панелі EMR Studio виберіть Створіть робочу область.
- Введіть назву робочої області. Ми використовуємо
iceberg-workspace
. - Розширювати Розширена конфігурація І вибирай Приєднайте робочу область до кластера EMR.
- Виберіть створений раніше кластер EMR.
- Вибирати Створити робочу область.
- Виберіть назву робочої області, щоб відкрити нову вкладку.
На панелі навігації є блокнот із такою ж назвою, що й робоча область. У нашому випадку це айсберг-робочий простір.
- Відкрийте зошит.
- Коли буде запропоновано вибрати ядро, виберіть Іскритися.
Налаштуйте сеанс Spark для Apache Iceberg
Використовуйте наступний код, надавши власну назву сегмента S3:
Це встановлює такі конфігурації сеансу Spark:
- spark.sql.catalog.demo – Реєструє каталог Spark під назвою demo, який використовує плагін каталогу Iceberg Spark.
- spark.sql.catalog.demo.catalog-impl – Демонстраційний каталог Spark використовує AWS Glue як фізичний каталог для зберігання бази даних Iceberg і інформації таблиці.
- spark.sql.catalog.demo.warehouse – Демонстраційний каталог Spark зберігає всі метадані та файли даних Iceberg у кореневому шляху, визначеному цією властивістю:
s3://iceberg-curated-blog-data
. - spark.sql.extensions – Додано підтримку розширень Iceberg Spark SQL, що дозволяє запускати процедури Iceberg Spark і деякі команди SQL лише для Iceberg (це буде використано на наступному кроці).
- spark.sql.catalog.demo.io-impl – Iceberg дозволяє користувачам записувати дані в Amazon S3 через S3FileIO. Каталог даних AWS Glue за замовчуванням використовує цей FileIO, а інші каталоги можуть завантажувати цей FileIO за допомогою властивості каталогу io-impl.
Перетворення даних у формат таблиці Iceberg
Ви можете використовувати Spark на Amazon EMR або Athena, щоб завантажити таблицю Iceberg. У сеансі Spark блокнота EMR Studio Workspace виконайте такі команди, щоб завантажити дані:
Після запуску коду ви повинні знайти два префікси, створені на шляху S3 вашого сховища даних (s3://iceberg-curated-blog-data/reviews.db/all_reviews
): дані та метадані.
Обробляйте додаткові дані за допомогою операторів SQL вставки, оновлення та видалення в Athena
Athena — це безсерверна система запитів, яку можна використовувати для читання, запису, оновлення й оптимізації таблиць Iceberg. Щоб продемонструвати, як формат озера даних Apache Iceberg підтримує поступове надходження даних, ми запускаємо оператори SQL вставки, оновлення та видалення в озері даних.
Перейдіть до консолі Athena і виберіть Запит-редактор. Якщо ви вперше використовуєте редактор запитів Athena, вам потрібно це зробити налаштувати розташування результатів запиту щоб бути сегментом S3, який ви створили раніше. Ви повинні бачити, що таблиця reviews.all_reviews доступна для запитів. Виконайте такий запит, щоб переконатися, що ви успішно завантажили таблицю Iceberg:
Обробляйте додаткові дані, виконуючи оператори вставки, оновлення та видалення SQL:
Налаштування продуктивності
У цьому розділі ми розглянемо різні способи покращення продуктивності читання та запису Apache Iceberg.
Налаштуйте властивості таблиці Apache Iceberg
Apache Iceberg — це формат таблиці, який підтримує властивості таблиці для налаштування поведінки таблиці, як-от читання, запис і каталог. Ви можете покращити продуктивність читання та запису в таблицях Iceberg, налаштувавши властивості таблиці.
Наприклад, якщо ви помітили, що ви записуєте занадто багато малих файлів для таблиці Iceberg, ви можете налаштувати розмір файлу для запису, щоб записувати менше, але файли більшого розміру, щоб покращити продуктивність запитів.
властивість | дефолт | Опис |
write.target-file-size-bytes | 536870912 (512 Мб) | Контролює розмір файлів, згенерованих для цільової приблизно такої кількості байтів |
Використовуйте такий код, щоб змінити формат таблиці:
Розбиття та сортування
Щоб запит виконувався швидше, чим менше даних буде прочитано, тим краще. Iceberg використовує багаті метадані, які він збирає під час запису, і полегшує такі методи, як планування сканування, розділення, скорочення та статистичні дані на рівні стовпців, такі як мінімальні та максимальні значення, щоб пропускати файли даних, які не мають відповідних записів. Ми розповімо вам, як працюють планування сканування запитів і розділення в Iceberg і як ми використовуємо їх для покращення продуктивності запитів.
Планування сканування запитів
Для певного запиту першим кроком у системі запитів є планування сканування, тобто процес пошуку файлів у таблиці, необхідних для запиту. Планування в таблиці Iceberg є дуже ефективним, оскільки багаті метадані Iceberg можна використовувати для скорочення файлів метаданих, які не потрібні, на додаток до фільтрації файлів даних, які не містять відповідних даних. Під час наших тестів ми спостерігали, як Athena сканувала 50% або менше даних для певного запиту в таблиці Iceberg порівняно з вихідними даними перед перетворенням у формат Iceberg.
Існує два види фільтрації:
- Фільтрація метаданих – Iceberg використовує два рівні метаданих для відстеження файлів у знімку: список маніфесту та файли маніфесту. Спочатку використовується список маніфесту, який діє як індекс файлів маніфесту. Під час планування Iceberg фільтрує маніфести, використовуючи діапазон значень розділу в списку маніфестів, не читаючи всі файли маніфесту. Потім він використовує вибрані файли маніфесту для отримання файлів даних.
- Фільтрація даних – Після вибору списку файлів маніфесту Iceberg використовує дані розділу та статистичні дані на рівні стовпців для кожного файлу даних, що зберігається у файлах маніфесту, для фільтрації файлів даних. Під час планування предикати запиту перетворюються на предикати даних розділу та спочатку застосовуються до файлів даних фільтра. Потім статистичні дані стовпця, такі як підрахунок значень на рівні стовпця, нульовий підрахунок, нижні та верхні межі, використовуються для фільтрування файлів даних, які не можуть відповідати предикату запиту. Використовуючи верхню та нижню межі для фільтрації файлів даних під час планування, Iceberg значно покращує продуктивність запитів.
Розбиття та сортування
Розбиття — це спосіб письмово згрупувати записи з однаковими значеннями ключових стовпців. Перевагою розділення є швидші запити, які отримують доступ лише до частини даних, як пояснювалося раніше в плануванні сканування запитів: фільтрація даних. Iceberg спрощує розділення, підтримуючи приховане розділення, таким чином, як Iceberg створює значення розділу, беручи значення стовпця та необов’язково перетворюючи його.
У нашому випадку використання ми спочатку виконуємо наступний запит для таблиці Iceberg, яка не розділена. Потім ми розділяємо таблицю Iceberg за категоріями відгуків, які використовуватимуться в умові запиту WHERE для фільтрації записів. З розділенням запит може сканувати набагато менше даних. Перегляньте наступний код:
Щоб побачити різницю в продуктивності, виконайте наведений нижче оператор select для нероздільної таблиці all_reviews і розділеної таблиці:
У наведеній нижче таблиці показано підвищення продуктивності розділення даних: приблизно на 50% підвищення продуктивності та 70% менше сканованих даних.
Назва набору даних | Нерозділений набір даних | Розділений набір даних |
Час виконання (секунди) | 8.20 | 4.25 |
Відскановані дані (МБ) | 131.55 | 33.79 |
Зауважте, що час виконання – це середній час виконання з кількома запусками в нашому тесті.
Ми побачили значне підвищення продуктивності після розділення. Однак це можна ще покращити, використовуючи статистичні дані на рівні стовпця з файлів маніфесту Iceberg. Щоб ефективно використовувати статистичні дані на рівні стовпця, ви хочете додатково відсортувати свої записи на основі шаблонів запиту. Сортування всього набору даних за допомогою стовпців, які часто використовуються в запитах, змінить порядок даних таким чином, що кожен файл даних матиме унікальний діапазон значень для певних стовпців. Якщо ці стовпці використовуються в умові запиту, це дозволяє механізмам запитів пропускати файли даних, тим самим уможливлюючи ще швидші запити.
Копіювання під час запису проти читання після злиття
Під час реалізації оновлення та видалення таблиць Iceberg в озері даних є два підходи, визначені властивостями таблиці Iceberg:
- Копіювати-записувати – Завдяки такому підходу, коли в таблицю Iceberg вносяться зміни, оновлення чи видалення, файли даних, пов’язані з постраждалими записами, дублюються й оновлюються. Записи буде оновлено або видалено з дубльованих файлів даних. Буде створено новий знімок таблиці Iceberg із посиланням на новішу версію файлів даних. Це робить загальний запис повільнішим. Можуть виникнути ситуації, коли потрібен одночасний запис із конфліктами, тому потрібно повторити спробу, що ще більше збільшує час запису. З іншого боку, під час зчитування даних не потрібна додаткова процедура. Запит отримає дані з останньої версії файлів даних.
- Злиття при читанні – Завдяки такому підходу, коли в таблиці Iceberg є оновлення або видалення, існуючі файли даних не будуть перезаписані; замість цього буде створено нові файли видалення для відстеження змін. Для видалення буде створено новий файл видалення з видаленими записами. Під час читання таблиці Iceberg файл видалення буде застосовано до отриманих даних, щоб відфільтрувати видалені записи. Для оновлень буде створено новий файл видалення, щоб позначити оновлені записи як видалені. Потім для цих записів буде створено новий файл, але з оновленими значеннями. Під час читання таблиці Iceberg як видалення, так і нові файли будуть застосовані до отриманих даних, щоб відобразити останні зміни та отримати правильні результати. Отже, для будь-яких наступних запитів відбудеться додатковий крок для об’єднання файлів даних із видаленням і новими файлами, що зазвичай збільшує час запиту. З іншого боку, запис може бути швидшим, оскільки немає потреби переписувати існуючі файли даних.
Щоб перевірити вплив двох підходів, ви можете запустити такий код, щоб налаштувати властивості таблиці Iceberg:
Запустіть оператори SQL update, delete і select в Athena, щоб показати різницю часу виконання для копіювання під час запису та злиття при читанні:
У наведеній нижче таблиці підсумовано час виконання запиту.
Запит | Copy-on-Write | Злиття при читанні | ||||
ОНОВЛЕННЯ | DELETE | ВИБІР | ОНОВЛЕННЯ | DELETE | ВИБІР | |
Час виконання (секунди) | 66.251 | 116.174 | 97.75 | 10.788 | 54.941 | 113.44 |
Відскановані дані (МБ) | 494.06 | 3.07 | 137.16 | 494.06 | 3.07 | 137.16 |
Зауважте, що час виконання – це середній час виконання з кількома запусками в нашому тесті.
Як показують результати наших тестів, у двох підходах завжди є компроміси. Який підхід використовувати залежить від ваших випадків використання. Підводячи підсумок, міркування зводяться до затримки читання чи запису. Ви можете ознайомитися з наступною таблицею і зробити правильний вибір.
. | Copy-on-Write | Злиття при читанні |
профі | Швидше читає | Швидше пише |
мінуси | Дорого пише | Вища затримка під час читання |
Коли використовувати | Добре підходить для частих читань, нечастих оновлень і видалень або великих пакетних оновлень | Добре підходить для таблиць із частими оновленнями та видаленнями |
Ущільнення даних
Якщо розмір вашого файлу даних невеликий, ви можете отримати тисячі чи мільйони файлів у таблиці Iceberg. Це значно збільшує кількість операцій вводу-виводу та сповільнює виконання запитів. Крім того, Iceberg відстежує кожен файл даних у наборі даних. Більше файлів даних призводить до більшої кількості метаданих. Це, у свою чергу, збільшує накладні витрати та операції введення/виведення під час читання файлів метаданих. Щоб покращити продуктивність запитів, рекомендується стискати невеликі файли даних у більші файли даних.
Під час оновлення та видалення записів у таблиці Iceberg, якщо використовується підхід читання після злиття, ви можете отримати багато невеликих видалень або нових файлів даних. Запущене стиснення об’єднає всі ці файли та створить нову версію файлу даних. Це усуває необхідність узгоджувати їх під час читання. Рекомендується регулярно виконувати завдання стиснення, щоб якомога менше впливати на читання, зберігаючи при цьому вищу швидкість запису.
Виконайте наступну команду стиснення даних, а потім запустіть запит на вибірку з Athena:
У наведеній нижче таблиці порівнюється час виконання до та після стиснення даних. Ви можете побачити приблизно 40% покращення продуктивності.
Запит | Перед стисненням даних | Після стиснення даних |
Час виконання (секунди) | 97.75 | 32.676 секунд: |
Відскановані дані (МБ) | 137.16 M | 189.19 M |
Зверніть увагу, що запити на вибір виконувалися на all_reviews
таблиця після операцій оновлення та видалення, до та після стиснення даних. Час виконання – це середній час виконання з кількома запусками в нашому тесті.
Прибирати
Після того, як ви дотримуєтеся покрокового керівництва рішення, щоб виконати сценарії використання, виконайте такі кроки, щоб очистити свої ресурси та уникнути подальших витрат:
- Перемістіть таблиці та базу даних AWS Glue з Athena або запустіть такий код у своєму блокноті:
- На консолі EMR Studio виберіть Робочі області у навігаційній панелі.
- Виберіть робочу область, яку ви створили, і виберіть видаляти.
- На консолі EMR перейдіть до студії стр.
- Виберіть студію, яку ви створили, і виберіть видаляти.
- На консолі EMR виберіть Кластери у навігаційній панелі.
- Виберіть кластер і виберіть Припинити.
- Видаліть сегмент S3 та будь-які інші ресурси, які ви створили як частину передумов для цієї публікації.
Висновок
У цій публікації ми представили структуру Apache Iceberg і те, як вона допомагає вирішити деякі проблеми, які виникають у сучасному озері даних. Потім ми ознайомили вас із рішенням для обробки додаткових даних в озері даних за допомогою Apache Iceberg. Нарешті, ми глибоко занурилися в налаштування продуктивності, щоб покращити продуктивність читання та запису для наших випадків використання.
Ми сподіваємося, що ця публікація надасть вам корисну інформацію, щоб вирішити, чи хочете ви використовувати Apache Iceberg у своєму рішенні озера даних.
Про авторів
Флора Ву є старшим постійним архітектором в AWS Data Lab. Вона допомагає корпоративним клієнтам створювати стратегії аналізу даних і створювати рішення для прискорення результатів їхнього бізнесу. У вільний час вона любить грати в теніс, танцювати сальсу та подорожувати.
Даніель Лі є старшим архітектором рішень у Amazon Web Services. Він зосереджується на допомозі клієнтам розробляти, адаптувати та впроваджувати хмарні сервіси та стратегію. Коли не працює, він любить проводити час на природі з сім’єю.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. Доступ тут.
- джерело: https://aws.amazon.com/blogs/big-data/use-apache-iceberg-in-a-data-lake-to-support-incremental-data-processing/
- 10
- 100
- 11
- 2022
- 2023
- 7
- 9
- a
- Здатний
- МЕНЮ
- вище
- прискорювати
- доступ
- управління доступом
- дію
- акти
- доповнення
- Додатковий
- адреса
- адреси
- Додає
- прийняти
- Перевага
- після
- проти
- ВСІ
- дозволяє
- завжди
- Amazon
- Amazon EMR
- Amazon Web Services
- Аналітичний
- аналітика
- та
- оголошений
- Apache
- застосування
- прикладної
- підхід
- підходи
- відповідний
- архітектура
- асоційований
- Authentication
- наявність
- доступний
- середній
- уникнути
- AWS
- Клей AWS
- заснований
- оскільки
- ставати
- перед тим
- користь
- Краще
- між
- більший
- Bootstrap
- будувати
- Створюємо
- підприємства
- захвати
- захопивши
- випадок
- випадків
- каталог
- каталоги
- Категорія
- проблеми
- зміна
- Зміни
- перевірка
- вибір
- Вибирати
- класифікація
- хмара
- хмарні сервіси
- кластер
- код
- Колонка
- Колони
- об'єднувати
- Приходити
- commit
- порівняний
- повний
- обчислення
- одночасно
- стан
- конфігурації
- міркування
- Консоль
- Перетворення
- перероблений
- рентабельним
- витрати
- може
- створювати
- створений
- створює
- Куратор
- Поточний
- клієнт
- Клієнти
- танці
- приладова панель
- дані
- Analytics даних
- Озеро даних
- обробка даних
- сховище даних
- Database
- набори даних
- глибокий
- глибоке занурення
- дефолт
- певний
- Демонстрація
- демонструвати
- залежить
- призначений
- деталі
- розвивати
- розробка
- різниця
- різний
- обговорювати
- Не знаю
- вниз
- різко
- Падіння
- під час
- кожен
- Раніше
- Рано
- редактор
- фактично
- ефективний
- або
- Усуває
- включений
- дозволяє
- закінчується
- двигун
- Двигуни
- Що натомість? Створіть віртуальну версію себе у
- підприємство
- корпоративні клієнти
- Ефір (ETH)
- Навіть
- еволюція
- еволюціонувати
- еволюціонує
- приклад
- існуючий
- існує
- пояснені
- Розширення
- додатково
- полегшує
- сім'я
- ШВИДКО
- швидше
- риси
- Рисунок
- філе
- Файли
- фільтрувати
- фільтрація
- Фільтри
- в кінці кінців
- знайти
- Перший
- перший раз
- фокусується
- стежити
- після
- формат
- Рамки
- частий
- від
- далі
- Крім того
- Загальне
- генерується
- отримати
- даний
- йде
- добре
- значно
- Group
- рука
- траплятися
- допомога
- допомогу
- допомагає
- прихований
- ієрархія
- на вищому рівні
- висока продуктивність
- високопродуктивний
- Вулик
- надія
- Як
- How To
- Однак
- HTML
- HTTPS
- IAM
- Особистість
- управління ідентифікацією та доступом
- Impact
- вплив
- здійснювати
- реалізація
- реалізації
- удосконалювати
- поліпшений
- поліпшення
- поліпшується
- in
- У тому числі
- Augmenter
- збільшений
- Збільшує
- індекс
- індивідуальний
- інформація
- встановлювати
- замість
- інтеграція
- введені
- Ізоляти
- IT
- січня
- Джобс
- ключ
- lab
- озеро
- великий
- більше
- Затримка
- останній
- останній випуск
- шар
- шарів
- вести
- рівні
- МЕЖА
- Лінія
- список
- трохи
- загрузка
- розташування
- зробити
- РОБОТИ
- управління
- багато
- позначити
- ринку
- матч
- узгодження
- Злиття
- метадані
- може бути
- мільйони
- сучасний
- більше
- рухатися
- множинний
- ім'я
- Названий
- Переміщення
- навігація
- Необхідність
- необхідний
- потреби
- Нові
- ноутбук
- об'єкт
- відкрити
- операція
- операції
- оптимізація
- Оптимізувати
- порядок
- оригінал
- Інше
- на відкритому повітрі
- загальний
- власний
- pane
- частина
- шлях
- моделі
- виконувати
- продуктивність
- фізичний
- планування
- plato
- Інформація про дані Платона
- PlatoData
- ігри
- підключати
- точок
- популярний
- це можливо
- пошта
- Харчування
- передумови
- Процедури
- процес
- обробка
- виробляти
- властивості
- власність
- забезпечувати
- забезпечує
- забезпечення
- забезпечення
- діапазон
- Сировина
- необроблені дані
- Читати
- читання
- реальний
- нещодавно
- рекомендований
- облік
- відображати
- регіон
- регістри
- регулярний
- звільнити
- випущений
- решті
- вимагається
- Вимагається
- ресурси
- результат
- результати
- Відгуки
- Багаті
- Роль
- корінь
- прогін
- біг
- то ж
- сканування
- seconds
- розділ
- безпеку
- обраний
- вибирає
- Без сервера
- обслуговування
- Послуги
- Сесія
- комплект
- набори
- установка
- налаштування
- Повинен
- Показувати
- Шоу
- простий
- ситуацій
- Розмір
- сповільнюється
- невеликий
- Знімок
- So
- Софтвер
- рішення
- Рішення
- деякі
- Іскритися
- конкретний
- швидкість
- Витрати
- SQL
- Починаючи
- стан
- Заява
- заяви
- статистика
- Крок
- заходи
- Як і раніше
- зберігання
- зберігати
- зберігати
- магазинів
- стратегії
- Стратегія
- структурований
- структуровані та неструктуровані дані
- студія
- підмережі
- наступні
- Успішно
- такі
- достатній
- РЕЗЮМЕ
- підтримка
- Підтриманий
- Підтримуючий
- Опори
- таблиця
- приймає
- взяття
- Мета
- завдання
- методи
- теніс
- тест
- Тестування
- Тести
- Команда
- інформація
- Держава
- їх
- тим самим
- тисячі
- три
- через
- час
- подорож у часі
- до
- разом
- занадто
- інструменти
- топ
- Усього:
- трек
- Transactions
- перетворення
- подорожувати
- Подорож
- ПЕРЕГЛЯД
- Типи
- при
- створеного
- Оновити
- оновлений
- Updates
- оновлення
- URL
- використання
- використання випадку
- користувачі
- зазвичай
- VAL
- значення
- Цінності
- перевірити
- версія
- пішов
- покрокове керівництво
- Склад
- годинник
- способи
- Web
- веб-сервіси
- Що
- Чи
- який
- в той час як
- широкий
- Широкий діапазон
- волі
- без
- Work
- робочий
- працює
- б
- запис
- лист
- вашу
- зефірнет