简介：通过本文，咱们将会介绍小迈科技如何通过 Hologres 搭建高可用的实时数仓。
作者：
李云，小迈高级数据仓库开发工程师，数据仓库负责人
雷文，小迈数仓开发工程师；
一、业务介绍
小迈科技成立于 2015 年 1 月，是一家致力以数字化当先为劣势，实现业务高质量自增长的挪动互联网科技公司。始终保持以用户价值为核心，以数据为驱动，为用户开发丰盛的工具利用、休闲游戏、益智、静止等系列的挪动利用。以成为寰球当先开发者增长服务平台为愿景及使命，小迈心愿通过标准化的产品和服务赋能，为开发者提供全链路解决方案，以技术 + 服务全方位保驾护航，助燃产品持续增长，帮忙工具和休闲游戏的开发者晋升产品的成功率。
小迈科技累计开发 400 余款产品，累计用户下载安装量破七亿，日活 500-1000w，数据量每天 100 亿 +。围绕高质量 APP、用户增长和商业化变现，公司通过大数据技术相继搭建了商业化变现、智能推广、财务管理等 10+ 利用零碎。但用户量指数级增长，业务团队对数据实时化、精细化的要求晋升，大数据系统开始备受挑战，如何更好的通过数仓建设为业务增长赋能成为重要突破点。
二、小迈数仓倒退历程：从神策到流批一体实时数仓
为了满足业务团队的数据需要，小迈大数据技术团队从业务倒退晚期就开始建设数仓零碎，从传统的神策阶段过渡到离线数仓，再倒退到现在稳固的流批一体实时数仓共经验了 3 个阶段，从业务和技术的挑战中，一直对数仓零碎进行迭代优化，从而撑持业务快速增长。上面将会进一步介绍小迈的大数据平台倒退历程：
1、神策阶段
在最原始的阶段，业务零碎基于神策实现。APP 数据间接接入神策，初期只能看到 APP 内的行为数据，以及广告数据，剖析能力无限，不够灵便，无奈自定义解决，不能和第三方数据进行整合剖析，无奈满足业务进一步要求。但因为业务还是起步阶段，数据平台的建设以满足现有业务需要为主，如果业务有非凡需要，再独自搭建对应的剖析零碎。
2、离线数仓（引入 MaxCompute）
随着公司业务的一直倒退，服务的用户越来越多，数据量指数级增长，对应的业务零碎越来越多，每个零碎之前也是割裂的，并且零碎稳定性开始面临微小挑战。基于神策的局限性，业务开始引入阿里云的 MaxCompute、DataWorks 和某分布式数据库（以下简称某 DB）搭建离线数仓。业务的次要流程：
- 通过 JDBC 的形式拉去神策罗盘服务器，并通过 DataWorks 将数据离线同步至 MaxCompute；
- 在 MaxCompute 中通过数仓四层建模（ODS、DWD、DWS、ADS），后果数据通过 DataWorks 离线同步至某 DB；
-
在某 DB 中对接业务零碎的各种剖析需要。
离线数仓的引入根本满足了整个公司各个角色的剖析决策，但随着业务的一直倒退，会呈现以下问题：
• 零碎间通过神策零碎以 JDBC 的形式拉取数据，适度依赖第三方神策，过于耦合，神策出问题的时候，整个计算流程无奈持续，无奈满足业务的麻利剖析需要。神策复原之后，手动参加从新跑数据，节约了许多人力。
• 数据统计完之后，数据入库慢，大大影响了整个链路的跑数工夫，而业务对数据计算的实时性要求越来越高，现阶段无奈撑持。
• 数据量出现指数级别的增长，剖析维度越来越多，后果数据根本达到了明细数据级别，现有的数据查问引擎某 DB 不足以撑持这么大数据的多维度剖析，面临最大的挑战就是对百亿级规模的行为数据做低提早、高 QPS 的查问剖析。
• 为了解决查问引擎不足以撑持大数据量查问的问题，因而数据做了很多的前置计算，造成计算冗余，成本上升。
• 同时零碎越来越多，导致运维老本、开发成本也随之线性增长，导致无奈疾速满足业务的各种诉求。
因为下面论述的痛点，导致频繁呈现的景象就是数据产出变慢，常常卡死，重大影响业务决策，常常被业务部门投诉，影响极其不好。基于此，技术部门迫切需要找到解决方案。3、流批一体实时数仓（引入 Hologres+Flink）
为了更好的解决业务诉求，第三阶段在原有根底上引入了阿里云的 Hologres 和 Flink，并由 Hologres 替换某 DB，搭建了流批一体的实时数仓。次要数据链路如下：
1、日志数据和业务数据 Kafka 通过 DataWorks 实时同步写入 MaxCompute，实时落地 ODS 层；对于数据时效性要求较要的业务，间接写入 Flink，Flink 外面进行实时 ETL 解决，而后写入 Hologres。
2、三方数据则是通过 DataWorks 离线同步至 MaxCompute，在 MaxCompute 中进行数仓分层（ODS、DWD、DWS、ADS）建设，并将解决好的数据间接写入 Hologres。
3、由 Hologres 存储实时和离线数据，并间接对接下层利用，承载业务零碎的多种查问要求，实现流批一体的实时数仓。
通过第三阶段 Hologres+Flink+MaxCompute 的流批一体实时数仓建设，曾经胜利撑持小迈科技的泛滥业务，包含数据化经营，BI，数据接口，业务中台等。新架构带来的益处有：
• 数据结构化更清晰：对于不同层级的数据，它们的作用域不雷同，每一个数据分层都有其作用域，这样业务在应用表的时候能更不便地定位和了解。
• 数据血统追踪：提供给业务应用的是一张业务表，然而这张业务表可能起源很多张表。如果有一张起源表出问题了，咱们能够疾速精确的定位到问题，并分明每张表的作用范畴。
• 缩小反复开发：数据分层规范化，开发一些通用的中间层数据，可能缩小反复计算，进步单张业务表的使用率。
• 简化简单的问题：把一个简单的业务分成多个步骤实现，每一层只解决繁多的步骤，比较简单和容易了解。而且便于保护数据的准确性，当数据呈现问题之后，能够不必修复所有的数据，只须要从有问题的步骤开始修复。有点相似 Spark RDD 的容错机制。
• 缩小业务的影响：业务可能会常常变动，这样做就不用改一次业务就须要从新接入数据。
• 数据更加实时，业务决策更加迅速。
• 数据与第三方进行解耦，稳健性更强。三、为什么抉择 Hologres？
抉择 Hologres 是咱们从多个方面调研以及测试验证的论断。上面咱们将联合业务从技术和应用场景两个方面讲述抉择 Hologres 的起因。
1、反对高性能写入和极速简单查问
最开始咱们别离基于某 DB 和 Hologres 进行了性能验证，外围是针对查问、写入进行验证，因为离线数仓阶段，数据库最大的瓶颈就是查问性能和写入性能。
• 查问性能：基于目前理论的业务场景，包含简略及简单 SQL 进行查问性能验证，后期未做优化体现差不多，前面对 Hologres 的表设计和底层优化，咱们验证出 Hologres 根本能有 4 倍左右的晋升，前面也会跟阿里的共事一起做更多性能调优工作。
• 写入性能：之前在某 DB 的环境上，MaxCompute 写入某 DB 的工夫十分长（1 亿数据一个小时左右），特地是查问业务上来后，写入性能有几倍的降速，甚至会宕机。而写入 MaxCompute 数据至 Hologres 的性能体现十分强悍，1 个亿的数据导入 10 多秒左右即可实现。2、满足多个剖析场景
联合 MaxCompute+Hologres+Flink 搭建的流批一体实时数仓，使得咱们的零碎利用场景更加丰盛，次要包含：
• 实时数仓：因为 Hologres 与 Flink 集成性好，通过实时的采集数据，Flink 实时计算，间接将数据写到入 Hologres 中，就能实时构建实时大屏、实时监控预警、实时举荐、实时训练等利用，疾速响应业务需要。
• MaxCompute 减速查问：Hologres 能够间接通过表面的形式，对 MaxCompute 的数据进行查问，如果须要更高的性能，则能够将数据导入到 Hologres 中更高性能的查询处理。如果是前一种形式，则能够在数据不输入的状况下，对离线数据进行查问剖析。
• 自适应广告剖析场景：Hologres 有很多丰盛的剖析函数，比方留存剖析函数和漏斗剖析函数，这对广告业务的相干场景十分实用，无需咱们二次开发，间接就能应用。
综上所述，无论从性能撑持还是应用场景都十分合乎咱们公司的业务需要。四、百亿级用户行为剖析最佳实际
用户行为是指用户在产品上产生的行为，通过对用户行为的剖析，为提供下一步经营运策略提供辅助决策，同时也为产品迭代和倒退提供方向。用户行为剖析在互联网公司是十分广泛的一种场景，但大多数业务其外围痛点就是用户数据量大，计算逻辑简单，导致计算性能不够好，往往不能及时拿到计算结果，从而影响下一步决策。
小迈在广告人群数据分析这个场景上，数据量约有上百亿，并且有很多的数亿行大表关联查问场景，之前的零碎计算比拟吃力，常常受到业务质疑。在当初的零碎上，咱们通过对 Hologres 中表的索引设计和性能调优，曾经能达到非常明显的性能成果，上面咱们具体介绍如何实现。
用户行为剖析的流程如下：
1、MaxCompute 中寄存支出表 income_dt_test，小时周期调度至 Hologres 后果表 holo_ad_income_dt_test
2、Hologres 存储用户行为表 holo_dws_usr_label_df，通过 Maxcompute 周期性调度写入。
4、在 Hologres 中对两张表做关联 Join 计算，进行人群剖析，示例剖析 SQL 如下：
联合业务场景对表和 SQL 做了如下优化操作：
1. 因为用户支出表和用户行为表须要做关联查问，因而设置散布字段 distribution_key，保障雷同的记录会被调配到同一个 shard 上，尽最大可能缩小 shuffle，尽量 Local Join，所以设置以下散布键，大大提高了关联查问的速度，
CALL set_table_property(‘holo_dws_usr_label_df’, ‘distribution_key’, ‘product_id,device_id’);
CALL set_table_property(‘holo_ad_income_dt_test’, ‘distribution_key’, ‘product_id,device_id’);
2. 因为报表筛选常常应用 product_id、ad_id、position_id 三个字段，而 bitmap_columns 的应用场景就是等值查问，所以把这三个字段设置为 bitmap_columns
CALL SET_TABLE_PROPERTY(‘public.holo_ad_income_dt_test’, ‘bitmap_columns’, ‘”product_id:on”,”ad_id:on”,”position_id:on”‘);
3. 粗略估算每天的增量数据在 1 亿左右，因而设置为分区表，进步查问速度，数据量较小的时候不太倡议设置分区，否则会影响查问性能。
4. 在用户数去重的时候，须要用到大量 count(distinct a.device_id），然而会耗费很多的资源，因而咱们改用 APPROX_COUNT_DISTINCT (a.device_id) 形式，性能晋升很多，然而会失落肯定的精度，通过参数
set hg_experimental_approx_count_distinct_precision=20 调节精度。
通过对表构造和 SQL 的优化，咱们的广告人群数据分析可能实现秒级响应，大大晋升了计算效率，也能疾速响应业务需要。五、Hologres 读写拆散高可用实现
1、优化背景：读写不拆散相互影响
随着迁徙到 Hologres 的业务越来越多，写入工作的频率越来越高，在高峰期实例开始呈现查问异样和写入工作报错的状况。具体起因次要有：
- 每天上午十点左右是离线（T+1）工作写入的高峰期，在这个时间段大量报表统计工作汇集，对 Hologres 写入操作占用资源很多。
- 其中局部写入工作的数据量特地大，天增量的后果数据达到了几亿条，写入工夫长，继续占用资源。而又有局部后果表字段数太多，达到了一千多个，耗费资源较多。
- 写入的同时，有局部 MaxCompute 读取 Hologres 表面的工作，造成连接数应用上涨，影响其余工作。
- 出报表的时间段也是是业务进行查问的高峰期，大量写入的同时有大量的查问在同时执行，相互影响。
-
写入工作存在主动重试机制，每次 oom、timeout 或其它异样报错时，工作会主动重跑占用资源，导致大面积的写入工作异样越来越多。
2、优化伎俩：Hologres 共享存储实例部署
在这种状况下，咱们对 Hologres 实例做了一些调整和优化，配置了 Hologres 的共享存储多实例，把读和写拆散，将一个读写实例调整为一个主实例读写以及一个只读从实例，两个实例共用一份存储：
• 将业务分成不同模块，同时将报表后盾、tableau、生产业务等模块的只读查问迁徙到只读从实例
• 同步工作和大量的读写工作保留在读写主实例，不同模块数据寄存在不同的 schema，方便管理。
调整前：
调整后：
与此同时咱们还依据业务现状做了一些其余优化，包含：
1、大写入工作减少 session 级的超时工夫设置：set statement_timeout = ‘Xmin’ ;
2、写入之前对表面和内表进行 ANALYZE，更新统计信息减速写入；
3、勾销 Hologres 写入工作的主动重试机制，防止影响后续的其它写入工作；
4、缩小非必要的 MaxCompute 读取 Hologres 表面数据的操作，升高连接数的应用；
5、某几个数据量特地大的表，错开写入和查问高峰期，调整为其它时间段写入；3、优化成果：零碎稳定性显著晋升
通过 Hologres 的读写拆散实例部署和相干写入优化后，写入工作不再对查问工作造成影响，报表等零碎能提供稳固的查问服务，同时写入工作资源应用和调配也更正当，不再呈现 oom 之类的写入异样，零碎服务稳定性有较大的晋升。
后续，咱们将会尝试把不同模块业务拆分到不同的只读实例，进一步加强服务的稳定性，带给服务应用方更好的体验。六、业务价值
通过 Hologres+Flink+MaxCompute 搭建的流批一体实时数仓平台，撑持了小迈多个利用场场景，包含监控大盘，DMP 人群等智能投放，财务剖析等。显著的业务收益有：
1、下层服务共享数据
数据共享之后就由平台对立对外输入服务，各个业务线无需自行反复开发，就能疾速失去平台提供的数据撑持，缩小了数据孤岛。
2、亿级简单查问秒级响应
通过 Hologres 本身的优良查问性能，再配合建表和 SQL 的优化伎俩，大大提高了报表的响应速度，即便是用户画像、行为剖析等亿级大表简单关联查问也能很快出后果，失去了业务的认可。
3、零碎读写拆散稳定性强
通过 Hologres 共享存储实例部署的形式，让业务实现了读写拆散，同时也只用了一份存储，既保证了零碎的稳定性，同时也不会带来额定的老本压力。