ByteHouse 基于 ClickHouse 优化实现实时数仓场景突破

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带来的稳定性问题。由于可视化管控工具的缺失，所以当用户要去做一些简单操作的时候，需要大量的手动执行。

字节ClickHouse的演进历程

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

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

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

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

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

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

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

基于ByteHouse的实时数仓方案

通过这些技术的演进，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也提供了灵活的多维分析和监控的能力。

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

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

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

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

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

金融行业实时数仓建设方案

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

第一种是实时数仓有多种架构，其中Lambda架构是最常见的一种。Lambda架构将数据分为实时数据和离线数据，使用流计算引擎处理实时数据并将计算结果存储在不同的存储引擎中，使用批量计算引擎处理离线数据。Lambda架构的优点是能够保证实时数据提供服务，同时也能快速分析历史数据。但是Lambda架构的缺点是难以保证离线和实时数据的统一性，需要通过数据清洗来保证一致性。

另一种架构是Kappa架构，它将数据源的数据全部转化成流式数据，并使用流计算引擎处理。这使得Kappa架构相对简单，但需要确保所有数据都是实时数据，即使是离线数据也需要转化为实时数据。如果数据流以流式数据为主，则更适合使用Kappa架构。

数据湖流批一体的架构将批处理和流处理的计算和引擎统一起来，并支持在各个层级进行OLAP实时查询。但是查询引擎的性能可能会受到限制，因此不适用于性能要求非常高的场景。数据湖是一个相对完善的实时数仓方案，也能够支持更大规模和复杂的应用场景。然而，由于数据湖方案的完善度比较高，启动成本相对较高。如果团队规模较大，或实时数仓的需求和结构非常复杂，则数据湖方案是较为合适的选择。

最后，使用MPP作为实时数据存储层也是一种常见的架构，本质上是Kappa架构的一种变形。通过ByteHouse对ClickHouse能力的升级和数据链路的简化，以及开发效率的提升，MPP储存方案得到了进一步增强。

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

案例一：实时运营监控场景

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

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

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

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

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

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

案例二：实时风控场景

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

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

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