这是彭文华的第104篇原创
今天带大家去看看字节跳动数据中台罗哲大佬的分享会。按照惯例，先放大佬介绍镇楼！
话不多说，直接上干货~~~先放个目录了解一下大佬的思路。
字节目前也处于数据平台向数据中台进军的道路上，并且已经有一些成绩了。
在18年的时候，字节的数据平台已经构建的比较完善了。其建设内容已经完全覆盖核心业务。这个不用过多解释哈，字节就是靠推荐吃饭的，这数据能力自然没的说。
所以在19年的时候，数据平台基本需求的建设基本就不是重点了，开始往用户体验和业务赋能方向探索，并且启动数据治理体系的建设。我理解，字节的数据治理肯定是一直在做的，因为这是根基啊！只不过19年才系统化、体系化的建立数据治理体系了。
20年的时候，开始思考商业化，并且开始追求中台服务化了。
其实绝大多数公司基本都是这个套路哈，先满足内部核心业务需求；然后再服务好外部客户，同时练好内功，搞好数据治理工作；然后再去追求商业化，产出更多商业价值。
这里也给各位中台负责人参考一下，这个是字节跳动的经验。这是国内最顶尖公司，以数据、算法起家的公司，都是这个套路，一步一个脚印。所以那些宣称买个数据中台产品、半年就能搭起来的人，你们就能知道是啥情况了哈。如果老板这么说，咱就可以抬出各种例子来跟他摆事实，讲道理，要不然后患无穷啊
关于数据平台的思考
俗话说，端多大碗，就吃多大饭。字节的数据平台已经趋于完善的情况下，自然就需要考虑数据平台的局限性，以及后续的发展。
数据平台最大的问题在于价值的有限释放，具体体现在两方面：
- 业务人员使用的成本和门槛较高
- 单纯被动赋能，功劳都是别人的
做数据的同学应该深有体会，有成果了，运营和产品拿去邀功，出问题了，全tmd是数据部门的错，俗称背锅侠。我经常被老板喊过去问这个数据是咋回事，然后回来一通彻查。所以为啥要做数据血缘啊，方便追溯啊~~~
罗哲大佬提了几个问题，基本上都是我们都需要自己想清楚的：
- 目标用户是谁？
- 要解决什么问题？
- 业务最需要的是什么？
很多人做数据中台，连这几个都没想清楚，就开始胡乱的做。找的供应商专业还比较好，会帮你梳理。要是找个半拉子供应商，所托非人，价钱压的又低，我就呵呵了。
字节遇到的问题跟绝大多数公司一样，无非就业务规模大、烟囱式建设、数据资产和治理几个方面，都是老生常谈了。出现这些问题的原因也很容易理解，信息系统建设从来都不是一蹴而就的，一点一点建设，必然就出现了烟囱；业务在前面跑，数据治理这种吃力不讨好的事情必然会延后；业务越做越大，基本上也就会出现了规模上的问题。
那为了解决上述的问题，就不能只停留在数据平台的层面了。中台的概念恰好在这个时机提出来，也恰好能满足大家对于上述问题的需求。
字节对数据服务的研究
罗哲大佬的这张图真的很有意思。
在公司野蛮生长的时期，大多数业务团队都自己养着几个数据分析师。但是玩着玩着就玩脱了，因为不同的语言就出现了，各个业务团队自说自话，一问形式一片大好，最终结果却惨不忍睹。这时候数据团队就成了业务的发言人。
于是公司就要建数据平台，将所有数据相关人员聚拢在一起，统一口径、统一平台，避免重复造轮子。这时候会造成非常多的业务线的阻碍和压力，如果不是一个强力的数据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架构应该是共存的状态。
