一、数据需求的产生

腾梭科技的产品发展历程经历了多个阶段。最初，我们专注于与互联网金融科技公司合作，提供网贷助贷核心对接等服务。随后，我们通过与其他友商联合打造业务获得了突破。在此基础上，我们开始将重心转向行业内的联合业务开展，并逐步实现了对全量客户群体的挖掘和线上营销。同时，我们也探索了纯线上获客新零售业务模式。这些演进不仅涵盖了业务架构和业务模式的调整，也促使了技术架构的演化。我们从单一的交易中心向多业务场景分布式应用发展，在后阶段业务系统全面的进行了微服务技术改造，以满足新零售金融场景的需求。

二、OLAP选型困扰

在演进过程中，我们产生了许多OLTP系统，包括MySQL、Oracle以及PG等等。然而，在数据规模不断扩大的情况下，OLTP系统之间出现了数据孤岛和数据割裂现象，无法进行端到端的数据关联和打通。因此，引入AP系统或工具已成为研发必然选择。但我们也面临着选型上的困境。

OLAP的发展历史已经相当悠久。技术栈中，我们使用广义的OLAP技术，如ElasticSearch和Redis等工具进行快速查询。虽然这些工具在OLAP中属于其中一种，但在数据规模扩大的后续使用中，它们不能很好的胜任我们的需求。因此，我们进行了OLAP引擎的选型调研。

在调研过程中，我们发现小团队会面临两种主要困境。对于大型企业来说，并不关心这些问题，因为总体投入产出要求虽高，但他们可能有更高的预算，并拥有更完善的技术与生态系统。然而，对于小型技术公司来说，这两个方面成为了我们的门槛——我们需要选择能够相对可控地支持后续业务发展的数据规模和灵活性高、成本相对低的工具或系统。我们需要避免陷入技术沼泽中，同时将技术门槛降至最低，避免深陷于Hadoop或SQL on hadoop技术生态中，从而让我们的业务研发顺畅而高效地进行。

我们的业务演进大概分成了三个阶段。

第一个阶段主要是基于离线数据的抽取阶段，因为从业务演进的角度来看， OLTP 系统的出现导致了端到端数据无法实现关联查询。因此，我们需要工具来打通数据源和数据源之间的联系。在第一个阶段，我们选择了Kettle，利用其ETL能力和丰富的技术组件构建报表系统。Kettle在第一阶段胜任了我们基础的报表取数工作。但是，在基于Kettle做ETL的阶段，我们仍然面临着无法实时关联查询，数据源和数据源之间查询时延高等问题。

第二个阶段，我们进行了对工具Trino的调研，想利用其在异构数据源和联合查询方面的优势，建立起信贷和风控等相关领域内多数据源间的数据连通。但是这个过程中仍存在一些技术痛点。因为Trino是基于大内存的SQL引擎，存储引擎并不是它的强项。我们还需要比较高的点查响应能力，但是Trino在处理小表和点查的场景上，有时会存在一些开销，需要结合外部数据源进行优化，才能满足响应要求。虽然之前我们已经解决了联合查询的问题，但是在数据规模扩张和实施场景演进的过程中，还需要进一步的优化。

在第三个阶段，我们探索、实践并应用了Doris。引入Doris进入我们OLAP系统的契机来自于我们在ToB项目中的需求。通过调研和使用Doris，我们发现它的整体性能以及数据规模扩张后的表现，在绝大多数情况下，都能满足我们的客户体量和数据规模要求。Doris解决了前两个阶段遇到的共同问题，能够打通数据源之间的关联查询，也能够加速数据查询速度。此外，Doris支持ISO标准SQL，与我们之前使用的MySQL OLTP系统无缝切换。同时，我们所使用的Doris是存算一体的，适用于我们后续的分库分表和定时冷数据归档业务场景。

在第三个阶段，我们引入了Doris。这主要是因为前两个阶段存在未解决的业务难题，我们决定借助Doris解决这些问题。

三、ApacheDoris实践

引入Doris之后，我们主要在两个方面进行了实践和探索，即并发查询的加速和数据架构的建设。

1、并发查询加速

因为在我们星云零售的信贷业务场景中，除了信贷以外，还有实时风控业务，需要应对低并发、高吞吐或高并发、高QPS的使用场景。我们的第一个实践方向是查询加速。

在进行查询加速时，我们遇到的第一个问题是模型选择。我们选择了Unique和明细模型，没有使用聚合模型，因为是纯金融交易系统，大部分场景都聚焦于交易事件、日志或明细日志场景，还没有使用聚合模型。后期可能会在偏实时场景中使用此模型，包括通过物化视图进行实时报表制作。

在查询加速阶段，我们遇到了很多问题，包括Doris基础模型的选择及其分区和存储分层的精细设计，这些问题耽误了我们很多时间。但在与社区的沟通中，我们更好地了解了Doris在逻辑分区和物理分桶上的设计，优化了key值、列和分桶key的设计，让我们在点查或并发查询场景下更好地使用Colocation Join方式，避免出现在较大表上进行跨节点Shuffle join的场景，提高了点查和高吞吐场景下并发查询的效率。

举两个查询加速方面的例子。第一个是在金融行业的日常业务中，我们会遇到众多的报表和数据供应场景。这些场景通常是低并发的，但需要高吞吐率。以往，我们采用了预聚合或MySQL分库的方式，但是这会带来很大的IO和CPU消耗，甚至会导致MySQL从库崩溃。现在，我们依靠Doris的多表聚合和高吞吐能力，成功解决了数据供应和离线T+1报表供应的痛点。此外，我们的后台管理系统也得到了改善，比如我们可以利用Doris提供的索引机制，进行多维度查询，以及使用高基数索引布隆过滤器机制来提高客户体验。

风控系统存在特征指标计算、特征模型以及逾期风险预测模型等场景，如B卡（逾期风险预测模型）贷中行为分析的场景，这些场景需要支持高QPS的点查。因此，我们利用Doris的key列设计和前缀索引机制来解决这些问题，基本上在key列设计合理的情况下，点查场景都能够达到毫秒级的响应。

2、数仓基座建设

第二个场景是在数据底座之上的探索。数据基础源自于我们的业务需求。我们有一些针对企业的项目，需要建立数据仓库，因为这些项目可能需要许多离线数据报表。所以我们建立了基于Doris的存储与分析的数仓底座。主要采用Dolphin Scheduler离线调度工具，DataX数据采集，或者基于JDBC catalog从源业务端或异构的数据源中做离线数据提取，亦或者采用 flink cdc做实时的binlog数据采集，并将其存入Doris数据存储。进行分析与建模后我们提供数据网关或报表系统等服务给业务人员，财务人员或实时交易大屏，Boss系统等数据应用，使得他们能够使用包括数据分析人员在内的Ad-hoc能力，实时分析风险数据。在监控方面，我们使用一套Grafana、Prometheus和Loki监控集群状态，监控Doris内存和CPU使用率，包括在实时或离线ETL执行时的compaction的稳定性及查询耗时等。

这是我们的业务模型。我们通过增量或全量方式获取业务数据，包括日志数据，然后将其实时或准实时地导入到我们构建的数据集市中。这个数据集市仍然遵循数仓的分层模型，类似于离线数仓的模型。导入后，我们将使用调度工具将其调度到T+1时间，然后将数据汇总到DW层，最终将其应用于我们的应用端。

3、业务场景落地

接下来演示一下我们在整体业务场景和落地方案中的几个小案例。第一个案例是风控大数据报表平台，正如之前所述，我们引入Doris来支持这个项目。我们的客户是一家银行，有较高的报表需求，包括风控和信贷两方面，共计近百张报表。通过前几个阶段的探索和技术手段，我们难以满足合作伙伴在业务规模和业务场景上的需求，因此我们进行了Doris方案的调研，并成功运用于风控大数据报表平台技术方案中。

我们基于海豚调度，做数据源的抽取，然后在中间构建工作流，完成ODS、 DW，以及ODS数据的 detail 加工，整体数据规模大概为 20T 左右，在这样的规模下整体任务编排和调度的性能，可以保持在5小时之内。

当前生产环境采用Doris1.2.4 的版本，在升级之前用的是 20 年Doris0.14的版本。升级后整体性能得到了提升，在没有做SQL优化的情况下，能够达到4倍的性能提升。编排调度从之前的 4 小时缩减到了现在的1小时。

我们采用了两种方式来进行数据的ETL。第一种是基于接入脚本进行T+1的数据ETL。另一种方式是基于Doris的JDBC Catalog进行准实时数据抽取。由于我们的业务合作伙伴对数据实时性要求比较高，例如交易报表和风控审核等，需要分钟级或实时效果。我们通过海豚调度做分钟级的调度，并结合Doris的JDBC Catalog进行抽取。我们的现有技术解决方案大多数报表都是T+1模式的工作流调度进行抽取。对于实时性要求比较高的场景，例如大屏或仪表盘的数据诊断，我们会使用分钟级的调度抽取。我们正在探索使用Flink CDC的方式进行更准确、更实时的场景，例如风控监控预警等。目前我们正在调研基于Streampark的Flink任务开发和管理，同时结合Doris的Flink CDC进行实时ETL，尚未投入到生产环境中。

接下来的这个案例是我们考虑日志存储分析时进行的研究。我们发现在业务开发和业务运营的过程中，有许多日志场景需要处理，包括生产异常日志和 API 访问日志等。因此，我们针对 Doris 1.2.4 版本进行了研究，以探索它在统一日志存储和分析方面的能力。虽然该版本没有使用倒排索引，但总体来看，性能基本上能够满足大部分客户在相应数据规模下的需求。

然后我们自主开发了用于实时数据采集的Flume的Java的sink的代理应用服务，并配合Doris Streamload方式，实现了将批量数据实时注入到Doris系统中。我们基于数据做了日志场景监控，通过分析API访问模式，我们发现了大量的HTTP访问场景。在业务端，我们实现了相对实时的监控预警。最后，与前文所述的日志分析场景相似，我们的客户在进行营收信贷业务（包括广告投放和自主获客）时需要用户行为数据。因此，我们研究了使用 JSONB 存储方式来收集小程序或广告投放的用户访问日志，并利用JSONB的存储和分析能力，分析用户行为以解锁用户意向。

在生产实践中，我们发现在使用 JSONB 存储格式的情况下，数据体积至少降低了70%。而之前我们在存储和压缩时使用ElasticSearch或Redis进行查询加速。客户的反馈也证明了效率的提升，获得了高度评价。

接下来分享一下星云在在线分析处理（OLAP）的发展过程中，包括在引用Doris之后，整个架构的收益。

首先，涉及到的用户群体，除了开发人员之外，还有业务人员。他们能够自主地获取和导出数据，系统可以满足多个维度下分钟或秒级别的数据查询需求。

运维成本是我们引入Doris最核心的收益点之一。由于我们是专注于业务研发的部门，相比于数据研发和运维人员，我们的实力稍显薄弱。因此，在选型阶段，我们花费了相当的精力考虑整体生产运维的问题。选择使用Doris也是希望借助其灵活的架构使运维更加简便。在生产环境中，我们基本上不需要对Doris进行独立的运维配合，因为它自身就具备保活机制和自运维的能力。

另外，在查询延迟方面取得了不少进展。从业务角度来看，包括风险控制和信贷审查，以及偏离线计算的场景。根据以往的收益，在像MySQL这样的情况下，引入Trino仅需几分钟，甚至十分钟内的查询响应时间就能显著提高。在大表的关联查询中，基本上可以实现分钟或秒级的响应速度。在点查产品中，甚至可以达到毫秒级的响应速度。

关于资源的节省，直接的效益主要体现在存储层面有了大幅度的提升。对于用户而言，他们的磁盘空间释放与需求得到了更加紧凑的管理。

四、后期规划

最后，介绍一下我们基于Doris在业务层面上的规划，我们可能还会偏向于解决业务痛点的规划。首先，我们会开发智能数据网关，该网关主要面向外部数据源的对接，对接之后会将数据写入到OLTP系统中，包括MySQL或者业务关键库，我们也可能会在之后的应用中使用甚至将其放入Redis中。

首先，我们需要做一个数据网关，主要是为了收敛多种异构数据源的场景，希望能使它更加灵活。在开始设计数据网关路由时，我们考虑是否可以从统一的数据存储位置中采集数据。我们可以基于Doris采集数据，当Doris的数据无法满足需求，或者Doris集群出现问题导致延迟较高时，我们再下发到下一级，以兜底查询。这是我们后续规划的使用场景。

第二个问题是做数据统一归档。我们的历史数据很多，因此需要对历史数据进行定期归档。但是目前的痛点是，如果没有使用OLAP引擎，或者没有Hadoop这样的生态系统，我们将其迁移到MySQL时，对历史数据的分析会变得非常复杂。如果我们将其归档到Lioak中，则整体存储占用的资源会相对更高。我们计划使用Doris来处理统一存储和归档数据的应用和场景。

五、问答环节

Q:第一个问题是在日志查询的案例里面日志查询是模糊查询吗？性能怎么样？有没有和 ClickHouse 做过对比？

A: 是的，我们所引用的版本是 Doris1.2.4，它不像最新的版本2.0一样支持日志检索和倒排索引场。我们仍然使用的是Doris1.2的稳定版本，在后来的Doris2.0中提供了倒排索引，包括日志场景，可以更高效地分析日志场景。我们使用了它的模糊匹配，虽然没有经过优化，但依然能够取得很好的效果。我们采用暴力的更新方法，在单个分区的情况下，基本上可以实现毫秒级的响应。在跨越多个分区的情况下，也能在秒级或者分钟级别满足我们在日志分析场景中的需求。

因为我们之前的日志分析方案是基于ELK（Elasticsearch, Logstash, Kibana），而ClickHouse并不在我们的技术栈中使用。虽然你刚才提到了与ClickHouse的比较，但我们并没有实际经验。不过相对于ELK，我们之前的方案已经带来了很大的收益。

Q: 第二个问题是关于风险控制大数据报表案例的。业务方问到这个大屏幕每隔多长时间会刷新一次，以及如何保证数据链路的及时性。

A：实时性要求有两个不同的场景，一是交易大屏，一是风控。针对拒绝原因或通过率等指标，两者的实时性要求不同。对于交易大屏场景，最好能在分钟级内刷新一次，间隔为10秒、5秒或10秒。而对于风控场景，则要求分钟级的实时效果。因此，在技术选择和实现上，我们有所区别。对于风控的场景，我们采用海豚调度的准实时数据采集，并配置分钟级的调度任务，将业务库中的数据抽取到Doris中。通过基于Doris的查询性能，我们可以轻松抗衡大屏的刷新。

Q：第三个问题涉及高可用性，例如在运维方面的存储是否采用了RAID技术，以及坏盘的应对处理方式。

A：关于运维，我们的高可用主要基于Doris内部的高可用机制，我们只实现了应用层面的保活机制。在大内存和高吞吐量下，可能会崩溃B1进程，但我们的保活机制可以在秒级内重启进程，确保服务正常。

在存储方面，我们会定期备份源数据，而对于B1节点的数据存储，因为我们使用三副本（大概10个节点，包括3个FB节点和7个BE节点），所以计划依赖Doris自身的副本和副本修复机制。因此，在运维方面，我们只进行了源数据的定期对等备份。