перше що зробила, прийшовши в нову компанію, описала колонки в основних таблицях: як пишуться, коли пишуться, коли можуть мінятись. Просто тому що задовбалась питати у розобників по кожному окремо. Бо раніше ці метадані були коментами в коді і всі просто в якийсь момент звикали як воно є ) Документація у невеликих командах здається просто злом, бо всі завжди в контексті всього, але насправді це дуже необхідне зло, бо контекст якраз швидко міняється і повернутись до попереднього контектсу часто ще той челендж.
Дякую) Так само проходив через це і повністю погоджуюсь))) Але додав ще від себе, що я трошки пішов в фанатизм. Наприклад, зберігав скріншоти pipelines, документував кожну таблицю та колонку тощо. Справа в тому, що все це швидко змінюється, і моя документація була не релевантна вже за місяць. Отже, чим складніша структура документації (це й про метадані) - ти важче вона обслуговується. Тому сьогодні я більш стриманий в бажанні описати все)))
Дякую за таку живу і необхідну інформацію. Питання, як знайти оптимальний мінімум для вивчення щоб отримати перший офер? Наприклад, яке рішення може бути щодо кількості вивчення функцій в GSheets? Мабуть, як варіант, вміння швидко знаходити необхідну використовуючи нейромережі?
Нікіта, дуже цікавить як ви збираєте та зберігаєте данні. Для мене це стало проблемою. Адже частина даних зберігається на особистих комп'ютерах співробітників, а OneDrive в нас не має. Спробувала викласти на Google Drive частину таблиць і зіткнулася з тим, що вони прям дуже туплять на комп'ютерах з віндою і літають на аппл. Виходить, що таблиці треба різати на маленькі шматочки, але як їх потім зливати в одну велику базу данних , що буде дописувати, а не наново об'єднувати всі файли у таці? Архітекторів баз даних в нас не має, щоб проконсультуватися 😢
Вітаю! Я проектую сховища даних, і кожну ніч у мене автоматично виконуються процеси оновлення таких даних. Але це потребує роботи інженера даних. Не можу підказати, на жаль, яке рішення в вашому випадку буде доцільним, адже все залежить від обсягів даних, доступності та приватности даних та багатьох інших факторів.
Может быть указано, кто добавил данные, в какое время, источник данных, кто последний выгружал эти данные, какой размер данных, формат данных и так далее
Так) Бачу, що недопрацював) Я завжди посилаюсь на визначення метадані - дані про дані, з цим легше сприймається) Але це не тільки опис того, що знаходиться в даних (навпаки, не так часто дані описуються), а як раз контекст навколо цих даних. Як часто оновлюються, які є доступи, джерело даних, подальший рух цих даних тощо)
@@ion_labинформацию о доступах к данным я например использовала когда работала в data governance team, чтобы понять кто читает данные: user или service account
@@ion_lab так, трошки не допрацював. Але тема дуже цікава й неймовірно складна. Замало сказати що мета це то що описує (дуже гарне за погляду контексту) . Чекаємо на продовження та розвиток.
![Нікіта Тимошенко [ Аналіз даних українською ]](http://yt3.ggpht.com/5bKDOrZon5pgQPUNOVAeKD6_zCefdaI1T_tQG6eeEpwqktMO5t_S_FDd7TqhyPD2nhRE_3Wk4A=s48-c-k-c0x00ffffff-no-rj)
Дякую за легку подачу інформації. Вас приємно слухати.
Дякую, Нікіто, за відео. Цікаво і корисно. Я ніколи раніше не чув визначення метаданих, тепер все стало зрозуміло.
перше що зробила, прийшовши в нову компанію, описала колонки в основних таблицях: як пишуться, коли пишуться, коли можуть мінятись. Просто тому що задовбалась питати у розобників по кожному окремо. Бо раніше ці метадані були коментами в коді і всі просто в якийсь момент звикали як воно є ) Документація у невеликих командах здається просто злом, бо всі завжди в контексті всього, але насправді це дуже необхідне зло, бо контекст якраз швидко міняється і повернутись до попереднього контектсу часто ще той челендж.
Дякую) Так само проходив через це і повністю погоджуюсь))) Але додав ще від себе, що я трошки пішов в фанатизм. Наприклад, зберігав скріншоти pipelines, документував кожну таблицю та колонку тощо. Справа в тому, що все це швидко змінюється, і моя документація була не релевантна вже за місяць. Отже, чим складніша структура документації (це й про метадані) - ти важче вона обслуговується. Тому сьогодні я більш стриманий в бажанні описати все)))
о так, розумію. зараз теж подивилась в ті таблиці річної давнини і ... треба перероблювати) @@ion_lab
Дякую за Вашу наполегливу працю над створенням дійсно корисного україномовного контенту!
Дякую Нікіто. Раніше зустрічала ці назви, але поки що не дійшла щоб знайти нюанси різниці. Тепер все більш зрозуміло. Цікаво!!
Дякую за цікавий ролик! Дуже приємний та легкий для сприйняття формат.
Микита - найкращий! Дякую!
цікаво, і класна манера викладання. Гарна вимова. Дякую
Вітаю, дякую за доступність та лаконічність 🤗
Дякую за відгук)
Дякую за ваші відео!
Микито, дякую за цю тему. Розуміти та коректно оперувати рівнями абстракції при роботі з даними дуже корисно
Повністю погоджуюся)
Стильно та зі смаком. Дякую за контент
Дякую вам за відео 🤗 хочу опанувати нову професію і дуже цікавить дата аналіз)
Я повністю розділяю вашу любов до даних) Удачі! Буду радий допомогти)
Дякую
❤️🔥❤️🔥❤️🔥
👌👌👌
Дякую за контект!! Зрозуміло та по ділу!)
Доволі інформативно і корисно.
Дякую, цікаво та корисно!
Дякую
Дякую за вашу роботу
Дякую за цікавий ролик!)
Було цікаво)
дякую!
👍👍👍👍👍👍👍👍
Дякую за таку живу і необхідну інформацію. Питання, як знайти оптимальний мінімум для вивчення щоб отримати перший офер? Наприклад, яке рішення може бути щодо кількості вивчення функцій в GSheets? Мабуть, як варіант, вміння швидко знаходити необхідну використовуючи нейромережі?
У вас новий формат?) Чекатиму на продовження цієї серії!
Нікіта, дуже цікавить як ви збираєте та зберігаєте данні. Для мене це стало проблемою. Адже частина даних зберігається на особистих комп'ютерах співробітників, а OneDrive в нас не має. Спробувала викласти на Google Drive частину таблиць і зіткнулася з тим, що вони прям дуже туплять на комп'ютерах з віндою і літають на аппл. Виходить, що таблиці треба різати на маленькі шматочки, але як їх потім зливати в одну велику базу данних , що буде дописувати, а не наново об'єднувати всі файли у таці? Архітекторів баз даних в нас не має, щоб проконсультуватися 😢
Вітаю! Я проектую сховища даних, і кожну ніч у мене автоматично виконуються процеси оновлення таких даних. Але це потребує роботи інженера даних. Не можу підказати, на жаль, яке рішення в вашому випадку буде доцільним, адже все залежить від обсягів даних, доступності та приватности даних та багатьох інших факторів.
Чесно, толком не зрозумів. То метадані це опис даних, що в них знаходиться, щоб було зрозуміло користувачу при роботі з даними?
Может быть указано, кто добавил данные, в какое время, источник данных, кто последний выгружал эти данные, какой размер данных, формат данных и так далее
Так) Бачу, що недопрацював) Я завжди посилаюсь на визначення метадані - дані про дані, з цим легше сприймається) Але це не тільки опис того, що знаходиться в даних (навпаки, не так часто дані описуються), а як раз контекст навколо цих даних. Як часто оновлюються, які є доступи, джерело даних, подальший рух цих даних тощо)
@@ion_labинформацию о доступах к данным я например использовала когда работала в data governance team, чтобы понять кто читает данные: user или service account
@@ion_lab так, трошки не допрацював. Але тема дуже цікава й неймовірно складна. Замало сказати що мета це то що описує (дуже гарне за погляду контексту) . Чекаємо на продовження та розвиток.
Дякую!