Logo
TGCATALOG
Catálogo Selecciones Blog
rzv Data Engineering - data eng

rzv Data Engineering - data eng

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

Sin valoraciones
8
08.09.2026
8
08.09.2026
Sin valoraciones
8
08.09.2026
Redirección segura vía bot
О канале

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

Подписчиков 2,997
Тематика Tecnología
Язык Español
Ссылка t.me/rzv_de

También te recomendamos

Kekaton AI  Voz en off y clon de voz
Kekaton AI Voz en off y clon de voz
Bot

bot de IA para clonar texto a voz y voz en Telegram. Cree audio utilizando la red neuronal de forma rápida y fácil.

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

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

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

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

Últimas publicaciones

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
Evolución de suscriptores
+0.0% últimos 30 días
Actuales
2,997
Hace un mes
2,996
Crecimiento medio
+0 / día
Actualizado
hace 1 hora

Reseñas de canal rzv Data Engineering - data eng

Inicia sesión para dejar una reseña

Solo los usuarios registrados pueden compartir su opinión.

Aún no hay reseñas

¡Sé el primero en compartir tu experiencia con este recurso!

Recursos similares

Actualizaciones paraRedmiNote 9 Pro Global: firmware, noticias y soporte

Canal

Jem Channel comparte pensamientos sobre la vida en los postes de la Atmósfera de la 'Pequeña Era Oscura' con un toque de melancolía y profundas percepciones.

Canal

Canal de noticias polacoKuCoin. Actualizaciones, eventos e información actualizada sobre el intercambio.

Canal
Cambiar a tema claro
Inicio Catálogo Selecciones Blog Entrar