带你去看“字节跳动数据中台服务化的发展与实践”分享会

这是彭文华的第104篇原创

今天带大家去看看字节跳动数据中台罗哲大佬的分享会。按照惯例，先放大佬介绍镇楼！

话不多说，直接上干货~~~先放个目录了解一下大佬的思路。

字节目前也处于数据平台向数据中台进军的道路上，并且已经有一些成绩了。

在18年的时候，字节的数据平台已经构建的比较完善了。其建设内容已经完全覆盖核心业务。这个不用过多解释哈，字节就是靠推荐吃饭的，这数据能力自然没的说。

所以在19年的时候，数据平台基本需求的建设基本就不是重点了，开始往用户体验和业务赋能方向探索，并且启动数据治理体系的建设。我理解，字节的数据治理肯定是一直在做的，因为这是根基啊！只不过19年才系统化、体系化的建立数据治理体系了。

20年的时候，开始思考商业化，并且开始追求中台服务化了。

其实绝大多数公司基本都是这个套路哈，先满足内部核心业务需求；然后再服务好外部客户，同时练好内功，搞好数据治理工作；然后再去追求商业化，产出更多商业价值。

这里也给各位中台负责人参考一下，这个是字节跳动的经验。这是国内最顶尖公司，以数据、算法起家的公司，都是这个套路，一步一个脚印。所以那些宣称买个数据中台产品、半年就能搭起来的人，你们就能知道是啥情况了哈。如果老板这么说，咱就可以抬出各种例子来跟他摆事实，讲道理，要不然后患无穷啊

俗话说，端多大碗，就吃多大饭。字节的数据平台已经趋于完善的情况下，自然就需要考虑数据平台的局限性，以及后续的发展。

数据平台最大的问题在于价值的有限释放，具体体现在两方面：

罗哲大佬的这张图真的很有意思。

在公司野蛮生长的时期，大多数业务团队都自己养着几个数据分析师。但是玩着玩着就玩脱了，因为不同的语言就出现了，各个业务团队自说自话，一问形式一片大好，最终结果却惨不忍睹。这时候数据团队就成了业务的发言人。

于是公司就要建数据平台，将所有数据相关人员聚拢在一起，统一口径、统一平台，避免重复造轮子。这时候会造成非常多的业务线的阻碍和压力，如果不是一个强力的数据leader和无条件信任的CEO，这个项目基本就黄了。

在中台建立之后，数据可以服务化，数据人员又可以下放到业务团队，深入业务，以业务目标为导向，帮助赋能业务线。

阿里的数据团队之前也这么玩过。车品觉大佬就曾经这么组织过，先聚拢，再打散，一收一放，都是浑厚的内功啊！

罗哲大佬的思路也是一样的，在这个阶段，启动数据BP，到业务团队中去，向下兼容底层数据各项能力，组织业务场景，向上对业务前台、业务中台、职能中台和技术中台输出解决方案。

从技术层面基本上也就这几个方面，做好数据生产，建好数据产品，治理和运营好这些数据。

但是最后一点比较有意思：对服务进行量化。

很多同学也在问，数据团队的OKR/KPI该怎么设？罗哲大佬给了一个参考：

服务提供价值度的量化就用访问覆盖度和访问量。这个用来量化团队的贡献。通过解析adhoc的查询流量，如果该查询落在数仓的那一层，则说明该层已经覆盖这个需求。然后把所有数据汇聚计算一下占比，就能得出数仓各层的查询需求覆盖度。要是所有数据都直接击穿数仓，查询ODS层，那就等于你这上面建的都白建了啊。

服务满意度的量化通过各业务团队的问卷调查来实现，主要调研范围有数据质量、数据产品/工具、OnCall服务（没细讲，应该是一次电话解决的意思）和需要提升的点。

那如何达到这个目标呢？自然是通过组织的力量。有个笑话说3000块钱月薪的人在思考世界格局，百万年薪的人在思考如何优化组织。你品，你细品~~~

这张片子里充满了工程学思维的味道，非常务实，完全是锤子钉钉子的逻辑。

人力资源和机器资源的协调、组织和平台的联动、业务痛点的点对相应、通用场景的工程能力抽象，这要是给HR部门，非得疯了不可，太干巴。咱技术人就是这么朴实无华，直击要害，就是要解决问题。

这个图很关键，但是PPT地方小，不是很好排版，我给你转化一下。

最下面是数据平台的工作，搞定各种基础数据、业务数据和各种画像。

然后就是实时和离线数仓，通过Cube注册和发布之后，在指标平台对各种指标进行管理等操作，对外提供数据服务。

另外这里也做了数据血缘的管理，方便对数据进行向上追溯和向下影响分析。

再往上应该就是数据中台服务化的核心–MFS，为C/B端提供指标查询服务。这里同时还用了微服务的理念，做了服务的监控、服务发现/注册、服务熔断/降级。这也能理解，字节的流量太大了，对于C/B端的应用，必须要高度重视，要不就闹笑话了。很多厂子里也这么玩，多一层解耦，下面应对的会更从容一些。

再往上就是各种数据应用了，A/B Test、BI平台、C/B端应用等。

这是数据架构，典型的Lambda架构。离线Spark，实时Flink。最后汇聚到各种存储，对外提供数据服务。

罗哲大佬还特意提到了微批计算，他们用的是hudi搭建的，对于一些介于实时和T+1之间的数据场景（主要是近实时场景），就可以用这套架构了。

最上面的Binlog是数据源，通过三条线往下游走，跟上面的图对应。最左边的一条线是通过DTS（数据传输服务）扔到Hive中，按天汇总后还是扔到Hive的离线数仓里，对外提供离线数据服务。

中间一条线是通过Flink 扔到Hudi中，加上离线数仓中的一部分数据，组成了准实时数据湖，通过增量的方式扔到Hive中，对外提供近实时的数据服务。

最右边一条直接走Flink之后，进行维度数据关联，到Spark/ Presto中汇聚，对外提供实时数据服务。

然后就是B端和C端的应用场景展示：

从罗哲大佬现场的讲解和这张图上可以看出，未来发展的重心还是如何让数据使用、探查的场景变得越来越易用。如果是换一家公司，可能会说怎么挖掘数据价值，但是字节的整个帝国都是建立在数据和算法基础上的，再强调这个也没啥太大的新意了吧。

原有的MFS、指标和血缘，都是为了更好的适应和满足“字段–>指标–应用”的场景。

但是之后会往知识模型的方向进行探索，绘制数据地图、建立数仓白皮书、答疑知识库等，让业务方更容易，也更简单的使用数据，提升创富效率。

罗哲大佬现场也透露，会进行kappa架构的探索。但不会搞一刀切，只是选择合适的场景进行建设。所以可以预见的是，字节数据架构中，Lambda和Kappa架构应该是共存的状态。

后台回复“字节跳动”获取罗哲大佬分享的“字节跳动数据中台服务化的发展和实践”PPT。

配合以下文章享受更佳

下载 | 实时数仓架构设计与选型

下载 | 阿特拉斯耸耸肩，数据治理法力无边~~

热文 | 什么是数据地图、血缘分析和数据资产？

案例 | 贝壳的数据中台工程架构实践之大数据开发平台

干货 | 一口气说完MR、Storm、Spark、SparkStreaming和Flink

我需要你的点赞，爱你哟