更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

ByteHouse 是火山引擎上的一款云原生数据仓库，为用户带来极速分析体验，能够支撑实时数据分析和海量数据离线分析。便捷的弹性扩缩容能力，极致分析性能和丰富的企业级特性，助力客户数字化转型。

全篇将从两个版块讲解 ByteHouse 的技术业务场景及实践经验。第一版块将核心介绍 ByteHouse 于字节内部的业务应用场景，以及使用 ClickHouse 打造实时数仓的经验。第二板块将集中讲解字节基于 ByteHouse 对金融行业实时数仓的现状的理解与思考。

字节跳动实时数仓经验

基于内部产品的业务背景

业务和数据之间有着什么样的关系？在进入主题前，先来了解一下相关业务背景。

在字节跳动内部，不同的业务线及产品背后，其实是有着大量的中台在进行支持。以抖音和今日头条为例，从内容运营的角度，核心逻辑是怎么样把优质的内容生产出来，准确地分发到不同的用户并且及时的收到反馈，以此来不断形成一个迭代闭环。从用户运营的角度，是该怎么样去协助客户进行有效的广告投放，让他们能够精准地触达到目标用户。

在这两个闭环中间，本质上都是跟数据流转有很大的相关性，也就是数据中台的能力，进一步就涉及到对实时数据的需求，通过对实时数据的收集处理和分析，运营就能更快的去迭代内容、收集和分析内容投放的效果，从而能更精准地触达到用户。

以 ROI 视角思考实时数仓需求

实时数仓，本质上是由原来的离线数仓所衍生出来的需求。业务场景对数仓的需求，已经上升到对实时数据分析能力的增强，以及对离线数仓的实时性的增强……

在这么多的需求之下，中台团队应该怎么去评估和量化这个需求，进行数仓的优化？

需求的评估和量化主要分为两个层面，怎么样通过实时数仓来衡量产出的效果，以及在产出里我们的投入又有哪些，本质上依然是 ROI 导向。

从产出的角度来看，相比起离线数仓，实时数仓更具有时效性和准确性。时效性，是指从数据源到数据的计算，再到数据的落地可查，这个过程都是完全实时的，而且保证时延是最低的。当数据落盘之后，用户需要的每一条查询尽可能的快。而从准确性来说，不管多么复杂的数据加工链路，实时数仓都不会因为节点抖动或其他问题，导致数据的重复或者丢失。

从投入的角度来看，当实时的数据链路被搭建起来之后，一定还要考虑的是开发、运维以及资源的成本。从开发效率来说，实时数仓是一个不断迭代起来的需求。最开始的时候，团队希望是能快速的构建起一条数据的链路，但在实际项目推进的过程中，业务场景需求是在不断变化的，因为实行要求高，所以实时数仓迭代的速度也会比离线数仓快很多，所以更需要的是能更快速的去调整数据和指标口径。

其次，还有可运维性，就实时数据分析来说，可回溯性以及及时监控和快速恢复等能力都是非常重要的。最后就是要尽量保证资源利用率达到最高。

选择 ClickHouse 的原因

面对这些需求，ByteHouse 团队选择了 ClickHouse 作为实时数仓的承载。

时效性、数据准确、开发运维成本低，这些跟 ClickHouse 的特性是高度相关的，也是 ByteHouse 团队选择 ClickHouse 的重要原因。

首先，ClickHouse 的性能很快，尤其在单表场景下，它能提供非常快速的查询性能，这也是很多用户选择它的原因之一。其次，ClickHouse 可以通过增加机器资源，去提升具体写入和查询的性能，基于已有架构，ClickHouse 可以实现非常好的非侵入式部署，不管是前面是大数据平台数据湖，后面是什么样的 BI 应用，ClickHouse 都可以和上下游去做到无缝的对接和整合。最后， ClickHouse 硬件资源的利用率也比较高，可以用更少的硬件资源来达到一个同类产品的效果。

ClickHouse 作为实时数仓储存层的问题

但 ByteHouse 团队在使用 ClickHouse 的过程中，也发现了一些问题。

第一，写入要求方面。当数据量非常大的时候，ClickHouse 还是会遇到吞吐量的问题。另外，原生的 ClickHouse 对于只有一次写入这方面的保障是不够好的，而且原生的 ClickHouse 很难做到高效的数据更新，但这个能力对于实时数据写入来说是刚需。

第二，查询的性能方面。ClickHouse 单表查询性能很快，但是多表场景可能表现的没有那么好，这个问题跟查询机制有关，就算通过扩容也很难去解决这个问题。

第三，在大规模的使用场景下，比如说要去做节点的重启，ZooKeeper 带来的稳定性问题。由于 GUI 的缺失，所以当用户要去做一些简单操作的时候，需要大量的手动执行。

字节 ClickHouse 的演进历程

以上问题一定程度上限制了 ClickHouse 作为实时数仓选型的存储层的能力要求，所以字节内部对 ClickHouse 做了进一步的优化演进。

第一个阶段，2017 年，团队开始试水 ClickHouse 来作为 OLAP 的引擎，初步使用在用户增长分析的业务场景。提到用户增长分析，本质上是说在百亿、千亿甚至万亿的数据量下面，怎么样去做到快速的分析？经过各种 OLAP 的选型的比对，最终发现 ClickHouse 非常适合这种类型的数据分析。

第二个阶段，随着不断的使用研究和增强，ClickHouse 也扩展到越来越多的业务线。在字节内部，有一个叫风神的 BI 平台，底层也是使用了 ClickHouse，来支持各种各样的报表。随着内部的规模扩大，以及对应场景范围的扩大，其实也带来了很多的问题，比如 ZooKeeper 和运维能力的问题，还有怎样去尽可能的利用不同集群之间的空闲资源的问题，这些都是明显的短板。

前两个阶段的优化演进主要是修补了 ClickHouse 的弱点。

第三个阶段，把大宽表的引擎扩展到通用引擎。在这个阶段，研发团队增加了非常多的底层优化，添加了数据更新的能力以及自研了优化器，使 ClickHouse 可以支持更多的分析场景，变成一个更丰富的场景化解决方案。

第四个阶段，ClickHouse 使用的内部量级已经达到 18,000 台，最大一个集群也达到了 2400 台。新的挑战变成了如何在业务继续增长、数据分析需求继续增长的情况下，不去增加更多的资源。针对这个挑战，研发团队对多级资源隔离的能力存算分离架构进行了升级。

以上就是 ByteHouse 团队在过去几年来，对 ClickHouse 进行优化演进的历程。

基于 ByteHouse 的实时数仓方案

通过这些技术的演进，字节版本的 ClickHouse——ByteHouse，就可以应用到实时数仓的存储层面。

从上图来看，各种各样的数据源都可以通过 Kafka 或者 Flink 写入到 ByteHouse 里面，然后来对接上层的应用。按照数仓分层角度，Kafka、Flink 可以理解为 ODS 层，那 ByteHouse 就可以理解为 DWD 和 DWS 层。

如果说有聚合或者预计算的场景，也可以通过 Projection 或者物化视图去做轻度的聚合，让一些数据可以更好的向上层提供服务。同时 ByteHouse 也开发了各种各样的运维的工具，比如说异常监控的报警、租户的管理、任务的管理、资源隔离等等。

ByteHouse 要做到实时数仓里边的存储层，其实离不开刚才说的几种能力。比如说实时的数据引擎，ByteHouse 一方面提升了数据写入的吞吐量，另外一方面也通过语义的支持，写入的时候做到不重不漏，这样可以更加稳定的去消费实时数据。

除了实时数据引擎，ByteHouse 也有数据更新引擎，可以保证在数据落盘的时候做到实时的数据更新，保证整个链路的数据时效性。

从查询性能的角度，ByteHouse 也增加了业界唯一自研的 ClickHouse 优化器。通过优化器，可以保证不管是在单表查询还是多表关联的场景下，ByteHouse 都可以有强悍的性能表现，从而丰富和扩大了 ByteHouse 的使用场景。

在架构层面，ByteHouse 也有存算分离的选择，在一套产品中可以提供选择用 MPP 的引擎还是用原生的引擎，不管用户的数据规模多大或者多小，都有比较合适的选择。

ByteHouse 的实时数仓方案在内部已经广泛用于很多场景，比如面向商家、达人等等实时盯盘的场景，用户会根据实时大屏中的指标，及时的去调整运营策略，或者直播的投放选品策略。

很多场景对指标的聚合度要求高，对时效性、稳定性、数据的一致性要求也比较高，ByteHouse 都可以很好的支持和满足。比如说实时分析能力，ByteHouse 可以提供数据集至 BI 看板，满足运营更精细化的需求。达到及时的观察线上指标，验证特殊场景的效果。除了实时性之外，ByteHouse 也提供了灵活的多维分析和监控的能力。

金融行业实时数仓建设思路

本版块将核心讲解字节基于 ByteHouse，对金融行业实时数仓现状的理解与思考。

数据技术现状和趋势

在以往，金融行业的数据技术还是基于经典的数据仓库，而数据仓库在过去十年也经历了一些升级。2015 年到 2017 年，数据仓库从集中式升级到了分布式，增强了可拓展性，随后再发展至大数据平台。过去十年，是从无到有的过程，不断地解决了金融行业一些数据的全量的存储，包括实时和离线的计算问题。

第二阶段，2018 年到 2021 年，批量计算逐渐成熟，金融行业开始有实时计算分析的需求，而这个阶段更多的是通过打补丁的方式，把离线和实时分开去计算。

第三阶段，从 2021 年至今，越来越多的金融行业用户去提出数据湖相关的需求，包括冷数据，非结构化数据的处理和分析……从某种角度来说，数据湖更像是大数据平台的技术迭代或者升级。

对于实时数仓，在金融行业它更多的像是数据湖和大数据平台的关系一样，是某一个细分场景的升级和迭代。比如说在金融行业里，像大数据风控、反欺诈或者说异常的监测场景，这些对于数仓的实时性能力要求更高，倒逼着对数据仓库做细分能力的增强。本质上来说，金融行业的实时数仓，是对于数仓和大数据能力里的一些实时性能力的抽象结合以及升级。

实时数仓建设方案

金融行业实时数仓建设方案从落地层面上，有哪些现有方案可以运用和借鉴？

首先，是 Lambda 架构。大部分实时数仓，都是从 Lambda 架构演化而来的。Lambda 架构是将数据分成实时数据和离线数据，针对实时数据，用流计算引擎来做实时的计算；针对离线的数据，用批量计算引擎，分别将计算结果存储在不同的存储引擎上面，再对外提供服务。Lambda 架构的优点，是离线和实时数据是有各自计算的效果，既能保证实时数据为业务提供服务，又能保证历史数据的一个快速的分析。但是 Lambda 架构的缺点是离线和实时数据的统一性比较难保障。在离线的数据之后，需要通过数据清洗的方式来保证强一致性。

其次，是 Kappa 架构。Kappa 架构将数据源的数据全部转化成一个流失的数据，并且统一到流失的计算引擎上面。这种特点使得 Kappa 架构变得相对比较简单，但是不足之处是需要确保这个数据都是实时数据，哪怕是离线数据需要再去转化。如果整个的数据流都是以流式数据为主的时候，可能更偏向于用这个 Kappa 的架构。

再者，是数据湖流批一体的架构。在这个架构下，批流的计算和引擎都得到了统一。另外，在整个数据湖流转链路的各层，都会支持 OLAP 的实时查询。当然查询引擎可能会有一些局限性，所以导致它对于性能要求非常极致的场景没有那么适合。数据湖其实是一个相对比较完善的实时数仓方案，它也可以支持更大规模和复杂的应用场景。

但由于数据湖的方案可能完善度比较高，所以一开始的启动成本也会相对高一点。如果说团队的规模比较大，或者对于实时数仓的需求或者结构非常复杂，那其实数据湖的方案是比较合适的。

最后，MPP 储存方案。使用 MPP 作为实时数据存储层，本质上其实也是 Kappa 架构的一个变形。基于 Bytehouse 对 ClickHouse 能力的升级，对数据链路的简化，以及开发效率的提升做了进一步的增强。

那 MPP 储存方案的好处是什么呢？在初期，用户可能对实时数仓的需求没有那么复杂，或者是大数据研发团队的规模没有那么大的时候，如果采用数据湖方案，可能需要投入更多的资源。这个时候，可以先选择使用 ByteHouse 的存储方案来作为实时数仓初步的构建，快速而敏捷的去构建起一套实时数仓的架构。

案例一

接下来简单介绍 Bytehouse 帮助金融行业客户去做实时数仓落地的案例。

第一个案例，Bytehouse 帮助一家股份制银行做实时运营监控的业务场景，通过各种数字化的工具，来促进银行用户的增长，实现数字运营的闭环。

实时运营监控有几个层面的数据分析，比如说一方面去分析用户的获取渠道，评估不同的渠道的获取成本。以及针对不同用户属性的 ROI 表现，可以搭建运营指标的评估体系，设计宏观的 ROI 看板，来评估产品的获客和运营效率的表现，针对用户触达的场景进行一些细化。从执行层面来说，可以通过数据的异常来发现线上的问题，或者通过实时数据的复盘，去解决产品和运营项目上线以后的效果。

在技术层面上，其实就需要 Bytehouse 的一些能力来做支撑，比如说高数据的吞吐和写入，整个数据可见的超低时延，还有非常快速的数据查询能力，保证在数据写入和查询的服务下面高可用的支持。

火山引擎 Bytehouse 团队会分几期去帮助客户落地这些需求。比如说客户总体的目标是希望通过数据看板、大屏、周会周报等一些管理手段，来实现产品运营情况的监控。在第一阶段，可能就会上线一些整体的指标呈现能力，从大的方向上去监控一个产品的整体方向。第二个阶段，可能会上线产品运营团队日常关注的可以直接去指导和优化产品运营动作的一个指标。第三个阶段，按照客户个性化需求，上线用户行为，分析细节指标等细节化模板，有效的帮助运营团队去细化和增强运营能力。

Bytehouse 不管是从写入的性能，到数据的延迟，开发的周期，以及数据推送的频率，都能非常好的去满足运营人员对于数据方面的需求。这个项目上线后，也得到了客户的非常不错的反馈和评价。

案例二

第二个案例，Bytehouse 帮助一家银行的信用卡中心实现实时风控场景。大家应该都知道，风控对于金融机构来说是非常的重要的。传统的风控往往是通过一些批任务的处理，从各个系统中抽取风控数据，然后加工成一些风控的指标。这种方式存在一些时间的窗口，比如说按天的或者按小时的，那在时间窗口之内的风控指标可能往往处于一种未加工的状态，导致一些这种窗口期内的风险指标是无法获取的。另外，银保监会的证监会也会不定期的去出台监管的新规。对于这些新规，银行或者金融机构需要做到快速的响应。说到底就是需要去修改一些业务的逻辑，自定义风险监控的口径。

针对上述的这些需求，金融机构可以通过 Bytehouse 去实时的拉取数据，特别是公共数据，保存入库后将这些数据流推送到风控的规则引擎。可以在规则引擎中通过编写 SQL 语句，或者编写各种各样规则，对于数据进行加工，定义风控规则，从而实现风控规则的快速迭代。同时，也可以结合驾驶舱 BI 大屏的应用，给管理层提供决策数据依据。

在这个落地案例里面，Bytehouse 也只是做到了初步的上线，但目前已经可以覆盖日均万笔的风险交易，处理千万级别的行为数据，在这种数据规模下，Bytehouse 也仍然保持了一个比较极致的查询性能。同时，Bytehouse 也非常快速的帮助业务人员以及风控人员去整合各种风控数据和计算指标，并且结合已有的规则引擎，去做到优秀的风控管理。

点击跳转 统一的大数据分析平台Bytehouse 了解更多