简介数据中台建设方案.docx 面向智慧城市、大数据与人工智能领域的方案设计者、项目负责人及技术架构师围绕如何搭建一套集成化大数据平台、支撑城市级数据汇聚、治理、计算与开发而整理。文档以星环科技 TDH 大数据基础平台与 TOS 云操作系统为参考架构依次展开总体建设方案、大数据集成平台、计算平台、开发平台及运维平台等模块并细分为数据采集层、存储层、交换层、管理层、资源管理层以及可视化工具、集成能力、安全性、高可用性、开放性与兼容性等专题便于读者快速理解数据中台的分层设计与落地路径。资源包内共1个docx文档压缩包约20.78MB内容以目录纲要与架构说明为主适合做方案汇报、招投标材料或技术选型时的框架参考。目前已有230人浏览学习可作为智慧城市数据平台规划阶段的入门与对照资料。1. 为什么智慧城市项目要先拆数据中台而不是先买服务器智慧城市项目最容易踩的坑是把它当成买一批服务器 装一套 Hadoop。真要落地就会发现物联网传感器、交通卡口、政务系统、视频平台各说各话数据在物理上挨着在逻辑上隔着十万八千里。数据中台建设方案要解决的正是这件事把采集、存储、交换、管理、资源五层拉齐再往上叠计算、开发和运维平台。这套方案的技术底座是 TDHTranswarp Data Hub加 TOSTranswarp Operating SystemTOS 基于 Docker 和 Kubernetes负责一键部署、抢占式调度和容器级隔离TDH 负责存算与 SQL 能力Inceptor 作为默认计算引擎向下兼容 Hadoop 生态、向上补 Sql 99/2003 与 PL/SQL 语法。它适合谁适合正在做智慧城市、政企数据汇聚的团队尤其是有 Oracle、DB2 存量资产、又不想推翻重来的那一批。下面我按从架构判断到落地参数、再到排错的顺序把这份方案里真正能抄的部分拆开讲。2. TDH 与 TOS 的分工边界谁管资源谁管算力2.1 TOS 到底解决什么问题TOS 是跑在容器里的操作系统核心有三块容器层、调度模块、系统服务层。容器层用 Docker 承载各个组件镜像与容器的关系类比类与对象调度模块基于 Kubernetes内置 FIFO、公平调度另外加了一套抢占式优先级调度系统服务层放 etcd、name service 这些支撑服务还有集中式应用仓库 TOSmarket。它跟传统资源框架最实际的差别在管控粒度。YARN 只能到 CPU 和内存Kubernetes 也主要管 CPU/内存而 TOS 把磁盘和网络带宽也纳入了配额。这意味着在同一台物理机上混跑实时流作业和离线批作业时你可以用磁盘 IO 和网络隔离来防止一方把另一方拖死——这在智慧城市的视频流接入场景里非常关键。维度YARN原生 KubernetesTOS资源粒度CPU/MEMCPU/MEMCPU/MEM/DISK/NETWORK隔离程度进程级不精确ContainerContainer Quota VLAN对 Hadoop 依赖强依赖不依赖不依赖支持负载类型少量计算引擎通用 Linux 负载大数据 通用应用2.2 一键部署与抢占式调度怎么用部署 TDH 集群时常见做法是通过 Web UI 或 REST API 提交组件清单TOS 会按服务依赖关系自动补齐前置组件。命令行方式大致如下参数含义我直接标在注释里# 使用 TOS 命令行工具提交 TDH 集群部署 tos-cluster create \ --name tdh-prod \ # 集群名同一 TOS 内唯一 --profile tdh-inceptor-holodesk \ # 组件画像决定装哪些服务 --nodes 12 \ # 参与的计算节点数 --priority high \ # 高优先级空闲时可抢占低优先级容器资源 --quota-cpu 96 \ # 集群级 CPU 配额核 --quota-mem 384g \ # 集群级内存配额 --quota-disk 20t # 集群级磁盘配额这是 TOS 区别于 K8s 的地方 # 查看部署进度与各服务健康状态 tos-cluster status --name tdh-prod --watch # 动态扩容业务高峰前加 4 个节点业务无需重启 tos-cluster scale --name tdh-prod --nodes 16第一条命令里的--profile是关键参数它决定 Inceptor、Hyperbase、Search 这些组件是否随集群一起拉起--priority影响的是抢占关系实时业务用 high离线跑批用 low低优先级容器的资源在集群空闲时会被高优先级回收但高优先级的作业不能被抢占。scale是热操作TOS 通过 Replicator 模块感知集群规模变化——如果某个 Hyperbase RegionServer 因硬件问题挂掉平台会在资源池内另起一个容器接替这个过程不需要人工介入。提示抢占式调度只解决资源被谁拿到不解决数据写在哪个节点。扩容后记得检查 HDFS 的块分布必要时用hdfs balancer -threshold 10手动均衡否则新节点会成为计算空转的热点。2.3 TDH 侧的能力取舍TDH 把 Spark 作为缺省计算框架Inceptor 在其上做了稳定性与性能改造官方口径是开源 Spark 的 2 到 10 倍这套方案里主要靠三点兑现一是列式内存存储 Holodesk走 SSD 或内存加速扫描二是基于成本CBO与基于规则RBO的双优化器做执行计划选择三是用轻量调度加多线程模型替代 MapReduce 的进程模型降低启动开销。存储侧 Hyperbase 建了全局索引、辅助索引和全文索引用于满足在线存储和 OLAP 的低延迟诉求。对智慧城市里车辆过卡口后 3 秒内要能查轨迹这类需求索引设计比堆集群规模更值钱。方案还提到 OLAP Cube在 1TB 数据集下 TPC-H 的跑分比 SparkSQL 和 Greenplum 快近 100 倍——这个数字只在模式固定的报表场景成立维度变化频繁的即席查询用不上选型时别被这个数量级带偏。3. 大数据集成平台的五层落地与分层参数3.1 采集层多源异构接入的字段设计采集层要面对的是配置、日志、网页、音视频、社交网络这几类数据。结构化和非结构化混在一起时我一般先做一次源特征盘点再决定走批量还是流式。下面这段是用 Java 走 JDBC 从 Oracle 抽数的骨架重点在分片字段的选择// 从 Oracle 抽取订单表按主键范围分片并发读取 String sql SELECT order_id, cust_id, amount, create_time FROM orders WHERE order_id ? AND order_id ?; // 分片键必须是单调、均匀的数字列否则会数据倾斜 int shardSize 500000; ListRangeLong shards splitByPrimaryKey(minId, maxId, shardSize); for (RangeLong shard : shards) { // fetchSize 控制单批行数避免一次性撑爆 JVM 堆 stmt.setFetchSize(10000); stmt.setLong(1, shard.lower()); stmt.setLong(2, shard.upper()); ResultSet rs stmt.executeQuery(sql); while (rs.next()) { buffer.add(toRecord(rs)); // 攒批后统一写入减少小文件 } }分片键选order_id而不是create_time原因是时间字段容易分布不均某几天的量可能占全量一半。fetchSize设 10000 是经验值太小会让网络往返次数暴增太大在并发高时会触发 GC。采集落地的格式建议统一成 Parquet 或 ORC避免后续每次查询都要重新解析文本。3.2 存储层冷热数据与归档表怎么切存储层的核心判断是数据温度。方案里没细说但实际项目绕不开近 7 天被查询频率高的放 Holodesk 或内存列存30 天内的放普通 HDFS 表超过半年的冷数据走归档表。-- 热表走 Holodesk 列存服务交互式分析 CREATE TABLE fact_traffic_hot ( plate_no STRING, gate_id STRING, pass_time TIMESTAMP ) STORED AS HOLODESK TBLPROPERTIES (holodesk.columnstoretrue); -- 归档表按月分区压缩存储只做批量回溯 CREATE TABLE fact_traffic_archive ( plate_no STRING, gate_id STRING, pass_time TIMESTAMP ) PARTITIONED BY (stat_month STRING) STORED AS ORC TBLPROPERTIES (orc.compressZLIB);STORED AS HOLODESK会把数据放在内存或 SSD查询快但成本高只给高频访问的窄表用。归档表用PARTITIONED BY按月切淘汰时直接ALTER TABLE ... DROP PARTITION比逐行删除快几个数量级也不会把元数据撑爆。分区字段别选日期到天智慧城市的数据一天一个分区会产生大量小文件按月或按周更稳。3.3 交换层与管理层血缘和权限数据交换层负责跨系统搬数管理层负责元数据、血缘和权限。这两块经常被合并成一个数据治理的模糊说法但落到实现上是两件不同的事。交换层我一般用中间落地区不直接点对点推送原因是出问题时要能重放。管理层的权限建议对齐 TDH 的细粒度访问控制结合 Kerberos/LDAP 做认证配合资源管理层做配额计算配额限制单租户能占多少 CPU/内存存储配额限制能写多少 HDFS 空间两者分开设避免一个跑批作业把整个集群的存储写满。4. 开发、计算与运维平台的打通顺序4.1 计算层的 SQL 兼容策略Inceptor 支持 SQL 99 与 SQL 2003 核心扩展兼容约 98% 的 Oracle PL/SQL 与 80% 的 DB2 SQL PL还能自动识别 HiveQL、SQL2003 和 PL/SQL 语法。对做存量迁移的团队这个兼容度直接决定改写工作量。语法能力InceptorApache HiveApache SparkSQL 99是是是SQL 2003是部分是Oracle PL/SQL是部分否DB2 SQL PL是否否存储过程是否否StreamSQL是否否存储过程和 ACID 是这张表里差异最大的两项。Inceptor 通过两阶段锁和 MVCC 实现可串行化隔离向同一数据块并发写入时不会互相覆盖这对数据清洗链路很重要否则一个补数作业和一个实时写作业撞上你得人工去查哪条记录被吞了。StreamSQL 的价值是把流计算写成 SQL省掉打包和部署环节实时研判类的需求用它上手最快。4.2 开发平台与可视化工具的衔接开发平台要解决的问题是把数据工程师、分析师和数据科学家的工具链装进同一个入口。方案里提到的可视化能力包括两个层面一层是结果展示对接 Tableau、SAP Business Objects、Oracle OBIEE 这类工具另一层是建模过程可视化比如拖拽式构建模型后再推到集群上训练。我通常按这个顺序打通先确认 JDBC 4.0 / ODBC 3.5 驱动在客户现有 BI 工具里能连通再开通 R 语言接口。R 侧可以访问 HDFS、Hyperbase也可以访问 Inceptor 内存中的分布式数据配合内置的并行化机器学习算法使用。这条路走通之后数据科学家不必再单独申请一套环境。4.3 运维平台的监控面运维平台覆盖安装、配置、监控、告警和高可用。高可用这块底层靠 HDFS 做数据持久化和冗余复制上层服务针对 HDFS 做 HA 优化。安全侧与 Kerberos/LDAP 整合支持细粒度访问控制和数据加解密。容器化最实际的收益是滚动升级TDH 组件在 TOS 上以微服务方式运行可以在不停业务的前提下做灰度升级。代价是排查问题时多了一层容器抽象——看到的是容器日志不是裸机日志运维同学要提前熟悉kubectl logs和 TOS 自己的诊断入口。5. 上手前先验证这三件事比堆跑分有用第一个技巧是别信单点跑分先做基线回归。方案里提到 TPC-DS 各数据量级的表现但你的数据分布和它不一样。拿去部署后的第一件事是挑 5 到 10 条生产真实查询记录在没有 OLAP Cube 加速下的耗时再决定是否要建 Cube。Cube 对模式固定的报表提速明显但维度改动时需要重建维度多、变更频繁的场景建了反而是负担。第二个技巧是用配额而不是告警来防雪崩。资源管理层的计算和存储配额要提前设死不要指望监控告警来救场。一个跑批作业写爆 HDFS 之后所有实时写入都会失败恢复时间远超设置配额的成本。设置后观察一周再按实际峰值上调。第三个是先验证抢占策略再上生产混合负载。抢占式调度让高优先级容器能抢低优先级的资源启动但前提是低优先级作业可被中断且能重跑。跑批作业如果没有幂等设计被抢占后重跑会写重复数据。上线前用一批可丢弃的测试作业做压测确认重跑逻辑正确这条比任何性能优化都省事。排错时的定位顺序也值得固定下来先看 TOS 的容器状态和资源配额是否触顶再看 Inceptor 的执行计划是不是选错了 join 方式最后才怀疑硬件。多数集群变慢的工单根因是配额分配不当或小文件过多而不是机器不够。本文还有配套的精品资源点击获取