简介《数据中台实战手把手教你搭建数据中台》电子书面向准备推进数据化转型的企业高层、产品经理、运营与开发人员以及希望入门数据领域的学生回应「数据中台是什么、为何要建、如何从0到1落地」这类常见困惑。全书以数据采集、数据存储与计算、数据打通、数据应用四个环节为主线涵盖指标管理体系与ODS到ADS分层建模、标签平台搭建、用户与商品及流量交易分析、自助分析平台与自动化营销等实战案例并提醒企业先判断自身业务密度与复杂度是否真的需要中台。包内为1个PDF文件约11.3MB版式完整、目录清晰便于按章节检索或在平板上通读。目前已有402人学习下载。读者可从中获得一套可对照执行的搭建流程、各环节的模块划分思路与落地注意事项也能借案例理解数据如何真正赋能业务运营。1. 别急着买机器大数据中台第一个拦路虎不是安装很多人对大数据中台的第一印象是「一堆服务器加一套 Hadoop」觉得组件装完、日志能进 HDFS中台就算搭起来了。我最初也是这么干的三台机器、一套 Hadoop、Hive 建库、Kafka 收日志一周跑通自我感觉良好。结果上线第一个月就被打回原形——两条产品线算出来的「活跃用户」相差 18%运营拿着两份报表来对质我翻了半天才发现两边的口径一个是「有登录行为」一个是「有任意行为事件」谁都没错错在没人把口径固定下来。这件事之后我才明白卡住人的从来不是安装包解压失败而是分层没规划、采集重复、指标没有唯一出口。这份资料把搭建过程拆成采集、存储、打通、应用四段和我后来重做的那套环境基本能对上所以下面按「装什么、怎么装、坏了怎么救」的顺序把我自己落地时的那套环境写清楚。适合三类人看第一次要从零搭一套分析链路的开发者、接了「数据化」任务但不知道从哪下手的产品或运营、以及已经装了一半卡在报错上的运维。2. 环境盘点与组件选型把四层架构拆到机器、端口和目录装之前先把话说死数据中台不是某一个软件它是一条链路。采集层负责把行为日志和业务库数据搬进来存储计算层负责分层建模和指标计算服务层把结果封装成接口应用层才是看板、标签、推荐这些业务方直接摸到的东西。任何一层装错症状都会在别的层冒出来所以我一般先把机器、端口、目录、用户这四件事定死再动手解压。这一章不讲原理只讲我这套环境的基线。下面的版本号是我自己环境里锁定并跑了半年的一套资料里并没有规定版本你按公司已有的基线替换即可但同类组件之间的大版本关系别乱动。2.1 机器与操作系统基线我的最小可用集群是 5 台2 台装存储与计算的主节点兼数据节点1 台作为调度与元数据节点2 台纯计算节点。这套配置支撑的是千万级日活以下的量再往上加机器属于横向扩展的事不影响安装顺序。操作系统我选 Rocky Linux 9CentOS 7.9 也能跑区别主要在 glibc 版本和部分组件的 native 库。装系统时有两件事必须先做否则后面全是玄学问题# 1. 关闭 SELinux不关会出现各种 permission denied且报错信息毫无指向性 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config setenforce 0 # 2. 时钟同步集群内所有节点偏差控制在 1 秒内 dnf install -y chrony systemctl enable --now chronyd chronyc sources -v第一段是把 SELinux 改成 disabled 并临时生效改完必须重启才彻底第二段装 chrony 并校验时间源。时钟这一项最容易被跳过但 Kerberos、Kafka 消息时间戳、调度依赖判断全都吃这个节点间差出几分钟后面排查能让你怀疑人生。主机名和 hosts 也要一次配齐别用 IP# 所有节点执行按实际主机名替换 hostnamectl set-hostname node01 cat /etc/hosts EOF 10.0.0.11 node01 10.0.0.12 node02 10.0.0.13 node03 10.0.0.14 node04 10.0.0.15 node05 EOFhosts 里写的是内网地址主机名统一用 node01 到 node05 这种无意义命名避免以后换机器名牵一发动全身。配置文件里凡是能写主机名的地方就不要写 IP迁移时改一处 hosts 就够。2.2 组件版本对照我锁的这一套版本这块我踩过最疼的一次是 Spark 和 Hive 的元数据客户端版本不匹配读表直接抛NoSuchMethodError堆栈里全是 guava 的类名看了两个小时才反应过来是依赖打架。所以下面这张表里的版本是我实际验证过能互相认的层组件我锁的版本选它的理由运行时JDK1.8.0_381Hive 3.x 对 JDK 11 支持不稳统一压 8存储Hadoop3.3.63.3 系列稳定社区文档多元数据MySQL8.0.36Hive 元数据库、调度库共用数仓Hive3.1.3与 Hadoop 3.3 兼容性最好计算Spark3.3.4与 Hive 3.1.3 的 metastore 客户端对齐实时Flink1.17.2CDC 连接器生态成熟消息Kafka3.6.1仍在 ZooKeeper 模式团队熟采集DataX202309 版离线全量同步够用OLAPDoris2.0.4支持明细 聚合查询延迟可接受调度DolphinScheduler3.2.1可视化依赖运维成本低表里最容易被忽略的是 JDK 那一行。很多人图新装 JDK 11 或 17Hadoop 能跑但 Hive 的 metastore 客户端会出各种反射异常最后还是要退回来。统一 JDK 8 之后Spark、Hive、Flink 三边的兼容问题基本消失。Kafka 我特意留在 ZooKeeper 模式不是不知道 KRaft 更轻而是团队里所有人都会用zkCli查元数据换模式等于把排错手段砍掉一半。新团队可以直接上 KRaft但要有心理准备出问题时能查的资料少很多。2.3 端口、目录和用户装之前先占好坑端口冲突是安装期最常见的翻车点尤其是 8088 这种大家都爱用的。我一般先按下面这张表规划好装一个勾一个组件端口用途HDFS9870NameNode Web UIHDFS8020NameNode RPCYARN8088ResourceManager UIHive10000HiveServer2Hive9083MetastoreKafka9092BrokerMySQL3306元数据库Doris9030 / 8030FE 查询 / Web UIDolphinScheduler12345API Server自助分析8089前端页面避开 8088目录规划同样要提前落因为一旦数据写进去再挪代价巨大# 所有数据节点执行 mkdir -p /data/disk1/dn /data/disk2/dn # HDFS 数据盘一块盘一个目录 mkdir -p /data/logs/{hadoop,hive,spark,flink,dolphin} mkdir -p /data/software # 安装包统一放这 chown -R bigdata:bigdata /data # 统一用户避免每台机器 UID 不一致导致 HDFS 权限错乱 groupadd -g 3000 bigdata useradd -u 3000 -g bigdata -m -s /bin/bash bigdata第一段按磁盘划分数据目录HDFS 的dfs.datanode.data.dir后面要写成/data/disk1/dn,/data/disk2/dn这种逗号分隔形式一块盘一个目录能让写入并行度上去。第二段创建统一用户这是血泪经验不同机器上同名用户 UID 不一致HDFS 上看到的就是陌生用户权限报错查半天查不出原因。提示所有安装动作都用 bigdata 用户执行不要图省事用 root。Hadoop 系组件在 root 下启动会有一堆警告而且后期排查会分不清文件属主是谁改的。2.4 JDK 与基础依赖一次装对环境变量我习惯写在/etc/profile.d/下独立文件里不往/etc/profile里堆# /etc/profile.d/bigdata.sh export JAVA_HOME/data/software/jdk1.8.0_381 export HADOOP_HOME/data/software/hadoop-3.3.6 export HIVE_HOME/data/software/hive-3.1.3 export SPARK_HOME/data/software/spark-3.3.4 export FLINK_HOME/data/software/flink-1.17.2 export PATH$JAVA_HOME/bin:$HADOOP_HOME/bin:$HIVE_HOME/bin:$SPARK_HOME/bin:$PATH这段没什么花活关键是JAVA_HOME必须排在PATH最前面否则机器自带的 openjdk 会抢先被找到java -version看到的和你以为的不是一个。写完之后source /etc/profile.d/bigdata.sh再用which java确认指向/data/software/jdk1.8.0_381/bin/java。Hadoop 的配置文件我一般只改四个core-site.xml里定fs.defaultFS和hadoop.tmp.dirhdfs-site.xml里定副本数和数据目录yarn-site.xml里定yarn.nodemanager.resource.memory-mbmapred-site.xml里把执行引擎指向 YARN。其中hadoop.tmp.dir一定要指到大盘默认在/tmp下机器一重启数据全没第一次踩这个坑的人会以为副本丢了。3. 数据采集层部署日志与业务库两条链路采集层是整条链路的入口装得对不对后面所有环节都能感觉到。我把它拆成两条完全独立的链路行为日志走「埋点 → Kafka → 落 HDFS」业务库走「CDC 或 T-1 抽取 → ODS」。两条链路的技术栈不共用出问题互不影响这是刻意的设计。3.1 行为日志链路从埋点到 Kafka 到 HDFSKafka 先起。三个 broker 的server.properties里我只关注这几个参数broker.id1 listenersPLAINTEXT://node01:9092 advertised.listenersPLAINTEXT://node01:9092 log.dirs/data/disk1/kafka-logs num.partitions6 default.replication.factor2 log.retention.hours72advertised.listeners是最容易配错的一个客户端连上来之后broker 返回给客户端的是这个地址如果这里写了 localhost远端客户端就会连到自己机器上报连接超时。num.partitions设 6 是为了和后面 Flink 的并行度对齐分区数小于并行度会导致有算子空转。保留 72 小时是按「下游最多停两天」的容忍度算的超过这个时间的日志走 HDFS 归档不再留在 Kafka。落 HDFS 这一段我用 Flink 消费 Kafka 直接写文件-- Flink SQLKafka 源表按事件时间切分 CREATE TABLE ods_event_log ( user_id STRING, event_name STRING, page_id STRING, ts BIGINT, proc_time AS TO_TIMESTAMP_LTZ(ts, 3), WATERMARK FOR proc_time AS proc_time - INTERVAL 5 SECOND ) WITH ( connector kafka, topic app_event, properties.bootstrap.servers node01:9092,node02:9092,node03:9092, properties.group.id ods_event_log, scan.startup.mode group-offsets, format json );建表语句里WATERMARK定义的是事件时间的乱序容忍度5 秒是按客户端上报延迟的 P99 定的设太大状态会膨胀设太小会丢迟到数据。scan.startup.mode用group-offsets而不是earliest是为了重启时能接着消费位点不会把历史数据重刷一遍。这段我只贴了源表落 HDFS 的 sink 表按天分区写分区字段用DATE_FORMAT(proc_time, yyyy-MM-dd)别用处理时间否则补数的时候分区对不上。3.2 业务库同步CDC 增量还是 T-1 全量业务库同步有两条路。T-1 全量简单DataX 配个 json 就完事缺点是每天凌晨一次大查询会把业务库拖慢表大了还跑不完。CDC 增量实时但对 MySQL 的 binlog 格式和权限有要求。我的做法是分表处理核心交易表走 CDC配置类小表走 T-1。CDC 用 Flink 的 MySQL 连接器CREATE TABLE ods_order_cdc ( order_id BIGINT, user_id BIGINT, amount DECIMAL(18,2), status STRING, update_time TIMESTAMP(3), PRIMARY KEY (order_id) NOT ENFORCED ) WITH ( connector mysql-cdc, hostname 10.0.0.20, port 3306, username cdc_reader, password ******, database-name trade, table-name t_order, server-time-zone Asia/Shanghai );server-time-zone这个参数必须显式写。不写的话连接器用 UTC 解释 MySQL 的datetime字段落到 HDFS 上就整体偏 8 小时第二天看板上的「今日订单」怎么算都不对。这个坑我调了一整天才定位到因为它不像报错它就是静悄悄地错。T-1 的 DataX job 我一般手写 json重点在两处{ job: { content: [{ reader: { name: mysqlreader, parameter: { username: sync_reader, password: ******, connection: [{ jdbcUrl: [jdbc:mysql://10.0.0.20:3306/trade?useUnicodetruecharacterEncodingutf8], querySql: [select id,name,price from t_product where update_time ${bizdate}] }] } }, writer: { name: hdfswriter, parameter: { defaultFS: hdfs://node01:8020, path: /warehouse/ods/t_product/dt${bizdate}, fileType: orc, writeMode: append } } }] } }querySql里用${bizdate}做增量条件而不是让 DataX 全表拉是为了减少对业务库的压力path里同样带${bizdate}保证每天一个分区后面 Hive 建外部表时按dt分区挂上去就能查。writeMode选append选truncate会把当天重跑的数据覆盖掉——听着合理但补数场景下你会希望保留原始覆盖交给下游的重刷逻辑处理。3.3 采集层自证三条对账采集装完不要急着往下走先自证。我固定跑三条对账源表条数与 ODS 分区条数、Kafka 最新位点与已消费位点差、日志文件数与事件条数是否每条一行。三条里任一条不齐先修采集别去做建模。对账语句我一般用一个脚本包起来每天调度跑一次结果落到一张小表里出问题直接看趋势。4. 存储与计算层搭建ODS 到 ADS 的分层与指标口径这一层是中台真正值钱的地方也是最容易被做成「一堆临时表」的地方。分层不是为了好看是为了让每个指标有唯一出口ODS 只负责还原原始DWD 只负责清洗和关联DWS 只负责聚合ADS 只负责面向场景任何跨层直接取数的需求都要被打回去。4.1 五层建模的建库建表规范建库时就按层分好命名前缀固定后面谁建表都逃不开这个规范CREATE DATABASE IF NOT EXISTS ods COMMENT 原始数据层 LOCATION /warehouse/ods; CREATE DATABASE IF NOT EXISTS dwd COMMENT 明细数据层 LOCATION /warehouse/dwd; CREATE DATABASE IF NOT EXISTS dws COMMENT 汇总数据层 LOCATION /warehouse/dws; CREATE DATABASE IF NOT EXISTS ads COMMENT 应用数据层 LOCATION /warehouse/ads; CREATE DATABASE IF NOT EXISTS dim COMMENT 公共维度层 LOCATION /warehouse/dim;库的LOCATION显式指定别用默认路径否则换集群时不知道数据在哪COMMENT一定要写中文说明元数据页面上一眼能看懂比任何文档都管用。明细表的建表模板我固定成这样CREATE EXTERNAL TABLE dwd_order_detail ( order_id BIGINT COMMENT 订单ID, user_id BIGINT COMMENT 用户ID, sku_id BIGINT COMMENT 商品ID, pay_amount DECIMAL(18,2) COMMENT 实付金额, order_status STRING COMMENT 订单状态 ) COMMENT 订单明细 PARTITIONED BY (dt STRING COMMENT 日期分区) STORED AS ORC TBLPROPERTIES (orc.compressSNAPPY);EXTERNAL是为了删表不删数据这一条在测试环境反复重建表的时候能救命ORC加SNAPPY是压缩率和查询速度的平衡点别用 TEXTFILE存储能差出三四倍分区字段用STRING类型的dt不用DATE因为跨引擎传参时字符串最不容易出格式问题。4.2 指标字典把口径写进表里活跃用户那个 18% 的差异最后是用一张指标字典表解决掉的。它的思路很简单每个指标在库里有一行记录定义了业务口径、技术口径、计算周期所有看板、所有接口都从这里取定义。CREATE TABLE dim.dim_indicator ( indicator_code STRING COMMENT 指标编码全局唯一, indicator_name STRING COMMENT 指标名称, biz_definition STRING COMMENT 业务口径描述, tech_definition STRING COMMENT 技术口径SQL 片段, calc_period STRING COMMENT 统计周期 day/week/month, owner STRING COMMENT 口径负责人, update_time TIMESTAMP ) COMMENT 指标字典;tech_definition存的是 SQL 片段而不是完整 SQL这样计算引擎换掉也不影响口径本身owner这一列看着像形式主义但真出事的时候必须能找到一个拍板的人否则两个团队各写各的永远对不齐。注意新增指标必须走字典表登记没有登记的指标不允许上报表。这条规矩立得越早后面省的事越多。4.3 调度依赖与回刷调度我用 DolphinScheduler工作流按「ODS 同步 → DWD 清洗 → DWS 聚合 → ADS 输出」串起来依赖是分区间级别的不是整个工作流级别。这样某天的 DWD 重跑不会把下游全带崩。上线前必须验证回刷随便挑一个历史日期从 ODS 到 ADS 整条链路重跑一遍看结果和原来是否一致。不一致说明中间有非幂等的操作比如用了current_date()而不是分区日期或者insert overwrite写成了insert into。这类问题在正常跑的时候永远看不出来只有在重跑时才暴露而重跑恰恰是出事后最常做的事。4.4 数据打通行为宽表的 join资料里把「打通」分成两块用户行为数据与业务数据的打通、产品线之间的打通。落到实现上就是一张宽表。常用的写法是行为表先按用户聚合出当日行为摘要再和订单明细按user_id dt关联INSERT OVERWRITE TABLE dws.dws_user_day PARTITION(dt${bizdate}) SELECT a.user_id, a.pv_cnt, a.click_cnt, COALESCE(b.order_cnt, 0) AS order_cnt, COALESCE(b.pay_amount, 0) AS pay_amount, CASE WHEN b.order_cnt 0 AND a.pv_cnt 0 THEN 1 ELSE 0 END AS is_converted FROM ( SELECT user_id, COUNT(1) AS pv_cnt, SUM(CASE WHEN event_nameclick THEN 1 ELSE 0 END) AS click_cnt FROM dwd.dwd_event_detail WHERE dt${bizdate} GROUP BY user_id ) a LEFT JOIN ( SELECT user_id, COUNT(DISTINCT order_id) AS order_cnt, SUM(pay_amount) AS pay_amount FROM dwd.dwd_order_detail WHERE dt${bizdate} GROUP BY user_id ) b ON a.user_id b.user_id;用LEFT JOIN而不是JOIN是为了保留「有行为但没下单」的用户这些人恰恰是转化分析里最需要看的COALESCE把空值补 0避免下游做算术时整行变 NULLis_converted这个标记字段看着冗余但它能把转化率的计算逻辑固化下来避免每个看板各写各的CASE WHEN。5. 避坑与排查五个真摔过的坑下面这五条都是我自己踩过的按现象、原因、解决三段的格式记下来方便出问题时直接对号入座。5.1 采集与存储环节的两个坑坑一NameNode 格式化了两次DataNode 全部起不来现象hdfs dfsadmin -report显示存活的 DataNode 为 0DataNode 日志里反复出现Incompatible clusterIDs。原因hdfs namenode -format会生成一个新的 clusterID而之前已经启动过的 DataNode 目录里存的是旧 clusterID两边对不上就拒绝连接。很多人遇到启动失败的第一反应是「再 format 一次试试」越试越糟。解决停掉所有进程删掉 NameNode 的dfs.namenode.name.dir和每个 DataNode 的dfs.datanode.data.dir下的内容重新 format 一次再统一启动。生产环境上出现这个先确认数据还要不要要数据的话从备份恢复元数据目录别直接删。坑二Hive 元数据库字符集不是 utf8mb4建表中文注释乱码现象建表时带中文COMMENTHiveServer2 报错或者注释落库后变成问号。原因Hive 元数据库初始化时用了默认的 latin1 字符集MySQL 8 虽然默认 utf8mb4但手工建库时如果照抄旧文档写了CHARACTER SET latin1后面全是麻烦。解决建元数据库时一次性写死CREATE DATABASE hive_metastore DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;已经建错的改库字符集只是第一步还得把 metastore 里已有的表注释字段一起改代价不小所以这一步必须在schematool -initSchema之前做对。5.2 计算与调度环节的三个坑坑三Spark 读 Hive 表报 NoSuchMethodError现象spark-sql查询 Hive 表时抛java.lang.NoSuchMethodError堆栈里全是com.google.common开头的类。原因Spark 自带的 guava 版本和 Hive 依赖的 guava 版本不一致类加载时先加载了低版本的方法签名对不上。这不是配置错误是依赖打架。解决在spark-defaults.conf里把 guava 显式指到 Spark 自带的那份并让 Spark 使用 Hive 的 metastore 版本spark.sql.hive.metastore.version3.1.3 spark.sql.hive.metastore.jarspath spark.sql.hive.metastore.jars.pathfile:///data/software/hive-3.1.3/lib/*.jarmetastore.jars设成path表示用本地 jar 而不是内置的这样版本就完全受控。改完必须重启 Spark 相关服务光改配置不重启是没用的。坑四DolphinScheduler 任务一直卡在「提交中」现象工作流实例状态停在「提交中」Worker 日志里没有任何任务输出。原因Worker 执行任务时要用配置的租户用户去sudo -u切换如果这个用户在某些 Worker 节点上不存在或者没配免密 sudo任务就卡住而且不报明显错误。解决确认每个 Worker 节点都有对应租户用户并在/etc/sudoers.d/下加一条免密规则。部署时最好把所有 Worker 的/etc/passwd对一遍别指望安装脚本帮你检查。坑五看板数据整体差 8 小时现象日志里明明是晚上 8 点的行为看板上算到了第二天。原因上游 Kafka 消息里的时间是 UTC 毫秒时间戳Flink 用TO_TIMESTAMP_LTZ转换时按 UTC 解释落盘后按天分区就跨天了。这个错不报异常只是安静地错。解决在 Flink 作业里显式设置会话时区或者在落分区时统一做8 小时偏移两个方案选一个并在整个链路里保持一致。我倾向前者因为它只在一处生效后者容易这个作业加了那个忘了加。6. 装完怎么验证跑通一份 30 分钟的端到端验收清单组件全绿不代表链路通了我见过太多「所有服务都是 running」但数据一条没进来的环境。所以装完必须做一次端到端验收从产生一条数据开始一路追到看板上出现它。第一步造一条可追踪的数据。用测试账号触发一次行为事件记下user_id和事件时间然后顺着 Kafka 消费、HDFS 分区文件、ODS 表、DWD 表一路查下去# 1. 确认消息进了 Kafka kafka-console-consumer.sh --bootstrap-server node01:9092 \ --topic app_event --from-beginning --max-messages 5 | grep test_user_001 # 2. 确认落到了当天分区 hdfs dfs -ls /warehouse/ods/ods_event_log/dt$(date %F) | head第一条能搜到说明采集通第二条能列出文件说明落盘通。两步都过了再去 Hive 里按user_id查 ODS 和 DWD条数应该一致DWS 里这条记录应该只有一行聚合值对得上。第二步做数量对账。源表 count、ODS 分区 count、DWD count 三个数摆在一起差值必须能解释。解释不了就停下来查别往下走。第三步固定指标快照。挑三个核心指标比如日活、下单转化率、客单价把某一天的值记下来写进回归基线。以后每次改模型、改调度、升级组件跑一遍比对差值超过 1% 就拦住。这招比任何文档都管用因为它能抓住那些「悄悄变了一点」的问题。第四步验证回刷。任选一个历史日期从 ODS 到 ADS 重跑结果与基线一致才算通过。回刷不过关的环境出事后根本不敢重跑只能干等。第五步验证失败告警。手动杀掉一个 DWD 任务看调度是否正确标记失败、下游是否被阻塞、告警是否发到人。告警不响的调度等于没有调度。验收项通过标准常见不通过原因单条链路追踪五层都能查到同一 user_id时区偏移、分区字段写错数量对账三层 count 差值可解释采集重复消费、join 放大指标回归与基线偏差小于 1%口径变更未登记回刷一致重跑结果与基线相同用了非分区日期函数告警触达5 分钟内收到通知告警通道未配置接收人从那以后我每次搭完一套环境都会强制走一遍这份清单哪怕只是升级了一个小版本。看起来是多了半小时实际上省下的是上线后被业务方追着问「为什么这个数和昨天不一样」的一整个下午。希望这套流程能帮你少走点弯路需要对照完整案例的把这份资料收着遇到口径分歧时翻到对应章节比对比在网上搜一堆互相矛盾的答案靠谱得多。本文还有配套的精品资源点击获取