共计 12850 个字符，预计需要花费 33 分钟才能阅读完成。
导语 | 数据工程要做什么？怎么设计和开发一套好的数仓？一个经验了内容类业务（腾讯视频），面向企业的消费品业务（腾讯优码），社区电商类业务（外部孵化中）的数仓开发鹅和你聊聊数据工程的道与术。
到新业务的前一段时间，总被人问到：“数仓要怎么建设？咱们现有的数仓有没有什么中央须要优化？”
我之前的答复总是零散的，点到哪里就说哪局部的办法，没有一个比拟成体系化总结。在重构和新建了几个业务的数仓当前，用文字的形式对数据链路上上游相干环节的实践和工作中的教训加以总结，心愿能给大型业务提供数仓标准化 ETL 的教训，给中小型和初创型业务梳理出常见数仓建设问题，厘清数仓建设的重点，从而进行疾速的优化和提效。
那么，就让咱们从数据的诞生一步步开始吧。
数据的源头
数据的源头是数据采集和上报。
“看似很小的视频为什么耗费了我那么多流量？数仓应用的数据是否就是业务 DB 里的数据？”
第一个问题的答案是：在 APP 启动的过程中，会以很高的频率进行着数据采样和上报。在目前的支流利用中，你所看到的和触摸屏幕产生的操作根本都会被采集几十或者上百个参数后上传到利用开发商的服务器上，这就造成了理论的流量耗费比视频自身的大小要多很多的状况。
这里引出数据采集的实质，是对间断的事实世界的采样，并且以结构化的形式存储起来。这样，利用开发商就能在任意工夫，从一条条数据里，复原出用户在 APP 里的一整套行为。但因为存在存储老本，原始数据个别不会保留太久，具体的保留工夫要依据业务和计算需要来确定。
（一）数据采集
采集内容
数据采集个别须要涵盖 4W（When、Where、Who、What）四大因素，像作文一样别离从工夫、地点、人物、事件对用户的行为予以形容。
When
操作工夫。有些数据上报并不是在采集后马上进行的，而是累计采集 N 条后打包上报；有些参数的获取须要前后台彼此交互，所以工夫的采集能够细分为动作产生的工夫、采集工夫、前后台交互实现工夫、上报工夫等，依据各业务需要和复杂程度决定采集的类型和范畴。
Where
操作地点。个别能够通过 IP 地址或经纬度确定。
Who
身份标识。这里次要介绍 2 种身份标识：用户账号和设施号。
用户账号是各个利用依照本人的规定赋予用户的外部身份标识。其中有些利用依据流量域属性、内容生产和生产属性等设计了多级账号体系（例如微信账号和视频号、腾讯视频创作号和账号等）；有些利用则应用单账号体系（例如 B 站等，用同一个账号既能够进行内容生产也能够进行内容生产）；有些应用大生态下的凋谢账号体系（例如微信、QQ、抖音开放平台的 openid 等），这里不再具体开展。
设施号是硬件设施的身份标识，包含但不限于手机、电脑、电视、智能可穿戴设施等。设施号的作用是辨认一台具体设施，例如 IMEI、IDFA、OAID 等，生成设施 ID 的相干的算法也在一直优化降级以达到更精确的辨认和标记。
在硬件推送（PUSH）场景下，用户账号要先转化为设施号能力进行失常推送。除此之外，设施号在黑产打击方面也有大规模的利用。
What
操作内容。诸如页面、曝光、点击等操作和相干的业务参数在此进行采集。在前端框架技术上反对的状况下，用户操作的起源和去向也能够依据统计须要进行采集。
数据采集和上报是为了优化服务的，不能适度影响到利用的失常性能，所以须要在肯定水平上进行衡量与精简。而操作内容的采集场景，存在大量的前后端数据交互，若申请数据结构过大，则可能影响传输性能进而影响应用体验。
采集形式
埋点采集
前后端利用开发人员在特定场景下的特定机会，依据须要采集特定的参数。晚期和中小型利用多应用该采集形式。其长处是开发成本低，批改灵便；但毛病是容易造成全局采集逻辑不统一的状况，后续保护老本和数据加工成本高。
SDK 采集
SDK 通过外部集成采集和缓存能力，对立采集机会和采集策略，标准化采集事件来进行全局参数采集，是从数据源头改善数据品质的重要形式，曾经被越来越多的大型业务所应用。其长处是标准化水平高，升高前后端开发人员的开发量；毛病是开发这一套工具须要较大的后期投入。
采集机会和采集策略的对立是 SDK 采集相较于埋点采集的重大改良。用曝光场景举个例子，若应用埋点上报，有些开发人员在指标露出屏幕 100 个像素时采集，另一些开发人员可能在指标露出 5% 时进行采集；不同的开发人员在采集同一个参数时，应用的代码和采集门路也不肯定完全相同。在大型利用中，数据的采集不是一次就能实现的，而是一个分阶段进行的过程，采集的参数个数也可能不是几个，而是几十上百个，所以不同的采集机会和采集策略就意味着能采集到参数的个数和品质也不尽相同。
BINLOG 采集
BINLOG 能够获取数据库的每一条变更记录，由此实现 DB 数据的采集。目前曾经有比拟成熟的开源组件能够间接应用。其长处是无需前后端开发人员的额定工作，但毛病是后续的数据加工会变得非常复杂，须要频繁的去重和取最新数据的操作，这在实时数据处理场景下简直是致命的。
集体总结：数据采集的品质决定了数仓品质的下限，数据开发的工程量是数据源品质和数仓设计与施行品质独特决定的。一个团队多做一点，另一个团队就少做一点，但在一些要害节点上，一个团队修补另一个团队的开发空缺可能是几倍甚至几十倍的工作量。在预期提供雷同质量数仓的前提下，决策者须要正当均衡数据源开发和数仓开发的工作配比，能力更大程度地施展数据价值。
（二）数据上报
拿到采集的数据当前，须要进行数据的上报，能力被后续的链路所应用。按采
集地点的差别，数据上报能够分为
- 客户端（前端）上报
客户端在采集到的数据后，间接或在缓存 N 条当前，批量将数据通过网络发送到日志服务器。这个过程可能因为网络稳定或者用户间接杀掉过程导致局部数据上报缺失；有些利用为应答网络问题会内置上报重试逻辑，肯定水平上解决上报缺失的同时也引入了反复上报的可能性。
无论是上报缺失或者上报反复，都是小概率事件，并且个别通过客户端上报的数据都是页面、曝光、点击这类的描述性数据，故在统计容忍的范畴内仍可承受。
- 后盾上报
后盾服务在用户触发较为关键性的操作时（例如拜访、下单、关注等）或者后盾被动操作时（例如发券、回收权限等）进行相干参数的采集和上报，也是通过网络发送到日志服务器上。但因为后盾服务个别处于比较稳定的外部生产环境，所以上报的成功率会比客户端更高，一些对准确性要求较高的统计数据能够应用后盾上报的形式。
- BINLOG 上报
数据库 BINLOG 的采集和上报个别是集成在一起的，能够在采集后立刻发送到音讯队列（多为 Kafka 队列）实现数据上报。
（三）数据源抉择
这里咱们能够答复章节结尾提到的第二个问题，数仓里的数据不是业务 DB 里的数据，两头通过了采集和加工过程。
那么趁势提出另一个问题：“什么时候应用 DB 里的数据，什么时候应用通过上报和数仓加工后的数据呢？”
因为数据在加工链路上不可避免地会产生肯定水平的失落和提早，所以在要求高准确性和低提早的简略统计场景下，在不会影响到利用基本功能的前提下更举荐在 DB 内间接统计数据；在同样要求高精确和低提早的较简单场景时，也能够通过进步数仓建设规范和肯定水平的定制开发，应用经数仓加工后的数据。
集体总结：数据源的抉择同样面临投入产出比的掂量，业务 DB 因为范式概念的设计，较难实现简单的统计需要，但具备精确和疾速的长处，数仓能够进行大规模简单计算，但面对极低提早和极强准确性的需要时也会进步其建设老本。具体业务和需要在抉择数据源的时候就见仁见智了。
数据加工
“数仓加工有那么难么，数据不是都有，这样 JOIN 一下再那样 JOIN 一下不就好了？”
不能说这个说法不对，然而咱们能够类比一下：一棵大白菜，从农场到家里，不就是摘下来，一个货车运到楼下菜市场，而后买回来就能够了么？能够说，这种形式对于一个小村镇来说，尚且可行，但如果面对的是一个人口 2000 多万的大型城市，要做到这一点，就不仅仅是看上去那么简略了。
（图源：36 氪）
本章节将一步步答复这个问题，讲述如何建造像“城市”一样运行的数仓。
（一）确定建设规范
在建设数仓之前须要依据数据根底和业务需要来决定要建设什么规范的数仓。
举个例子：如果上游数据无奈做到及时传输（例如事件产生工夫与达到数仓工夫之差的平均值大于 1 分钟），或对于时效性要求很低的业务，那么建设实时 + 离线数仓的必要性就不如仅建设离线数仓。
（二）梳理现存问题
常见数仓问题
在经验了几个业务的数仓开发后，发现一些无论大型还是小型业务都可能存在的问题，总结下来别离是
公共底层加工逻辑扩散：对于来自多个数据源，但须要应用雷同过滤和解析形式公共底层数仓，其过滤和解析代码在每个工作或配置中间接动态复制，未做到对立治理。加工逻辑扩散带来的影响是如果公共底层数仓字段须要更改（增删，批改过滤、解析形式等），须要刷新一遍所有相干工作的代码。如果还存在着无奈感知到所有的批改地位、批改进度不统一、批改过程呈现问题等状况，上游的数据应用就可能呈现问题。
如图展现了基于公司外部零碎，将公共底层加工逻辑从扩散（深蓝色动线）到对立（红色动线）的改变实际。
烟囱式开发：针对每一个需要或者每一个计算指标，都从底层数据开始，应用雷同或极其类似的限定条件、计算逻辑、接出形式，产出的后果仅在很小范畴内应用。烟囱式开发带来的影响是上游数据口径产生差别，反复解析造成的计算和存储资源节约，无奈通过扩充规模晋升开发效率，并且不利于数据的团队内外共享。
批流建设拆散：实时数仓和离线数仓在机制上无奈应用雷同的荡涤和加工逻辑。这是 Lambda 架构下很常见的问题，可能间接影响到实时数仓和离线数仓的数据一致性。
部分业务问题
除此之外，还有一些个别业务数仓可能存在的问题
数据含意含糊：存在于数仓各个层级的数据中，包含但不限于字段内数据存在多义性（例如应用函数 nvl(id1, id2) 的后果作为 id1）、字段名与含意不符（例如雷同的指标名称，在某些表中示意当天的统计量，但在另一些表中示意当年累计的统计量）、维度和指标的组合存在偏差（例如工夫字段内的含意是多天的范畴，但指标统计的仅仅是当天；或者将不相干的字段，诸如将维度：商品 Id 和指标：App 启动次数组合在一起）等。
数据的多义性会给上游应用带来艰难，有时候上游须要确定性的某一种 ID，那么就还须要复原解决，如果判断条件有余还会呈现无奈拆散的状况；字段名含意不符增大了数仓的应用老本，即每一次个字段的应用都要通读上游所有代码能力确定其含意；维度指标偏差则可能产生谬误数据，并且给上游应用方带来困扰。
溯源性差：因为数仓加工代码逻辑限度，或者数据表的生命周期设置不合理，造成的历史数据重跑艰难，或者历史问题现场无奈复原。数据的重算和问题溯源是常见的数仓需要，如果无奈回溯则可能导致谬误数据的累积，或者无奈很好地帮忙业务定位问题。
指标收缩：因为短少标准上的束缚，导致指标中涵盖了本能够作为维度的内容，造成了指标收缩。例如应用 <0~10 岁付款金额、10~15 岁付款金额、15~20 岁付款金额……> 作为多个指标就不如应用维度 < 年龄段 >+ 指标 < 付款金额 > 更简洁高效。随着业务的倒退，收缩适度的指标会导致利用数仓越来越臃肿且难以保护。
数仓标准缺失：数仓开发中短少对立的标准限度，导致工作设置、元数据管理、数据层级调用、字段命名、计算口径等随着开发横蛮成长，并最终导致开发效率升高。
（三）明确建设步骤
了解业务
开始建设数仓之前，首先要全面理解业务逻辑，这样更便于做出正确的数据域和数仓架构划分。
确定了业务逻辑当前，下一个关键步骤就是形象业务行为，也就是划分数据域。如果你的业务是内容类，那么曝光（页面、元素）、点击、播放、进入退出利用（如果领有独立 APP）等就是业务内的根本行为；如果你的业务内容是电商类，那么加购物车、下单、领取、发货、退款等就是业务内的根本行为。
很侥幸，有些业务在布局上报的时候曾经进行了数据域划分的操作，那么数据加工的时候就能够间接继承这种划分关系；如果有些业务在上报时没有进行很好地数据域辨别，导致很多类型的数据混在一份数据源里，那么数据开发人员就要在加工时进行辨别。
不管本身业务的数据源品质如何，数据开发人员的价值体现为无论基于什么上报根底都能构建对上游敌对的数仓。但也能够显著看出，如果数据源品质太过顽劣，那势必耗费数据开发人员大量的工夫在荡涤与规整上，在数仓其余方面的建设未免分身乏术，这时可能就须要思考数据源治理的事件了。
制订开发标准
一千个读者就有一千个哈姆雷特，每个开发人员的开发习惯也各不相同，所以对于多人协同的数据开发来说，制订对立的开发标准能力保障开发规范不会在外部就乱了套。
遵循建设准则
有三大准则贯通了数仓建设的始终，我将其总结为一致性、准确性和复用性。
一致性
一致性蕴含但不限于批流荡涤逻辑的统一、指标计算口径的统一和维度含意的统一。
目前少数业务都有实时和离线两种时效性的数仓需要，无论是 lambda 架构还是 kappa 架构，要保障多事件（业务下所有数据域）、跨计算引擎（批处理引擎和流解决引擎）场景下的数仓逻辑对立，须要从机制上保障而不是间接在代码中，靠开发人员的工程素养，通过手动批改来保障。
举个例子，因为数据源层面的开发变动，公参 ip 字段的解析地位要从门路 A 变更为门路 B，对于存量的上百张离线表和实时表，要做到同时变更，逻辑统一。如果一个个批改离线计算 SQL 和实时工作 JAR 包里的解析逻辑，势必会将批改工夫拉得很长，故上游接管到的数据，在一段时间内是无奈保障含意统一的。
终极解决方案是通过数据开发中台，保障全链路的逻辑一致性，应用界面拖拽代替代码开发来建设和批改数仓。但因为业务数据的复杂性极高，这种计划的研发投入和保护老本也特地高，故目前大多数业务应用到一些折中的计划。
目前曾经实现的是批流荡涤逻辑的机制一致性。
同理，数仓的命名（表名、维度名和指标名）也须要在全局有一个对立的标准，防止在一个数仓中呈现同一个指标，在不同表里叫不同名字的难堪局面。
准确性
准确性是数仓开发的生命线，对于心愿应用数据驱动的业务来说，一份不精确的数据的危害比没有数据还要大。更细地来说，准确性可分为明细层字段的准确性，和聚合层计算逻辑的准确性。
明细层字段的准确性能够通过上报校验或者白名单入数仓来标准，上报校验的后果定期反馈给上报开发方进行修改。白名单过滤掉不合标准的数据，保障数仓内的数据 100% 可用，但因为更新白名单的老本高，并且会抛弃相当一部分业务数据，很少被正式业务所采纳。
聚合层计算逻辑的准确性因为和业务耦合较深，个别通过业务开发间互相的代码 CR、产品经营的数据敏感度和测试同学的用例测试来保障其准确性。
复用性
数据分层将数仓各个功能模块解耦，别离满足不同等级的数据需要，是重要的数据加工伎俩。这里二八定律仍然无效，即 20% 的表能够满足 80% 的数据需要。依据每一个需要，从流水数据一路开发到利用数据的烟囱式开发是不可取的，因为在业务量扩充后，保护这些数据的对立就会变成一件十分麻烦的事件。
（四）构建数据模型
无论上游的数据源如许简单，数据上报是否标准，数据工程师的必备技能就要求可能将这些数据进行分类、筛选和解决，产出一套对上游来说含意清晰、应用便捷的数仓。
绝大多数业务，其根底数仓表都能够分为流水表和维表两大类，在此之上能够建设各种类型的聚合表、利用表、模型表等，形成如图所示的大抵援用关系。
流水表
流水表是对用户的任意一个在事实中产生的不可拆分的行为的记录，也可称之为原子行为。例如交易就不是一个原子行为，因为其中蕴含了很多的过程；而下单、点击领取、领取胜利能够算是——至多在一些简略业务里能够算是——原子行为。相似的还能够推广到一次瞬发技能开释、一个页面曝光、一次扫二维码、一条聊天发送等等。
依据应用频率，有些流水表须要进行肯定的数据过滤来让上游更不便地了解和应用。例如有些数据源中会含有某个数据域内【非胜利】或者【已知的显著异样】数据，那么在设计这个数据域的根底数仓表时，间接过滤掉这些数据，就要比把所有数据都落表，再告知上游所有应用方去过滤掉下面 2 种异样数据要好得多，即谓词下推。这样一来是应用方须要了解的内容更少，二来能够防止不同应用方自行过滤掉不同范畴的数据导致的上游某些指标的计算口径不统一的问题。
与之匹配的操作是，适当减少原始层数据的存储工夫。这样如果须要对问题数据进行剖析时，也能够在不影响根底数仓的状况下独自对原始数据从新解析和剖析。
轻度聚合表
轻度聚合表次要实现对类似数据域的指标聚合和口径对立，并且保留局部重要的去重参数以便应用层进行后续计算。
可加和类指标（次数、金额等）从流水层须要通过一些计算逻辑能力变成对应指标，这个口径对立保护在轻度聚合层，不仅上游应用方能够防止了解简单的计算逻辑，间接应用轻度聚合层加工好的指标，而且在口径须要批改时能够做到无需上游改变，同时失效。
轻度聚合层很显著地体现了数仓建设准则中的一致性和复用性。
维表
维表是对任意一层数据表中信息的关联与拓展，字典表也算一种维表。
流水层和一些聚合层不不便间接开展（比方某个视频的 37 个属性）的字段，能够保护在维表中，上游在应用的时候进行关联。维表在指定的主键下只有一条行记录，但能够很宽。不倡议在雷同主键下保护 2 张及以上的维表（除非有应用频次和效率的考量）。
个别状况下维表须要落地一份存储供上游应用，而不是从原始数据层间接解析后写在关联逻辑里。一方面防止读取上游表全副分区的状况，另一方面使上游维度的应用保持一致。
模型表
基于根底数仓能够依据应用需要构建一系列模型表。以下举两个例子简略形容其应用场景，其余品种的模型表能够触类旁通。
用户模型表不仅能够保留性别、年龄、学历等根底信息，也能够附带起源渠道、活跃度、进行某些要害行为的次数、内容生产习惯等业务拓展信息，提供更全面的剖析根底。
漏斗模型表能够统计群体用户在某种周期内，每一个步骤的操作。在内容类利用里，能够是用户从进入利用的每一步跳转直到退出的过程；在交易类利用里，能够是从浏览、加购物车、下单、领取直到实现售后的过程。
数据利用
（一）数据加工
根底数仓大多数应用存算拆散的形式，凑近应用层逐步开始应用到兼具存储和计算能力的剖析引擎来提供对内对外疾速的数据查问和剖析服务，例如 Clickhouse、Impala 等。
计算引擎的抉择以不影响计算时效性，提供丰盛的加工函数为规范；存储介质的抉择须要满足业务数仓适当的数据冗余、数据回溯和排查溯源的需要。Hive 仍然是低成本存储的较优抉择。
（二）数据血统
数据血统相似族谱一样，反映数据加工链路上的关联关系。由此咱们能够弄清楚一份数据源能够影响到多少上游数据，反之亦然。数据血统的准确水平能够分为表级别、字段级别和行列级别，能够通过剖析执行语句，或解析计算引擎的执行打算来实现。因为业务计算逻辑的复杂性，血统剖析个别由数据平台提供服务。
表级别的数据血统曾经由欧拉 – 腾讯数据资产平台实现。最精密的行列级别数据血统是数据链路工业化的根底，将来能够实现数据上报、数仓加工、可视化展现全链路的齐全拖拽式开发，有可能成为下一代规范数仓开发方式。
（三）数据品质
数据品质包含数据源的品质和数仓品质。
数据源品质
上游数据源的品质间接影响数仓品质的好坏，要求数仓开发团队人为地批改上游数据源的办法既浪费时间（逻辑校对工夫和计算工夫）又不便保护，最终造成臃肿的数仓逻辑。
数据源品质能够按三级规范进行要求：
- 有没有：字段是否有上报。
- 对不对：上报是否合乎该字段应有的格局。
- 准不准：字段的内容是否在业务内具备正确的含意。
三级规范顺次递进，假如一个业务的内容 id 是 11 位字母 + 数字的组合，如果一条上报的这个字段合乎这种组合形式，但在全部内容维表中都找不到这个 id，那么只能说这条上报达到了【对】的要求但达不到【准】。
对于成熟的业务来说，上报平台能够同时测验数据源的品质，在全局和局部细分维度上输入数据源品质报告，其余业务则可能须要肯定的人工开发操作。无论应用什么形式，对每一个上报方的数据进行分类校验后，都能够输入一个准确到字段和事件级别的品质报告，再依据这个品质报告，根据事件和字段重要性调配品质分权重，最初归一化，就能够失去每一个上报方的数据源品质得分，之后就能够依照业务的紧急水平推动批改，或者实施另外的品质奖惩措施。
依据校验数据的关联性，能够将校验类型划分为对单条数据的独立校验和对群体数据或关联数据的联结校验。【有没有】和【对不对】属于独立校验，【准不准】属于联结校验，在实际操作过程中，倡议将这两种类型的校验逻辑解耦，并逐级进行校验。对于校验论断，因为最终的指标是推动上报批改，所以切忌平铺式列出所有问题，应该依据优先级和重要水平进行排序，做成不便上报方了解和执行的列表，一一进行修改。如果剩下 1% 的数据有些问题，如果对业务影响不是很大，能够疏忽而不是持续耗费大量人力来持续排查解决。
数仓品质
数仓品质这个命题范畴较大，包含了数仓的准确性，及时性，一致性和应用便捷度等等。这里次要探讨两个点：异动监测和数仓复杂度。
如果说对于一个较为安稳的业务要害指标（如 DAU，GMV 等），在上涨了超过 50% 的第二天，还没有预警收回，那么就是异动监测没有进行到位。监测数仓数据量和要害指标异动，能够基于数据中台，也能够自行设置定时工作，无论是哪种形式，最终都要告诉到开发负责人，及时排查问题并给出解决论断。
如果一个业务数仓中建设的表数量和复杂程度，远远超过了业务自身的复杂程度，那么就须要思考，数仓的架构设置是否得当，复用性是否能够晋升。这种剖析应该在数仓开发的各个阶段及时发现并且批改，防止因为臃肿的数仓，拖慢了业务倒退的速度。
（四）数据试验
“购买按钮设置成绿色还是橙色，用户的下单志愿更高？”
“应用什么样的疏导文案，用户更可能在线上为公益活动进行捐款？”
对于用户群体的试验个别须要几天甚至几周的工夫能力得出相信论断，单层试验能够让咱们晓得上述问题的答案，多层数据试验能够让咱们更多地晓得其余问题的答案。
单层试验
相似于控制变量法，单层试验将用户根据某种策略分成不同的群组，取其中的局部群组进行两种或三种策略的试验，并设置对照组。
在理论验证开始之前，首先进行空跑期验证，对于试验想要观测的指标，在空跑期内保障各个组之间的差别在可承受的范畴之后，进行理论验证。验证完结后通过假设检验，得出是否能够认为指标的变动是因为策略差别所导致的论断。
多层试验
单层试验进行的最多试验数是有下限的，并且因为业务稳固的需要，尽量避免把所有的用户都同时置于试验之中。多层试验就是在单层试验的根底上倒退而来。
多层试验的外围是用户分群，在单层用户的根底上，对用户 ID 进行重新分配，保障同一层不同分桶内的用户是平均的，且任意两层的用户是正交的，此时每一层正在进行的试验都能够看做是一个单层试验，多层试验大大拓展了可同时进行试验的个数。多层试验的层数取决于用户分群算法的优劣，以及进行试验的关联性等。
（五）数据接口治理
存储在数仓中的数据，是无奈被普通用户间接拜访的，要想进行即席的数据拜访，须要不拘一格的数据接口来实现。
单个的数据接口如果由开发同学自行保护，既不方便管理，又不能保障接口性能的对立。长此以往容易造成有些接口尽管还在提供断断续续的性能，然而实现它的代码仅存在于传说之中。
数据接口治理平台 Homo 数据服务门户提供了一层形象性能，其内侧面向数仓，能够提供多种数据库的连贯与查问，并由数仓开发同学依据需要组装查问逻辑；其外侧面向用户，体现为一个个数据接口，依据不同的申请量和时效要求进行缓存和其余性能优化。
（六）数据进口治理
“团队对外提供的数据，哪些被真正利用起来了？哪些需要占据了大量的开发人力，但最终几个月只被查看了一次？”
数据进口治理平台能够监控到所有数仓提供给内部的数据，并对应用频次和数据成果进行肯定水平上的计算，反过来对数据需要开发提供领导倡议，防止人力破费在低价值数据的开发上。
（七）数据布局
提给数据团队的需要无穷无尽，如何从更高层面设计数据团队的工作方向，防止被零星几个需要阻挡了视线，在吸纳了原 Uber 数据负责人参加设计的腾讯视频数据工程团队布局后，整顿如下。
数据实时化
离线数仓的时效性个别是日或者小时级别，曾经难以满足业务迅速察看策略成果并随时做出扭转的需要，实时数仓的同步建设变得越来越重要。
实时数仓的建设规范也有不同，能够齐全依照离线数仓的数据范畴建设，也能够仅用实时数仓统计要害链路的要害指标，离线链路持续承当大数据量级的多维分析和大范畴数据看板性能。在建设实时数仓的过程中，链路稳固和数据对账性能也须要重点关注。
数据资产化
数仓表应该成为数据团队的资产，相似于银行对客户资产的爱护状况一样，数据团队对不同重要水平的数据资产也要做不同品质的保障。基于良好划分和保障的数据资产，将来在对外提供服务时甚至能够量化数据的精确价值。
数据服务化
如何掂量一个数仓建设的好坏？如何将本人数仓的能力便捷地赋能内部业务和团队？
尽管目前业界没有一个对立的模型，但从数据服务化的方向上可窥见一斑。DaaS（Data As A Service，数据即服务）是近年来提出的一个新概念，通过后期积攒积淀下来的数据根底、利用教训、服务能力等，提供应用简略，功能强大的各类数据服务。
聚焦在数仓层面，数据服务化要求对外提供的数仓具备明确的含意，便捷的应用形式，并提供与之配套的应用文档。如果说你能够依据云服务厂商的使用手册，将本人的业务迁徙上云；那么数仓服务化要求在用户浏览完应用文档后，能够齐全独立地应用数据团队所提供的数仓。
数据智能化
“每日的数据变动，是什么起因导致的？如何提前一步，预测可能产生的用户群体行为？”
业务指标每日都会存在或涨或跌的状况，有些是周期相干的，有些则与经营或其余事实因素相干。归因剖析能够依据已有数据，得出哪些因素更多地导致了数据的稳定，无论是正向促成还是负向消退，其中隐含的数据根底是数仓领有足够多的可供剖析的维度，并且足够精确，否则剖析的论断可能因为数据品质不高导致与事实相同。
数据预测能够依据周期，自定义规定等对将来一段时间内的业务指标进行预测，在预测安稳运行后能够依据预测后果进行经营策略上的调整。目前技术上有多种归因预测模型在应用，使用了 Facebook 的 Prophet 模型的天眼平台，实现了对业务数据的归因剖析和数据预测。
数据治理
数据治理是一个宏大的工程，本章节的探讨兴许不迭数据治理全貌的十分之一，但我仍然想在无限的了解范畴内聊聊数据治理。因为数据要想体现其领导业务的价值，只盯着数仓的一亩三分地是远远不够的，数据开发同学要踊跃染指整个数据的上下游流程，了解多个零碎的外在逻辑（下图中的绿色文字），能力建设出高质量的数仓，并打造数据驱动型的业务。
（一）上报治理
作为数据的源头，上报的品质间接关系着数仓的品质。有没有、对不对、准不准是上报倒退过程中顺次要解决的问题。一个人造的矛盾点是做上报开发的同学，自身简直不会应用到本人开发进去的上报数据，如果没有一套无效的上报测试和管理系统，仅靠每个开发同学集体的自我束缚很难维持整体上报的规范性。
解决这个矛盾的方向是标准化采集上报工具和简略可执行的上报标准流程。
有条件的业务能够开发本人的采集上报工具（SDK），实现上报机会、采集参数地位的对立，将开发人员从每个埋点的反复开发工作中解放出来。若场景比较复杂，很难用工具进行标准化，或者数据开发人力不足，无奈维持上报工具的开发与保护，能够依据本人的业务特色，制订一套简略可执行的上报标准。其中简略可执行是设计的外围，肯定要让开发人员一看就明确该怎做，否则在标准设计人员看来很简略的货色，推广到几十上百人时就会变成一场了解老本劫难，那么了解的对立又成了一个问题。
（二）参数治理
大型业务的上报参数，可能已有上千个之多。起因在于不同场景下的经营和产品团队可能是独立的，就导致了即便 2 个参数的类似度高达 90%，但上报的字段名却是不同的。
这就是上报凌乱的另一个问题：参数收缩。对于存量业务，从熟悉业务参数到找到类似参数并进行整合，上下游配合批改，是一个比拟长且比拟消耗人力的操作，看到收益前的投入会十分大，但如果评估进去的收益更大，那么就须要决策者有足够的定力，去继续投入和推动。更加优雅的形式应该是前端框架的性能模块化，雷同的模块具备雷同的性能和上报参数命名。如无必要，勿增实体须要被严格地执行起来。
（三）指标治理
指标治理来到了数仓层面，同样是因为不足对立标准，导致类似度很高的指标，以不同的名称在多张表中出现，给上游的应用带来纳闷。
解决的方向之一是建设对立指标库，新增指标须要进行评审能力退出指标库并进行开发。集体认为更衰弱的形式应该是加深数仓和上游团队彼此的了解和信赖，有些比拟定制化的业务指标，能够由业务方后行计算并验证其可行性，不须要从一开始就固化在数仓层面；通过验证并确认无效的，数仓同学要想方法将其交融进现有数仓。
（四）流程治理
在业务曾经比拟成熟的数据团队内，规范化数据开发流程能够肯定水平上防止横蛮开发，进步迭代效率。DataOps 是一种合作数据管理实际，将数据开发、治理、剖析、经营融为一体的方法论，通过更好的合作和自动化来改善组织对于数据的应用。
目前的问题在于数据开发者平台在更底层还要借助公司内各种数据平台能力实现数据的加工计算，所以和已有数据平台的对接及用户应用友好度这里还有待晋升。
（五）老本优化
因为一些历史起因，有些数据表和计算工作的使用率很低或者高度反复，造成了计算和存储资源的节约，就像每次搬家的时候往往能发现一大堆素来没用过的货色。
数仓老本优化次要能够从两方面进行：计算资源优化和存储资源优化。计算资源优化次要能够通过如下几种形式：
- 定期回顾数仓计算工作，合并相似的计算工作。
- 根底流水的解析，在实时工作保障稳固的前提下，离线工作能够不必例行化执行，仅作为实时工作的备份。
- 正当设置计算工作的所需资源，防止工作申请远超于理论需要的计算资源。
- 适当地用视图代替理论计算。
存储资源优化次要能够通过如下几种形式：
- 依据数据表上游应用状况，正当设置生命周期。
- 针对上游数据应用的时效性，正当抉择存储引擎。
- 及时下线数仓中已生效的字段。
- 适当地应用视图代替实体表。
（六）价值循环
数据治理的最终目标是更大程度地施展数据价值，融入数据价值循环中促成正反馈。其中数据团队的话语权是可能进行深度数据治理的先决条件，数据治理的成绩个别在两三年后能力缓缓浮现，属于长期价值投入，如果没有肯定的根底是无奈坚持下去的。数据治理的后果是数据品质的晋升，进而能够在局部场景下产生业务决策，促成支出的增长。在这种正向驱动的作用下，数据的价值进一步凸显，数据团队也有更多的资源来持续晋升数据品质和服务水平。
但数据不是万能的。在强内容品质、特定人群共识、内部公司合作等场景下，无奈仅通过数据大幅晋升业务的要害指标，这时更要害的业务驱动力来源于产品设计的和经营治理，此时数据团队更多的时候是提供根底的经营数据分析，以辅助和倡议为主。
结语
最近的几年内我经验了数据上报和数仓架构降级、批流一体化实际、数据工业化降级，见证了试验平台、数据 BI 平台、归因预测平台、接口服务平台的从无到有，负责过每日千亿级原始数据量的业务场景，也负责过刚诞生的新业务。暂且把这些零散的教训汇聚总结起来，总结出不依赖于腾讯外部平台的方法论，心愿依此方法论能够在任何一个组织里依据理论条件设计并开发数仓。
本文章中的数据工程次要包含数据仓库技术和数据布局治理，对于大数据平台开发和数据迷信领域下的数据利用的内容绝对较少，受限于作者的知识面，这部分待我有了更深的了解后，再来更新。
举荐浏览
万字避坑指南！C++ 的缺点与思考（上）
看完这篇，成为 Grafana 高手！
10 大性能陷阱！每个 C ++ 工程师都要晓得
AI 绘画火了！一文看懂背地技术原理
