Logo
TGCATALOG
Catalog Collections Blog
rzv Data Engineering - data eng

rzv Data Engineering - data eng

Авторский канал о инжиниринге данных: термины, практики, задачи. Для новичков и инженеров до senior уровня.

No ratings
12
09.09.2026
12
09.09.2026
No ratings
12
09.09.2026
Safe redirect via bot
О канале

Авторский канал о инжиниринге данных: термины, практики, задачи. Для новичков и инженеров до senior уровня.

Подписчиков 2,997
Тематика Technology
Язык English
Ссылка t.me/rzv_de

We also recommend

Kekaton AI | Voiceover and voice clone
Kekaton AI | Voiceover and voice clone
Bot

AI bot for text-to-speech and voice cloning in Telegram. Create audio using neural network quickly and easily.

Description
📊 rzv Data Engineering - авторский канал, где разбираются основы и нюансы инжиниринга данных. Простые объяснения терминов, лучшие практики и реальные рабочие задачи помогают освоить профессию шаг за шагом. 🔧 Контент ориентирован на новичков в data engineering и специалистов до senior. От ETL-проц...Read More ↓Description ↑

📊 rzv Data Engineering - авторский канал, где разбираются основы и нюансы инжиниринга данных. Простые объяснения терминов, лучшие практики и реальные рабочие задачи помогают освоить профессию шаг за шагом.

🔧 Контент ориентирован на новичков в data engineering и специалистов до senior. От ETL-процессов и хранилищ данных до оптимизации пайплайнов – всё с примерами и советами для практики.

💡 Закрепленные посты служат отличным стартом: гайды по инструментам вроде Airflow, Spark и BigQuery. Канал развивает навыки через понятные разборы, делая сложные темы доступными для самостоятельного изучения.

Latest posts

rzv Data Engineering - data eng
rzv Data Engineering - data eng
🔒Открыть пост
и посмотреть медиа
Опыт миграции небольшого стека с Docker compose на Kubernetes 4/4 🔸 Что это даёт, по крайней мере для меня Прежде всего - интеграцию с готовой платформой для "прогерских лабораторных работ", где k8s-манифесты это пререквизит Возможность горизонтального масштабирования за пределы одной ВМ на будущее Более удобный способ из одного контейнера управлять состоянием другого, например для сервиса выдачи доступов (в docker-compose стеке есть bind-mount /var/run/docker.sock, но идёт вместе с уязвимостью в виде root права на запуск любых контейнеров) 🔸Выводы Для собственных проектов пока всё ещё не вижу смысла в k8s, как ни пытаюсь разглядеть. Всё в конечном итоге запускается на виртуальных машинах, за которые платишь. Даже в managed сервисе вроде "yandex cloud managed k8s" идёт отдельная аренда за месяц CPU/RAM/disk конкретных ВМ. Пока продолжаю всей душой любить Docker compose. Поделитесь в комментах, если есть удачный опыт переноса проектов на кубер, кроме случаев когда это кластеры на десятки ВМ. Я с интересом почитаю)
rzv Data Engineering - data eng
rzv Data Engineering - data eng
🔒Открыть пост
и посмотреть медиа
Опыт миграции небольшого стека с Docker compose на Kubernetes 2/4 Что стало на k8s 🔸 Во-первых, сколько абстракций добавилось: - Deployment — чтобы кластер сам следил за нужным состоянием пода - Secret — API-объект с RBAC-управлением доступами на чтение и живой ротацией без передеплоя - Service — чтобы у пода был стабильный сетевой адрес: свой внутренний IP он теряет при каждом пересоздании - Ingress — чтобы к сервису можно было подключиться снаружи; по умолчанию кластер находится в полностью изолированном окружении "без окон и дверей" - ConfigMap — набор key-value пар параметров 🔸 Во-вторых, какие строчки конфига во что превратились: - image / container_name -> Deployment, containers[].image — без изменений - depends_on -> нативного аналога нет, приходится писать небольшой initContainer, который сам проверяет, что сервис-зависимость запущен и можно стартовать текущий - сеть по имени контейнера -> Service — обязательный отдельный объект, потому что у пода нет постоянного IP; адресация теперь по label-селектору, т.к. подов по умолчанию больше одного - открытые ports -> Service.ports + Ingress — тот же объём работы, что раньше делал nginx вне compose, просто теперь это объект кластера, а не отдельный конфиг на хосте - restart: healthcheck -> readinessProbe / livenessProbe с тем же смыслом - environment -> Secret - лимиты ресурсов железа -> resources.requests/limits — выглядит похоже, влияет на выбор планировщика "куда размещать новый под при масштабировании" - отдельные .config, .properties для Trino -> универсальные ConfigMap key-value файлы Для запуска использую облегчённую версию k3s на одной ВМ. Deployment: apiVersion: apps/v1 kind: Deployment metadata: name: trino spec: replicas: 1 selector: matchLabels: app: trino template: metadata: labels: app: trino spec: initContainers: - name: wait-for-hive-metastore image: busybox:1.36 command: ["sh", "-c", "until nc -z hive-metastore 9083; do sleep 2; done"] containers: - name: trino image: trinodb/trino:483 env: - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: minio-credentials key: access-key - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: minio-credentials key: secret-key ports: - containerPort: 8080 resources: requests: cpu: 250m memory: 2Gi limits: memory: 3Gi readinessProbe: httpGet: path: /v1/info port: 8080 initialDelaySeconds: 15 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 30 volumeMounts: - name: trino-etc mountPath: /etc/trino/config.properties subPath: config.properties - name: trino-etc mountPath: /etc/trino/jvm.config subPath: jvm.config - name: trino-catalog mountPath: /etc/trino/catalog/iceberg.properties subPath: iceberg.properties volumes: - name: trino-etc configMap: name: trino-etc - name: trino-catalog configMap: name: trino-catalog Он ссылается на Secret через secretKeyRef, значит нужен и такой объект: apiVersion: v1 kind: Secret metadata: name: minio-credentials type: Opaque stringData: access-key: secret-key: Дальше — Service: apiVersion: v1 kind: Service metadata: name: trino spec: selector: app: trino ports: - port: 8080 targetPort: 8080
rzv Data Engineering - data eng
rzv Data Engineering - data eng
🔒Открыть пост
и посмотреть медиа
Опыт миграции небольшого стека с Docker compose на Kubernetes 3/4 Отдельно — Ingress: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: trino spec: rules: - host: trino.example.com http: paths: - path: / pathType: Prefix backend: service: name: trino port: number: 8080 И отдельно — 2 ConfigMap вместо папки ./trino/etc: apiVersion: v1 kind: ConfigMap metadata: name: trino-etc data: config.properties: | coordinator=true node-scheduler.include-coordinator=true http-server.http.port=8080 discovery.uri=Ссылка скрыта jvm.config: | -server -Xmx2G -XX:+ExitOnOutOfMemoryError node.properties: | node.environment=lab node.id=trino-lab-1 ... Итого на стороне k8s: 6 объектов (Deployment, Secret, Service, Ingress, 2 ConfigMap), около 230 строк. 150 против 230, 2+7 файлов с описанием инфры против 6 объектов. В k8s нужно больше конфигурации на тот же набор параметров, потому что в k8s эти параметры обязательны и оформлены отдельными объектами. В Docker compose они описываются опциональными полями внутри одного сервиса.
rzv Data Engineering - data eng
Subscriber dynamics
+0.0% last 30 days
Current
2,997
Month ago
2,996
Average growth
+0 / day
Updated
3 hours ago

Reviews for channel rzv Data Engineering - data eng

Log in to leave a review

Only registered users can share their opinion.

No reviews yet

Be the first to share your impression of this resource!

Similar resources

Fan channel about equipment and gadgets. Reviews and news.

Channel
36

ArchivesZIPfiles: sounds, design, fonts and motion graphics.

Channel
157

Useful courses and lessons on working with raster and vector graphics in Telegram.

Channel
Switch to Light Theme
Home Catalog Collections Blog Login