数据|字节造火山，又一个数据中台的故事( 二 ) https://p0.ssl.img.360kuai.com/dmfd/

值得一提的是，数据中台基于Clickhouse开发的OLAP引擎也是在此期间上线和能力改造，以解决数据分析性能的瓶颈。
这个阶段，主要解决的是效率和成本优化的问题，包括对底层架构进行升级，从接入第三方的工具，到尝试自研一些开发工具、调度工具等，使得研发和运维的效率变得更高。

2018年~2020年：

2018年应该是一个比较关键的节点，并且为字节跳动带来了三个主要改变。
一是数据中台的“成型”。
这个节点开始，字节跳动业务有了更深入、全面化的发展，继今日头条之后，陆续有抖音等现象级的爆款应用，以及孵化的新业务。“正是因为火山引擎的数据中台在头条、抖音都打磨过，所以当有新的业务出现时，可以非常快地接入。”罗旋指出。
二是数据中台的BP化。
另一个重要变化是，在业务线变得越来越多的同时，很多业务的体量也足够大了，比如为抖音提供服务时，单纯提供一些通用型工具是不够的，而是需要更加贴近其业务场景，满足其定制化的场景需求。
这种背景下，字节跳动也开始筹备“数据中台的BP团队”，对“前端”业务进行专门的支撑。BP全称是Business Partner，类比于HRBP，组织形式上是集中式的，可以统一管理调配培养，执行上分布式到各个业务，解决业务问题。这种组织方式的优势在于，尽管BP团队向上支撑了不同类型的业务线，但向下其实是兼容了底层数据的各项能力，具备相似的技能栈，对工具引擎的学习和使用是高效且顺滑的。
雷锋网认为，除了数据中台底层好之外，字节跳动BP团队存在的基础是其企业具有强有力的组织能力，以及企业的部门墙比较低，否则怎么能让业务部门和中台组织能够很好融合？
三是真正意义上有了“客户”的理解。
这一个改变是水到渠成的。正是因为数据中台早期在支撑更早期的业务线方面积累了很多的“信誉”，为今后支撑更多的业务线奠定了良好基础，并形成了正循环。
这种视角下，需要团队不仅有对数据的理解，还要有对“客户”的理解，将业务线看成你的“客户”，还能根据需要提供一些定制化需求。

文章插图

【图：火山引擎数据中台架构图】

2020年之后：

2020年字节跳动将数据中台通过火山引擎对外开放，恰恰说明了一件事：字节跳动的数据中台已经很好服务于内部，它开始思考如何服务好外部的事情了。
无论是之前的飞书，还是如今的火山引擎，逐步将内部实践过的技术或用的好的产品开放出来，在形成商业化路径的同时，还能反馈给内部，进一步提高内部技术。
从面向“业务价值”入手
越来越多的企业经历了建中台到拆中台的过程，但不同的是字节跳动始终在坚守中台，并且还通过火山引擎对外开放了，这是为什么？
原因不难得出——字节跳动的中台发挥了应用的价值，一是上面说的BP制给业务带来了很好的支撑；二是面向业务价值构建数据中台，先判断业务的需求是什么，然后提供轻量化的工具，随之再逐步配套更多的能力。
这样的方式也延伸到了火山引擎数据中台的服务理念上来，面向应用构建数据中台。简单来讲就是，面向应用更有目标性，能更早地发挥数据的价值，让企业客户的数字化转型路径不再是一个漫长的周期建设，而是一个逐步演进的过程。换一个更好的理解方式，其实是面向企业客户实际需求，以及业务价值构建数据中台。
这与其他的数据中台厂商的服务有点大相径庭，他们侧重于搭建完整的体系，这种方式往往会给客户带来困惑：周期非常长且重。数据中台最后是搭好了，但有不少客户往往也找不到数据应用的场景，数据中台建了半天没用起来，更没发挥出应有的作用。如果此时企业没有一个强有力组织的话，很有可能“中道崩殂”。