覆盖的人群非常广泛，几乎支持字节跳动内部所有业务线，覆盖绝大多数员工使用需求，每天运行20万张以上活跃的仪表盘，支持超过500万次巨大数据量的查询，每天有超过5万人在使用 。
分享嘉宾｜徐冰泉 火山引擎 技术负责人
编辑整理｜卢梦桃 巴斯大学
出品社区｜
01
在字节跳动的使用场景
主要有三个使用场景：
02
发展历程
是一个相对年轻的产品。
第一个版本诞生于2018 年，那时它还是一个简单的 SQL 查询工具，用户通过写 Query 提交去查询结果，但等待时间相对比较久。后来逐步拓展了可视化查询的能力，让越来越多没有技术背景的人通过拖拉拽的方式，去上手数据分析和仪表盘制作。
数据分析本身是离不开数据的。有一个常见的场景，想要分析的数据在数仓还没有，或者已有的不是你想要的，这对一个没有技术背景的用户来说，做数据分析的过程可能就会被卡住。所以，我们又构建了一系列的数据准备能力，以零代码低门槛的方式帮助没有技术背景的业务人员轻松完成 ETL。
为了适应不同场景的数据展示诉求，我们引入了完善的移动端驾驶舱大屏能力。在 2021年左右，为了更方便的被第三方系统集成，开放平台正式构建。
03
产品能力
目前， 平台基本上已具备了一站式的数据服务和分析能力，包含数据接入、数据整合、数据集成、查询、分析、探索、协作等一系列功能。
04
与火山引擎
了解火山引擎的朋友可能都知道，火山引擎包含了很多数据产品，也不乏数据分析类的产品，那么 跟其它产品的区别和联系是什么呢？
从产品定位来讲，特定领域的分析产品都会有一些场景相对固定的深入的数据分析和展示方法，如 AB测试中的显著性、用户行为分析的留存分析、某个用户的行为重放等等。则是更关注通用场景下的数据分析诉求的满足情况。
另外，能够打通企业内部绝大多数的数据资产，与火山引擎的其它数据产品保持紧密联动，如分析型数据库 、湖仓一体分析服务LAS 等，也可以跟 VeCDP、 等产品的数据直接打通实现数据查询。通过打通各类数据，用户可以很便捷地把用户行为数据和数仓其他数据融合在一起，用进行分析。
05
数据洞察
之所以力求对常用的分析场景、分析方法和数据资产做到全覆盖，是因为数据分析过程本来就是一个灵活、启发式的探索过程，这与做问题排查非常类似。
分析原因之前，要设置多个假设。验证一个假设后，会排除一些可能性，又会产生新的想法。在这个过程中，问题的领域有可能发生变化，如营收数据异常、或重新分析用户行为数据、查看监控数据、发现用户留存或者用户行为有异常等。
在启发式的探索过程中，快速响应非常重要的。如果不能做到快速响应，验证其中某种假设将耗费很长时间，等结果出来时可能已经忘了之前的分析思路。因此，理想情况是有一个强大的数据分析系统，只要问问题，就能快速准确地产出结果。
要达到快速响应，背后需要很多工作。
要知道到哪里能找到相应的数据，这些数据要如何组合起来，基于这些数据，要构建出什么样的数据模型来做查询，去分析结果。分析完结果以后，又可能会产生新的问题，这个链路很容易变得非常耗时，甚至有时候在一个团队内都很难去做到闭环，影响整个数据洞察的效率。
考虑到 在字节内部有众多用户，对整个公司的效率影响非常明显，这条链路需要变得更快、更简单。思路其实也很明确，就是要省掉一些不必要去做的事情，同时让必须要做的步骤更快地完成。按照这个思路，有很大的优化空间，比如把元数据的管理、指标维度体系做好，优化元数据的搜索、排序和推荐。
当用户有一个新想法时，可能发现已经有人做好了相应的图表和仪表盘，就可以直接查或者申请一下权限。又或是相应的仪表盘虽然没有，但是相应数据的底表在数仓里已经有了，可以直接去查询。
这些都能够让链路变得更快。
大多数的场景下，查询是不能省略的，所以提升查询性能非常重要，尤其是在巨大数据量上实现更快的查询，其重要性更为突出。这方面如果不能得到改善，通常来讲，就只能做两种选择，一是减少数据量，或者去做一些预聚合，但问题是在启发式的数据探索过程中，会不断产生新问题，很容易发现维度、指标或力度不满足需求，又需要去跑数据；二是用大数据量的细粒度数据去查，需要用户等待时间较长。所以，近年来， 一直在想方设法地提升查询性能。
06
用户特征
1. 海量数据的明细查询
提高查询性能后，字节跳动的用户更加喜欢用明细表来做数据分析火山移动开发平台，内部一周内被查到的数据量，基本上维持在400PB以上。每天会有 500 万次以上的查询，查询数据量过亿甚至过10亿行的这种查询是司空见惯的，基本上查询都可以在 10 秒内完成。
保持这样的水准其实是比较困难的，因为内部业务在快速的发展，分析需求也在快速增长，表规模也变得越来越大。在过去半年，查询量增长了 50% 以上。在不久之前，像抖音等业务方的查询数据量在 10 亿行左右，而现在很多数据分析已经是基于千亿行的规模。
在硬件资源基本不增加的情况下，可能很努力的把大查询从30秒左右提升到了10秒，甚至5秒内，用户觉得体验变好了，又会上更大规模的数据。这也促使不断地去提升查询性能，关注的指标是 10 秒内的查询占比，内部认为在这个时间量级内完成响应，通常不会阻碍启发式的数据分析和探索的过程。
为了实现在大数据量下快速返回查询结果，在很多方向上做了努力。
首先，在硬件与引擎方面，收益是非常可观的。更高的机器与网络配置，加上在大数据量查询上面更有优势的引擎，往往已经能够带来非常明显的体验提升。火山引擎的 是我们目前使用最频繁的引擎，其性能比开源版本 更加突出，也会拿的查询场景去做优化，为整体的查询性提供基本的保障。
其次，在应用层面，我们也会做各种各样的优化尝试，比如尽量减少需要扫描的数据量，减少不必要的消费。我们尽可能的让数据的存储方式，更匹配其查询方式，因为 本身就是在通用场景下的数据分析平台，要做到这一点是有一定难度的，根据用户的查询方式，去重新调整数据的分区分片方式，以及索引等，就会有明显的提升。
此外，还有一些常用的场景，如 join或者是在BI领域使用得很频繁的计数去重。对这些频繁使用，但是性能往往比较差的场景， 做了特定的优化，能很显著地改善用户体验。
最后，就是不同的引擎对资源的需求也是不一样的。比如说， 有两个版本，其中 CE 版可以提供比较好的性能，但存储计算不分离，成本相对较高。CDW 云数仓版的性能没有 CE 版那么卓越，但是它是存算分离的结构。我们内部也会根据用户的数据量、对查询响应的预期，去做数据存储上面的分解，把硬件资源划分成规模不同的集群。根据数据的规模，还有查询的方式，去选择最适合的引擎和集群。
上述内容也体现在了架构中，底层有一些不同的引擎，每种引擎都由火山引擎的团队针对场景做优化。数据访问层屏蔽了这些对引擎访问方式的差异。对一些重要程度比较高的仪表盘，会做预刷的处理和缓存。对查询的统计分析，我们希望能够影响数据的存储方式，进而去影响查询的组装和优化，服务于不同场景的模块。
2. 非技术人员也想做数据建模
有些场景下，现有数据不能直接查询，必须做一些处理，如筛选、连接、合并。或者在更复杂的场景下，可能需要把Mysql 的表跟 Hive 的表去做 join，这时就免不了要做一些数据模型构建。
的主要用户大多都不具备技术背景，如果遇到数据上的卡点，往往无法独立写数据处理任务，再把这个任务调度起来，在实时的场景上可能就更为吃力，这样就会影响整体效率。
因此能够做数据建模工作，是 用户一个非常迫切的需求。通过打磨，满足了这部分的需求——通过可视化的方式构建数据模型。随着模型的构建，还能够探查到到每一步数据的具体内容，真正做到了所见即所得。
在数据建模的能力上也是比较完备的，能够从超过40种数据源中抽取数据，有丰富的算子，甚至包含很多机器学习相关的算子，可以完成非常复杂的模型构建工作。
与查询场景类似，可视化建模也是为了满足通用场景设计，而增加了复杂度。用户的使用场景、数据源，包括数据本身的大小、构建出来的数据模型，会不会存在数据倾斜或者数据膨胀这种情况，其实都是未知的。
资源和人力都有限的情况下，我们要求整套系统具备比较好的稳定性和性能火山移动开发平台，能够尽量做到无人值守。用户本身没有太多的技术背景，往往不具备大数据开发领域的知识，比如参数怎么去调、为什么报错……这些都要求的平台做得更加智能、简单和友好。
从结果来看，还是做得比较成功的，这个不用写代码，门槛相当低的数据建模，在字节跳动内部也被广泛使用，任务量和数据规模也非常大。走商业化路线后，使用的客户不仅多，还给了非常正向的评价。
从架构上看，数据源、执行系统、还有最终数据的存储，其实跟一般的大数据开发平台类似。值得强调的是运行管理和监控，为了让内部还有客户环境，都能够尽可能的做到无人值守，会在任务执行当中加入一些检测，比如数据是否发生了倾斜膨胀，再及时去调整任务的执行。
为了尽可能的让门槛降低，会辅助用户去做一些操作，比如说类型的推导，根据数据源的某一个列的类型，以及后续的一些操作，去推断其最终的类型，也会尝试根据字段类型、字段名等，推断几张表之间是否存在关联关系，让用户的操作步骤更加简短，构建数据模型时更加方便。
3. 随时随地做数据分析
对移动端的支持，也是为了让用户能够在更适合自己的场景下去完成数据分析和协作。用户可以订阅感兴趣的仪表盘，或是关注某些指标移动情况，平台还可以按照用户的偏好，通过飞书、邮件等各类渠道推送给用户。用户也可以随时随地拿起手机来访问 ，主动的去做数据分析。也形成了移动端的管理驾驶舱，高层也可以频繁地使用去关注他们感兴趣的指标，做数据分析。
4. 复用意识碰上定制化需求
字节跳动强调效率，内部团队也有比较强的复用意识。大家在使用过程当中会遇到 无法满足的特殊场景。
从 团队的视角来讲，明显带有定制化色彩的需求，如果没法支持，就意味着公司业务方要花比较大的代价实现平台已经支持的功能，做平台类产品的同学可能都会有这样的困扰。
通过打造自己的开放能力解决以上诉求，如提供白标能力、主题配色能力等。甚至对于一些深度集成场景，为集成方提供了一系列的控制点位，允许集成方做深入定制化，如权限控制、查询控制，甚至筛选条件控制。
目前，内部已经有众多业务方用以上方法复用 。在商业化过程中，客户也会基于以上开放能力完成二次开发。
07
架构回顾
最后，上图为 整体架构。前文提到的大多数内容在这里都有所体现，包括零代码、低门槛的可视化建模，以及支撑海量数据快速查询的关键组件。
基于产品定位、目标以及技术架构， 已经有效提升了字节跳动内部分析效率，并且通过火山引擎数智平台VeD对外输出。未来，我们也会继续从让数据分析更快、更简单的角度，进一步优化 。
对 感兴趣的同学，可以登录官网了解试用。
限时特惠:本站持续每日更新海量各大内部创业课程，一年会员仅需要98元，全站资源免费下载
点击查看详情
站长微信:Jiucxh
