共计 6252 个字符，预计需要花费 16 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【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 理解更多
