大数据环境下数据仓库的容器化部署

大数据环境下数据仓库的容器化部署

关键词:大数据、数据仓库、容器化、Docker、Kubernetes、微服务架构、云原生
摘要:本文深入探讨了在大数据环境下如何将传统数据仓库系统进行容器化部署的完整解决方案。文章首先介绍了大数据和数据仓库的基本概念,然后详细分析了容器化技术的优势及其在数据仓库部署中的应用。接着,我们通过实际案例展示了使用Docker和Kubernetes实现数据仓库容器化的具体步骤和最佳实践。最后,文章讨论了容器化数据仓库面临的挑战和未来发展趋势,为读者提供了全面的技术视角和实践指导。

1. 背景介绍

1.1 目的和范围

随着大数据技术的快速发展和企业数字化转型的加速推进,传统数据仓库系统面临着前所未有的挑战和机遇。本文旨在探讨如何利用容器化技术解决大数据环境下数据仓库部署和管理中的关键问题,包括:

  • 提高资源利用率
  • 简化部署流程
  • 增强系统弹性
  • 实现快速扩展
  • 降低运维成本

本文的范围涵盖从理论到实践的完整容器化数据仓库解决方案,包括技术选型、架构设计、实施步骤和运维管理等方面。

1.2 预期读者

本文适合以下读者群体:

  1. 数据架构师和数据工程师:寻求现代化数据仓库部署方案的专业人士
  2. DevOps工程师:负责大数据平台部署和运维的技术人员
  3. 云计算专家:关注云原生大数据解决方案的从业者
  4. 技术决策者:评估和选择数据仓库技术路线的管理者
  5. 大数据相关专业的学生和研究人员

1.3 文档结构概述

本文采用循序渐进的结构,从基础概念到高级应用,逐步深入探讨数据仓库容器化部署的各个方面:

  1. 背景介绍:建立基本概念和上下文
  2. 核心概念与联系:分析关键技术和架构
  3. 核心算法原理:深入技术细节
  4. 数学模型:提供理论支持
  5. 项目实战:展示完整实施案例
  6. 应用场景:探讨实际应用价值
  7. 工具资源:推荐实用工具和学习资料
  8. 总结展望:分析未来发展趋势

1.4 术语表

1.4.1 核心术语定义

数据仓库(Data Warehouse):面向主题的、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理决策。

容器化(Containerization):一种操作系统虚拟化技术,允许应用程序及其依赖项在资源隔离的进程中运行。

Docker:开源的容器化平台,用于开发、部署和运行应用程序。

Kubernetes:用于自动部署、扩展和管理容器化应用程序的开源系统。

1.4.2 相关概念解释

微服务架构(Microservices Architecture):将单一应用程序划分为一组小型服务的方法,每个服务运行在自己的进程中,服务间采用轻量级机制通信。

云原生(Cloud Native):构建和运行充分利用云计算模型优势的应用程序的方法。

持续集成/持续部署(CI/CD):一种软件开发实践,团队频繁地将代码变更集成到共享存储库中,并通过自动化流程进行构建、测试和部署。

1.4.3 缩略词列表
  • ETL:Extract, Transform, Load (抽取、转换、加载)
  • OLAP:Online Analytical Processing (联机分析处理)
  • OLTP:Online Transaction Processing (联机事务处理)
  • YAML:YAML Ain't Markup Language (一种数据序列化语言)
  • API:Application Programming Interface (应用程序编程接口)

2. 核心概念与联系

2.1 大数据环境下的数据仓库架构演进

传统数据仓库架构在大数据环境下面临诸多挑战:

  1. 扩展性问题:传统架构难以应对数据量的指数级增长
  2. 资源利用率低:固定资源配置导致资源浪费
  3. 部署复杂:依赖特定硬件环境,部署周期长
  4. 维护困难:版本升级和补丁管理复杂

容器化技术为解决这些问题提供了新的思路:
挑战 问题 问题 问题 问题 解决方案 解决方案 解决方案 解决方案 传统数据仓库 大数据环境 扩展性不足 资源利用率低 部署复杂 维护困难 容器化技术

2.2 容器化数据仓库的核心组件

容器化数据仓库系统通常由以下核心组件构成:

  1. 数据存储层:分布式文件系统或对象存储
  2. 计算引擎层:分布式查询处理引擎
  3. 元数据管理层:目录服务和元数据存储
  4. 编排管理层:容器编排和调度系统
  5. 监控告警层:性能监控和异常告警系统

数据源 数据摄取 数据存储层 计算引擎层 元数据管理层 编排管理层 监控告警层 应用层

2.3 容器化与传统部署方式的对比

特性 传统部署 容器化部署
部署速度 慢(小时/天级) 快(分钟级)
资源利用率 低(30-50%) 高(70-90%)
扩展性 垂直扩展为主 水平扩展为主
环境一致性 难以保证 高度一致
隔离性 较弱
迁移难度
运维复杂度

2.4 容器化数据仓库的技术栈选择

构建容器化数据仓库需要考虑以下技术栈:

  1. 容器运行时:Docker, containerd
  2. 编排系统:Kubernetes, Docker Swarm
  3. 存储方案:Persistent Volumes, Ceph, MinIO
  4. 网络方案:Calico, Flannel, Weave Net
  5. 监控方案:Prometheus, Grafana
  6. 日志方案:ELK Stack, Loki

3. 核心算法原理 & 具体操作步骤

3.1 容器化数据仓库的核心算法

3.1.1 资源调度算法

容器编排系统中的资源调度算法对数据仓库性能至关重要。Kubernetes默认调度器使用以下优先级函数:

python 复制代码
def default_priorities():
    return [
        LeastRequestedPriority,  # 选择请求资源最少的节点
        BalancedResourceAllocation,  # 平衡CPU和内存资源
        NodeAffinityPriority,  # 节点亲和性
        TaintTolerationPriority,  # 污点容忍
        SelectorSpreadPriority,  # 服务分散
        InterPodAffinityPriority,  # Pod亲和性
        MostRequestedPriority  # 选择请求资源最多的节点(适合批处理)
    ]
3.1.2 自动扩展算法

Horizontal Pod Autoscaler(HPA)使用的自动扩展算法:

python 复制代码
def calculate_desired_replicas(current_replicas, target_utilization, current_utilization):
    """
    :param current_replicas: 当前Pod副本数
    :param target_utilization: 目标资源利用率(百分比)
    :param current_utilization: 当前资源利用率(百分比)
    :return: 期望的Pod副本数
    """
    return math.ceil(current_replicas * current_utilization / target_utilization)

3.2 数据仓库容器化的具体操作步骤

3.2.1 容器化ETL流程
  1. 抽取阶段容器化
python 复制代码
# 使用Apache NiFi的Dockerfile示例
FROM apache/nifi:latest
COPY flows.xml /opt/nifi/nifi-current/conf/
COPY custom-processors /opt/nifi/nifi-current/lib/
EXPOSE 8080 8443 10000 8000
CMD ["../scripts/start.sh"]
  1. 转换阶段容器化
python 复制代码
# Spark转换作业的Kubernetes部署示例
apiVersion: batch/v1
kind: Job
metadata:
  name: spark-etl-job
spec:
  template:
    spec:
      containers:
      - name: spark
        image: bitnami/spark:latest
        command: ["spark-submit"]
        args: ["--master", "k8s://https://kubernetes.default.svc",
               "--deploy-mode", "cluster",
               "--class", "com.example.ETLJob",
               "local:///opt/spark/jobs/etl.jar"]
      restartPolicy: Never
3.2.2 数据仓库服务容器化
  1. 构建数据仓库镜像
dockerfile 复制代码
# PostgreSQL数据仓库镜像
FROM postgres:13
ENV POSTGRES_PASSWORD=warehouse
ENV POSTGRES_USER=admin
ENV POSTGRES_DB=data_warehouse
COPY init.sql /docker-entrypoint-initdb.d/
EXPOSE 5432
  1. Kubernetes部署配置
yaml 复制代码
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: dw-postgresql
spec:
  serviceName: "dw-postgresql"
  replicas: 3
  selector:
    matchLabels:
      app: dw-postgresql
  template:
    metadata:
      labels:
        app: dw-postgresql
    spec:
      containers:
      - name: postgresql
        image: dw-postgresql:latest
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: dw-data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: dw-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Gi

4. 数学模型和公式 & 详细讲解 & 举例说明

4.1 容器资源分配模型

容器化环境中的资源分配可以通过以下数学模型进行优化:

4.1.1 资源分配优化模型

设集群有 N N N个节点,每个节点 i i i有 C i C_i Ci个CPU核心和 M i M_i Mi GB内存。有 K K K个数据仓库服务,每个服务 k k k需要 c k c_k ck个CPU和 m k m_k mk GB内存。

优化目标是最小化资源浪费:

min ⁡ ∑ i = 1 N ( α ⋅ C i u n u s e d C i + β ⋅ M i u n u s e d M i ) \min \sum_{i=1}^{N} \left( \alpha \cdot \frac{C_i^{unused}}{C_i} + \beta \cdot \frac{M_i^{unused}}{M_i} \right) mini=1∑N(α⋅CiCiunused+β⋅MiMiunused)

约束条件:

∑ k ∈ S i c k ≤ C i ∀ i ∈ 1 , . . . , N \sum_{k \in S_i} c_k \leq C_i \quad \forall i \in 1,...,N k∈Si∑ck≤Ci∀i∈1,...,N

∑ k ∈ S i m k ≤ M i ∀ i ∈ 1 , . . . , N \sum_{k \in S_i} m_k \leq M_i \quad \forall i \in 1,...,N k∈Si∑mk≤Mi∀i∈1,...,N

其中:

  • S i S_i Si是部署在节点 i i i上的服务集合
  • α \alpha α和 β \beta β是CPU和内存的权重系数
  • C i u n u s e d = C i − ∑ k ∈ S i c k C_i^{unused} = C_i - \sum_{k \in S_i} c_k Ciunused=Ci−∑k∈Sick
  • M i u n u s e d = M i − ∑ k ∈ S i m k M_i^{unused} = M_i - \sum_{k \in S_i} m_k Miunused=Mi−∑k∈Simk
4.1.2 示例计算

假设集群有3个节点:

  • 节点1:16CPU, 64GB
  • 节点2:32CPU, 128GB
  • 节点3:64CPU, 256GB

有5个数据仓库服务:

  • 服务A:4CPU, 16GB
  • 服务B:8CPU, 32GB
  • 服务C:16CPU, 64GB
  • 服务D:8CPU, 32GB
  • 服务E:4CPU, 16GB

优化目标是将这些服务分配到节点上,最小化资源浪费。通过求解上述模型,可以得到最优分配方案。

4.2 性能预测模型

容器化数据仓库的查询响应时间可以通过以下模型预测:

T q = T b a s e + ∑ i = 1 n ( S i B i + L i ) + max ⁡ j ∈ J ( D j P j ) T_q = T_{base} + \sum_{i=1}^{n} \left( \frac{S_i}{B_i} + L_i \right) + \max_{j \in J} \left( \frac{D_j}{P_j} \right) Tq=Tbase+i=1∑n(BiSi+Li)+j∈Jmax(PjDj)

其中:

  • T q T_q Tq:查询总响应时间
  • T b a s e T_{base} Tbase:基础开销时间
  • S i S_i Si:第 i i i个阶段的数据大小
  • B i B_i Bi:第 i i i个阶段的带宽
  • L i L_i Li:第 i i i个阶段的延迟
  • D j D_j Dj:第 j j j个并行任务的数据量
  • P j P_j Pj:第 j j j个并行任务的处理能力
  • J J J:并行任务集合

5. 项目实战:代码实际案例和详细解释说明

5.1 开发环境搭建

5.1.1 基础环境准备
  1. 安装Docker
bash 复制代码
# Ubuntu安装示例
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
sudo systemctl enable docker
sudo systemctl start docker
  1. 安装Kubernetes
bash 复制代码
# 使用kubeadm安装
sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
5.1.2 数据仓库组件选择

本项目使用以下组件构建容器化数据仓库:

  • 存储层:MinIO (S3兼容对象存储)
  • 计算引擎:Presto (分布式SQL查询引擎)
  • 元数据:Hive Metastore
  • 编排:Kubernetes
  • 监控:Prometheus + Grafana

5.2 源代码详细实现和代码解读

5.2.1 MinIO容器化部署
  1. Docker Compose配置
yaml 复制代码
version: '3.7'
services:
  minio:
    image: minio/minio:latest
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      MINIO_ROOT_USER: admin
      MINIO_ROOT_PASSWORD: password123
    volumes:
      - minio-data:/data
    command: server /data --console-address ":9001"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
      interval: 30s
      timeout: 20s
      retries: 3

volumes:
  minio-data:
  1. Kubernetes部署
yaml 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  name: minio
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: minio
  template:
    metadata:
      labels:
        app: minio
    spec:
      containers:
      - name: minio
        image: minio/minio:latest
        args:
        - server
        - /storage
        - --console-address
        - ":9001"
        env:
        - name: MINIO_ROOT_USER
          value: "admin"
        - name: MINIO_ROOT_PASSWORD
          value: "password123"
        ports:
        - containerPort: 9000
        - containerPort: 9001
        volumeMounts:
        - name: storage
          mountPath: "/storage"
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: minio-pvc
5.2.2 Presto集群部署
  1. Coordinator Dockerfile
dockerfile 复制代码
FROM prestodb/presto:0.265
COPY etc /usr/lib/presto/etc
USER root
RUN chown -R presto:presto /usr/lib/presto/etc
USER presto
  1. Worker Kubernetes配置
yaml 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  name: presto-worker
spec:
  replicas: 3
  selector:
    matchLabels:
      app: presto
      role: worker
  template:
    metadata:
      labels:
        app: presto
        role: worker
    spec:
      containers:
      - name: presto-worker
        image: presto-worker:latest
        ports:
        - containerPort: 8080
        env:
        - name: PRESTO_IS_COORDINATOR
          value: "false"
        - name: PRESTO_DISCOVERY_URI
          value: "http://presto-coordinator:8080"
        resources:
          limits:
            cpu: "2"
            memory: "8Gi"
          requests:
            cpu: "1"
            memory: "4Gi"

5.3 代码解读与分析

5.3.1 关键配置解析
  1. Presto配置目录结构

    etc/
    ├── catalog/ # 数据源连接配置
    │ ├── hive.properties # Hive连接配置
    │ └── postgresql.properties # PostgreSQL连接配置
    ├── config.properties # 全局配置
    ├── jvm.config # JVM参数
    └── node.properties # 节点特定配置

  2. config.properties关键参数

properties 复制代码
# Coordinator专用配置
coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=8080
query.max-memory=50GB
query.max-memory-per-node=8GB
query.max-total-memory-per-node=10GB
discovery-server.enabled=true
discovery.uri=http://presto-coordinator:8080

# Worker专用配置
coordinator=false
http-server.http.port=8080
query.max-memory-per-node=8GB
query.max-total-memory-per-node=10GB
discovery.uri=http://presto-coordinator:8080
5.3.2 性能优化技巧
  1. 资源限制设置
yaml 复制代码
resources:
  limits:
    cpu: "2"
    memory: "8Gi"
  requests:
    cpu: "1"
    memory: "4Gi"
  • 设置合理的requests和limits可以防止资源争抢
  • CPU requests应设为实际需要的下限
  • 内存limits应设为容器最大可用内存
  1. 亲和性规则
yaml 复制代码
affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - presto
        topologyKey: kubernetes.io/hostname
  • 将Presto worker分散到不同节点提高容错性
  • 避免单节点资源过载

6. 实际应用场景

6.1 电商数据分析平台

场景描述

大型电商平台需要分析用户行为、交易数据和库存信息,支持实时决策和个性化推荐。

容器化解决方案

  1. 数据流架构

用户行为日志 Flink实时处理 交易数据 Kafka消息队列 Spark批处理 实时数据仓库 Presto查询 BI可视化

  1. Kubernetes部署
  • 每个组件作为独立微服务部署
  • 使用HPA实现自动扩展
  • 实时组件和批处理组件隔离部署

6.2 金融风控系统

场景描述

银行需要构建反欺诈系统,实时分析交易模式,检测异常行为。

容器化优势

  1. 快速部署:新规则和模型分钟级部署
  2. 资源隔离:敏感数据处理的独立环境
  3. 弹性扩展:应对交易高峰期的自动扩容

实现方案

yaml 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fraud-detection
spec:
  replicas: 3
  selector:
    matchLabels:
      app: fraud-detection
  template:
    metadata:
      labels:
        app: fraud-detection
    spec:
      containers:
      - name: detection-engine
        image: fraud-detection:1.2.0
        env:
        - name: RISK_THRESHOLD
          value: "0.85"
        resources:
          limits:
            cpu: "1"
            memory: "2Gi"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10

6.3 物联网数据处理

挑战

  • 海量设备产生的时序数据
  • 高写入吞吐量需求
  • 复杂分析查询

容器化方案

  1. 专用时序数据库:TimescaleDB容器化部署
  2. 分层存储
    • 热数据:本地SSD存储
    • 温数据:网络附加存储
    • 冷数据:对象存储
  3. 读写分离
    • 写入专用节点
    • 读取专用节点

7. 工具和资源推荐

7.1 学习资源推荐

7.1.1 书籍推荐
  • 《Kubernetes in Action》 - Marko Luksa
  • 《Designing Data-Intensive Applications》 - Martin Kleppmann
  • 《Data Warehouse Toolkit》 - Ralph Kimball
7.1.2 在线课程
  • Coursera: "Big Data Specialization" (UC San Diego)
  • Udemy: "Docker and Kubernetes: The Complete Guide"
  • edX: "Introduction to Apache Spark" (Berkeley)
7.1.3 技术博客和网站
  • Kubernetes官方博客
  • Docker官方文档
  • Presto官方技术博客
  • Medium上的数据工程专栏

7.2 开发工具框架推荐

7.2.1 IDE和编辑器
  • VS Code with Docker/Kubernetes插件
  • IntelliJ IDEA Ultimate (支持Kubernetes)
  • DataGrip (数据库开发)
7.2.2 调试和性能分析工具
  • kubectl debug (Kubernetes调试)
  • k9s (终端UI)
  • Prometheus + Grafana (监控)
  • Jaeger (分布式追踪)
7.2.3 相关框架和库
  • Apache Airflow (工作流管理)
  • Trino (Presto分支)
  • Apache Iceberg (表格式)
  • Debezium (变更数据捕获)

7.3 相关论文著作推荐

7.3.1 经典论文
  • "Google Borg论文": Omega: flexible, scalable schedulers for large compute clusters
  • "Docker论文": Docker: lightweight Linux containers for consistent development and deployment
7.3.2 最新研究成果
  • "Serverless Data Warehouse" (SIGMOD 2022)
  • "Containerized Analytics at Scale" (VLDB 2023)
7.3.3 应用案例分析
  • Netflix数据平台容器化实践
  • Uber大数据平台Kubernetes迁移经验
  • Airbnb数据仓库现代化案例

8. 总结:未来发展趋势与挑战

8.1 发展趋势

  1. Serverless数据仓库

    • 按使用量计费
    • 无服务器架构
    • 自动弹性扩展
  2. 混合云部署

    • 跨云数据仓库
    • 数据本地化合规
    • 统一管理平面
  3. AI驱动的优化

    • 自动查询优化
    • 智能资源分配
    • 预测性扩展

8.2 技术挑战

  1. 数据本地化要求

    • 合规性约束
    • 跨区域数据同步
    • 延迟敏感应用
  2. 有状态服务管理

    • 数据持久化
    • 状态一致性
    • 备份恢复
  3. 性能调优复杂度

    • 多层缓存策略
    • 网络性能优化
    • 存储I/O瓶颈

8.3 建议与展望

  1. 渐进式迁移策略

    • 从无状态组件开始
    • 逐步迁移核心服务
    • 建立回滚机制
  2. 人才技能培养

    • 容器技术深度掌握
    • 云原生思维培养
    • 跨领域协作能力
  3. 生态系统整合

    • 与CI/CD流水线集成
    • 安全合规框架对接
    • 监控告警统一管理

9. 附录:常见问题与解答

Q1:容器化数据仓库与传统方案相比有哪些优势?

A:主要优势包括:

  1. 更高的资源利用率(70-90% vs 30-50%)
  2. 更快的部署速度(分钟级 vs 小时/天级)
  3. 更好的环境一致性
  4. 更灵活的扩展能力
  5. 更低的迁移成本

Q2:如何处理数据仓库中的有状态服务?

A:有状态服务容器化的关键策略:

  1. 使用持久化卷(Persistent Volumes)存储数据
  2. 采用StatefulSet而不是Deployment
  3. 实现定期的备份和恢复机制
  4. 考虑使用云原生数据库服务

Q3:容器化数据仓库的安全如何保障?

A:安全最佳实践:

  1. 最小权限原则运行容器
  2. 定期更新基础镜像和安全补丁
  3. 使用网络策略限制通信
  4. 敏感数据加密存储
  5. 实施运行时安全监控

Q4:如何监控容器化数据仓库的性能?

A:推荐监控方案:

  1. 指标收集:Prometheus
  2. 日志管理:ELK或Loki
  3. 分布式追踪:Jaeger
  4. 可视化:Grafana
  5. 关键指标:查询延迟、资源利用率、队列深度

Q5:容器化数据仓库的成本如何优化?

A:成本优化策略:

  1. 合理设置资源requests和limits
  2. 使用自动扩展(HPA/VPA)
  3. 采用分层存储策略
  4. 利用Spot实例运行批处理作业
  5. 实施资源配额和限制

10. 扩展阅读 & 参考资料

  1. Kubernetes官方文档:https://kubernetes.io/docs/
  2. Docker官方最佳实践:https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
  3. CNCF云原生景观:https://landscape.cncf.io/
  4. Presto技术文档:https://prestodb.io/docs/current/
  5. 《Data Warehousing in the Age of Cloud》 - Gartner研究报告
  6. 《Containerized Data Warehouses: Benchmark Study》 - IEEE Transactions on Cloud Computing
  7. 《Performance Analysis of Kubernetes Networking》 - ACM SIGCOMM Conference
相关推荐
2401_840108161 小时前
一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比)(1)
大数据·数据仓库
isNotNullX2 小时前
数据仓库是什么? 一文带你看清它的架构
大数据·数据仓库·架构·etl
oldboat_10122 小时前
数据仓库相关组件知识
数据仓库
秦JaccLink2 小时前
Hive导入数据的五种方式及其应用
数据仓库·hive·hadoop
爱加糖的橙子2 小时前
Dify升级到Dify v1.10.1-fix修复CVE-2025-55182漏洞
人工智能·python·ai
梦里不知身是客112 小时前
flink有状态计算中状态的分类
大数据·flink
老蒋新思维3 小时前
创客匠人峰会实录:创始人 IP 变现的 “人 + 智能体” 协同范式 —— 打破知识变现的能力边界
大数据·网络·人工智能·网络协议·tcp/ip·创始人ip·创客匠人
jkyy20144 小时前
端到端生态闭环:智能硬件+云平台+应用终端,最大化穿戴设备价值
大数据·人工智能·物联网·健康医疗
路边草随风4 小时前
java实现发布flink yarn application模式作业
java·大数据·flink·yarn