基于MaxCompute+Hologres的人群圈选和数据服务实践

本文涉及的产品
实时数仓Hologres,5000CU*H 100GB 3个月
简介: 基于MaxCompute+Hologres的人群圈选和数据服务实践

本文作者 刘一鸣 阿里云智能 高级产品专家

直播视频请点击 直播观看

人群圈选系统基本逻辑架构

人群圈选并不是一个新业务, 几乎所有的互联网公司都在做,因为这是一个基本营销场景,选定的人群要发代金券,要导入流量,要做针对性促销,要选择合适的人群,那怎么做这件事情呢?实际上要通过人群的行为特征,采购特性,关注特征,兴趣特性,甚至是教育程度等等,把人群划分成不同的组。通过划分人群组,在有限的营销预算里面,将资源投放给转化率或点击率最高的人群。

基本的业务架构逻辑如下图,自下而上。首先是标签加工引擎,主要以离线加工为主。在标签加工引擎内,会对用户历史的采购行为、访问行为、关注行为等等做很多标签,可以统计出来,哪些人对哪些商品关注过多少次,点击过多少次,留意过多少次等等,会有很多统计性的属性在里面。这些标签会导入到在线画像服务引擎内,服务引擎是给运营人员,广告主进行交互式的查询,因为要根据用户行为特征,筛选出最关注的用户群体。这个用户群体可能是30天内关注某些商品但是没有买的群体,或者是相关的上下游产品,通过行为特征筛选出来。筛选过程是一个高度交互过程,因为一个人的行为特征是非常复杂的。所以需要频繁的选择某个条件,去掉某个条件,条件和条件之间可能会做合并、去重的操作等等。直到把人群大小限定到预算可支持的范围内,比如我们要投递给1万个人广告,那要通过各种限定条件把这1万个人找出来。找出来还不能做直接投递,还需要对人群做更细粒度的分析,通过历史数据行为分析这1万个人是不是想要的目标人群。之后会把目标群体以投递包的形式,导出给投递系统。这是一个基本业务逻辑。

合一1.png

那这个业务需求的背后技术要求是什么呢?

典型人群业务版块的核心是洞察分析,洞察分析一般的场景是,要支撑几万个不同的广告主,他们会在平台上自由选择更感兴趣的人群,每个广告主对人群的诉求是不一样的,某些人关注的购买力,有些关注的是收藏行为。每天数万广告主发出数百万次的查询请求,构建数万次各种人群包,各个系统的计算复杂度是要求非常高的。这里的核心诉求包含几个点,毫秒级洞察,因为所有的查询希望是交互式的,需要在界面上每一次互动,每一次下拉菜单,每一次选择,每一次条件组合,都希望看到一个互动结果,整个人群是变大还是变小,目标人群是不是跟期望的相似。这一点对性能要求是非常大的。同时提醒大家,数据一定要脱敏处理,保护好用户的个人隐私,所有的分析都是建立在合规数据基础之上的分析。

合一2.png

人群圈选系统服务引擎核心诉求

规模数据上的交互式分析性能

数万广告主提交数百万次的数据查询,需要毫秒级的响应,查的快是必须的。这个快加了一个限定词,是规模数据。百万级不算规模,行为日志是非常大的,希望是百亿级别以上,依旧有一个很好的交互式分析能力,能够在秒级响应。

灵活筛选能力

用户的筛选行为多种多样,等值比较、数值大小范围比较、时间范围比较等。各种各样的筛选条件能够灵活组合,表达这些筛选结果就体现出来计算引擎的能力。

高吞吐更新能力

用户标签并不是静态的,当前一切实时化,一切在线化,所有的行为数据变化,都希望能够实时触发,实时反馈下一时刻的系统决策。比如最新收藏夹里放了什么商品,这种行为能不能成为在线画像的一部分。所以对高实时的吞吐能力要求会很高。

从计算层面来讲,可以分成下图几种计算模式。

标签过滤分为等值过滤,可以用Equal/In/Between,这些过滤可以在百亿级别上进行操作。操作之后的结果集,要做很多的交差并集,举个常见例子,一个用户既关注了竞品品牌也关注了本公司商品,却没有买,这里面其实有并的关系,有差的关系,有交的关系。所以这些人群关系之间要组合,有很高的交差并集计算。最后还有很强的精确去重的需求,因为最终要把计算结果,变成一个唯一定位用户的ID,这个ID会用来做广告的投递。那这些需求,在引擎层面上就是数据读取效率怎么样,如果用行存读取是不是会出现IO放大的问题,数据按行去存,真正过滤是按照某一列过滤,但是IO读取,会把整行读取,会出现IO放大问题。列存还会有索引问题、过滤效果问题。计算算子上表连接时是Hash JOIN方式还是用Nest Loop JOIN方式。精确去重的效果如何。这些都是对计算引擎效率上有很高的要求。所以本质上是要解决高效数据存储与过滤、关系运算内存/CPU消耗、精确去重内存/CPU消耗问题。

这里就有很多不同的解决优化思路,是用更多的内存还是CPU。行业内大致的思路有两种。

一种是通过预结算思路,有Kylin/Druid这样的技术。这些技术可以在一些预定义的维度上,进行一次提前的预加工。预加工后,数据集会在本质上进行减少。比如要找一个用户群体,关注了第一个商品却没有关注第二个商品。每一个结果集都可以用bitmap数组来表达,数组之间做交差并集效率是非常高的。预计算技术实际上是把精确去重和交差并集上计算是有很大好处的。但缺陷也比较明显,最大的缺陷就是不灵活,同时完整SQL表达能力也比较弱。另一种是属于MPP分布式数据库技术,一些通过列存、分布式、索引方式提供更好的查询性能。

所以真正落地一套人群筛选方案时,一般不是只选择一个方案。因为不管是预计算方案还是MPP方案都有一些本质的缺陷。

合一3.png


那市场上哪些技术更适合做存储和查询呢?

第一类技术,大家都比较熟悉的事务数据库。事务数据库是行存储,对单行数据写入存储效率是非常高的,用来做查询,做过滤统计,在千万级以上会发现消耗资源是非常大的。所以一般不会拿TP系统直接做分析操作。

第二类系统,AP系统,是我们常见OLAP系统。这一类系统针对大规模数据扫描场景做了优化,包括利用分布式技术,列存技术,压缩技术、索引的技术等等。这类技术查的都很快,但本质缺陷是大部分系统更新上做的不太友好,因为数据查的快,所以数据该紧凑紧凑,该压缩压缩,所以在更新能力上弱一些。还有一类系统,在大数据分析也常见,我们把它叫Serving系统,支持在线业务的一类系统,这类系统查的是足够快,但牺牲的其实是查询的灵活性。比如,文档数据库、KeyValue系统查询方式有很大的局限,只能按照它的key去查询。这样灵活性减少了,但是性能上无限放大,因为可以横向扩展,因为key相对来说访问效率是最高的,而且更新效率也非常高,按照key更新,可以替换整条记录。我们过去就不得不针对不同场景,把数据拆分到TP、AP、Serving,数据在几个系统之间来回传递。让我们对整个系统的依赖度变的更高,只要数据有一次依赖,就会产生一次数据不一致,产生数据不一致就意味着数据的修正,数据的开发成本变的更高。所以大家都会在很多领域做创新,第一类创新是在TP和AP领域里做一个混合负载能力。尝试通过一个技术把这两个场景解决掉。有支持事务,又能支持分析,也希望未来有一天这个系统真正很好的落地。这类系统也有一定的局限,要支持事务操作,各种分布式锁开销还是必不可少的。这类系统因为具备了一些能力,所以在整个并发和性能上,开销是比较大的,所以有一定的性能瓶颈。

在下图左侧部分也是可以做一些创新的,左侧的创新会发现最大的问题是不支持事务。把事务能力弱化,不需要那么多事务,希望查的足够快,更新的足够快。所以这个地方是有可能做技术创新,这个技术既具备很好的灵活的分析能力,也具备很好的数据写入能力,有具备完整的SQL表达能力。所以左侧的交集部分的技术,很适合刚才提到的三点技术要求。这就是今天要分享的产品Hologres。

合一4.png


Hologres=向量化SQL引擎 + 灵活的多维分析+高吞吐实时更新

Hologres,一站式实时数仓,提供实时分析(OLAP)与在线服务(点查)两种能力,与MaxCompute无缝打通,实现一套架构,多种负载(OLAP、在线服务、交互式分析)共存,减少数据孤岛,避免数据割裂,简化链路,提升用户体验。

统一存储

  • 一份数据支持多种负载 (OLAP、在线服务、MaxCompute交互式分析),减少数据割裂
  • 数据无孤岛,无频繁数据导入导出,提高数据开发效率、简化链路

统一接口

  • 接口兼容开源Postgres协议,支持主流开发和BI工具,无需应用层重写,生态开放
  • 统一用SQL描述多种场景,提高数据应用开发效率
  • 统一数据模型,通过“表”来描述数仓模型,语义一致

实时离线一体

  • 支持实时写入、实时更新、写入即可查,原生集成Flink
  • 与MaxCompute存储无缝打通,透明加速,无需数据移动,支持交互式分析能力,支持实时数据关联历史数据

高性能

  • OLAP场景性能好于Clickhouse、Impala、Presto,支持亚秒级响应与高QPS
  • 在线服务(点查)场景性能好于HBase,点查支持100K+QPS


Hologres:一站式实时数仓

Hologres为什么能支持高性能,高吞吐写入?

实际上没有神秘的地方,Hologres更多还是依赖于整个IT行业,有很多底层技术上的进步。比如,带宽变宽,延迟变低。好处是之前必须依赖本地的操作,比如之前依赖本地磁盘,现在可以依赖网盘。其实Hologres底层的存储,分多副本存储,高可靠存储,把这些负责状态管理的事情,都交给阿里云,底层是盘古存储引擎,自带多副本,自带压缩,自带缓存,自带高可靠。这就会使整个计算节点的逻辑变的轻薄和简单,也让高可靠更加简单。任何一个节点宕掉之后,可以很快从一个分布式的网盘里恢复状态。会让计算层变的无状态,这是第一点。第二点是磁盘的利用,过去磁盘的转速有机械瓶颈。机械磁盘是按圈去转的,一秒钟多少转。所以我们的IO场景都是面向扫描场景做了大量的优化。我们希望所有的数据都是以块为单位,进行更新、读写。所以在过去这种高更新场景,在整个数仓里很难实现。Hologres是采用SSD设计,固态硬盘支持更好的随机读写能力。这让我们设计存储架构的时可以抛开过去必须依赖于这种扫描场景,去设计整个存储的数据结构。Hologres可以行存也可以列存,分别适应不同的场景,同时也采用log structured merge tree 的方式。支持高吞吐数据的写入和更新的场景。第三个是CPU多核化,CUP的主频已经不会有本质的提升。但是在多核化场景下,如果可以把一CPU内部多个核并行利用起来,就能把CPU资源充分发挥到极致。这就要求对操作系统的底层语言掌握的要比较好,Hologres使用C++实现的数仓。Hologres底层的算子都会用向量化方式重写,尽量发挥多核化并行计算能力,吧计算力发挥到极致。

从下图可以看出,我们在网络上、存储上、计算上、硬件层面有很多改进,这些改进都充分发挥出来,能够做出一个不一样的效果的系统。

合一5.png


人群圈选场景之前提到,既有预计算场景,又有MPP分布式计算场景。使用单一某一个技术往往不太适合,真正落地的时候,希望既有预计算又有分布式计算,要把两个技术更好的整合在一起。比如维度过滤场景就很适合用BITMAP,因为可以在BITMAP上做位图索引。如true和false的场景,购买级别、对什么产品关注等等,这些需要过滤的场景就适合做位图索引。Hologres是支持位图索引的。

第二种是关系运算,关系运算是我们提到的各种数据集之间的交差并,也非常适合位图计算。因为位图计算相当于是0和1之间,做很多与或差的操作,而且是并行操作,效率也是非常高的。

精确去重是BITMAP天生就具备的能力,因为位图在构建时,就通过下标位,就唯一确定了ID。通过不同下标位之间上面一的值的简单累加,就可以很快计算出精确去重的值是多少。这几乎是把一个O(N)的问题变成O(1)的场景,效果也非常明显。所以在做人群圈选场景里面,预计算是很重要的技术。Hologres支持RoaringBitmap数据类型,高效率实现Bitmap的交叉并计算。

上文提到预计算是灵活性不足,需要通过分布式计算把计算力发挥出来,就用到了Hologres的向量化执行引擎。对MaxCompute数据外表直接加速,包括MaxCompute数据同步到Hologres里,是会比MaxCompute同步到其它数据源性能提高10倍已上。

合一6.png

典型架构图

典型架构图如下,数据源基本是通过埋点数据,通过消息中间件kafka,第一件时间投递到Flink,做一次轻量级数据加工,包括数据治理的修正,数据轻度汇总,数据维度拉宽。其中维度关联是一个很重要的场景,真正的埋点数据都是记录某些ID,这些ID都要转换成有属性意义的维度信息。第一件事就是做维度拉宽,这是就可以使用Hologres的行存表,维度关联时,基本是通过主键去关联的,使用Hologres的行存表,可以存几亿几十亿的维度信息。这些信息可以实时的被更新。加工的结果集会写到kafka里面,因为并不是一次加工,可能是加工几个循环。通过kafka做消息驱动的方式,在Flink里面做几次加工,加工的结果基本上双写的场景会比较多,一部分实时写入Hologres,另一部分以批量方式写到MaxCompute里面。离线数仓到实时数仓是一个很好的数据修正的场景,数据是一定会被修正的,所以会有大量通过离线数仓对实时数仓进行修正的场景,包括标签加工也是典型的离线数仓来补充实时数仓的场景。所以一些行为是需要通过离线数仓加工好之后,把数据同步到实时数仓里。但有另外一些属性,是跟当下决策有关系的。这些是可以直接写到实时数仓Hologres里。所以可以把标签分为离线和实时两部分,实时写到Hologres,离线通过MaxCompute加工后同步到Hologres。

在对外提供数据服务是,有几种方式。建议的方式是,对外提供服务时,加一个网关,网关服务里面会做很多限流、熔断等等,这也是能提高数据服务稳定性的一个很好的帮助。如果是对内使用交互式分析的长治,可以直接通过JDBC的方式连接Hologres,如果是一个在线应用,建议通过API网关连接到Hologres。

合一7.png


MaxCompute

Hologres

使用场景

ETL加工,标签加工

在线查询、面向外部应用,交互式分析

用户使用

异步的Job/Task

同步的Query

集群资源

共享大集群,计算时资源可扩展

独享集群,计算资源预分配

计算引擎

基于StageFile设计的,持久化的,可扩展SQLEngine

基于内存的,超快速响应的SQLEngine,计算不落盘

调度方式

进程级别,运行时分配

轻量级线程,资源预留

扩展性

几乎不受限制

复杂查询尽量避免跨多节点数据shuffle

存储格式

列式

行式、列式共存,面向不同场景

存储成本

基于PanguHDD成本低

基于PanguSSD成本相对高

更新方式

批量更新

实时更新、批量更新

接口标准

MCSQL

PostgreSQL

数据结构层

离线数仓加工两张表,一个是用户基础属性表,记录一些用户属性,性别城市年龄等。一个是交易明细表,记录某个人在某一天针对某个商品买过多少,看过多少,收藏多少等。这些通过离线数仓加工好后,数据导入Hologres。在通过配置把表列描述信息以人类可读的方式描述出来,再配置相关属性标签。把标签上线后,广告主会通过交互界面进行配置筛选。这种筛选背后都是翻译成各种SQL语句,其实就是个各种SQL表达式。真正把查询下发到底层引擎。那下发时底层引擎该如何建表呢?

合一8.png

宽表模式

•每行描述一个用户的标签组合,每个key是一列,每一行对应value。

列不建议超过300列,列多会降低实时写入的性能。分为热点标签和非热点标签

热点标签独立为列,具备明确的数据类型,可以针对性设计索引,对查询友好

•非热点标签,通过数组类型和JSON支持,适合动态更新,但索引不是最优,可扩展性更好

•适应场景:维度属性数量较低;实时写入频繁;更新以人的单位

•优势:开发简单快速上线

方案描述:

用户数据:例如user_tags表,宽表

行为数据:例如shop_behavior表,事实表

更新时,可以实时、批量更新不同的列

合一9.png

案例

-------------------- 用户标签维度表 ---------------------begin;--3个热点标签字段(text、integer、boolean类型),2个扩展标签字段(text[]类型和JSON类型)createtable user_tags
(  user_id textnotnull primary key,  city_id text,  consume_level integer,  marriaged boolean,  tag_array text[],  tag_json json
);call set_table_property('user_tags','orientation','column');-- 分布列call set_table_property('user_tags','distribution_key','user_id');-- text类型设置bitmap索引call set_table_property('user_tags','bitmap_columns','city_id,tag_array');-- 热点标签,这是字典编码call set_table_property('user_tags','dictionary_encoding_columns', ‘city_id:auto’);commit;-------------------- 用户行为事实表 ---------------------begin;createtable shop_behavior
(  user_id textnotnull,  shop_id textnotnull,  pv_cnt integer,  trd_amt integer,  ds integernotnull);call set_table_property('shop_behavior','orientation','column');call set_table_property('shop_behavior','distribution_key','user_id');--- 聚合键 对group by等运算更加友好call set_table_property('shop_behavior','clustering_key','ds,shop_id');Commit;


窄表模式

将user_tag表转为窄表,每一个标签一行记录,标签名为一列,标签值为一列。

数据类型均退化为字符串类型,适合标签不固定,标签稀疏,允许牺牲部分性能但提高标签定义的灵活度。支持几十到几十万不同标签规模。

•适应场景:维度属性数量高;更新以标签的单位

•优势:开发简单快速上线

合一10.png

案例

-------------------- 用户标签维度表 ---------------------begin;createtable tag2.user_tags(  userid textnotnull,  tag_key text,  tag_value text,  ds text) partition by list(ds);call set_table_property('tag2.user_tags','orientation','column’); -- 分布列call set_table_property('tag2.user_tags', 'distribution_key', 'user_id');call set_table_property('tag2.user_tags', 'bitmap_columns', 'tag_key,tag_value');call set_table_property('tag2.user_tags', 'dictionary_encoding_columns', 'tag_key:auto,tag_value:auto');commit;--查询例子--WITH f1 AS (    SELECT userid     FROM tag2.user_tags    WHERE ds = '20210101'    AND   tag_key = 'tag_single'    AND   tag_value = 'myname'),f2 AS (    SELECT userid     FROM tag2.user_tags    WHERE ds = '20210101'    AND   tag_key = 'tag_date'    AND   tag_value > '20210101'),f3 AS (    SELECT userid     FROM tag2.user_tags    WHERE ds = '20210101'    AND   tag_key = 'tag_numeric'    AND   to_number(tag_value, '99G999D9S') > 90),f4 AS (    SELECT userid     FROM tag2.user_tags    WHERE ds = '20210101'    AND   tag_key = 'tag_multi'    AND   tag_value IN ('HONOR', 'MI'))SELECT COUNT(DISTINCT userid)FROM ((SELECT userid FROM f1 UNION SELECT userid FROM f2) INTERSECT (SELECT userid FROM f3 EXCEPT SELECT userid FROM f4)) crowd;


预计算模式(宽表、窄表均适合)

对维度组合的人群固化为更优的数据结构bitmap

•适应场景:基数高,计算复杂度大,更新频率低场景

优势:查询性能高

方案描述:

由于roaringbitmap需要整数类型作为ID参数,因此增加usermapping表做用户逻辑ID与底层物理ID的映射。

合一11.png

案例

-------------------- 用户标签维度表 ---------------------BEGIN;CREATETABLE tag3.user_tags("tag_key"text,"tag_value"text,"userlist" roaringbitmap,    ds text) partition by list(ds);CALL SET_TABLE_PROPERTY('tag3.user_tags','orientation','column');CALL SET_TABLE_PROPERTY('tag3.user_tags','bitmap_columns','tag_key,tag_value');CALL SET_TABLE_PROPERTY('tag3.user_tags','dictionary_encoding_columns','tag_key:auto,tag_value:auto');COMMIT;begin;createtable tag3.usermapping(    userid_int serial,    userid text);commit;--构建RoaringBitmap--INSERTINTO tag3. user_tags SELECT tag_key ,tag_value ,rb_build(array_agg(user_id::INT))FROM tag2.user_tagsGROUPBY tag_key ,tag_value  
--查询例子--SELECT Rb_cardinality(Rb_and(Rb_or(t1.r, t2.r), Rb_andnot(t3.r, t4.r)))FROM(SELECT Rb_and_agg(userlist)AS r
FROM   tag3.user_tagsWHERE  ds ='20210101'AND    tag_key ='tag_single'AND    tag_value ='myname')AS t1,(SELECT rb_and_agg(userlist)AS r
FROM   tag3.user_tagsWHERE  ds ='20210101'AND    tag_key ='tag_date'AND    tag_value >'20210101')AS t2,(SELECT rb_and_agg(userlist)AS r
FROM   tag3.user_tagsWHERE  ds ='20210101'AND    tag_key ='tag_numeric'AND    to_number(tag_value,'99G999D9S')>90)AS t3,(SELECT rb_and_agg(userlist)AS r
FROM   tag3.user_tagsWHERE  ds ='20210101'AND    tag_key ='tag_multi'AND    tag_value IN('HONOR','MI'))AS t4


用户画像与圈定的一些经验

•标签分为主画像和扩展画像多张表,区分高频访问和低频访问

•标签分为实时(Flink)更新和离线(MaxCompute)更新两部分,两部分共享一张表,减少运行时Join,Flink加工实时部分,MaxCompute加工离线部分,在Hologres中合并

宽表模式简单,擅长定性分析

窄表模式灵活,计算量大,擅长定量分析

•基于RoaringBitmap的预计算技术,用户体验最好,开发复杂度较高(比如bitmap分桶),SQL需要定制,适合DMP等有封装能力的平台,擅长UV

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
2月前
|
SQL 分布式计算 运维
如何对付一个耗时6h+的ODPS任务:慢节点优化实践
本文描述了大数据处理任务(特别是涉及大量JOIN操作的任务)中遇到的性能瓶颈问题及其优化过程。
|
1月前
|
机器学习/深度学习 算法 搜索推荐
从理论到实践,Python算法复杂度分析一站式教程,助你轻松驾驭大数据挑战!
【10月更文挑战第4天】在大数据时代,算法效率至关重要。本文从理论入手,介绍时间复杂度和空间复杂度两个核心概念,并通过冒泡排序和快速排序的Python实现详细分析其复杂度。冒泡排序的时间复杂度为O(n^2),空间复杂度为O(1);快速排序平均时间复杂度为O(n log n),空间复杂度为O(log n)。文章还介绍了算法选择、分而治之及空间换时间等优化策略,帮助你在大数据挑战中游刃有余。
54 4
|
8天前
|
边缘计算 人工智能 搜索推荐
大数据与零售业:精准营销的实践
【10月更文挑战第31天】在信息化社会,大数据技术正成为推动零售业革新的重要驱动力。本文探讨了大数据在零售业中的应用,包括客户细分、个性化推荐、动态定价、营销自动化、预测性分析、忠诚度管理和社交网络洞察等方面,通过实际案例展示了大数据如何帮助商家洞悉消费者行为,优化决策,实现精准营销。同时,文章也讨论了大数据面临的挑战和未来展望。
|
25天前
|
SQL 分布式计算 数据挖掘
加速数据分析:阿里云Hologres在实时数仓中的应用实践
【10月更文挑战第9天】随着大数据技术的发展,企业对于数据处理和分析的需求日益增长。特别是在面对海量数据时,如何快速、准确地进行数据查询和分析成为了关键问题。阿里云Hologres作为一个高性能的实时交互式分析服务,为解决这些问题提供了强大的支持。本文将深入探讨Hologres的特点及其在实时数仓中的应用,并通过具体的代码示例来展示其实际应用。
128 0
|
30天前
|
SQL 消息中间件 分布式计算
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
65 0
|
30天前
|
SQL 大数据
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(二)
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(二)
54 0
|
30天前
|
SQL 消息中间件 分布式计算
大数据-130 - Flink CEP 详解 - CEP开发流程 与 案例实践:恶意登录检测实现
大数据-130 - Flink CEP 详解 - CEP开发流程 与 案例实践:恶意登录检测实现
37 0
|
3月前
|
分布式计算 搜索推荐 物联网
大数据及AI典型场景实践问题之通过KafKa+OTS+MaxCompute完成物联网系统技术重构如何解决
大数据及AI典型场景实践问题之通过KafKa+OTS+MaxCompute完成物联网系统技术重构如何解决
|
3月前
|
人工智能 分布式计算 架构师
大数据及AI典型场景实践问题之基于MaxCompute构建Noxmobi全球化精准营销系统如何解决
大数据及AI典型场景实践问题之基于MaxCompute构建Noxmobi全球化精准营销系统如何解决
|
3月前
|
SQL 消息中间件 OLAP
OneSQL OLAP实践问题之实时数仓中数据的分层如何解决
OneSQL OLAP实践问题之实时数仓中数据的分层如何解决
52 1

热门文章

最新文章

相关产品

  • 实时数仓 Hologres