idc中国数字金融论坛2021中国最快dns

对于SaaS企业来说，产品是核心竞争力。从能量模型的角度来看，产品价值是积蓄势能的来源，而势能则决定了营销推广阶段企业最终能获得的动能，即商业收益。可以说，持续提升产品价值是SaaS企业提高经营势能的关键。一般来讲，提升SaaS产品的竞争力，离不开产品、运营和研发三个部门：第

一，满足客户主要业务需求。以SaaS产品为载体，满足目标客户经营过程中特定环节的信息化、数字化、智能化建设需求。第

二，持续提升付费转化。在产品功能满足客户需求的情况下，通过运营手段加强客户价值感知，提升付费/续费转化。第

三，以更先进、更强大的研发实力，打造更有市场竞争力的产品。针对提升产品价值这一终极目标，我们可以拆解出三个关键目标，并梳理出对应的行动策略和面临的挑战，如下所示：在此背景下，神策数据正式提出SaaS产品评估解决方案，并对外发布，通过帮助SaaS企业建立指标体系，统一企业内各部门、各角色的“数字语言体系”，实现公司上下明确目标、统一口径、了解现状、科学决策，驱动业务发展。

一、基于数据驱动下的三重洞察，全面评估SaaS产品价值一款SaaS产品的价值该如何评估，通常从“有没有人用”“好不好用”“对企业有没有帮助”三个方向展开。针对SaaS产品的特殊性，神策支持C–T–B（Customer–Team-Business）多主体分析。既可以分析用户Customer的行为数据，也可以以团队Team或企业Business作为主体，聚合同一团队/企业下多个用户的行为数据，搭建多主体、多维度的产品评估体系。

1、“有没有人用”——用户对产品的依赖程度从用户规模、用户黏性上判断目标客群对产品的依赖度。通过神策数据SaaS产品评估解决方案，企业可以全面分析用户的使用情况和使用黏性：分析产品中各个功能模块的用户数/企业数，并在用户群体、功能、终端设备、版本等多个维度做同比环比。比如，在使用情况上，应用神策分析内置的分析模型，完成相关维度的数据评估。

（1）洞察使用频次分布，了解产品设计要点。在该场景中，针对使用频次很高的功能，重点考虑入口便捷性、流程简洁度、使用顺畅度等；针对使用频次一般的功能，重点考虑使用门槛和功能完备性。

（2）甄别高频使用用户，洞察需求。通过数据分析定位高频使用某功能的用户、每天都要进入系统的用户等。同时，要着重考虑高频用户的实际场景是否需要开发高阶功能或者重点维护产品稳定性等。

2、“好不好用”——产品功能操作是否顺畅当具备一定规模的用户后，产品各个细分功能板块是否都能顺利流转，给用户较好的使用感受，它是一个比较笼统抽象的评估方向。结合数据指标来看，可以从操作费力度、性能表现、转化情况来分析用户对产品的真实使用感受。以费力度举例，可以进一步向下拆解，从操作成本、新用户/新功能的学习曲线、流程路径来综合分析“费力度”。比如，大多数SaaS产品中都会有“审批”功能，而审批功能中通常会有“表单”这一功能。评估“表单”功能产品费力度时，可以从“中途退回次数”（每个单据中途被退回的次数）和“操作时长”（单据完成审核所需时长）两个数据指标入手。若“中途退回次数”过多，分析退回原因是否为审批决策人所需的决策依据信息在创建时囊括不完整、表格设计不合理等；若“操作时长”过长，需要进一步了解是负责人操作有BUG、未及时提醒、还是查看审批单的耗时较久，进而做产品功能操作的优化。

3、“有没有帮助”——用户是否愿意进行产品分享与推荐企业在用户使用SaaS产品后，从主观反馈上收集用户是否愿意将产品推荐给其他人，或者从客观数据表现上查看老用户是否通过分享功能拉新。通常，“有没有帮助”需要结合客户反馈进一步评估。常见的形式中，企业可以采用NPS问卷形式，收集客户的主观满意度。如果是PLG（ProductleadsGrowth）模式的产品，还可以结合分享裂变的表现来客观评估客户满意度。一般情况下，SaaS产品可以从“邀请”和“受邀”两个分析思路进行“有没有帮助”的评估：“邀请”角度主要参考邀请页面的流量入口有哪些？老客的邀请率如何？按照客户价值、注册时长、付费版本等维度如何细分？新老客留存有何区别……“受邀”角度主要观察受邀页面的点击量分布如何？是否聚焦？新客的产品使用情况如何？按客户价值、注册时长、人口特征等维度如何细分……

二、优化细分功能，以点带面提升产品竞争力与核心价值搭建多主体、多维度的产品评估体系只是提升产品价值的第一步，业务同学还需要结合实际数据与业务目标，定向优化细分功能，逐步提升产品价值。对应“有没有人用”“好不好用”“对企业有没有帮助”三个评估方向，接下来将举三个例子分别阐述数据的应用。

1、基于用户旅程，提高使用人数比例对于SaaS产品来说，用户旅程通常包括“授权→留存→活跃→流失”，在各个环节所需度量的指标有所差异，比如“授权”阶段需关注新增用户数、用户总数、渗透率等；“留存”阶段核心关注留存率；“活跃”阶段侧重于用户使用频次和使用周期；“流失”阶段则重点关注流失率。如何提高使用人数比例？企业可以通过神策数据提供的SaaS产品评估解决方案分析目标用户使用功能用户等占比（渗透率），确定使用用户增长空间和潜在用户规模；分析用户的使用频次，确定用户对该功能的粘性。

2、深入用户使用间隔分析，降低产品使用费力度用户使用产品的路径可以总结为“点击入口→浏览列表→点击功能→产生结果”。通过深入用户使用间隔分析，神策数据可以帮助SaaS企业从新/老用户、用户部门、用户岗位等角度，查看间隔时长最长环节，确定可优化的关键环节，缩短用户完成全部操作的时间。

3、提升完整使用产品的用户占比与完结业务数如果把用户使用SaaS产品的某个功能路径概括为“了解功能→点击步骤A→完成步骤A→点击步骤B→完成步骤B→业务完结”，解账户神策数据为SaaS企业提供的数字化产品与服务，企业可以通过用户点击次数、点击人数、各环节转化率等数据指标，从新/老用户、用户部门、用户岗位等角度，查看转化率最高环节，确定可优化的关键环节，提升用户在每个环节的转化效果与质量。综上所述，数据在提升SaaS产品价值的过程中，能够起到监测、定位、量化、验证的作用，通过真实的数据反馈明确当前产品优化过程中的问题，并在加以改进后持续验证优化情况。

任何完整的大数据平台，一般包括以下的几个过程：数据采集数据存储数据处理数据展现（可视化，报表和监控）其中，数据采集是所有数据系统必不可少的，随着大数据越来越被重视，数据采集的挑战也变的尤为突出。这其中包括：数据源多种多样数据量大，变化快如何保证数据采集的可靠性的性能如何避免重复数据如何保证数据的质量我们今天就来看看当前可用的一些数据采集的产品，重点关注一些它们是如何做到高可靠，高性能和高扩展。ApacheFlumeFlume是Apache旗下，开源，高可靠，高扩展，容易管理，支持客户扩展的数据采集系统。Flume使用JRuby来构建，所以依赖Java运行环境。Flume最初是由Cloudera的工程师设计用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。Flume设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个Agent的网络，支持数据路由。每一个agent都由Source，Channel和Sink组成。SourceSource负责接收输入数据，并将数据写入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，SpoolingDirectory。其中Spooling支持监视一个目录或者文件，解析其中新生成的事件。ChannelChannel存储，缓存从source到Sink的中间数据。可使用不同的配置来做Channel，例如内存，文件，JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。SinkSink负责从管道中读出数据并发给下一个Agent或者最终的目的地。Sink支持的不同目的地种类包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的FlumeAgentFlume在source和sink端都使用了transaction机制保证在数据传输中没有数据丢失。Source上的数据可以复制到不同的通道上。每一个Channel也可以连接不同数量的Sink。这样连接不同配置的Agent就可以组成一个复杂的数据收集网络。通过对agent的配置，可以组成一个路由复杂的数据传输网络。配置如上图所示的agent结构，Flume支持设置sink的Failover和LoadBalance，这样就可以保证即使有一个agent失效的情况下，整个系统仍能正常收集数据。Flume中传输的内容定义为事件（Event），事件由Headers（包含元数据，MetaData）和Payload组成。Flume提供SDK，可以支持用户定制开发：Flume客户端负责在事件产生的源头把事件发送给Flume的Agent。客户端通常和产生数据源的应用在同一个进程空间。常见的Flume客户端有Avro，log4J，syslog和HTTPPost。另外ExecSource支持指定一个本地进程的输出作为Flume的输入。当然很有可能，以上的这些客户端都不能满足需求，用户可以定制的客户端，和已有的FLume的Source进行通信，或者定制实现一种新的Source类型。同时，用户可以使用Flume的SDK定制Source和Sink。似乎不支持定制的Channel。FluentdFluentd（Github地址）是另一个开源的数据收集框架。Fluentd使用C/Ruby开发，使用JSON文件来统一日志数据。它的可插拔架构，支持各种不同种类和格式的数据源和数据输出。最后它也同时提供了高可靠和很好的扩展性。TreasureData,Inc对该产品提供支持和维护。Fluentd的部署和Flume非常相似：Fluentd的架构设计和Flume如出一辙：Fluentd的Input／Buffer／Output非常类似于Flume的Source／Channel／Sink。InputInput负责接收数据或者主动抓取数据。支持syslog，ess"path=>"/var/log/apache2/other_vhosts_ess.log"}file{type=>"apache-error"path=>"/var/log/apache2/error.log"}}filter{grok{match=>{"message"=>"%{COMBINEDAPACHELOG}"}}date{match=>["timestamp","dd/MMM/yyyy:HH:mm:ssZ"]}}output{stdout{}redis{host=>"192.168.1.200"data_type=>"list"key=>"logstash"}}几乎在大部分的情况下ELK作为一个栈是被同时使用的。所有当你的数据系统使用ElasticSearch的情况下，logstash是首选。ChukwaApacheChukwa（github）是apache旗下另一个开源的数据收集平台，它远没有其他几个有名。Chukwa基于Hadoop的HDFS和MapReduce来构建（显而易见，它用Java来实现），提供扩展性和可靠性。Chukwa同时提供对数据的展示，分析和监视。很奇怪的是它的上一次github的更新事7年前。可见该项目应该已经不活跃了。Chukwa的部署架构如下。Chukwa的主要单元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相当复杂。由于该项目已经不活跃，我们就不细看了。ScribeScribe是Facebook开发的数据（日志）收集系统。已经多年不维护，同样的，就不多说了。SplunkForwarder以上的所有系统都是开源的，在商业化的大数据平台产品中，Splunk提供完整的数据采金，数据存储，数据分析和处理，以及数据展现的能力。Splunk是一个分布式的机器数据平台，主要有三个角色：SearchHead负责数据的搜索和处理，提供搜索时的信息抽取。Indexer负责数据的存储和索引Forwarder，负责数据的收集，清洗，变形，并发送给IndexerSplunk内置了对Syslog，TCP/UDP，Spooling的支持，同时，用户可以通过开发ScriptInput和ModularInput的方式来获取特定的数据。在Splunk提供的软件仓库里有很多成熟的数据采集应用，例如AWS，数据库（DBConnect）等等，可以方便的从云或者是数据库中获取数据进入Splunk的数据平台做分析。这里要注意的是，SearchHead和Indexer都支持Cluster的配置，也就是高可用，高扩展的，但是Splunk现在还没有针对Farwarder的Cluster的功能。也就是说如果有一台Farwarder的机器出了故障，数据收集也会随之中断，并不能把正在运行的数据采集任务Failover到其它的Farwarder上。总结我们简单讨论了几种流行的数据收集平台，它们大都提供高可靠和高扩展的数据收集。大多平台都抽象出了输入，输出和中间的缓冲的架构。利用分布是的网络连接，大多数平台都能实现一定程度的扩展性和高可靠性。其中Flume，Fluentd是两个被使用较多的产品。如果你用ElasticSearch，Logstash也许是首选，因为ELK栈提供了很好的集成。Chukwa和Scribe由于项目的不活跃，不推荐使用。Splunk作为一个优秀的商业产品，它的数据采集还存在一定的限制，相信Splunk很快会开发出更好的数据收集的解决方案。

有同学咨询如何引入及应用数据库产品，对比简单列了一下相应的阶段，及对应输出的文档。阶段工具项描述输出选型阶段

1.确认要选型的数据库产品类型

2.确认需要对比的同类数据库产品各位产品的市分析对比报告，包括并不限于，厂商支持，社区，费用，用户群体，应用场景等POC测试阶段

1.熟悉引入产品特性，确认测试架构，并搭建测试环境

2.确认POC测试范围，如，基准SQL测试，压力性能测试，备份恢复测试，实际业务场景测试，破坏性测试，关键特性测试

3.确认测试工具，或是编写相关测试用例

4.对个场景开展测试工作，如数据准备，各场景测试，并记录测试结果，

5.对测试结果进行分析，找出差异与问题，并进行迭代测试POC测试报告，包括对各产品的对比数据，分析结论引入阶段

1.确认主机，网络要求，设计数据库架构，部署方式等

2.确认相应的参数规范

3.确认开发应用场景架构规范文档，部署配置安装文档，开发规范，监控配置文档应用阶段

1.对于运维人员进行培训

2.日常常见问题处理

3.监控配置管理运维手册等推广阶段对于一款新引入的数据库产品在应用成熟后那么就有了成熟的运维管理方式，包括日常的监控，运维，架构设计，应用场景匹配，灾难恢复等，甚至是产品化，那么就可以进入大规模的推广了。

在市场竞争日益激烈的环境下，产品定位是企业成功的关键因素之
一。产品定位是指根据目标市场和目标消费者的需求、偏好和期望，确定产品的特性、功能、形象和价值，并与竞争对手的产品进行差异化的过程。产品定位不仅影响产品的设计、开发、生产和推广，也影响消费者的认知、态度和行为。大数据技术可以为产品定位提供强大的支持和帮助。通过收集、分析和挖掘海量的数据，企业可以更准确地了解市场的动态、消费者的需求、竞争对手的策略和自身的优势，从而制定出更合理、更有效、更有针对性的产品定位方案。具体来说，大数据技术可以在以下几个方面助力产品定位：市场细分市场细分是指将整个市场划分为具有相似特征或需求的若干个子市场，每个子市场都是一个相对独立和有潜力的目标市场。市场细分可以帮助企业更清楚地了解市场的结构和规模，更有效地选择目标市场，更灵活地调整营销策略。大数据技术可以帮助企业进行更精准、更细致的市场细分。通过对用户的注册信息、购买记录、浏览行为、评价反馈等数据进行分类、聚类、关联等分析方法，企业可以将用户划分为不同的细分市场，每个细分市场都有其特定的特征、需求和潜力。例如，根据用户的性别、年龄、地域、收入、职业、兴趣等维度进行细分，或者根据用户的购买频率、购买金额、购买时间等维度进行细分。这样，企业可以根据不同细分市场的特点，设计出不同的产品或服务，满足不同消费者群体的需求，提高市场占有率和利润率。以某电商平台为例，该电商平台主要销售服装、鞋子、箱包等时尚类商品，面向的目标市场是年轻、时尚、追求个性的消费者群体。该电商平台通过对用户的注册信息、购买记录、浏览行为、评价反馈等数据进行分析，将用户划分为不同的细分市场，例如性别、年龄、地域、收入、职业、兴趣等。然后，该电商平台根据每个细分市场的特点和需求，推出了不同的产品或服务，例如针对女性用户推出了更多的款式和颜色的服装，针对年轻用户推出了更有创意的商品，针对高收入用户推出了更多高质量的商品。消费者洞察消费者洞察是指对消费者的行为、偏好、心理和情感，以及影响消费者决策的各种因素进行深入的分析和理解，从而揭示消费者的真实需求和期望。消费者洞察可以帮助企业更准确地把握消费者的需求和动机，更有效地满足消费者的期望，更有力地影响消费者的认知和态度。通过对用户的搜索词、点击率、收藏率、购买率、转化率、留存率等数据进行描述、预测、推荐，企业可以深入了解用户的偏好和心理，以及影响用户决策的各种因素。根据用户的搜索词可以了解用户的兴趣和需求，根据用户的点击率可以了解用户的注意点，根据用户的留存率可以了解用户的重复购买。企业可以根据用户的期望，通过有效的沟通和传播方式，塑造产品在用户心目中的形象。再以某电商平台为例，该电商平台利用大数据技术，对用户的搜索词、点击率、收藏率、购买率、转化率、留存率等数据进行分析，深入了解用户的偏好和心理，以及影响用户决策的各种因素。然后，该电商平台根据用户的真实需求，确定了产品的功能、品质、形象和价值。竞争分析竞争分析是指对竞争对手的产品特点、优势、劣势和市场表现等进行全面的分析和评估，从而了解竞争对手的策略和举措，以及竞争对手可能采取的应对措施。竞争分析可以帮助企业更清楚地了解自身的优势和劣势，更有针对性地制定差异化策略，更有效地抵御竞争压力。大数据帮助企业进行客观实时的竞争分析，对竞争对手的产品信息、价格信息、销售数据、评价数据、口碑数据等进行比较、评估、优化，企业可以全面了解竞争对手的产品特点、优势、劣势和市场表现，以及竞争对手可能采取的策略和举措。根据自身的核心竞争力和差异化优势，确定产品与竞争对手产品之间的差异化点，并通过突出自身产品的独特性和优越性，赢得用户的青睐。再以某家电商平台为例，大数据技术分析竞争对手的产品信息、价格信息、销售数据、评价数据、口碑数据等，全面了解竞争对手的策略和举措，以及竞争对手可能采取的应对措施。然后，该电商平台根据自身的核心竞争力和差异化优势，确定了产品与竞争对手产品之间的差异化点，并通过突出自身产品的独特性和优越性。总之，大数据技术可以为产品定位提供强大的支持和帮助。通过利用大数据技术进行市场细分、消费者洞察和竞争分析，企业可以更准确地了解市场的动态、消费者的需求、竞争对手的策略和自身的优势，从而制定出更合理、更有效、更有针对性的产品定位方案，提高产品的竞争力和市场表现。

近日，云原生智能数据管理平台NineData和泽拓昆仑分布式数据库产品Klustron完成产品兼容互认证。经过严格的联合测试，双方软件完全相互兼容、功能完善、整体运行稳定且性能表现优异。本次玖章算术与泽拓科技的携力合作，在双方共同的努力下，高效完成了双方产品兼容性互认证，为产业发展更进一步，同时，为更好地支撑业务创新需求迈出了坚实的一步，对IT基础设施实现稳定、高效、可信、可靠，筑牢产业数字化基石。认证证书关于泽拓科技泽拓科技（深圳）有限责任公司于年底创建，年以来完成多次数千万元人民币融资，团队规模快速发展，产品研发持续迭代。我公司致力于为各行各业数字化、信息化、智能化提供可靠的基础平台和技术，解决用户在海量数据存储、管理和利用方面面临的可靠性、可扩展性、稳定性和性能等一系列难题和技术挑战，让客户的应用系统提供优质的服务给其终端用户，有效支撑客户业务稳定高效流畅运作。泽拓科技独立研发的新一代分布式数据库Klustron同时支持MySQL和PostgreSQL数据库连接协议和SQL语法的分布式HTAP数据库系统，可扩展的AI基础设施。聚焦于解决各行业的应用软件、Web系统和SaaS云服务在存储、管理和利用海量关系数据中存在的各种问题，并致力于提供支撑高并发高负载的事务处理和数据读写服务，进而助力应用软件开发商、服务商，一起为最终用户最大限度地创造价值。关于玖章算术玖章算术（浙江）科技有限公司，聚焦在云计算与数据管理基础技术领域，通过云原生技术打造全球领先的技术平台，致力于帮助客户更好地使用云计算技术，创造业务价值。NineData是新一代的云原生智能数据管理平台，提供了数据复制、SQL开发、数据备份以及数据对比等多种功能，帮助用户轻松实现混合云、多云数据源的统一管理。NineData的数据复制功能支持数十种同异构数据源之间的实时复制，提供单向和双向实时同步功能，适用于实时数仓构建、数据迁移、异地容灾、异地多活、数据库扩缩容、数据库版本升级以及数据仓库实时数据集成等多种业务场景。可以满足企业多种场景下数据流动需求，让企业能更专注于自身业务的发展。

数据运营可以理解为数据化运营和运营的数据化，也许这里面会有概念上的差异，但只要你能做出用户喜欢的产品，沉淀一堆优质数据提高用户体验，那就可以了！那么，作为一个产品运营的同学，该如何通过数据的方式来做好运营？其实你做数据也好，做运营也好，最后都会回归到业务本身。而很明显，你从数据角度去思考运营，会发现你对业务的理解更加透彻。

1.运营数据的解读运营数据有很多，而作为产品运营，其实就是欠缺一点点的逻辑思维。这也不能怪谁，平时淹没在大量的运营活动和策划等事无巨细的工作中，没有跳出来思考运营都包含哪些东西，以及如何使用已有的数据。第一反应和运营数据相关的就是一堆指标和报表，就是流量指标 交易指标 会员指标。流量指标重点就是关注每天的日UV、PV变化，各渠道的投放效率和ROI：交易指标更多是产生收益的环节，销售额、客单价、订单和转化率：会员指标更像是一个用户健康的监控，所以包括拉新、活跃和流失这些都不能出现太大的异常：

2.分析的基本方法如果从运营角度去做分析，就需要从对比、趋势、相关性、SWOT、日报周报、专题分析这些角度去思考如何做好运营。而从运营的角度怎么去做好分析呢？无外乎以下几点：

(1)明白对象：做运营的目的是提升活跃度还是做用户的拉新引流？

(2)定好标准：到底做到500W日UV算引流合格还是活跃度做到300W？

(3)清晰对比：和之前相比、和其他业务相比、和类似的产品相比我们做的怎么样？

(4)看清趋势：既然做运营就是要事无巨细，总不能把一个业务做到没有用户吧？

(5)观察全局：要联系产品、BD合作、推广这些，有些是产品问题导致流量的急剧下降，有些是推广渠道关闭了所以没有流量，相信运营的同学在这块深有感触。

3.提升数据运营能力这里也是主要从运营的角度去考虑，别一上来就各种报表和产品，作为一个产品运营还是没办法有这么多技术实力。所以这里要说的是，一个综合实力强的数据产品运营一定是：数据团队 运营团队，这样的强强联合。作为运营团队，学会用数据说话，用图表说话，能够平时和数据的团队多交流，多提一些数据需求。作为数据团队，学会从运营的角度思考问题，最近在搞什么活动，有没有什么会员权益，如何提供一个可视化的数据平台供产品运营参考。只有这样的紧密合作，才会做到所谓的：数据化运营。

4.掌握数据运营工具有了数据运营的方法和能力，接下来就要考虑怎么把它们发挥出来？靠写代码显然是不现实的，你不可能为了实现某一个分析而从头到尾去开发一个应用，更何况运营团队中又有多少人懂得技术？所以，需要借助一款成熟的BI工具来实现这个目标，由广州思迈特软件推出的Smartbi就完全可以胜任。Smartbi覆盖数据分析的全流程，包括数据连接与准备、数据分析与挖掘、数据共享与应用，除了满足你日常的报表和指标分析需求，用来做数据的可视化展示也是非常好用的。有了BI工具的加持，相信一定会让你的产品运营如虎添翼。​

一、前言在做企业服务类(ToB)的产品时，我们经常会遇到如下场景：每个客户拿着他们的需求清单，来咨询我们的产品是否可满足他们的诉求。如图所示：每个客户的需求有重叠的内容，也有不一样的内容，而这些需求，在某一领域均具有较强的通用性。如何满足这些客户需求的同时又能使各个需求沉淀为标准功能，而不仅仅是为了交付项目？这成为ToB类产品经理思考最多的问题。为支撑客户诉求，基本的做法是抽象各个需求，落地为标准功能，将各个功能拼装成一个产品。但是一段时间后大家就会发现功能越堆越多、产品越做越庞大，但是用户体验却越来越差，产品开发维护越来越困难。如何既能满足客户诉求，又能解决产品存在的这些问题？模块化设计是一个方向。后面我们展开介绍下，数栈在模块化设计方面的一些经验供参考。

二、模块化设计介绍（一）目的从商务销售的角度说，产品模块可自由组合报价，贴合不同客户的需求，提高产品销售的成单率。从产品研发的角度说，减少重复造轮子的现象，提高研发效率和产品扩展性。（二）落地经验模块化设计在数栈平台的落地实施，从大到小主要分为下面三种方式：子产品化公共模块组件/插件化开发

1、子产品化1）需求背景：每个客户，甚至同一个客户在不同阶段，对数据中台的理解都不尽相同。比如客户A是个中等规模企业，希望能有款产品帮助他建设离线数仓，满足基本的数据开发诉求，那数栈的离线开发模块就可以满足他们的诉求。比如客户B是个大型的集团企业，希望能从数据开发、数据服务、数据治理等多个方面搭建起集团数据中台，那就得输出一整套数栈去满足该客户。2）设计思路：产品上——根据业务逻辑，各个模块独立解耦，定位升级为子产品，负责解决不同的业务场景诉求。商务上——销售时可单独报价输出，也可组合报价输出。3）落地成果：数栈作为一款数据中台产品，其中包含了：离线开发、实时开发、算法开发、数据服务、数据资产、数据质量、智能标签等子产品，每个子产品可解决不同的业务场景诉求，并支持独立、组合部署。

2、公共模块1）需求背景：数栈的各个模块独立化成子产品后，虽然可以解决不同的业务场景诉求，但是在数据中台这个框架内，仍然会存在一些相同的基础功能诉求，比如用户体系、数据源管理、任务运维等。如果每个子产品内部独立实现，会存在两个问题：增加了用户的使用成本。比如相同的用户、相同的数据源需要在各个子产品内多次维护，而且还容易造成理解歧义。增加了产品的研发成本。相同的功能需要重复实现，重复造轮子，浪费研发资源和运维成本。2）设计思路：剥离各个子产品中的通用功能作为公共模块，统一进行维护管理，然后为各个子产品提供服务。公共模块的设计需要充分调研各个子产品的诉求。对于通用诉求，抽象出标准功能；对于拓展诉求，提供配置化功能；对于个性诉求，由子产品自行实现。3）落地成果：

3、组件/插件化开发1）需求背景：如果说前两部分的模块化设计是对产品经理能力的考验，那这部分内容更多是对开发人员的要求。下面介绍我们在日常工作中遇到过三个问题场景：a、产品设计时，需要新增一个输入框，要求是：属于必填项、内容格式限制中英文、长度限制255字符。需求很简单，但是每次评审时，产品经理都得给研发说明如果为空时怎么提示、内容不符合格式要求时怎么提示、长度超过限制时怎么处理，沟通成本极大，而这仅仅是整个原型设计中1%都不到的内容。b、产品设计时，需要复用另一个模块中的表单，表单中维护的各个表单项、表单项关联逻辑均相同。功能完全一致，但是研发调研后发现，原有的表单处理逻辑和业务处理逻辑强耦合，导致表单代码无法复用，需要重新独立开发。c、在产品迭代过程中发现存在一类需求，更新相对频繁，需求逻辑具有一定共性，而且更新不会涉及已有功能的改动。这类需求对于开发，和公共模块之于产品类似，可以抽象为一种公共技术能力对外提供服务。比如我司经常会遇到的需求有：新增支持一种数据源、引擎新增一种任务类型等。2）解决方案：前端沉淀标准组件库。对于一些常用的设计，通过组件复用来减少开发和产品的工作量；目前我们已沉淀30 前端组件，并在持续迭代中。代码的低耦合设计。这部分要求比较虚，而且没有非常明确的边界，依赖开发经验和对业务的理解，需要持续成长。插件化设计。区分应用层代码和底层代码，底层代码进行插件化封装，可为上层不同的应用提供支持，在支持快速迭代的同时又不会影响已有功能，这样应用层开发可以投入更多地精力去支持业务。目前已落地：数据源插件、数据同步插件、Engine插件、血缘解析插件。

三、总结思考模块化设计是一种解决方案，并不是最终目的，因此，在产品设计时不能为了模块化而模块化。尤其是产品初期，此时产品功能并不丰富，而且为了快速迭代抢占市场，并不适合投入较多的精力去做这个事情。但是一旦产品进入稳定发展期，产品经理和研发同学都应该开始思考模块化设计在日常工作中的应用了。模块化设计并不是产品换个名称、独立做个页面就是模块化了，业务层面如何划分、模块之间如何配合、插件剥离的边界在哪，代码逻辑怎么解耦等等，这些都是需要思考的地方。数栈是云原生—站式数据中台PaaS，我们在github和gitee上有一个有趣的开源项目：FlinkX，FlinkX是一个基于Flink的批流统一的数据同步工具，既可以采集静态的数据，也可以采集实时变化的数据，是全域、异构、批流一体的数据同步引擎。大家喜欢的话请给我们点个star！star！star！github开源项目：/DTStack/flinkxgitee开源项目：/dtstack_dev_0/flinkx

近日，OpenCloudOS开源社区签署阿里巴巴开源CLA(ContributionLicenseAgreement,贡献许可协议),正式与阿里云PolarDB开源数据库社区牵手，并展开OpenCloudOS（V8）与阿里云开源云原生数据库PolarDB分布式版、开源云原生数据库PolarDBPostgreSQL版兼容性适配。经过严格测试，双方产品完全兼容，整体运行稳定，在功能、性能及兼容性方面表现良好。关于PolarDB开源PolarDB是阿里云自研的云原生数据库产品家族，采用存储计算分离、软硬一体化设计，既拥有分布式设计的低成本优势，又具有集中式的易用性，可满足大规模应用场景需求。年，阿里云把数据库开源作为重要战略方向，正式开源自研核心数据库产品PolarDB，助力开发者和客户通过开源版本快速使用阿里云数据库产品技术，并参与到技术产品的迭代过程中来。开源云原生数据库PolarDB分布式版（PolarDBforXscale，简称“PolarDB-X”），是阿里云自主研发的高性能云原生分布式数据库产品，其采用Shared-nothing与存储计算分离架构，支持水平扩展、分布式事务、混合负载等能力，具备企业级、云原生、高可用、高度兼容MySQL系统及生态等特点。开源云原生数据库PolarDBPostgreSQL版（PolarDBforPostgreSQL，简称“PolarDB-PG”），是阿里云自主研发的云原生关系型数据库产品，100%兼容PostgreSQL；采用基于Shared-Storage的存储计算分离架构，具有极致弹性、毫秒级延迟、HTAP的能力和高可靠、高可用、弹性扩展等企业级数据库特性。同时，PolarDB具有大规模并行计算能力，可以应对OLTP与OLAP混合负载。关于OpenCloudOS开源OpenCloudOS操作系统开源社区是由操作系统、软硬件厂商与个人共同倡议发起的操作系统社区项目，为用户提供自主可控、绿色节能、安全可靠、高性能的下一代云原生操作系统。OpenCloudOS8.6是OpenCloudOS社区发布的新版本，其基础库和用户态组件完全与CentOS8兼容，并通过内核层面的优化和增强，经万 节点大规模验证，稳定性提升70%，特定场景性能提升50%，能够提供给用户相比于CentOS8更优的解决方案。完成兼容性适配后，通过双方的交流合作和资源共享，可以一起打造在数据库领域的生态，更好地让双方开源生态融合，从而提高用户的业务效率和体验。

随着互联网的发展，产品的分发方式也在逐步演进。本文主要介绍四种常见的产品分发策略，并且讲述如何通过数据智能的方式提升各种分发策略的效率，助力精细化运营；同时，结合具体案例进一步说明如何进行推荐策略的迭代与优化。

一、如何理解产品分发？为了更好地理解产品分发，我们以最常见的支付宝APP为例。每个人的支付宝首页所看到的内容是不一样的，有的有生活缴费，有的有推荐卡片，有的有资讯卡片，支付宝APP不同模块的产品和内容的分发逻辑是不同的。在支付宝首页，是如何进行分发的呢？“扫一扫”“收付款”“出行”“卡包”四大“金刚位”，是用户进入APP的视觉焦点，这四个位置只承接公司的战略业务，因此基本所有人看到的都是一样的。一旦这些位置的内容有所调整，说明支付宝甚至阿里的经营战略可能已经发生了变化下方的五大“罗汉位”，之前是无法编辑的，因为承接的是支付宝仅次于战略业务的方向性业务，后来综合考虑用户的使用效果进行了调整，因为即使是方向性业务，用户不点击也是流量的一种浪费再下方的宫格位承接的是诸如餐饮、出行、缴费等生活服务入口，其位置也可以进行排序。再下方的“消息”，并不通过规则分发，而是由业务逻辑触发，比如商品到货、退款到账等……总结来说，支付宝首页既有完全一样分发的战略业务，又有基于规则排序的宫格位；有基于运营和投放的Banner，还有基于个性化推荐的Feed，基本涵盖了互联网产品主流的分发逻辑。如果某个互联网产品所能够提供的服务较少，核心沟通场景只有一个，原则上不用考虑分发策略，但当产品开始出现运营需求，就要开始考虑人工运营的分发。而随着服务能力的增多，需要通过简单的规则进行排序，比如高点击率、高曝光、高转化的页面排在前面；当服务能力进一步增强，内容逐步增多，简单的规则排序已经不能满足分发效率，这时可以通过搜索帮助用户直达某项服务；当用户圈层越来越多，用户体量越来越大，单纯的搜索可能也无法满足需求，这时可以考虑个性化推荐。简而言之，随着互联网的发展，分发规则也在逐步演进。通常，产品的分发策略总共分为4类：人工运营、规则分发、搜索分发、算法分发。人工运营：可以实现千人一面（即所有人看到的是相同的版本）或者百人一面（通过圈人的方式提高某些页面的效率）规则分发：当服务的品类变多，需要通过简单的规则提升效率搜索分发：基于明确的需求，进行精准的召回算法分发：个性化推荐或相关推荐那么，产品分发究竟是什么？产品分发本质上是用户需求的分发。当用户打开一个产品，其需求是比较明确的，比如打开抖音就是要看短视频、打开淘宝大概率要买东西、打开腾讯会议是要开会等，产品分发原则上要以最短的路径把想看的内容展示给用户。对平台而言，用什么样的分发方式可以将用户导流到业务线

一、业务线二等，如何提高匹配的效率就变得比较重要。同时效率不单只针对用户，也要平衡平台效率，比如当前战略目标是做好某项业务，站在平台的视角，适合什么样的分发规则？解决匹配效率时，要实现产品战略和平台收益的最大化。

二、数据智能提升分发效率人工运营、规则分发、算法分发，从前到后三类分发方式的智能化程度越来越高，效率也是越来越高。接下来分别讲述如何通过数据智能提升三种分发方式的效率。

1、人工运营举个例子，某金融APP运营要在首页增加理财弹窗。通常，首页弹窗的用户体验不太好，原则上是能不弹就不弹，但如果必须进行弹窗的话，建议只对那些对弹窗内容感兴趣的用户进行弹窗触达，避免对其他用户的打扰。过去的做法一般是基于地域、性别或年龄对人群进行定向筛选，比如过去购买此类理财产品的用户大多为北京、年龄在25-30岁，那就基于这些静态特征将这批用户圈选进行弹窗展示。但更高效的分发方式其实是只给对相关活动感兴趣的用户弹窗，那么目标就是如何找到感兴趣的用户？如果只基于用户过往行为，比如过去参加过类似活动而展示，可能会错失一些虽然没参加过活动但可能同样感兴趣的潜在客户，这时可以基于特征挖掘找到站内相似的用户。如果之前平台没有做过类似活动，没有相关特征该如何挖掘呢？平台在进行相关活动推广时，通常会先进行小规模放量的灰度测试，比如先切10%的流量给到相关活动，在这10%的用户中，如果有人点过相关弹窗，说明他们对弹窗是感兴趣的。这时便可以从10%的用户中筛选出种子用户，基于他们进行全站特征挖掘，从而把对活动感兴趣的用户全部圈选出来。在人工运营的分发方式中，提效的主要路径是从粗放式运营到用户分群运营。用户分群如何分？主要有三种：基于静态属性分群、基于行为分群、基于用户行为特征挖掘分群。

2、规则分发规则分发该如何提效？假设用户点开某金融APP后，同时命中10个弹窗规则，到底应该弹哪个？通常针对这种情况都会制定相关规则，比如点击率（CTR）最高、上线最久或是即将下线等等，但这往往会陷入一个逻辑陷阱：所有排序的规则大都基于不同弹窗的表现情况，而并没有考虑用户偏好。如果想找到用户爱看的弹窗，首先要对用户进行更细颗粒度地洞察，比如过往是否买了理财、是否贷过款、是否领过赠险……根据过往的行为，为用户打上偏好标签，从而对他们有进一步的认知，然后基于标签匹配进行规则分发，比如为有理财偏好的用户弹出理财体验金；为已通过授信但尚未提现的用户弹出免息券等。总之，通过更细颗粒度的用户标签为规则分发提效。

3、算法分发如果相关分发规则颗粒度更细，其实就进入到个性化算法分发模式。我们对用户的理解越细致，分发的效果就越好。通常个性化算法分发比较依赖数据，用户是谁？有什么特点？用户特征如何？这些是做运营，甚至是做个性化推荐的基础。用户特征通常分为两类，一类是静态特征，一类是动态特征。静态特征：一段时间内不会发生变化的特点，比如性别、年龄、地域、渠道等。动态特征：基于用户行为来提取的特征，他和用户当前场景下的兴趣和爱好息息相关。比如：用户手动输入的信息：包括用户在搜索引擎中输入的关键词，用户反馈的信息，对推荐对象的喜好程度等；用户基于Item的行为：包括浏览、点击、停留时长以及互动行为（转评赞等）；负反馈：不喜欢、不感兴趣。除了对用户特征的刻画，还需要对物品特征进行刻画。比如对视频内容、运营物料等有所了解，这些称之为Item，Item也分为静态和动态特征。物品静态特征：指内容自身的属性特征。例如：视频时长、图片宽高比、安全等级、风控等级、作者、内容字数、一级分类、二级分类……物品动态特征：指的是基于用户行为抽象的特征，动态特征又分为正反馈和负反馈。例如：点击率、完播率、点赞率、分享率、评论率、收藏率、负反馈……知道了用户和物品的特征后，只有做好中间的匹配，才能做好个性化分发。

三、推荐策略的迭代与优化

1、个性化分发的逻辑框架个性化算法分发涉及的逻辑结构主要有三个：召回、排序、重排。召回比如某个新闻资讯APP对站内内容按照热门来排序，高点击率的内容放在前面，即热门召回；比如有的APP会基于用户偏好进行排序，即基于用户偏好召回；此外还有基于地域的召回等。召回指的是基于什么样的规则或特征，把内容从库里检索出来进行排序分发。排序排序的目标要结合具体的业务场景确定，即业务上达成什么样的目标，最有可能实现目标的物料会被排到前面。比如业务目标是提高新闻资讯流CTR，那么就按照CTR预估排序，用户最可能点哪个，就把哪个放前面；比如电商的推荐目标是提升购买转化率，哪个对用户来说最可能成单，哪个就排前面。重排因为召回和排序的过程是一个算法黑盒，没有办法控制。当算法排序结果不符合预期时，可以进行策略干预，这被称为重排序。比如某个作者比较热门，其内容表现都很好，如果按照正常运算的排序，很可能多次刷到的都是他一个人的内容，而平台希望用户看到更多元和丰富的内容，这时就需要打散重排。

2、策略迭代的SDAF原则个性化算法该怎么优化？基于神策SDAF原则，所有策略优化都要基于数据洞察，明确要优化的方向和目标，进行策略方案迭代，通过A/B试验展开行动，最终基于试验结果进行归因。Sense：问题感知对于推荐策略的数据洞察，包含三部分：数据异常、主动优化、阶段目标调整。数据异常：包括核心指标CTR下降，要去看为什么会下降，与哪些因素有关等。主动优化：比如想把当前CTR由15%提升到30%，优化哪些维度可以实现。阶段性目标调整：当完成CTR优化后，接下来想优化互动率这个指标，那么排序的目标就要从CTR转为互动率，这影响的是底层的算法逻辑。Decision：明确策略迭代方案以电商为例，如果只优化CTR，对曝光和点击进行埋点即可；而如果要优化成交率的话，那么就要看与成交相关的行为，比如收藏、加购等，这些都需要进行埋点，获取数据后进入到模型训练流，只有获取到数据，模型才能基于目标进行优化。数据洞察的主要目标是拒绝拍脑门的需求，每个需求在进行A/B实验前都需要拿数据先验证一轮。基于数据洞察，提出具体的优化策略。Action：设计A/B实验设计A/B实验时要遵循三个原则：科学的实验分组、分组流量可置信、实验组之间变量唯
一。Feedback：实验效果回收/归因当实验结果不符合预期，要进行归因分析。但神策认为即使试验的收益是正的，也要进行归因分析。案例1：某UGC平台要求仅召回高评论内容某UGC平台要求召回高评论的内容。在评估这个需求时，我们可以思考两个问题：是否进行了数据洞察？高评论内容一定是好内容吗？好内容具有CTR高、消费表现好、互动率高的特点，而高评论只是互动率这个指标的体现，并不是整体好内容的指标，因此评估高评论内容的消费表现，需要进行数据洞察。假设优化了高评论的排序后，能够提升社区消费的深度，那么就要把高评论的内容选取出来，并对他们的消费表现进行数据洞察，如果比大盘表现好，那么就可以进行优化。但这里还有一个问题需要明确，即什么是高评论的内容？它的标准是评论数量超过20还是100，还是评论率超过20%等，需要明确清楚，因为不同标准的表现也不同。假设确定完高评论的标准后，还要看符合标准的内容到底有多少，比如要召回的评论数量要大于200，那大于200的内容到底有多少，如果只有20条，那这样排序是否还有必要？经过以上指标拆解和数据洞察，就能大概判断改变策略之后的效果。案例2：陌生人交友平台回复率优化某陌生人交友平台，通过用户的动态匹配提高用户沟通成功率，从而帮助用户建立关系。具体来说，这个动态匹配的过程大致分为五步：第一步，系统以男用户的身份给女用户发送一条消息；第二步，消息曝光，女用户看到消息；第三步，女用户回复该条消息；第四步，男用户看到女用户回复的消息，即回复的消息被曝光；第五步，男用户回复这条消息。为了提升双向沟通的概率，通过对这个链条进行漏斗分析，发现在第二步的漏斗转化率偏低，即大部分女用户都没有看到这条消息。通过数据洞察发现：系统为女用户推荐男用户时，女用户大多数都处于未登录状态用户平均使用APP的时长为15分钟基于这样的洞察，提出策略优化方案：召回最近登录时间在15分钟之内的女用户，即给最近登录时间在15分钟之内的用户发送系统默认消息。有了这个迭代策略后，随后随机抽取25%的用户进行1天实验观察。通过实验组和对照组效果对比，发现第二步的漏斗转化率有明显提升。为了继续优化第五步/第一步的转化率，按小时查看最终转化率发现：下午的转化率明显下降。此时，通过数据洞察发现：由于推荐策略中限制了每个女用户最多只能收到50个男用户的推送，而上午已经完成50个用户的推送，因此下午没有新的男用户可推荐给女用户女用户push次数与第五步成功率成正比于是，可提出策略优化方案：15分钟内最多只推5个男用户，并取消50个推送限制。接下来，随机抽取25%的用户进行2天实验，经过实验组与对照组效果对比，发现策略调整后全时段回复率均有提升，达成预期。总结起来，进行个性化策略迭代的方法论是：首先根据数据洞察得到策略迭代的方向，进行A/B实验，再基于试验结论进行正向和负向归因。

随着大数据时代的到来，数据资源正在成为“数据资产”，数据汇聚和应用正在为企业、社会提供新的经济效益。取之于民的数据被安全使用，进行合理的加工，造福于民，正在成为现实。在海南省，购买数据产品已经像逛超市一样方便，通过数字技术实现数据的安全有序流动。什么是数据产品超市？海南省数据产品超市（/）是集数据“归集共享、开发生产、流通交易、安全保障”为一体的“理念先进、功能齐备、配套完善、管理高效、运营良好”的数据开发利用创新平台、国际性的数据要素流通交易市场与大数据产业孵化平台。为加快培育数据要素市场，海南省大数据管理局联手中国电信天翼云推出海南省数据产品超市，通过有序开放公共数据资源整合社会数据资源，引进具有技术服务能力和研究分析能力的大数据企业、机构和团队，进行数据产品开发生产、供需对接、流通交易，构建一个统一公平、竞争有序、成熟完备的数据要素市场体系，满足各级政务部门及企事业单位对数据产品日益增长的需求，全面提高数字化政务服务效能，使公共服务更便捷、城市管理更高效、交通出行更畅通、人民生活更智慧，打造智慧共享、和睦共治的新型数字生活。全国首例的数据产品超市是如何建成的？年5月，海南省被国务院办公厅列为全国公共数据资源开发利用试点省份，全国首例省级数据产品超市正式问世。海南省大数据管理局充分利用海南省已建成的“七个一”大数据能力支撑底座，并基于天翼云技术服务能力，搭建全省统一的功能强大的数据产品开发利用平台，有序开放公共数据资源和电子政务平台能力资源。这是全国首例，也是一个探索性的实施工程。天翼云结合自身多年的数据治理和运营经验，与海南省大数据管理局联合打造了数据业务运营服务平台建设方案。在保障数据安全的前提下，引进多方安全计算、隐私计算、联邦学习等多种前沿技术，实现多路径多元化融合技术创新，提升数据应用价值。双方着手构建数据要素市场化流通机制，基于强大的数据中台和业务中台“双中台”融合共建优势，为平台建设提供数据建模等应用服务，构建了平台底座与应用创新一体化建设方案，打破“数据壁垒”和“业务壁垒”。如何驾驭海量数据？在平台建设过程中，也遇到了一些挑战。比如，在开放实践数据过程中，普遍存在“不愿”、“不敢”、“不便”三大难题。在数据授权方面，数据权责不清，公共数据使用申请不顺畅，垂直管理单位数据共性问题处理难度大。各方申请使用公共数据时，对企业数据使用的认知不统

一，数据权属不明确。如何解决数据安全问题是建立统一标准、流程和体系的基础。▎数据安全方面天翼云资源池已通过中央网信办安全审查，能够全面满足云上等保2.0体系建设的云原生安全产品，确保不触碰用户数据，坚决捍卫用户数据安全。▎数据管理方面通过构建可视化建模平台，完成建模流程，建立统一的公共数据运营管理体系，实现了数据脱敏接入系统，并通过构建海南省数据产品超市交易服务平台和数据产品开发利用平台，建立数据全生命周期管理体系。▎数据处理方面天翼云发挥在数据资源及数据处理方面的能力，有序利用公共及社会数据资源，开展数据产品交易和数据服务，满足各级部门对数据产品的需求。海南省数据产品超市以有序、安全、开放的机制，促进了公共数据资源的场景化应用和发展，将全面提高数字化政务服务效能，成为其他省份推进公共数据资源开发利用的标杆，也为全球城市数字化转型提供了中国样板。

近日，XSKY星辰天合旗下产品与阿里云PolarDB开源数据库社区展开产品集成认证。测试结果表明，星辰天合旗下的融合计算管理平台XHERE（V2）、统一数据平台XEDP（V6）、天合翔宇分布式存储系统（V6）与阿里云的开源云原生数据库PloarDB分布式版（V2.2）以及开源云原生数据库PolarDBPostgreSQL（V11），完全满足产品兼容认证要求，兼容性良好，系统运行稳定。云原生数据库PolarDB是阿里云自研产品，在存储计算分离架构下，利用了软硬件结合的优势，100%兼容MySQL和PostgreSQL生态，为用户提供秒级弹性、高性能、海量存储、安全可靠的数据库服务。PolarDB分布式版历经十余年淬炼，始终保持对阿里集团“双十一购物狂欢节”所有相关业务的全面支撑。PolarDB坚定遵循自主可控、开放生态的发展思路，持续围绕MySQL、PostgreSQL开源生态构建企业级、分布式能力，以求最大程度降低用户的学习使用成本。作为PolarDB开源数据库社区的长期生态伙伴，星辰天合凭借在软件定义存储领域的深厚积累，旗下融合计算管理平台XHERE（V2）、统一数据平台XEDP（V6）、天合翔宇分布式存储系统与PolarDB的集成认证完成之后，可以帮助双方共同的客户更好的实现数字化转型，铸就更完善的数据基础设施。未来，星辰天合将进一步携手阿里云PolarDB开源社区，在存储等诸多方向共同探索，共同打造更优质的产品，提供更好的产品体验。

近日，博睿数据与东方通以及达梦数据完成产品兼容互认，博睿数据BonreeBrowser、BonreeDataview、BonreeONE、BonreeRUM、BonreeSDK、BonreeServer等多款产品与东方通应用服务器软件TongWebV7.0以及达梦数据库管理系统V8完全兼容，整体运行稳定高效。作为国内APM和可观测性的领军企业，博睿数据十分重视生态发展，并积极与芯片、操作系统、数据库、中间件、应用软件等生态厂商保持高度紧密的协同合作，以此不断完善产品性能，为客户提供更优质的产品和服务。此次博睿数据旗下BonreeBrowser、BonreeDataview、BonreeONE、BonreeRUM、BonreeSDK、BonreeServer等多款产品与东方通应用服务器软件TongWebV7.0以及达梦数据库管理系统V8完全兼容，不仅是基于产品功能和性能的测评认证，更是双方共同携手、持续创新，在信息技术应用创新产业生态发展中的不懈努力。目前，博睿数据公司的产品线已经覆盖APM、NPM、DEM、智能运维和可观测性等多个方向。在APM领域，博睿数据首家通过了代表软件能力成熟度最高等级的CMMI5级评估认证；年5月，BonreeServer获得优炫软件产品兼容互认证书和海量数据兼容互认证书。在产品适配方面，博睿数据也在全力布局适配主流的国产化整机、CPU、操作系统、中间件、数据库厂商等。在未来的发展中，博睿数据将通过内外部协同合作，整合优势资源，建设生态合作网络。同时，充分发挥自身的优势，更全面地满足多行业、多业务应用需求，持续推进APM和可观测性等技术在信息技术应用创新产业拓展与创新。关于东方通TongWebV7.0东方通应用服务器软件TongWebV7.0产品，是东方通推出的遵循JavaEE7规范的企业级应用服务器，提供了诸如负载均衡、集群、WebService数据库连接池、事务处理服务、安全管理等功能，它为企业应用提供了可靠、可伸缩、可管理和高安全的基础平台。同时具有功能完善，支持开放标准和基于组件开发，多层架构、轻量等特点，为开发和部署企业应用提供了必需的底层核心功能。关于达梦数据库管理系统V8达梦数据库管理系统V8融合了分布式、弹性计算与云计算的优势，多样化架构充分满足不同场景需求，支持超大规模并发事务处理和事务-分析混合型业务处理，动态分配计算资源，实现更精细化的资源利用、更低成本的投入，是理想的企业级数据管理与分析服务平台。

近日，北京柏睿数据技术股份有限公司（以下简称柏睿数据）与阿里云PolarDB开源数据库社区展开产品集成认证。测试结果表明，柏睿数据旗下数据虚拟化管理平台（V1.0）与阿里云以下产品：阿里云PolarDB数据库管理软件、阿里云PolarDB-X云原生分布式数据库管理软件，完全满足产品兼容认证要求，兼容性良好，系统运行稳定。PolarDB是阿里云自主研发的国内首个云原生数据库，过去5年，阿里云针对PolarDB进行了诸多创新，通过采用存储计算分离、软硬一体化设计，PolarDB实现成本仅为传统商业数据库的十分之
一。所实现的计算、内存与存储资源的“三层解耦”架构、多主多写、基于IMCI（内存列存索引）的HTAP、Serverless等功能已是全球首创或业内领先的技术。从PolarDB发布以来，它在技术和商业化上都获得了迅猛发展，如今已经成为阿里云数据库产品家族中最闪耀的产品。年，阿里云正式开源PolarDB（源码仓库：/ApsaraDB/），将PolarDBforPostgreSQL和PolarDB-X进行了全内核开源，以此来推动行业的技术变革。作为PolarDB开源数据库社区的生态伙伴，柏睿数据提供基于分布式内存分析数据库为基础的一栈式实时数据智能分析产品及解决方案，在内存实时计算、OLAP增强分析、数据仓库性能提升、实时云数仓应用等领域具有独特的技术领先优势。公司核心产品包括分布式内存分析数据库RapidsDB，数据联邦RapidsFederation，数据编织RapidsDataFabric,库内人工智能RapidsParallelAI，机器学习建模平台AIWorkflow,数据库加速