实时计算平台实践
doris实践案例
Doris实践案例：基于Doris的数据分析平台建设背景随着大数据时代的到来，越来越多的企业开始关注如何利用海量的数据来进行深入的分析和洞察，以支持业务决策和优化运营。
然而，传统的数据仓库和分析平台往往面临着数据量大、处理速度慢、扩展性差等问题，无法满足业务的需求。
因此，很多企业开始采用新一代的数据分析平台，如Doris，来构建高效、可扩展的数据分析解决方案。
Doris是由百度公司开源的一款可扩展、高性能、高可靠的分布式列式存储和计算引擎。
它具有以下特点：•列式存储：Doris采用列式存储，可以大幅度提高查询性能，特别是在大规模数据查询时表现更为突出。
•实时计算：Doris支持实时数据的快速导入和实时计算，可以满足实时分析的需求。
•高可扩展性：Doris采用分布式架构，可以方便地进行水平扩展，支持PB 级别的数据存储和处理。
•高可靠性：Doris具有自动容错和自动恢复的能力，支持数据的高可靠性和持久性。
本案例将以某电商企业为例，介绍基于Doris的数据分析平台建设的过程和结果。
过程1. 需求分析与架构设计首先，我们与电商企业的业务团队进行需求沟通和分析，了解他们的数据分析需求和痛点。
通过与业务团队的交流，我们确定了以下需求：•实时分析：需要对实时的交易数据进行分析，以及时发现和解决问题。
•历史分析：需要对历史的销售数据进行深入的分析，以了解销售趋势和用户行为。
•高性能和可扩展性：需要一个高性能和可扩展的数据分析平台，能够支持PB级别的数据存储和处理。
基于以上需求，我们设计了以下架构：架构中的关键组件包括：•数据源：从电商企业的交易系统和其他数据源中获取数据，并实时导入到Doris中。
•数据导入：使用Doris提供的导入工具或自行开发的数据导入程序，将数据导入到Doris中。
•数据存储：Doris使用列式存储引擎存储数据，以提高查询性能。
•数据计算：Doris支持在线查询和离线计算，可以根据需求选择合适的计算方式。
航空发动机控制系统的实时仿真技术
航空发动机控制系统的实时仿真技术张天宏【期刊名称】《航空制造技术》【年(卷),期】2015(000)012【总页数】5页(P26-30)【作者】张天宏【作者单位】南京航空航天大学能源与动力学院【正文语种】中文随着航空发动机技术的发展，其对发动机控制系统的设计要求日益提高。
全权限数字电子控制（Full Authority Digital Electronic Control，FADEC）是现代航空发动机的重要特征之一。
FADEC系统是一种典型的复杂嵌入式控制系统，具有极高的可靠性要求。
航空发动机控制系统设计正面临着控制任务多、复杂度高、难度大且需求多样化的技术挑战，传统的量体裁衣和基于经验的设计流程已经不能适应现代航空发动机控制技术的发展需求，迫切需要采用先进的设计理念和高效的研发手段加以应对。
美国英国等技术先进国家在航空、汽车等复杂嵌入式控制系统研制领域已广泛采用基于模型的设计（Model Based Design, MBD）理念。
所谓MBD是指，在整个控制系统的开发过程中使用系统模型作为载体进行方案评估、验证和目标系统的发布，整个开发流程呈现一种从上至下的技术分解以及从下而上的系统综合过程，即所谓的“V”形体系结构。
与传统的基于经验的设计方法相比，基于模型的设计方法有助于更好地理解备选设计方案和权衡设计要素，从而能够对复杂系统进行高效的优化设计。
设计师采用图形化的工具快速构建各种系统模型，将现有的C代码与标准控制模块库整合，实现基于代码复用的自动代码生成，使嵌入式控制系统设计效率大幅度提高。
基于MBD理念开展复杂嵌入式控制系统研发的必要条件是拥有一种合适的实时仿真平台，这种仿真平台一方面能实时运行控制对象或控制器本身的模型；另一方面要具备与控制器实物或控制对象的信号接口能力。
基于这样的仿真平台可以构建控制器快速原型（RCP），或者开展控制器实物在回路仿真（HIL）[1-2]。
通过实时仿真，能够及时发现各种模型之间的差异，而不需要等到设计周期完成后才发现存在的问题。
深度学习机器学习实战项目案例分析
深度学习机器学习实战项目案例分析本文根据平安人寿AI资深专家吴建军老师在平安人寿DataFunTalk算法主题技术沙龙—“机器学习/深度学习在金融领域最新研究和应用实践”中分享的《机器学习/深度学习工程实战》编辑整理而成，在未改变原意的基础上稍做整理。
今天主要从以下几个方面进行分享：平安人寿AI应用技术概览，数据处理和编码，模型应用与实时服务，算法与模型训练。
首先讲一下平安人寿AI应用技术概览，首先分一个大数据平台开发，分为平台级的开发和应用级的开发。
平台级开发主要有离线计算平台，实时计算平台，以及多维分析引擎等；应用级开发有数据采集清洗，统计报表开发，画像挖掘等。
算法研究方面分为三个方向，第一个统计分析，金融数据比较复杂，需要投入大量的人力财力做统计分析，用的比较多。
还有就是机器学习、深度学习两类方法，主要解决的问题有：机器学习主要解决分类与推荐、知识图谱、自然语言处理，深度学习解决量化精算、视觉模型，强化学习正在研发当中。
后台系统分为两块，一个是组件类开发，一个是服务类开发。
组件主要是服务框架、训练平台、容器平台，还有一些分布式存储组件。
模型服务主要是针对这个应用来开发一些专用的系统，用专用的应用服务对接。
上图是我们的平台架构，首先是数据搜集，主要依靠Kafka，对于老系统自有一套收集机制，数据搜集完成进入Hadoop和关系DB。
数据清洗主要依靠hive和spark，hive实现hql，spark进行复杂的数据处理。
除此之外还要做一些洞察分析，分为两块一个是单表快速实时分析，第二个是多表关联实时分析。
单表主要用Druid ES做多维，多表关联主要靠Presto Impala。
还有一些用matlab, SAS做精算量化模型，还用Tensorflow做深度学习，用Hbase，Redis 主要做画像存储，提供实时查询，还有一些容器平台对外提供容器调用。
接下来讲下我们用AI技术干嘛，AI在金融领域用的还是很广，很多业务都是靠数据推动，金融对数据依赖性很强。
基于zookeeper和storm的车载流式计算框架
案例技术方案
最佳实践
架构不足及经验分享
MongoDB介绍及最佳实践 Storm介绍及最佳实践 ZooKeeper介绍及最佳实践
案例背景1——业务背景
业务场景
物流公司 校车安全 油气公司
主要功能
运行数据记录 监视驾驶 违规警告 绩效考评 报表输出 危险地带 实时监控
DBn
…
Analysis Process
现状 问题
同一公司的车辆数据分布在同一数据库 分析计算进程与DB一对一地分析数据 若一个公司有很多辆车，那么一个分析计算进程应付不过来，无法分散计算 若一个公司车辆很少，那么该公司对应的分析进程将没有任务，浪费服务器资源 因为分析进程的缓慢执行，车辆的实时运行数据无法反映到客户端
W -
(※) 62,340
3,722,157 29,763,261 504,875 4,032,874 600,874 4,804,430 27,0964 216,784 60,079 480,100
654,722,397 7,856,6448,198 88,704,782 1,064,448,769 105,600,100 1,267,200,296 6,480,540 77,760,054 10,560,006 126,720,190
・Heavy Write ・ Heavy Read ・ Past Useless
此表抽出
※：车载机发送数据最高频率2次/秒，每次发送4KB数据。10000台车载机的峰值为10000*2*4KB =80000KB=80M/S ※：从这个数据可以算出实际平均吞吐量是62340*4KB/60 = 4M/s, 但是固定时间点车载机会同时向云端发送运行数据
大数据运维和网络安全运维
模块化设计
采用模块化设计，提高数据中 心的可扩展性和灵活性。
绿色节能技术
应用绿色节能技术，如自然冷 却、高效能设备等，降低数据 中心能耗。
智能化管理
引入DCIM等智能化管理系统， 实现数据中心的远程监控和自 动化运维。
分布式存储系统部署与调优方法论述
存储架构设计
根据业务需求和数据特点，设计合理的分布 式存储架构。
监控与告警技术
实时监控大数据平台的运行状态和性能指 标，及时发现并处理潜在问题，如 Prometheus、Grafana等监控与可视化 工具。
自动化运维技术
降低运维成本和减少人为错误，如 Ansible、Chef等自动化配置管理工具。
分布式计算技术
应对大数据处理和分析的挑战，如Spark 的内存计算框架和Flink的流处理框架。
恶意攻击识别、防御和应急响应方案设计
攻击识别
利用安全监控、日志分析等手段，及时发现恶意攻击行为 ，如DDoS攻击、SQL注入、跨站脚本等。
防御措施
针对不同类型的恶意攻击，采取相应的防御措施，如部署 防火墙、入侵检测系统、Web应用防火墙等。
应急响应
建立应急响应机制，对发现的恶意攻击进行快速处置，如 隔离攻击源、恢复受损系统等，并通知相关人员及时跟进 。
负责从各种数据源中采集数据 ，并进行清洗、转换和加载等 操作。
数据处理层
运用分布式计算框架，如 Spark、Flink等，对数据进行 实时或批处理分析。
运维管理层
负责大数据平台的监控、告警 、故障排查、性能优化等运维 工作。
大数据运维关键技术
分布式存储技术
解决海量数据的可靠存储和高效访问问题 ，如Hadoop HDFS的分布式文件系统。
高性能计算平台的使用技巧
高性能计算平台的使用技巧高性能计算平台是为了满足大规模、复杂问题的计算需求而设计的一种计算系统。
它使用了现代计算机科学和工程技术，旨在提供高度并行、高效能的计算能力。
本文将介绍高性能计算平台的一些使用技巧，帮助您更好地运用该平台进行科学计算和大数据处理。
首先，合理利用任务并行性是高性能计算平台的关键。
在使用高性能计算平台进行计算任务时，我们通常将待解决的问题分解为多个子任务，利用并行计算的优势来缩短计算时间。
为了充分利用任务并行性，您可以使用任务调度器来调度和管理任务，确保每个节点得到充分利用。
其次，使用高效的编程模型和并行算法能够极大地提高计算性能。
并行算法是一种特殊的算法设计技术，可以将问题划分为多个子问题，并通过同时解决这些子问题来加速计算。
在高性能计算平台上，您可以选择合适的并行编程模型，如MPI（Message Passing Interface）或OpenMP （Open Multi-Processing），来实施并行算法。
同时，还可以使用一些高性能计算库，如BLAS（Basic Linear AlgebraSubprograms）或MPIIO（MPI Input/Output），来优化计算过程。
另外，合理分配资源对于高性能计算平台的使用也至关重要。
资源的合理分配包括内存、存储空间、处理器核心等方面的分配。
在进行计算任务之前，您可以通过调整资源的分配情况来满足问题的需求。
同时，还可以根据任务的特点，合理选择节点配置和存储策略，以提高计算效率和数据处理能力。
此外，对数据的优化处理也是高性能计算平台中不可忽视的一部分。
数据的优化处理可以包括数据预处理、数据压缩、数据分片等方面。
在进行高性能计算时，若能将数据的规模压缩至较小，并选择适当的数据压缩算法，可以在一定程度上减少数据传输和存储的开销。
同时，对数据进行分片操作，也可以帮助实现并行计算，提高计算效率。
最后，及时监控和调优是高性能计算平台使用的关键环节。
亚马逊AWS 基于AWS云平台上的 实时数据分析最佳实践分享
基于AWS云平台上的实时数据分析最佳实践分享庄富任产品拓展, A WS 中國Business Development ManagerAWS 基于云的完整大数据服务GlacierS3EC2Redshi5 DynamoDBEMRData P ipeline实时数据流 |大规模存储|大集群并行计算 Kinesis采集处理AWS上的一些大数据客户大数据挑战存储 洞察收集 分析4TB每天S3长期 归档Glacier数据 挖掘H adoop实时 数据采集Kinesis数据 仓库Redshi5实时数据流处理使用案例§▪ 对于广告平台§▪ 用户在互联网上的行为能实时的影响其广告推送内容，在用户下一次刷新页面时，就提供给用户新的广告§▪ 对于电商§▪ 用户的每一次收藏、点击、购买行为，都能被快速的归入他的个人模型中，立刻修正商品推荐§▪ 对于社交网络§▪ 用户社交图谱的变更和发言等行为，也能快速被反映在他的好友推荐、热门话题提醒上。
大数据收集和存储收集 分析存储 洞察典型的实时动态数据流处理架构和工作流程Client/SensorAggregatorConDnuous P rocessingStorageAnalyDcs + R eporDng1）数据采集负责从各节点上实时采集数据例如选用flume(cloudera) 来实现例如使用 Apache 开源工具架构2）数据接入由于采集数据的速度和数据处理的速度不一定同步，因此添加一个消息中间件来作为缓冲 例如选用apache的kafka (LinkedIn) 3）流式计算对采集到的数据进行实时分析例如选用apache 的storm (twitter)§ Amazon EC2 服务器上搭建收集器 (Kafka, Fluentd, Scribe 和 Flume等)从多个来源 汇集数据区域可用区 AEC2§▪ 客户端无法发送数据到端点 (数据收集器可靠性?) §▪ 无法立即消化大量併发事件 (数据收集器吞吐量?)从多个来源 汇集数据区域可用区 AEC2数据采集高度 伸缩可靠从多个来源汇集数据 区域可用区 A EC2 可用区 BEC2载入数据 S3 存储在本地磁盘容量?持久性?存储 并行数据加载到S3 S3Simple S torage S ervice (S3)高度可扩展无限制容量的对象存储每个对象存储达 1 b yte 至 5TB 容量99.999999999% 持久性 从多个来源汇集数据 区域 可用区 AEC2可用区 BEC2Amazon K inesis 实时数据流处理 §▪ 实时数据采集, 摄入, 传输 §▪ 处理实时动态数据流 §▪ 并行写入写出 §▪ 支持数据输出到不同存储目的地S3 Amazon KinesisHadoop EMR数据仓库Redshi> DynamoDBD ataS ourcesApp.4 [Machine L earning]A W S E n d p o i n t App.1 [Aggregate & D e -‐Duplicate]D ata S ources Data S ourcesD ata S ources App.2 [MetricE xtracDon]S3DynamoDBRedshift App.3 [Sliding W indow A nalysis]D ata S ources AvailabilityZone Shard 1 Shard 2 Shard N Availability Zone AvailabilityZone Amazon K inesis 实时数据流处理数据流Shard 分片§▪ 分片是 Amazon K inesis 数据流的基本吞吐量单位 §▪ 一个分片提供§▪ 1MB/秒数据输入(write)容量 = 1, 000 T PS§▪ 2MB/秒数据输出(read)容量 = 5 T PS实时数据流摄入实时玩家动作Amazon KinesisHay D ay 《卡通农场》Shard 1 Shard 1Shard 1Shard N§▪ 简单的调用 PUT 命令动态摄入数据 §▪ 每个分片 (Shard) 可摄入每秒1MB 数据(高达1000 T PS) §▪ 不停机状态下动态扩展 Shard 数量Producer Shard 1Shard 2Shard 3Shard n Shard 4Producer ProducerProducer Producer Producer Producer ProducerProducerKinesis " PutRecord A PI 用于添加数据到 Amazon K inesis 数据流" 指定数据流的名称和分区键 (ParOOon K ey) " 分区键用于分配数据记录到不同的数据流分片将数据输入 Amazon K inesis 数据流实时数据流处理In-game activity实时 数据流Amazon KinesisKinesis 应用程序WorkersKinesis 应用程序简化实时数据流的并行处理 §▪ 分布式处理多 Shards §▪ 容错§▪ 实时动态扩展 Workers专注数据处理逻辑Shard 1Shard 2Shard 3Shard nShard 4KCL Worker 1KCL Worker 2EC2 InstanceKCL Worker 3KCL Worker 4EC2 InstanceKCL Worker nEC2 Instance Kinesis 处理来自 Amazon K inesis 数据流的数据• Amazon K inesis 应用程序 (Workers)• 读取和处理来自数据流Stream数据的使用者 • 使用Amazon K inesis 客户端库 (KCL) 构建应用程序执行分布式流处理的繁重任务 • 自动扩展组 (Auto Scaling) 实时Amazon K inesis v.s S torm实时动态数据流处理典型的架构和工作流程使用 Apache 开源工具1）数据采集负责从各节点上实时采集数据例如选用flume (cloudera) 来实现2）数据接入由于采集数据的速度和数据处理的速度不一定同步，因此添加一个消息中间件来作为缓冲例如选用apache的kafka (LinkedIn)3）流式计算对采集到的数据进行实时分析例如选用apache的storm (twitter)使用 AWS 服务 Kinesis不用担心配置，部署软件和硬件维护 不用担心服务中断接入 Amazon S3, R edshi>, & D ynamoDB实时数据流处理& 海量数据存储In-game activity实时 数据流Amazon KinesisKinesis 应用程序S3Workers实时 趋势分析表 仪表盘聚合数据 预处理数据游戏玩家的数量 虚拟货币的使用量 热门道具 …Glacier长期归档In-gameactivityAmazonKinesisKinesis 应用程序S3归档聚合数据预处理数据实时趋势分析表仪表盘Workers低成本归档存储服务低至1美分/GB/月可以设定归档策略实时数据流GlacierHadoop数据挖掘In-game activityAmazon KinesisKinesis 应用程序S3聚合数据 预处理数据Glacier归档Hadoop数据 挖掘实时 趋势分析表 仪表盘Workers实时 数据流预测 分类 回归分析 关联规则 …Redshi5商务智能 BIAmazon KinesisKinesis 应用程序S3聚合数据 预处理数据Glacier归档Hadoop数据 挖掘实时 趋势分析表 仪表盘Workers实时 数据流Redshift商务 智能 BIClickstream A nalyDcs w ith A mazon K inesisClickstream P rocessing A ppAggregate C lickstream S taDsDcsClickstream A rchiveClickstream T rend A nalysisSimple M etering & B illing w ith A mazon K inesisBilling A uditorsIncremental B ill C omputaDonMetering R ecord A rchiveBilling M anagement S ervice总结§▪ 实时收集并处理数据§▪ 易于使用§▪ 通过 Java, Python KCL 轻松构建应用程序§▪ 并与Amazon S3、Amazon R edshi>、Amazon D ynamoDB 其他服务和工具集成§▪ 并行处理§▪ 聚合数据发送到Amazon S3 等存储对象中§▪ 实时分析日志并在发生例外情况时触发警报§▪ 实时分析网站点击流§▪ 灵活应变§▪ 动态调节 Amazon K inesis 数据流的吞吐量§▪ 可靠§▪ 三个设施间同步复制数据，并将数据保留 24 小时，以防数据在应用程序故障时丢失谢谢！马上开启您的云旅程中文网站：新浪微博：@亚⻢马逊AWS中文博客：/awschina 微信 AWS 中国。
云计算技术在智慧农业中的应用与实践
云计算技术在智慧农业中的应用与实践近年来，随着科技快速发展，云计算技术也开始在各个领域得到广泛应用，其中智慧农业更是成为了热门的应用领域之一。
国内众多的云计算公司纷纷布局智慧农业，并推出了各种创新产品和技术，助力农业现代化转型。
本文就将介绍云计算技术在智慧农业中的应用与实践，探讨未来智慧农业的前景和挑战。
一、云计算技术在智慧农业中的应用1. 数据采集、传输与存储农业生产中需要大量的数据支持，这些数据需要通过传感器等设备收集并存储。
在传统的农业生产模式下，数据采集和传输需要耗费大量时间和人力物力，而且难以实现实时监控和快速反应。
而利用云计算技术，可以搭建高效的数据采集、传输和存储系统，实现实时监测、自动化控制和数据共享。
这不仅便于农民进行管理和决策，也有助于在一定程度上提高农业生产效率。
2. 智能控制与自动化云计算技术结合物联网、传感器等技术，可以实现智能化控制和自动化。
例如智能灌溉系统可以根据土壤湿度、气象信息等数据，实现精准灌溉，降低用水量，提高作物产量。
智能化的喷雾设备可以根据作物类型、生长阶段和气象信息等因素，进行自动化控制，提高农业生产的精度和效率。
3. 作物种植与管理云计算技术还可以帮助优化作物种植和管理过程。
借助数据分析和人工智能技术，可以实现作物生长的动态监测，提高作物品质和产量。
同时，云平台还可以管理种植过程中的农药、肥料等投入品的使用，防止过度使用和浪费。
这一系列措施不仅有助于减少对环境的污染和生态破坏，也能提高生产效益和农民收益。
二、智慧农业云计算的实践案例1. 阿里云智慧农业阿里云智慧农业是阿里云在智慧农业领域的云计算解决方案。
通过阿里云的物联网平台，可以实现传感器数据的实时采集和分析，并对作物生长、病虫害监测、土壤水分等进行精准控制。
同时，阿里云还可以提供富有创新性的智能农机、无人机等各类设备和服务，帮助农民提高生产效率和质量。
2. 华为云智慧农业华为云智慧农业是华为云基于云计算、物联网和大数据技术打造的一套智能农业管理系统。
高性能队列Fqueue的设计和使用实践
负责向队列中添加元素，支持并发访问。
消费者（Consumer）
负责从队列中取出元素，支持并发访问。
关键技术选型
无锁化设计
采用无锁化设计避免锁竞争， 提高并发性能。
原子操作
通过原子操作实现线程安全， 避免多线程下的数据竞争问题 。
内存管理
采用内存池技术减少内存分配 和释放的开销，提高性能。
统中。
丰富的功能选项
02
支持多种队列操作和功能选项，满足不同场景下的需求。
良好的文档和社区支持
03
提供详细的文档和活跃的社区支持，帮助开发者解决使用过程
中的问题。
04 fqueue使用实践
使用场景分析
异步处理任务
fqueue适用于需要异步处理大量任务的场景，如日志处理、消息队列等。通过将任务放入队列，可以实现 任务的异步处理，提高系统的吞吐量和响应速度。
2
fqueue的核心思想是采用无锁化设计，通过精细 化的内存管理和多线程并发控制，实现高性能的 消息处理。
3
fqueue支持多种部署方式，可以独立部署，也可 以与其他系统集成，提供灵活的使用方式。
设计目标和原则
设计目标
fqueue的设计目标是提供一个高性能、低延迟、高吞吐的消息队列解决方案， 满足高并发场景下的需求。
优化策略
针对fqueue的性能瓶颈，可以采取多种优化策略。例如，优化队列的数据结构、减少锁 竞争、使用无锁队列等，可以提高fqueue的性能和并发能力。
性能测试工具
为了对fqueue进行性能测试，可以使用一些性能测试工具，如JMH（Java Microbenchmark Harness）等。这些工具可以帮助我们准确地测量fqueue的性能指标，为 优化提供数据支持。
2015 DAMS-诸超-唯品会大数据实践
Redis
• Storm计算用redis保存中间和结果数据
– 流量一直增加 – 大促流量狂涨 – 计算复杂度一直增加 – 不停拆分。。。 – 每次改代码
• 怎么办？
– 逐个模块拆分 – 一开始就按模块写不同instance – 一开始就Shard – Twemproxy – 优化数据结构 – Pipeline/Batch – 不求100%准确hll log – Redis Cluster
– 实时计算商品品牌信息，用户profile – 实时推荐 – 实时算法迭代更新 – 实时Abtest verify
• 个性化，个性化，个性化
– 移动天然是个个性化的好场所 – 更多的个性化因子 – 更加全面的数据：用户画像建设，曝光数据的收集…
17:45:01
DAMS—中国数据资产管理峰会
29
我们走过的路
• 2013Q4-2014Q1:基于人群分组和人工排序的个性化运营尝试
– 人群划分 – 首页人工排序 – 列表页人工规则自动排序 – 无效果。。。
• 2014Q2:开始有机会在小流量新版首页尝试技术主导
– 机器学习+业务规则 – 首页动态生成个性化推荐模块 – 首页动态生成个性化排序页面 – 提高了首页到列表页转化率，降低了跳出率，提高了销售
• 可以看到pool之间的互相调用关系；
• 全无入侵，应用上线即插即用；
DAMS—中国数据资产管理峰会
Data Service Quality
DAMS—中国数据资产管理峰会
大数据在唯品会特卖模式的业务价值
DAMS—中国数据资产管理峰会
FDS 探索号 CDN Nginx域
WTW
HeatMap
实时数据平台技术实践
关键环节详解—实时数据采集
• 实时数据来源 在线系统记录日志 统一的实时日志采集方案 支持数据上报 提供SDK支持用户上报实时数据 基于数据库日志 无需开发 数据最全
• 优势 几乎覆盖全部业务数据 通过产品化实现用户自助接入 快速新增实时数据
关键环节详解—实时数据采集
• 数据库日志采集方案
关键环节详解—实时计算平台
• 统一的实时计算平台 • 基于Storm打造的流式计算平台 • 提供SDK实现与JDQ的对接，从而通过JDQ获取实时数据 • 提供可视化的配置管理系统 • 支持Job的自助上传、测试、发布、管控服务 • 支持Job的版本控制 • 集成监控，实现状态、延迟等异常报警 • 实时查看Job运行日志 • 实现了公司资源利用最大化，包括人力、技术、硬件等
Tracker
数据压缩
DB
数据确认
异构适配
实时采集
JDQ
内部使用 保证顺序
库粒度 数据缓存 原始日志
Parser
数据压缩 数据过滤
分库分表 数据合并
数据拆分 格式转换 协议解析
JDQ
对外消费 保证顺序 表粒度 数据缓存 结构数据
关键环节详解—高可用的任务调度框架
• 实时任务调度框架 – Magpie 保证任务的高可用 节点不可用时任务自动切换到可用节点 调度框架通过Zookeeper实现各调度节点的无状态 根据CPU，内存，网络资源平衡集群各节点压力 通过分组实现集群内资源隔离 集群规模水平扩展 整合监控
• 营销场景
– 根据用户位置、实时浏览轨迹、商品价格变化等实现精准推荐、广告
– Top排行榜：销量排行、热度排行等
• 优化离线数据仓库数据抽取环节
– 传统“T+1”模式的数据仓库每天凌晨第一件事就是增量或全量抽取业务数据
实时数仓和离线数仓的概念
实时数仓和离线数仓的概念1、数据仓库的发展趋势1.1数据仓库的趋势关于数据仓库的概念就不多介绍了。
数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化⼯具的升级和新⼯具的应⽤，数据量变的越来越⼤，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展。
数据仓库的趋势：实时数据仓库以满⾜实时化&⾃动化决策需求⼤数据&数据湖以⽀持⼤量&复杂数据类型1.2 数据仓库的发展数据仓库有两个环节：数据仓库的构建与数据仓库的应⽤。
早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应⽤以报表为主，⽬的是⽀持管理层和业务⼈员决策（中长期策略型决策）。
随着业务和环境的发展，这两⽅⾯都在发⽣着剧烈变化。
随着IT技术⾛向互联⽹、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了⾮结构化数据，⽐如⽹站 log，IoT 设备数据，APP 埋点数据等，这些数据量⽐以往结构化的数据⼤了⼏个量级，对 ETL 过程、存储都提出了更⾼的要求。
互联⽹的在线特性也将业务需求推向了实时化，随时根据当前客户⾏为⽽调整策略变得越来越常见，⽐如⼤促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联⽹化之后导致同时服务的客户剧增，有些情况⼈⼯难以完全处理，这就需要机器⾃动决策，⽐如欺诈检测和⽤户审核。
总结来看，对数据仓库的需求可以抽象成两⽅⾯：实时产⽣结果、处理和保存⼤量异构数据。
2、数据仓库架构的演变从1990年 Inmon 提出数据仓库概念到今天，数仓架构经历了最初的传统数仓架构——离线数仓库——离线⼤数据架构、Lambda 架构、Kappa 架构以及 Flink 的⽕热带出的流批⼀体架构，数据架构技术不断演进，本质是在往流批⼀体的⽅向发展，让⽤户能以最⾃然、最⼩的成本完成实时计算。
百度爱番番基于图技术流式计算的实时CDP建设实践
百度爱番番基于图技术流式计算的实时CDP建设实践导读：随着营销3.0时代的到来，企业愈发需要依托强大CDP能力解决其严重的数据孤岛问题，帮助企业加温线索、促活客户。
但什么是CDP、好的CDP应该具备哪些关键特征？本文在回答此问题的同时，详细讲述了爱番番租户级实时CDP 建设实践，既有先进架构目标下的组件选择，也有平台架构、核心模块关键实现的介绍。
一、CDP是什么1.1 CDP由来CRM、DMP、CDP三个平台核心作用不同，但纵向来对比，更容易理解CDP。
三者之间在数据属性、数据存储、数据用途等方面都较大差异。
有几个关键区别如下：1.CRM vs CDP–客户管理：CRM侧重于销售跟单；CDP更加侧重于营销。
2.DMP vs CDP–数据类型：DMP是匿名数据为主；CDP以实名数据为主。
–数据存储：DMP数据只是短期存储；CDP数据长期存储。
1.2 CDP定义2023年MarTech分析师 David Raab首次提出CDP这个概念，后来其发起的CDP Institute给出权威定义：packaged software that creates a persistent, unified customer database that is accessible to other systems。
这里面主要包含三个层面：•Packaged software：基于企业自身资源部署，使用统一软件包部署、升级平台，不做定制开发。
•Persistent, unified customer database：抽取企业多类业务系统数据，基于数据一些标识形成客户的统一视图，长期存储，并且可以基于客户行为进行个性化营销。
•Accessible to other systems：企业可以使用CDP数据分析、管理客户，并且可以通过多种形式取走重组、加工的客户数据。
1.3 CDP分类CDP本身的C（Customer）是指all customer-related functions, not just marketing。
集团公司数据治理实践研究分析
集团公司数据治理实践坚持大数据与经济社会深度融合，带动全要素生产率提升和数据资源共享，促进产业转型升级，提高政府治理效能，加快数字社会建设。
一、集团公司数据治理实践1、集团公司数据治理背景集团的整体系统体系主要围绕核心ERP系统，股份总部的IT人员很多是ERP的开发、运维人员，基于股份集团的业务管理，ERP大量自研模块。
ERP作为核心系统，各大系统从ERP接入所需数据，同时将关键数据回流到ERP。
另外ERP作为核心应用系统，大量的报表数据通过ERP计算、展现。
随着业务的扩展，股份集团对外服务平台越来越多，数据的类型越来越复杂，需求越来越多样，数据资产管理的问题逐渐突出，主要表现在：一是ERP作为整个架构中的核心系统底层，在大数据的汇集、存储、计算的效率上，无法及时、准确满足数据使用需求，导致整个系统性能较慢；二是缺少大数据平台工具，无法很好地对数据及数据处理过程进行管理，数据缺乏管理；三是数据应用覆盖率不高，以单点数据应用为主，目前的模式数据应用满足效率较差。
在数字化转型是大时代背景下，为了实现集团科技赋能战略，促进核心业务的数据分析和运用，推动股份集团数据资产建设，项目从整体规划、架构设计、平台工具建设三大层面，构建股份集团的数据资产体系。
2、集团公司数据治理解决方案为了全局性、统筹性地进行数据资产规划，梳理数据资产管理模式，开展数据治理，项目整体分为以下三大阶段。
第一阶段：咨询规划，选模式，定方向。
这个阶段，主要是通过咨询规划，初步确定数据治理模式，确定落地方向。
集团由信息化模式转向大数据模式，从治理模式、管理模式、未来的场景的方向看，对企业都存在不确定性，因此集团选择优先咨询规划，明确治理模式，然后再逐步展开。
1）调研诊断，全面盘点现有数据、业务现状，定位目前问题。
一是现有源系统及现状盘点，包括内部系统、对外服务平台、外部数据盘点；二是数据架构的现状－数据流转过程盘点，以ERP为核心系统与对外服务平台、内部业务系统和外部数据进行数据交互的过程分析；三是数据应用的现状盘点，面向集团管理层、行业板块中层管理等不同层级的数据应用现状盘点，整体以散点式基础统计为主，覆盖率不高；四是数据权限管理，目前尚未建立权限管理，需求盘点；五是数据质量及管理情况盘点。
Flink 在 OPPO 的平台研发与应用实践
流
Stream
表
flatmap()
二
象
Stream
性
Table ad_clicks_user
日志检索 自我介绍
日志采集pipeline
自我介绍
SQL
JAR
OStream
log4j. properties
containerized.master.env. ostream.app.id
containerized.master.env.
计计算引算擎
Storm Flink Spark streaming Kafka streams
存存储储引擎
Redis HBase Elasticsearch MySql
平台化的推进 自我介绍
业务赋能（点）
o 屏蔽底层，提高易用性 o 抽象接口，适用于更多用户 o 签订SLA，服务有保障
规模效应（面）
从自动化到智能化 自我介绍
自动化
机械、重复
智能化
自适应、自学习
智慧化
自我意识、思维
自动化
智能化
o 端到端自动打通 o SQL自动生成 o 告警规则自动生成
o 作业资源自动伸缩 o 作业异常自我修复 o 作业参数动态调优
端到端环节割裂 自我介绍
Kafka Table
SQL + UDF
数据处理
Kafka Table
小时/天级 à 分钟/秒级
业务侧
平台侧
o 实时报表：人群投放的到达率/曝光率/点击率 o 实时标签：用户当前所在的商圈 o 实时接口：用户最近下载某APP的时间
o 调度任务：凌晨0点大批量启动 o 标签导入：全量导入耗费数小时 o 质量监控：无法及时发现数据异常
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
LIRS SQL cardinality Partition result
Day 1： Query 1
06/01
06/02
06/03
06/04
06/05
06/07
06/08
Day 2： Query 2
06/02
06/03
06/04
06/05
06/07
06/08
06/09
劢态规划算法 Monitor 服务器分布式锁（主/备） 参数：
一些数字：
已接入： 搜索成交信息 > 5 亿 / 天 活跃用户信息 > 1 亿 即将接入： 用户类目偏好信息 > 10 亿 用户品牌偏好信息 > 20 亿 >>>>>>>>>>>>>>>
性能：
QPS > 300
AVG Query Scan Row > 300 万 AVG Query Compute Column > 50
SkipList
5
5 5
200,000 1000
200,000 100
47439
552799
3272251 3421260
B+ tree
3922 6112 4261 58458
200,000 1000
特别说明：此为单台 16core E5620 @2.40GHZ,24GB内存的测试结果。
Master： SQL解析 路由分发 结果缓存合并 Localnode SQL解析 索引查找 计算 带宽？
Partition
• • • Interval Range Hash
Garuda
DBx
TableGroupx
TableGroup
• • Join PartitionGroup
Table
Partition
计算列/索引列(倒置) 索引
• • • • • •
计算列 @ memory 索引列 @ disk Hash B+Tree Skiplist Bitmap
5 5
5 5 5
200,000
100
10 5
177 112994350 772 259067358 17497813 18453589 477863
200,000 1000 200,000 100
Hashmap
653 1143 533 10838 28959 41853 36179 5
200,000 1000 200,000 100
Garuda
JDBC CN-1 (缓存节点) LCN-1 (本地计算节点) PANGU/HDFS
CN-… (缓存节点) LCN-… (本地计算节点)
MCN
管理中心
REST 云梯1/云梯2（数据源）
数据源&存储
盘古集群(集中存储)
Fixed/Free Schema（列存储） Partition/TableGroup 全索引 本地计算 大表Join 缓存 资源管理调度 可用性
TableGroup： 分区Join 附属表（支持M:N）： 存储：主表内存位置+ 自身内存位置 加载：主表增加虚拟列 附加索引（支持M:N）： 存储：主表内存位置 只能用来定位和count
-------------------------------------WHERE keyword contains (‘iphone’,‘智能') ------------------------WHERE cpv in (‘x1',‘x2')
全部导入/局部导入 列存储
TableSchema对象 ColumnSchema 数组 Table对象 TableSchema对象 版本信息
查询/计算 性能无损
ColumnSchema对象 列名
….
总记录计数器
Int二维数组 Short二维数组
定位数据列
列类型 类型下标 默认值
同一条记录在所 有数组顺序一致
– – – – – – – 可用内存、可用磁盘（Buffer阈值） 每个表占用的内存、磁盘 最小可用实例数 最小Failover机器数 每个分区最小可用份数（在线上集群） 每个表最多保留分区数（Rotate） 超时设置(上线/下线/导入 超时)
– 表组信息 – 虚拟机组 – ….
Failover Rotate 资源虚拟化(T4)
Index array(abstract)
tree<T,int[]> skiplist<T,int[]> SSD SSD
倒排
压缩
• •பைடு நூலகம்
hashmap<T,int[]> SSD unique<T,int> memory
String？ PForDelta(7%)
数据结构 Array
数据集大 每次参与运算 每请求耗时 总耗时 每秒处理记 线程数 (ms) (ms) 小(亿条) 数据量(条) 录数
主表
存储主表 内存位
附加索引1
附加索引3
附加索引2
本地节点缓存：
LIRS Evicted Factor：
Object Type/Object Size Object Domain
资 源 层
Memory
数据 主键索引
SSD
高频小 索引
DISK
低频大 索引
高频索引缓存区
Master节点缓存：
明细数据
Redis集群
分片统计结果
Prom Service
1.倒排索引 2.本地计算(Hbase) 3.自动扩容(Hbase)
1.冗余度 2.网络带宽 3.定制性
请求
WEB
REST
ISV
中间层
ITier
MYSQL
ITier
MN-1 (合并节点)
MN-.. (合并节点) JDBC
ZK
CCN
配置中心 ZK
FailOver
导入
Heartbeat 双机房 任务分布式锁 任务持久化 任务跟踪JobID 执行时间监控
下线 OLD
集群
持久化 盘古
上线
Materiality formless
交易信息+搜索信息 > 5亿条 * 7 天 （即将接入30天） 附加索引 3个 表4张 QPS > 300 平均响应时间<2s
淘宝实时计算平台实践
离哲@淘宝网 @flyinweb
1.简介 2.现状 3.历叱变迁 4.架构总览 5.关键特性
6.应用案例
7.未来展望
时间
海量 数据
轻 结构
?
无 规则
实时计算定义：
针对历叱数据进行即时数据的获取和计算
相关： RTOLAP(Realtime OLAP) Grid Computing In-memory database
• 海量数据 •无法预算 • 高并发 •高可用
• SQL •Schema Free
•低延时 •计算精确
分布式/全索引/内存/数据库
Redis集群
冗余ID 列表
分片统计结果
Tokyo Cabinet集群
明细数据
Prom Service
1.冗余度 2.明细数据慢 3.规则变复杂
Hbase集群
冗余ID 列表
SNS：
用户信息>100,000,000 表1张 QPS > 600 平均响应时间 < 90ms
实时数据源（MVCC） 迭代计算 资源隔离(DB/USER/表) 索引离线计算（hadoop） 存储结构优化 SSD优化
谢谢! Q&A
结果（master）
Lcn1
Lcn2
Lcn3
Lcn4
Lcn5
特殊： 跨TableGroup 大表+小表（batch） 虚拟列 group by partition_key AVG sum/count Limit 全局limit * 阈值 Order by rand() limit n rand(cardinality*limit+2) Distinct 全局 Bitset+Bloom Filter