简介：本文主要介绍如何通过MaxCompute添加大量人的标签，通过全息药物分析建模，从而支持大型人的复杂圈子选择场景中的互动体验，以及基于API的最佳实践 -基于数据服务。
人群圈不是一项新业务。几乎所有互联网公司都在这样做，因为这是一个基本的营销场景。分为不同的小组。通过将人群群体分开，在有限的营销预算中，资源被投入到转换或点击率最高的人们中。
基本的业务体系结构逻辑如下所示，首先是标签处理引擎，主要是离线处理。在标签处理引擎中，用户历史记录的采购行为，访问行为，访问行为，，将有很多标签可以计算注意力行为等，注意多少次关注哪些产品，您点击了多少次，您注意多少次等等等等。被进口到在线肖像服务引擎中。该服务引擎是为操作员和广告商进行交互式查询的，因为根据用户行为的特征，可以筛选出最关心的用户组。本用户组可能是一个关注某些产品但不在30之内购买的组通过行为特征筛选的几天或相关的上游和下游产品。筛选过程是一个高度互动的过程，因为一个人的行为特征非常复杂。因此，您需要经常选择某个条件来删除某个条件，并且可以合并，在条件和条件之间进行工作，等等。直到人群的规模仅限于预算支持的范围，例如，如果我们想提交10,000人，我们必须找到这些通过各种有限的条件，有10,000人。找到直接做的，您需要对人群进行更精细的颗粒分析。通过分析历史数据行为分析，这10,000人是否想要他们想要的目标群体。此后，目标组将以交付软件包的形式导出到交付系统。这是基本的业务逻辑。
该业务需求背后的技术要求是什么？
典型人群业务部分的核心是洞察力和分析。洞察力和分析的一般场景是支持成千上万的不同广告客户。他们将自由选择对平台更感兴趣的人。例如，有些人关注购买力，有些人担心收集行为。成千上万的广告客户每天都会发出数百万个查询请求，以建立数十张广告请求成千上万的人群包。每个系统的计算复杂性非常高。
这里的核心吸引力包含几个点，毫秒见解，因为所有查询希望都是互动的，并且需要在界面上进行交互，每个drop -down菜单，每个选择，每个条件组合，我都希望看到一个oneas结果，是否整个人群变得更大或更小，目标人群与期望相似吗？这对于性能非常大。
同时，提醒必须将数据脱敏以保护用户的个人隐私。所有分析均基于基于合规数据的分析。
比例数据中的互动分析性能
成千上万的广告商提交了数百万个数据查询，这需要毫秒响应。有必要检查。这几乎添加了一个有限的单词，即比例数据。数百万的级别不被视为规模，行为日志非常大。希望它的水平超过1000亿。仍然有良好的互动分析能力，可以在几秒钟内做出响应。
灵活的筛选能力
用户的筛选行为是多种多样的，等效的值比较，值的值范围和时间范围。可以灵活地组合筛选条件，表达这些筛选结果反映了计算发动机的能力。
高通量更新能力
用户标签不是静态的。目前，它是实用的，一切都是在线的，所有行为数据都会改变希望实时触发，并实时反馈系统决策的下一个系统。这种行为可以成为在线肖像的一部分。因此，高时间吞吐量的要求很高。
从计算的角度来看，它可以分为下面的几种计算模式。
标签过滤分为等效滤波，可以通过等效/之间/之间使用，可以在数十亿美元处进行操作。操作后，应进行操作结果，并应做一个常见的示例。对于一个常见的例子，用户既关注竞争品牌又要注意公司的产品，但它不会购买。实际上，有一种关系。关系之间的关系很差，因此，必须将这些人群之间的关系组合在一起，并且有一个高平行和计算。最后，有强烈而精确的需求，因为计算结果最终被转向进入唯一定位用户的ID。该ID将被用作广告交付。然后，在发动机层面上，这些需求是数据读数的效率。如果您使用它，则会有IO扩大问题。数据是根据线路存储的。它将读取整个行，并将出现IO扩增问题。还将有索引和滤过列的效果。当计算操作员在上表中连接到上表是Hash Join方法或巢回路联接方法。精确和重的效果是什么作用。这些是计算引擎效率的高要求。因此，本质上，有必要解决高效数据存储和过滤的问题，关系计算内存/CPU消耗，并精确地消除了重型内存/CPU消耗。
这里有许多不同的优化思想解决方案，无论是更多的记忆还是CPU。行业中有两个一般思想。
一种技术是通过预先设定的想法进行的技术。这些技术可以在某些预定的维度上提前准备。在预处理后，数据组件本质上会减少。产品但不关注第二个产品。每个阵列可以表达每个结果集，并且阵列之间的性交的效率非常高。预计计算技术实际上非常好，可以准确删除该计算技术准确性和交叉点。但是，缺陷也相对明显。最大的缺陷不是灵活的，与此同时，完整的SQL表达能力也相对较弱。另一个是MPP分布式数据库技术，该技术通过列表，分布式和索引方法提供更好的查询性能。
因此，当一组人群筛查计划真正降落时，通常不仅选择一种解决方案。因为估计和MPP解决方案都有一些基本缺陷。
那么，市场上哪些技术更适合存储和查询？
第一种技术，每个人都更熟悉的事务数据库。事务数据库是存储，单行数据的存储效率非常高。它用于进行查询和过滤统计。可以发现，消费资源在数以平时或以上是数万计的。因此，通常不需要TP系统直接进行分析。
第二种系统AP系统是我们的通用OLAP系统。这种类型的系统针对大型数据扫描方案进行了优化，包括使用分布式技术，上市技术，压缩技术，索引技术等。快速检查技术，但基本缺陷是大多数系统更新不是很友好。由于数据被快速检查，因此数据应紧凑和压缩，因此更新能力较弱。也有一种在大数据分析中常见的系统。我们称其为支持在线业务系统的服务系统。这种类型的系统检查得足够快，但是牺牲实际上是查询的灵活性。例如，文档数据库和KeyValue系统查询方法具有很大的限制，只能根据其钥匙进行查询。减少了，但是性能是无限扩大的，因为它可以水平扩展，因为键相对较高，并且更新效率非常高。根据关键更新，可以替换整个记录。只要数据取决于数据，它就会产生一个不一致的数据。生成数据的数据的不一致意味着对数据的校正和数据开发的成本变得更高。因此，每个人都会在许多领域进行创新。第一种创新的类型是在TP和AP字段中建立混合负载能力。尝试通过技术解决这两个场景。我还希望有一天，这种系统在将来真的会好起来。这种系统也有一定的局限性。为了支持交易操作，各种分布式锁定开销是必不可少的。由于某些功能， 该系统具有大量的开销和性能，因此具有一定的性能瓶颈。
也可以在下图的左侧完成一些创新。左边的创新会发现最大的问题是最大的问题是不支持交易。没有这么多交易的事务。我希望能够足够快地检查它，并且更新已经足够快。因此，这个地方可能会进行技术创新。该技术具有良好且灵活的分析功能，但也具有良好的数据编写能力，并且具有完整的SQL表达能力。因此，左侧的交叉路口技术非常适合现在提到的三种技术要求。我今天想分享的产品全息。
Hologres =向量SQL引擎 +灵活的多维分析 +高吞吐量实时更新
Hologres，一个停滞的真实时间仓库，提供真实的时间分析（OLAP）和在线服务（点-Check），与MaxCompute无缝连接以实现一组体系结构，多个负载（OLAP，在线服务，交互式分析））共存，减少数据岛，避免数据片段，简化链接并增强用户体验。
统一存储
统一界面
真实 - 时间离线
高性能
全息草为什么可以支持高性能，高吞吐量？
实际上，没有神秘的地方，全息原子仍然更多地取决于整个IT行业，而且底部有许多技术进步。以前，例如依靠本地磁盘，现在您可以依靠网络磁盘。管理到阿里巴巴云。高和可靠。这将使整个计算节点的逻辑变得薄而简单，它将变得更高可靠性，更简单。在任何节点下降后，您可以快速从分布式网络磁盘恢复。是使计算层变得没有状态的第一点。
第二点是使用磁盘。过去，磁盘的速度具有机械瓶颈。机械磁盘是由圆圈旋转的，一秒钟是多少。因此，我们的IO场景对扫描方案进行了很多优化。我们希望所有数据都基于基于更新，阅读和写作的块。在过去，在整个倒计时很难实现此较高的更新场景。Hologres使用SSD设计，Solid -State Hard Disk支持更好的随机读取和写入能力。这使我们能够设置除了必须依靠此扫描方案的存储体系结构来设计整个存储数据结构。可以存储或存储，它们可以分别适应不同的方案，还使用日志结构合并时间。高吞吐量数据。
第三是CPU多核化，杯赛的主要频率将不再具有重大改进。但是，在多核化场景中，如果您可以在CPU内使用多个内核，则可以充分利用CPU资源极端。这需要更好地了解操作系统的基础语言。Hologres使用C ++来实现位置。Hologres底层的Hologres将以矢量化方法重写，尝试使用多核并行计算能力，并可以将计算能力用于极端。
从下图可以看出，我们在Internet，存储，计算和硬件级别上都有许多改进。这些改进是完全施加的，可以产生不同的效果系统。
之前提到了人群圈，预计计算和MPP分布式计算方案。使用单个技术通常不合适。当它真正着陆时，我希望有预期和分布的计算，并且必须更好地集成这两种技术。场景，购买级别，涉及哪些产品等。这些需要过滤的场景适用于图形索引。Hologres支持图形索引。
第二个是关系操作。关系之间的关系是我们提到的各种数据集之间的差异，并且它也非常适合位图计算。由于位图的计算等于0到1之间，因此使用或不良操作进行了许多操作，它是并行操作，效率也很高。
精确至关重要的是位图出生的能力，因为当构建位图时，ID仅由下bid确定。通过上述竞标之间的简单积累，精确权重的值可以是快速计算。这几乎是o（n）的场景，效果非常明显。因此，在人群圈子的选择场景中，预计这将是一项非常重要的技术。Hologres支持RoaringBitmap数据类型，交叉并计算高效率。
如上所述，预计计算不足。需要通过分布式计算来使用计算能力，并将矢量化执行引擎用于全息。来源。
典型的体系结构图如下。数据源基本上是由数据掩埋的，并且第一次通过消息中间件传递到flink.width。维度关联是一个非常重要的情况。真正的掩埋数据是记录某些ID。这些ID必须转换为具有属性意义的维度信息。
第一件事是使尺寸宽度。这可用于使用全息线。当尺寸关联时，它基本上是通过主键关联的。使用Hologres系列存款表，您可以节省数百个信息的信息，可以实时更新。处理的处理结果是在Kafka中编写的，因为它不是处理，因此可能是处理的几个周期。消息 - 驱动方法，在flink中进行多个处理。处理结果基本上是双重编写的场景。其中一些是用真实的全息图编写的，另一部分是用批量批准的。
离线数字仓库到真实的时间仓库是一个很好的数据校正方案。数据肯定会得到纠正，因此将有大量场景通过离线倒计时修改真实的仓库。Warehouse来补充真实的时间仓库的场景。因此，需要通过离线处理某些行为仓库的计数和数据已同步到真实的时间仓库。
但是，还有其他与当前决定有关的属性。这些属性可以直接写在真实的仓库全息图中。因此，标签可以分为两个部分：离线和真实时间。真实的时间写作写信给全息图，通过MaxCompute处理后，离线与全息相关。
在外部提供数据服务，有几种方法。推荐的方法是，在向外界提供服务时，添加网关，并且网关服务将有很多当前限制，保险丝等。这也是一个很好的帮助这可以提高数据服务的稳定性。
如果是使用交互式分析的纵向，则可以通过JDBC直接连接全息。如果是在线应用程序，建议通过API网关连接到全息。
有两个用于离线仓库处理的表，一个是用户的基本属性表，它记录了某些用户属性，性别城市的年龄等。，某个产品的数量是多少。处理这些离线数字仓库后，数据是导入的全息图。该表通过配置描述信息以描述人类中的信息，然后配置相关属性标签。已启动，广告客户将配置配置界面。欣赏此筛选被翻译成各种SQL语句，实际上是各种SQL表达式。真的将查询发送到底部 - 层引擎。如何在底部引擎时构建底部引擎。发动机发行？
宽度模式
?每一行描述用户的标签组合，每个键是列，每行都对应于值。
?不建议超过300列，并且列会降低真实时间写作的性能。
?热点标签基于独立性，具有清晰的数据类型，可以设计为索引和查询友好
?由数组类型和JSON支持的非hot -point标签适用于动态更新，但索引不是最佳的，并且可以更好地扩展
?适应方案：尺寸的尺寸数量很低；实时频繁写作；更新人们的单位
?优势：简单开发和快速在线
?计划说明：
用户数据：例如，User_tags表，宽表
行为数据：例如
更新时，您可以实时和分批更新不同的列
案件
狭窄的表模式
将USER_TAG表转换为窄表。记录每个标签，标签称为列，标签值为列。
数据类型被降级为字符串类型，适用于非标签，稀疏标签，并允许牺牲部分性能的灵活性，但要改善标签的定义。支持数十个至数十万个不同的标签。
?适应方案：尺寸的数量很高；标记的更新单元
?优势：简单开发和快速在线
案件
估计计算模式（宽表，窄表合适）
将尺寸结合到更好的数据结构位图的组合向小组清理
?适应方案：高基础，大计算复杂性和更新的频率低
?优势：高查询性能
计划说明：
由于RoaringBitMap需要一个整数类型作为ID参数，因此它将usermapping表添加为用户逻辑ID和基础物理ID的映射。
案件
?标签分为主要肖像和扩展肖像多个表，区分高频访问和低频访问
?标签分为两个部分：真实时间（Flink）更新和离线（MaxCompute）。两个部分共享一个表，以减少运行时过程的实际时间部分。
?宽桌模式很简单，擅长定性分析
?窄表模式是灵活的，计算量很大，并且擅长定量分析
?基于RoaringBitmap的估计计算技术，用户体验是最好的。开发复杂性很高（例如位图拆分枪管）。SQL需要自定义。它适用于DMP和其他平台。擅长紫外线