关于大数据:从MySQL到ByteHouse抖音精准推荐存储架构重构解读

<article class=“article fmt article-content”><blockquote>更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群</blockquote><p>抖音依附本身举荐零碎为用户推送可能感兴趣的视频内容,其中趣味圈层是举荐的重要能力,通过了解外围用户的偏好特色,判断两者偏好的相似性,从而构建同类用户的趣味圈层,实现精准举荐。</p><p>以往的趣味圈层往往依赖繁多的维度或标签,比方内容类型、时长、天文特色等,难以揭示用户趣味的底层逻辑。例如,重庆美女小姐姐吃播视频、二次元古风舞蹈视频,外表上标签类型可能齐全不一样,但深度剖析后发现喜爱两个视频的是同一个类型的人,并把他们划分在同一个趣味圈层中。</p><p>要搭建这样一套趣味圈层平台,不仅须要算法策略,对底层数据存储架构也是一大挑战。抖音每日新增的数据量宏大、业务标签形形色色,更须要满足业务人员对简单查问的实时性诉求。之前技术团队采纳MySQL作为存储架构,作为一种行式存储的数据库,MySQL对于大量数据的解决效率较低。如果要在MySQL上查问上亿级别的数据,可能须要更高配置的硬件,甚至可能须要采纳分片、读写拆散等策略来晋升性能,这将导致硬件老本显著进步。</p><p>因而,技术团队逐步将趣味平台基于ByteHouse进行重构。ByteHouse是一款OLAP引擎,具备查问效率高的特点,在硬件需要上绝对较低,且具备良好的程度扩展性,如果数据量进一步增长,能够通过减少服务器数量来晋升解决能力。本文将从趣味圈层建设难点及构建计划等角度拆解如何基于OLAP引擎来搭建趣味圈层平台。</p><h2>趣味圈层平台介绍</h2><p>趣味圈层指兴趣爱好雷同的人组成的群体,趣味圈层能够从用户视角更深刻的了解短视频作者和内容,挖掘出该圈层作者外围用户群体的独特趣味点和典型偏好特色,作为划分作者的重要标签,利用在内容散发、垂类经营、数据分析、战略规划等场景中输入价值。趣味圈层以簇(cluster)的模式存在,通过机器模型聚类而成,每个簇蕴含一位种子作者及多位与之关联作者。</p><p></p><p>圈层生产流程:数仓的天级 Hive 表以定时工作的形式将 Hive 表内数据依照分区导入 RDS(MySQL) 数据库,同时预计算脚本每天会定时将 RDS 内的数据按需写入缓存(如圈层信息等通用查问)或写回RDS(如圈层的父节点信息等外围数据),生产流程胜利会标记在缓存代表今日数据无效,反之报警告诉相干负责人。</p><p>圈层查问流程:用户操作查问,前端发送查问场景数据申请,服务端接管到申请后读取相应的缓存、数据库表及分区,对数据进行组装,最终返回给用户。</p><h2>次要问题</h2><h4>数据收缩</h4><p>日更版本导致数据量级收缩,圈层根底信息表日增万级数据,圈层作者信息表日增百万数据,圈层用户信息表日增千万条左右数据,曾经达到 MySQL 秒级千万级查问的性能瓶颈。</p><p>查问效率已无奈满足需要,即便有缓存减速缩小联表查问,单表查问的效率在到10s以上,其中圈层了解(圈层用户信息表)进入页面的工夫超过15s,肯定水平影响业务应用体验。之前做了很多包含索引优化、查问优化、缓存优化、表构造优化,然而单次对表更新列/新增批改索引的工夫曾经超过2天,优化老本也逐步升高。</p><h4>历史架构过薄,难以承接较简单圈选能力</h4><p>从现状来看,以后圈层架构简略且为辨别查问场景,与数据库间接交互且仅反对简略的同步查问,当业务须要较简单的泛化圈选条件时,须要用户在平台期待超过15s。</p><p>从将来布局,目前以 RDS 为存储的同步查问架构已无奈反对须要关联多个表和特色的简单条件查问的业务场景。</p><h4>业务特色收缩</h4><p>标签特色收缩,以后圈层有越来越多的标签形容,因为不同业务方会通过不同视角了解圈层,如垂类标签/圈层关键词形容/圈层品质分类/圈层画风等,目前圈层信息实体特色达到几十种,预计圈层属性标签仍会收缩。</p><p>一站式圈选泛化指标作者诉求增多,以后作者只蕴含根底信息,业务方心愿基于圈层和其余根底作者特色,如粉丝数,作者品质,活跃度等以满足对作者的流量定向策略等需要,以满足简单条件多维度的筛选排序功能。</p><h2>基于 ByteHouse 重构趣味圈层平台</h2><p>RDS 作为行式数据库更适宜单点事务剖析工作显然不合乎以后平台诉求,咱们别离从查问场景、查问性能、存储老本、迁徙老本对存储选型。</p><h3>查问场景</h3><ol><li>圈层信息由模型生产,按工夫分区批量导入,不存在长期导入,为 append only 场景。</li><li>圈层特色多,业务方依照诉求对和本身业务相干的特色进行筛选,列式存储比行式存储更适合。</li><li>圈层次要以剖析统计为主,不强需要事务处理,面向 OLAP 业务。</li></ol><h3>查问性能</h3><ol><li>MySQL 对于多列简单的条件查问时,查问性能很难优化,须要通过强依赖 redis 缓存减速,否则平台性能不可用。</li><li>圈层场景通常限度在部分数据中聚合剖析,如计算圈层id位于汇合内的关键词频率统计,若该汇合范畴过大索引生效会被劣化为全表扫描。</li></ol><h3>具体场景测试</h3><p><strong>重构前后存储比照</strong></p><table><thead><tr><th>MySQL</th><th>ByteHouse</th></tr></thead><tbody><tr><td>关系型数据库,反对事务</td><td>分布式列数据库,反对最终事务</td></tr><tr><td>行存储模式,适宜尽量少的读取须要的行数据</td><td>列存储模式,且数据压缩比高,对大批量数据读取有着人造劣势</td></tr><tr><td>单过程多线程服务,单条业务申请查问无奈无效利用到多个 CPU 资源</td><td>多核并行</td></tr><tr><td>面向 OLTP 业务</td><td>面向 OLAP 业务</td></tr></tbody></table><p><strong>具体场景比照</strong></p><p>数据管理信息查问场景:</p><p></p><p>利用工具剖析场景:</p><p></p><h2>总结</h2><p>综上能够看到,基于 ByteHouse 替换 MySQL 重构抖音趣味圈层平台后,不同几个典型场景的查问效率均匀晋升了 100 倍左右,大大晋升了用户体验。因为 ByteHouse 杰出的查问性能和良好的数据压缩比,中等资源的服务器就能很好的满足需要,这也升高了综合硬件老本。此外,ByteHouse 具备良好的程度扩大能力,如果数据量进一步增长,也能够便捷的通过减少服务器数量来晋升剖析能力。</p><p>点击跳转火山引擎ByteHouse理解更多</p></article>

March 5, 2024 · 1 min · jiezi

关于大数据:破局数据分析滞后难题赋能企业高速增长的指标管理解决方案

指标是什么? 业务倒退过程中,企业内外部都会产生很多的业务数据,对这些数据进行采集、计算、落库、剖析后,造成的统计后果称为指标。简略来说,指标是业务被拆解、量化后造成的数量特色,企业利用数据指标对业务进行精准的号脉,实现对业务的科学管理和无效优化。 在咱们对多家企业开展深刻调研的过程中,发现数据指标作为数据化治理的外围因素,对于泛滥从事数据工作的同学而言,他们在实际操作中面临着各种各样的挑战和问题。 业务诉求,指标的真正使用者。在理论状况中,少数业务人员在面对盘根错节的各类指标时,往往感到莫衷一是,不仅难以无效利用这些指标,还认为现有的指标体系未能充沛展示其价值。并且,他们急需的关键性指标往往无处可寻,也找不到提需要的入口。 治理诉求,数据管理部门。不足欠缺的指标全生命周期管理体系,使得指标的权限管制与品质治理均难以失去无效保障,同时,指标的重复性问题始终得不到解决。 开发诉求,指标开发人员。指标模型设计无奈造成束缚,导致模型构建凌乱,并且在生成新的指标后,因为不足标准化的试算验证环节,无奈无效确保各项指标计算结果的精确性。同时,指标开发后无奈与品质校验工作进行联动,导致数据品质无奈失去保障。 指标属主诉求,指标发起者,指标需要的归口部门。在理论工作中,面临大量指标需要,难以精准地评估各个指标的优先级;局部指标定义不足规范的依靠,导致指标定义有歧义。并且不足指标生成定义血统追溯的能力,导致品质问题排查艰难,无奈疾速查到具体的起因。 指标治理解决方案围绕指标治理的痛点问题,依靠于袋鼠云指标治理DataIndex 平台,联合企业流程制度,提供产品化的解决方案,实现指标体系建设,让指标建设、指标复用更加的标准和高效。 指标解决方案的次要流程包含: 第一步,从指标需要的角度登程。剖析辨认是否存在相似的已有指标,根据相干指标的相似性信息,精准界定新指标的定义与口径,并在此基础上明确指标建设的层次结构。关键在于后期设计阶段,要对指标建设进行全面、有序的布局布局。 第二步,具体实施指标建设。依据先前明确的指标定义发展指标的开发工作,涵盖但不限于指标模型的设计构建、指标开发的具体任务执行以及任务调度的合理化治理等多个方面。 第三步,将开发好的指标进行上线。进行严格的公布审批流程,并对指标利用进行权限调配与应用受权治理,同时涵盖与指标治理和平安保障相干的实际内容,以确保上线指标的平安无效运行。 第四步,指标的理论利用。通过不同的数据利用模式,对数据指标进行应用,包含数据看板、自助取数、归因剖析等。 第五步,对于指标应用状况的评估。实现从指标的生成到下线的残缺闭环。 指标建设施行步骤实践弄明确了,具体的还是要落地到实际中来。 搭平台在传统的指标治理场景中,少数指标数据都是扩散在各个平台当中,有些散布在报表平台,有些散布在业务零碎或是内部业务利用。广泛状况下,这些指标的元数据管理依赖于 Excel 等离散文件形式,这就造成了指标的元数据管理信息不通,导致指标反复开发,二义性等问题。 因而,改良的第一步就是要摒弃这种 Excel 的管理模式,转而采纳对立的指标治理平台,实现指标及其元数据的整合存储与标准化治理。 剖析平台能力在充沛了解客户以后所面临的指标治理问题的根底上,构建出适应客户业务需要的指标治理全流程计划,从而切实有效地解决客户在指标治理方面遇到的各种简单挑战。 · 指标需要治理:次要解决需要治理层面的问题,确保每一个需要都能失去及时响应,并确保需要可能被正当合成细化。 · 指标定义:在理论业务场景中,大量要害信息通常存储于 Excel 表格中,为实现指标的对立治理,能够通过指标注销性能将这些现存的指标逐个导入并进行注册治理。针对新增的指标,间接利用指标定义性能对其元数据进行标准化定义,从而确保所有指标都能在一个集中的平台上失去无效治理与保护。 · 指标开发:袋鼠云指标治理平台反对两种灵活多样的开发模式,无论是通过编写 SQL 脚本还是利用可视化界面,都可能顺利完成指标开发工作。 · 指标治理:在实现指标开发之后,借助平台内置的指标公布性能,开发者能够依据需要抉择合适的共享级别,通过不同级别的审批流程来正式公布指标。此外,袋鼠云指标治理平台还装备了指标评估与评估机制,使得指标使用者可能在指标公布后对其进行反馈和评估,从而实现了从开发、公布到应用反馈的全流程治理。 · 指标市场:当指标胜利公布至指标市场后,应用指标的人员能够充分利用平台提供的弱小搜寻性能,该性能内置有多种检索逻辑,使用户能更为便捷高效地定位并获取本人须要的指标。 · 指标利用:袋鼠云指标平台反对多样化的数据利用模式,包含自助取数、API接口调用、数据可视化看板以及指标卡等多种性能,以满足用户在不同场景下的指标需要利用。 指标治理流程与平台的联合设计指标治理流程次要由四大类部门协同(指标属主部门、大数据中心、数据管理核心、业务部门),整合使用指标治理平台、离线开发平台、实时开发平台以及数据资产平台等多种平台能力,从而实现指标的整体建设,具体设计流程如下图所示: 实现指标治理计划的建设构建全面的指标治理计划次要包含如下图所示的四个关键步骤,这四个步骤环环相扣,从最后的业务需要辨认直至最终的指标下线,全方位笼罩了指标的整个生命周期,旨在实现精细化的全生命周期治理。 · 业务诉求:指标数据查阅 · 指标剖析:业务指标查看与剖析 · 指标布局:利用指标体系布局 · 指标注销:指标需要注销 · 模型定义:新建数据模型 · 指标经营:基于指标评估体系助力指标治理 · 指标审计:在指标利用过程中如何保障数据安全 总结不做指标对立治理,指标永远是错综凌乱,指标标准化,在很大水平上也在影响着数据分析的时效性。基于此,指标平台应运而生。 袋鼠云指标治理平台是对指标体系搭建与自助取数平台,通过指标的规范化定义、标准化开发,搭建企业数据指标体系,落地指标数据后果,同时提供指标的自助式疾速查问、报表制作,打消数据二义性,升高业务与技术的沟通老本,实现指标数据的可视、可用、可管。 《数栈产品白皮书》下载地址:https://www.dtstack.com/resources/1004?src=szsm ...

March 1, 2024 · 1 min · jiezi

关于大数据:开源大数据集群部署十三Ranger-集成Trino

作者:櫰木 1、装置ranger trino插件在trino的coordinator节点部署 解压ranger-2.3.0-trino-plugin.tar.gz [root@hd2.dtstack.com ]#tar -zxvf ranger-2.3.0-trino-plugin.tar.gz -C /opt配置ranger trino插件文件install.properties,内容如下 : # Licensed to the Apache Software Foundation (ASF) under one or more# contributor license agreements. See the NOTICE file distributed with# this work for additional information regarding copyright ownership.# The ASF licenses this file to You under the Apache License, Version 2.0# (the "License"); you may not use this file except in compliance with# the License. You may obtain a copy of the License at## http://www.apache.org/licenses/LICENSE-2.0## Unless required by applicable law or agreed to in writing, software# distributed under the License is distributed on an "AS IS" BASIS,# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.# See the License for the specific language governing permissions and# limitations under the License. ## Location of Policy Manager URL## Example:# POLICY_MGR_URL=http://policymanager.xasecure.net:6080#POLICY_MGR_URL=http://hd1.dtstack.com:6080/ ## This is the repository name created within policy manager## Example:# REPOSITORY_NAME=trinodev#REPOSITORY_NAME=trinodev # Configure INSTALL_ENV=docker if running trino in docker environment#INSTALL_ENV=docker## Name of the directory where the component's lib and conf directory exist.# This location should be relative to the parent of the directory containing# the plugin installation files.#COMPONENT_INSTALL_DIR_NAME=/opt/trino # Enable audit logs to SolrXAAUDIT.SUMMARY.ENABLE=false#Example#XAAUDIT.SOLR.ENABLE=true#XAAUDIT.SOLR.URL=http://localhost:6083/solr/ranger_audits#XAAUDIT.SOLR.ZOOKEEPER=#XAAUDIT.SOLR.FILE_SPOOL_DIR=/var/log/trino/audit/solr/spool XAAUDIT.SOLR.ENABLE=falseXAAUDIT.SOLR.URL=http://hd1.dtstack.com:8983/solr/ranger_auditsXAAUDIT.SOLR.USER=NONEXAAUDIT.SOLR.PASSWORD=NONEXAAUDIT.SOLR.ZOOKEEPER=hd1:2181,hd2:2181,hd3:2181/ranger_auditsXAAUDIT.SOLR.FILE_SPOOL_DIR=/var/log/trino/audit/solr/spool # Enable audit logs to ElasticSearch#Example#XAAUDIT.ELASTICSEARCH.ENABLE=true#XAAUDIT.ELASTICSEARCH.URL=localhost#XAAUDIT.ELASTICSEARCH.INDEX=audit XAAUDIT.ELASTICSEARCH.ENABLE=falseXAAUDIT.ELASTICSEARCH.URL=NONEXAAUDIT.ELASTICSEARCH.USER=NONEXAAUDIT.ELASTICSEARCH.PASSWORD=NONEXAAUDIT.ELASTICSEARCH.INDEX=NONEXAAUDIT.ELASTICSEARCH.PORT=NONEXAAUDIT.ELASTICSEARCH.PROTOCOL=NONE # Enable audit logs to HDFS#Example#XAAUDIT.HDFS.ENABLE=true#XAAUDIT.HDFS.HDFS_DIR=hdfs://node-1.example.com:8020/ranger/audit# If using Azure Blob Storage#XAAUDIT.HDFS.HDFS_DIR=wasb[s]://<containername>@<accountname>.blob.core.windows.net/<path>#XAAUDIT.HDFS.HDFS_DIR=wasb://ranger_audit_container@my-azure-account.blob.core.windows.net/ranger/audit#XAAUDIT.HDFS.FILE_SPOOL_DIR=/var/log/trino/audit/hdfs/spool XAAUDIT.HDFS.ENABLE=falseXAAUDIT.HDFS.HDFS_DIR=hdfs://__REPLACE__NAME_NODE_HOST:8020/ranger/auditXAAUDIT.HDFS.FILE_SPOOL_DIR=/var/log/trino/audit/hdfs/spool # Following additional propertis are needed When auditing to Azure Blob Storage via HDFS# Get these values from your /etc/hadoop/conf/core-site.xml#XAAUDIT.HDFS.HDFS_DIR=wasb[s]://<containername>@<accountname>.blob.core.windows.net/<path>XAAUDIT.HDFS.AZURE_ACCOUNTNAME=__REPLACE_AZURE_ACCOUNT_NAMEXAAUDIT.HDFS.AZURE_ACCOUNTKEY=__REPLACE_AZURE_ACCOUNT_KEYXAAUDIT.HDFS.AZURE_SHELL_KEY_PROVIDER=__REPLACE_AZURE_SHELL_KEY_PROVIDERXAAUDIT.HDFS.AZURE_ACCOUNTKEY_PROVIDER=__REPLACE_AZURE_ACCOUNT_KEY_PROVIDER #Log4j Audit ProviderXAAUDIT.LOG4J.ENABLE=falseXAAUDIT.LOG4J.IS_ASYNC=falseXAAUDIT.LOG4J.ASYNC.MAX.QUEUE.SIZE=10240XAAUDIT.LOG4J.ASYNC.MAX.FLUSH.INTERVAL.MS=30000XAAUDIT.LOG4J.DESTINATION.LOG4J=trueXAAUDIT.LOG4J.DESTINATION.LOG4J.LOGGER=xaaudit # Enable audit logs to Amazon CloudWatch Logs#Example#XAAUDIT.AMAZON_CLOUDWATCH.ENABLE=true#XAAUDIT.AMAZON_CLOUDWATCH.LOG_GROUP=ranger_audits#XAAUDIT.AMAZON_CLOUDWATCH.LOG_STREAM={instance_id}#XAAUDIT.AMAZON_CLOUDWATCH.FILE_SPOOL_DIR=/var/log/hive/audit/amazon_cloudwatch/spool XAAUDIT.AMAZON_CLOUDWATCH.ENABLE=falseXAAUDIT.AMAZON_CLOUDWATCH.LOG_GROUP=NONEXAAUDIT.AMAZON_CLOUDWATCH.LOG_STREAM_PREFIX=NONEXAAUDIT.AMAZON_CLOUDWATCH.FILE_SPOOL_DIR=NONEXAAUDIT.AMAZON_CLOUDWATCH.REGION=NONE # End of V3 properties ## Audit to HDFS Configuration## If XAAUDIT.HDFS.IS_ENABLED is set to true, please replace tokens# that start with __REPLACE__ with appropriate values# XAAUDIT.HDFS.IS_ENABLED=true# XAAUDIT.HDFS.DESTINATION_DIRECTORY=hdfs://__REPLACE__NAME_NODE_HOST:8020/ranger/audit/%app-type%/%time:yyyyMMdd%# XAAUDIT.HDFS.LOCAL_BUFFER_DIRECTORY=__REPLACE__LOG_DIR/trino/audit# XAAUDIT.HDFS.LOCAL_ARCHIVE_DIRECTORY=__REPLACE__LOG_DIR/trino/audit/archive## Example:# XAAUDIT.HDFS.IS_ENABLED=true# XAAUDIT.HDFS.DESTINATION_DIRECTORY=hdfs://namenode.example.com:8020/ranger/audit/%app-type%/%time:yyyyMMdd%# XAAUDIT.HDFS.LOCAL_BUFFER_DIRECTORY=/var/log/trino/audit# XAAUDIT.HDFS.LOCAL_ARCHIVE_DIRECTORY=/var/log/trino/audit/archive#XAAUDIT.HDFS.IS_ENABLED=falseXAAUDIT.HDFS.DESTINATION_DIRECTORY=hdfs://__REPLACE__NAME_NODE_HOST:8020/ranger/audit/%app-type%/%time:yyyyMMdd%XAAUDIT.HDFS.LOCAL_BUFFER_DIRECTORY=__REPLACE__LOG_DIR/trino/auditXAAUDIT.HDFS.LOCAL_ARCHIVE_DIRECTORY=__REPLACE__LOG_DIR/trino/audit/archive XAAUDIT.HDFS.DESTINTATION_FILE=%hostname%-audit.logXAAUDIT.HDFS.DESTINTATION_FLUSH_INTERVAL_SECONDS=900XAAUDIT.HDFS.DESTINTATION_ROLLOVER_INTERVAL_SECONDS=86400XAAUDIT.HDFS.DESTINTATION_OPEN_RETRY_INTERVAL_SECONDS=60XAAUDIT.HDFS.LOCAL_BUFFER_FILE=%time:yyyyMMdd-HHmm.ss%.logXAAUDIT.HDFS.LOCAL_BUFFER_FLUSH_INTERVAL_SECONDS=60XAAUDIT.HDFS.LOCAL_BUFFER_ROLLOVER_INTERVAL_SECONDS=600XAAUDIT.HDFS.LOCAL_ARCHIVE_MAX_FILE_COUNT=10 #Solr Audit ProviderXAAUDIT.SOLR.IS_ENABLED=falseXAAUDIT.SOLR.MAX_QUEUE_SIZE=1XAAUDIT.SOLR.MAX_FLUSH_INTERVAL_MS=1000XAAUDIT.SOLR.SOLR_URL=http://localhost:6083/solr/ranger_audits # End of V2 properties ## SSL Client Certificate Information## Example:# SSL_KEYSTORE_FILE_PATH=/etc/hadoop/conf/ranger-plugin-keystore.jks# SSL_KEYSTORE_PASSWORD=none# SSL_TRUSTSTORE_FILE_PATH=/etc/hadoop/conf/ranger-plugin-truststore.jks# SSL_TRUSTSTORE_PASSWORD=none## You do not need use SSL between agent and security admin tool, please leave these sample value as it is.#SSL_KEYSTORE_FILE_PATH=/etc/hadoop/conf/ranger-plugin-keystore.jksSSL_KEYSTORE_PASSWORD=myKeyFilePasswordSSL_TRUSTSTORE_FILE_PATH=/etc/hadoop/conf/ranger-plugin-truststore.jksSSL_TRUSTSTORE_PASSWORD=changeit ## Custom component user# CUSTOM_COMPONENT_USER=<custom-user># keep blank if component user is defaultCUSTOM_USER=trino ## Custom component group# CUSTOM_COMPONENT_GROUP=<custom-group># keep blank if component group is defaultCUSTOM_GROUP=hadoop2、初始化插件[root@hd1.dtstack.com ranger-2.3.0-trno-plugin]# ./enable-trnio-plugin.sh ...

February 29, 2024 · 2 min · jiezi

关于大数据:vivo-在离线混部探索与实践

作者:来自 vivo 互联网服务器团队本文依据甘青、黄荣杰老师在“2023 vivo开发者大会"现场演讲内容整顿而成。 随同 vivo 互联网业务的高速倒退,数据中心的规模不断扩大,老本问题日益突出。在离线混部技术能够在保障服务质量的同时,极大的晋升数据中心资源利用率,降低成本。混部技术波及任务调度、资源隔离、运维观测等一系列技术难题,本文将介绍 vivo 在混部技术方面的实际和摸索,为读者提供借鉴和参考 一、在离线混部技术背景1.1 为什么混部 数据中心运行的服务能够分为在线服务和离线工作两大类,它们具备不同的资源应用特色。 在线服务是指那些长时间运行、对时延十分敏感的服务,如电商、游戏等,在线服务的资源利用率存在显著的波峰波谷景象,均匀利用率较低。离线工作是指那些运行周期短,有容错性,对实时性要求低的服务,如数据转换、模型训练等,离线工作在执行过程中资源利用率很高。 在混部之前,在线和离线都是离开独立部署,机器不共享,无奈造成无效的资源互补,这导致数据中心整体资源利用率不高,却要一直购买新机器,造成了资源节约。 1.2 混部技术定义 通过混部技术,咱们能够将在线和离线部署到同一台物理机上,造成资源互补,晋升物理机的资源利用率,降低成本。混部技术最早由谷歌在2015年提出,通过多年的倒退,混部技术曾经趋于成熟,目前业内利用混部技术能够将数据中心的CPU利用率晋升至40%左右 。 vivo在2020年开始调研混部技术,2023年混部平台投入生产,目前咱们曾经将局部混部集群的CPU利用率晋升至25%(最新已达30%)左右。相较业界标杆这还有肯定的差距,但随着混部规模的扩充,咱们将挑战更高的指标。 二、在离线混部平台实际2.1 混部平台产品能力 混部平台必须具备两个产品能力: 第一、弱小的调度、隔离能力第二、欠缺的监控、运维能力弱小的调度能力解决了,咱们如何将离线工作高效、正当的调度到在线服务所在的物理机上。而弱小的隔离能力保障了在线服务的品质不受离线工作烦扰。欠缺的监控和运维能力则能够让咱们洞悉整个混部平台的运行状况,及时发现潜在危险,帮忙运维人员更高效的实现零碎和业务的运维工作,保障集群的高稳定性。 2.2 混部差异化资源视图 混部首先要解决的一个问题是离线应用哪一部分资源。 在vivo混部零碎中在线和离线看到的资源视图是不同的: 在线可用资源为 整机资源离线可用资源为 整机资源减去 在线理论应用的资源同时为了防止整机负载太高影响零碎的稳定性,咱们设置一个平安水位线,用于调节离线可用资源大小。 2.3 混部QoS等级 为了保障混部零碎的slo,咱们将服务分为三个等级:高、中,低。 不同等级的服务对物理资源如:CPU、内存 应用时有不同的优先级。高优先级服务反对绑定CPU模式,实用对延时十分敏感的在线服务。个别的在线服务可设置为中优先级。离线工作设置为低优先级,通过这样的等级划分,咱们很好的实现在线对离线的资源压抑和隔离,保障了在线服务质量。 2.4 混部外围组件架构 咱们所有的混部组件都是以插件形式独立运行,对原生K8s无侵入。咱们实现了一个混部调度器,在线和离线对立应用这个调度器,防止了多调度器资源账本抵触的问题。 每台物理机上都会部署一个混部agent,它能够实时采集容器资源应用数据,并依据平安水位线对离线工作进行压抑、驱赶等操作。 内核层面咱们应用了龙蜥OS,它具备弱小的资源隔离能力,能够帮忙咱们更好的隔离在线、离线资源应用,保障在线服务质量。 2.5 混部组件性能 咱们把混部组件分为管控组件和单机组件两大类。 管控组件次要负责调度和管制,依据vivo业务应用场景,咱们对调度器做了一些加强,提供了numa感知、负载感知,热点打散,批量调度等能力。 混部控制器次要提供了一些配置管理能力:如资源画像统计、node slo配置、node扩大资源变更等。 2.6 混部可视化监控 咱们为混部建设一套残缺的可视化监控体系。 针对在线服务咱们提供了:容器资源应用指标,受离线烦扰指标、业务混部收益指标等监控能力。 针对离线工作,咱们提供了离线可用资源、工作异样状态等监控能力。 在平台层面上咱们提供了节点、内核,外围组件的监控,通过这些监控可及时发现平台潜在的危险。 2.7 混部平台运维 为了简化运维操作,晋升运维效率,咱们对混部集群搭建和节点扩缩容操作进行了白屏化革新,开发了资源池治理性能,简化了物理机接入流程,运维效率大幅晋升。 在运维平台上运维人员能够疾速调整混部隔离、水位线等参数,如果发现在线服务受到烦扰,运维人员能够一键敞开混部,驱赶离线工作,保障在线服务质量。 2.8 问题与挑战2.8.1 apiServer拆分 通过混部产品能力的建设,咱们很好的实现了容器混部能力,然而在实践中咱们还是遇到一些新的挑战:绝对于一般K8s集群,混部集群中运行着更多的容器,而且离线工作因为生命周期短,容器创立销毁更为频繁,这对K8s apiServer 产生了很大的压力。 所以咱们拆分了apiServer ,离线工作应用独立的apiServer ,保障了集群apiServer 负载始终处于一个平安程度。 2.8.2 监控架构优化 同样混部之后因为采集了更多的监控指标,导致Prometheus内存耗费过多,无奈满足平台指标 采集需要。针对这个问题,咱们优化了监控架构,将在线和离线监控组件离开部署,离线改用性能更好的vmagent,通过这个优化,监控组件内存耗费缩小到原来的十分之一。 ...

February 29, 2024 · 1 min · jiezi

关于大数据:数据驱动的实验文化字节跳动产品优化之路

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群在近期CCF TF第123期用户体验工程主题流动中,火山引擎DataTester产品经理联合字节跳动在产品优化方面的教训,围绕“数据驱动的试验文化”这一话题进行了分享。 用户体验优化的最终目标是为了实现商业价值,为了确保优化方向的正确,企业须要有办法对用户体验和用户价值进行评估。AB测试是目前最简略牢靠的评估办法,它的根本的逻辑是通过控制变量,保障在同一时间、同一环境,只有产品性能有差别的状况下进行成果评估。AB测试可能为每一次数字化体验的优化提供牢靠的决策依据,帮忙企业力求每次决策都带来正向收益,通过复利效应实现继续稳固的增长。 如何利用AB测试做好产品决策字节跳动领有用户全生命周期的试验解决方案,可能从公域营销、私域经营以及产品优化三个场景帮忙企业应用AB测试实现用户体验的晋升。上面从四个案例分享字节跳动在产品优化过程中对AB测试的利用。 抖音-熟人社交的产品摸索通过AB试验低危险地疾速试错,让团队「勇于创新、敢于摸索」。 在抖音弹幕性能上线前,抖音团队利用AB测试设计了一个试验。将没有弹幕的页面设置为对照组,将有弹幕无其余互动性能的页面和有弹幕有其余互动性能的页面别离设为实验组1、2。 通过试验,抖音团队发现弹幕性能在保留了其余互动性能的时候能够在某些水平上晋升互动率,但与此同时,视频的浏览量和用户留存都有降落。即,弹幕性能不足以转化为长期的比较稳定的用户价值。因而,试验后抖音团队作出的决策是不上线此性能。 抖音-视频蒙层的设计优化通过AB试验更低成本地验证多个计划,帮忙团队「精打细磨、找到最优」。 设计师在抖音应用过程中感觉到视觉疲劳显著,通过业余思考心愿通过调整视频蒙层参数调整优化视觉状态。 团队通过DataTester开启AB试验,将原有计划设为对照组,调整视频蒙层高度、透明度等参数的计划设为实验组。通过小流量试验发现,视频蒙层优化后,人均App应用时长和人均App沉闷天数都有显著回升。 懂车帝-APP晋升登录率的优化实际懂车帝的指标是在不影响未登录用户应用体验的前提下,晋升登录率。通过定位问题、确定计划、开启AB试验,三个步骤抉择出最佳的计划进行迭代降级。实现登陆率的晋升,给用户提供更多的个性化服务。 客户案例:悟空租车如何晋升领取转化率通过AB试验,帮忙团队缩小依赖“教训”进行决策。 为了晋升领取转化率,悟空租车为用户提供了免押金服务,但用户使用率不达预期,领取转化率也没有显著晋升。为了晋升领取转化率,产品团队将租金领取和押金领取进行了拆分。对原有计划和新计划开启AB试验,发现拆分后下单转化率晋升了7%,实现了领取转化率的晋升。 试验驱动的产品迭代文化体系建设除了具体的试验案例,企业团队要想利用AB测试实现持续增长,就波及到了企业试验文化的培养。组织、方法论与工具是AB测试驱动增长在全公司范畴内可继续运行的三大因素,三者独特形成了AB测试可继续利用金三角。字节外部试验文化的培养教训就能够从这三个因素层面进行总结。 AB测试可继续利用:方法论在方法论层面,企业须要步步为营的增长思路和试验理念联合,因而企业能够从拆解增长指标和迷信评估成果两个角度实现方法论的欠缺。 首先,企业须要拆解增长指标,将业务OKR转化为外围指标指标,通过设计试验、运行剖析试验和决策、继续迭代三步,一直迫近业务指标,选取最优策略。 其次,企业利用AB测试的方法论包含实现迷信评估成果。针对此,企业能够从四个方面实现: 搭建指标体系:基于公司业务OEC指标建设试验指标体系。设立优化指标:拆解优化打算至子目标,包含评估指标和衡量标准。治理试验成果:子目标跟试验外围指标深度关联,批量监控优化成果。积攒决策教训:积淀试验教训,反对按指标晋升成果进行查找、学校和参考。AB测试可继续利用:组织在组织层面,企业须要实现必选试验的需要迭代流程、保障试验施行运行的团队以及对立增长指标和决策逻辑的建设和欠缺。即能够总结为流程机制以及组织机制两方面建设。 流程机制:配套的需要迭代流程和上线机制将AB试验流程融入惯例需要流程,简单决策进行Launch Review。 组织机制:搭建AB测试接口团队,工具+服务双轨运行企业须要搭建AB测试接口团队,对外部客户提供服务时,DataTester须要将工具+服务的机制双轨推动给客户。也就是除了工具,火山引擎DataTester还提供陪跑服务和咨询服务帮忙企业运行好从实验设计到试验开发上线到决策的整个链路。同时企业还须要建设沟通渠道和考核规范,实现从业务的角度看问题,帮忙业务胜利。 AB测试可继续利用:工具在工具层面,火山引擎DataTester能够在实现科学性保障的同时帮忙企业实现降本提效。一方面,DataTester能为企业提供牢靠的平台和数据。另一方面DataTester更贴近产品,易学易用,应用门槛低,且流程短,可能帮忙企业疾速开启实现AB试验,并实现后续的试验剖析和经验总结。 DataTester的接入层接入层是 AB 测试平台和业务服务端的会话的形式。通过 SDK 的形式能够和业务端的服务端、客户端,等触点进行通信。在 SDK 里封装了分流服务和这个数据上报和回收的性能,通过此性能,业务上的各个端能够通过 SDK 与平台进行失常的通信,实现申请求分流服务,上报数据等。 DataTester的性能层性能层是平台里所有人可见的性能,包含了从实验设计到配置公布整个流程治理和实验报告。其中,实验报告包含根底信息的展现指标减少趋势以及它统计散布的状况。此外,平台会针对试验给出较为全局的论断,并能够实现实时监控告警。 DataTester的数据层DataTester领有开放平台的能力,可能与业务端其余平台进行对接,接入第三方的数据和埋点。实现在DataTester已有的 push 平台或 banner 位的资源管理平台里疾速开启AB试验。 据理解,火山引擎DataTester源自字节跳动长期积淀,2023年中数据显示,字节已通过DataTester累计做过240万余次AB试验,日新增试验 4000余个,同时运行试验5万余个。DataTester目前服务了包含美的、华泰证券、博西家电、乐刻健身等在内的上百家企业,为业务的用户增长、转化、产品迭代、经营流动等各个环节提供迷信的决策依据,将成熟的“数据驱动增长”教训赋能给各行业。 点击跳转火山引擎A/B测试理解更多

February 29, 2024 · 1 min · jiezi

关于大数据:开源大数据集群部署十二Ranger-集成-hive

作者:櫰木 1、解压装置在hd1.dtstack.com主机上执行(个别抉择hiveserver2节点) 解压ranger-2.3.0-hive-plugin.tar.gz[root@hd1.dtstack.com software]#tar -zxvf ranger-2.3.0-hive-plugin.tar.gz批改install.properties配置[root@hd1.dtstack.com ranger-2.3.0-hive-plugin]# vim install.propertiesPOLICY_MGR_URL=http://hd1.dtstack.com:6080/REPOSITORY_NAME=hivedevCOMPONENT_INSTALL_DIR_NAME=/opt/hiveXAAUDIT.SOLR.ENABLE=trueXAAUDIT.SOLR.URL=http://hd1.dtstack.com:8983/solr/ranger_auditsXAAUDIT.SOLR.USER=NONEXAAUDIT.SOLR.PASSWORD=NONEXAAUDIT.SOLR.ZOOKEEPER=hd1:2181,hd2:2181,hd3:2181/ranger_auditsXAAUDIT.SOLR.FILE_SPOOL_DIR=/var/log/hive/audit/solr/spoolXAAUDIT.ELASTICSEARCH.ENABLE=falseXAAUDIT.ELASTICSEARCH.URL=NONEXAAUDIT.ELASTICSEARCH.USER=NONEXAAUDIT.ELASTICSEARCH.PASSWORD=NONEXAAUDIT.ELASTICSEARCH.INDEX=NONEXAAUDIT.ELASTICSEARCH.PORT=NONEXAAUDIT.ELASTICSEARCH.PROTOCOL=NONEXAAUDIT.HDFS.ENABLE=falseXAAUDIT.HDFS.HDFS_DIR=hdfs://__REPLACE__NAME_NODE_HOST:8020/ranger/auditXAAUDIT.HDFS.FILE_SPOOL_DIR=/var/log/hive/audit/hdfs/spoolXAAUDIT.HDFS.AZURE_ACCOUNTNAME=__REPLACE_AZURE_ACCOUNT_NAMEXAAUDIT.HDFS.AZURE_ACCOUNTKEY=__REPLACE_AZURE_ACCOUNT_KEYXAAUDIT.HDFS.AZURE_SHELL_KEY_PROVIDER=__REPLACE_AZURE_SHELL_KEY_PROVIDERXAAUDIT.HDFS.AZURE_ACCOUNTKEY_PROVIDER=__REPLACE_AZURE_ACCOUNT_KEY_PROVIDERXAAUDIT.LOG4J.ENABLE=falseXAAUDIT.LOG4J.IS_ASYNC=falseXAAUDIT.LOG4J.ASYNC.MAX.QUEUE.SIZE=10240XAAUDIT.LOG4J.ASYNC.MAX.FLUSH.INTERVAL.MS=30000XAAUDIT.LOG4J.DESTINATION.LOG4J=trueXAAUDIT.LOG4J.DESTINATION.LOG4J.LOGGER=xaauditXAAUDIT.AMAZON_CLOUDWATCH.ENABLE=falseXAAUDIT.AMAZON_CLOUDWATCH.LOG_GROUP=NONEXAAUDIT.AMAZON_CLOUDWATCH.LOG_STREAM_PREFIX=NONEXAAUDIT.AMAZON_CLOUDWATCH.FILE_SPOOL_DIR=NONEXAAUDIT.AMAZON_CLOUDWATCH.REGION=NONEXAAUDIT.HDFS.IS_ENABLED=falseXAAUDIT.HDFS.DESTINATION_DIRECTORY=hdfs://__REPLACE__NAME_NODE_HOST:8020/ranger/audit/%app-type%/%time:yyyyMMdd%XAAUDIT.HDFS.LOCAL_BUFFER_DIRECTORY=__REPLACE__LOG_DIR/hive/audit/%app-type%XAAUDIT.HDFS.LOCAL_ARCHIVE_DIRECTORY=__REPLACE__LOG_DIR/hive/audit/archive/%app-type%XAAUDIT.HDFS.DESTINTATION_FILE=%hostname%-audit.logXAAUDIT.HDFS.DESTINTATION_FLUSH_INTERVAL_SECONDS=900XAAUDIT.HDFS.DESTINTATION_ROLLOVER_INTERVAL_SECONDS=86400XAAUDIT.HDFS.DESTINTATION_OPEN_RETRY_INTERVAL_SECONDS=60XAAUDIT.HDFS.LOCAL_BUFFER_FILE=%time:yyyyMMdd-HHmm.ss%.logXAAUDIT.HDFS.LOCAL_BUFFER_FLUSH_INTERVAL_SECONDS=60XAAUDIT.HDFS.LOCAL_BUFFER_ROLLOVER_INTERVAL_SECONDS=600XAAUDIT.HDFS.LOCAL_ARCHIVE_MAX_FILE_COUNT=10XAAUDIT.SOLR.IS_ENABLED=falseXAAUDIT.SOLR.MAX_QUEUE_SIZE=1XAAUDIT.SOLR.MAX_FLUSH_INTERVAL_MS=1000XAAUDIT.SOLR.SOLR_URL=http://localhost:6083/solr/ranger_auditsSSL_KEYSTORE_FILE_PATH=/etc/hive/conf/ranger-plugin-keystore.jksSSL_KEYSTORE_PASSWORD=myKeyFilePasswordSSL_TRUSTSTORE_FILE_PATH=/etc/hive/conf/ranger-plugin-truststore.jksSSL_TRUSTSTORE_PASSWORD=changeitUPDATE_XAPOLICIES_ON_GRANT_REVOKE=trueCUSTOM_USER=hiveCUSTOM_GROUP=hadoop2、hive初始化[root@hd3.dtstack.com ranger-2.0.0-hive-plugin]# ./enable-hive-plugin.sh初始化实现后会在/opt/apache-hive-3.1.2-bin/conf目录下生成5个文件hiveserver2-site.xml文件内容如下: [root@hd3.dtstack.com conf]# cat hiveserver2-site.xml<?xml version="1.0" encoding="UTF-8" standalone="no"?><?xml-stylesheet type="text/xsl" href="configuration.xsl"?><!--Licensed to the Apache Software Foundation (ASF) under one or morecontributor license agreements. See the NOTICE file distributed withthis work for additional information regarding copyright ownership.The ASF licenses this file to You under the Apache License, Version 2.0(the "License"); you may not use this file except in compliance withthe License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, softwaredistributed under the License is distributed on an "AS IS" BASIS,WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.See the License for the specific language governing permissions andlimitations under the License.--><configuration><property><name>hive.security.authorization.enabled</name><value>true</value></property><property><name>hive.security.authorization.manager</name><value>org.apache.ranger.authorization.hive.authorizer.RangerHiveAuthorizerFactory</value></property><property><name>hive.security.authenticator.manager</name><value>org.apache.hadoop.hive.ql.security.SessionStateUserAuthenticator</value></property><property><name>hive.conf.restricted.list</name><value>hive.security.authorization.enabled,hive.security.authorization.manager,hive.security.authenticator.manager</value></property></configuration>3、hive 重启[root@hd3.dtstack.com apache-hive-3.1.2-bin]# sh stop.sh[root@hd3.dtstack.com apache-hive-3.1.2-bin]# sh start.sh[root@hadoop05 apache-hive-3.1.2-bin]# sh stop.sh[root@hadoop05 apache-hive-3.1.2-bin]# sh start.sh4、ranger admin页面配置拜访地址:http://hd2.dtstack.com:6080/用户明码:admin/rangerAdmin123参数配置阐明: ...

February 27, 2024 · 1 min · jiezi

关于大数据:助力春节精准营销火山引擎ByteHouse加速数据分析效率

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群随着元宵节的完结,2024年春节圆满闭幕。据抖音生存服务公布的《2024年春节生产数据报告》显示,元旦至大年初六(2月9日-2月15日),吃喝玩乐等生存服务业日均生产规模同比增长153%,这与春节期间商家发展的各种营销流动是严密相干。 因为促销或者广告投放等营销流动对数据实时剖析要求十分高,不少商家或平台通过引入OLAP引擎来解决实时数据分析的问题。以OLAP为数据库架构不仅助力商家实时收集和剖析数据,联合数据洞察等产品,还能让商家理解营销策略有效性,判断哪些产品或服务更受欢迎,帮忙商家理解客户的需要和偏好。例如,在线上电商场景中,基于实时数据,在发现某个产品销量忽然下降时,商家能够立刻剖析起因,并采取调整价格、减少库存或优化产品描述等相应措施,做到及时止损。 ByteHouse是火山引擎推出的一款基于开源ClickHouse构建的云原生数据仓库,能提供极速数据分析服务,撑持实时数据分析和海量数据离线剖析,对内通过字节跳动大量业务测验,对外也已在互联网、游戏、金融、汽车等畛域落地,并产生了良好业务成果。基于以上场景,ByteHouse在春节营销场景中也能够帮忙商家更好地理解市场和客户需要,实时调整营销策略。 比方,在广告投放场景中,ByteHouse能够满足大规模数据的剖析和查问需要,并具备一套用于解决汇合的交并补计算在实时剖析场景中的性能晋升问题的定制模型BitEngine。相比于一般和Array或者用户表形式,BitEngine在查问速度上有10-50倍晋升,解决了人群圈选中误差大、实时性不强以及存储老本高的痛点。这一能力能够晋升春节期间广告投放的效率,助力了销量增长。 再者,在实时营销场景中,ByteHouse采纳自研的Kafka引擎反对流式数据的实时写入、入库,保障数据传输的及时性,从而反对实时的业务决策;并且自研的Unique引擎可能实现实时的upsert语义,确保数据实时写入、实时去重,从而防止数据唯一性的问题。ByteHouse凭借其在数据处理畛域的当先技术,为企业在春节期间的营销实时监控畛域提供了数据分析和预测、指标客户精准推送、广告成果评估和优化的弱小技术支持,从而进步春节期间的营销成果。 将来,ByteHouse也将在晋升实时数据查问、剖析方向的技术及产品能力上继续晋升,帮忙商家在更好地理解用户需要和市场趋势,优化营销策略和广告投放,进步营销成果和ROI,从而在数据驱动下助力企业进步品牌价值和市场竞争力。 点击跳转火山引擎ByteHouse理解更多

February 27, 2024 · 1 min · jiezi

关于大数据:AB测试助力企业优化私域运营春节营销节点背后的科学决策

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群2024春节是一个近4.8亿人次出游的假期,餐饮、游览、批发等热门行业的支出都不同水平上涨,以生产行业为例,春节作为开年的重大营销节点,商家围绕春节的私域营销之战一直降级,一方面因为消费者年底的可摆布财产多且生产需要大,另一方面是因为企业踊跃进行私域经营及策略优化,实现了转化率晋升。那么,企业该当如何抓住机会进行私域经营优化?本文将从A/B试验的利用窍门登程,介绍3类企业在节假日期间能够罕用的私域经营优化形式。 A/B测试是迷信的随机对照试验,其外围价值是帮忙企业在业务决策时更正当的归因及更迷信的决策,被称为成果评估“金规范”。在生产行业常见的私域经营场景上,企业每上线一个新玩法,一个新性能,都可通过A/B测试取得即时反馈,从而通晓所做收益是否为正向,如用户触达场景、最佳经营策略抉择、最佳页面地位设置等。 下方是某奢品小程序的节日改版案例,案例中应用了A/B试验优化产品UI。该小程序通过对用户展现布局的改变,新增“混搭”、“经典搭配”、“热门产品”板块,并通过A/B试验发现转化成果晋升显著,商品详情的点击率晋升了70%以上,每个模块的加购转化率有了30%的晋升。 还有一类值得企业关注的私域场景,是通过A/B试验进行用户应用链路的优化,包含但不仅限于用户注册链路、登录链路、下单领取链路等多个方面。以某电商网站的登录链路优化为例,该网站更新设计了两套用户登录计划,对照组链路更加强调“注册”,实验组链路更加强调“登录”,并通过A/B试验选出了最合适的计划,用户登录率也取得了显著晋升。 对企业的私域营销而言,如何让信息顺畅地触达给受众也非常重要,在信息触达场景中,A/B试验也能够施展无足轻重的作用。常见的A/B试验类型有“短信营销试验”和“App Push推送试验”,以火山引擎VeDI推出的A/B测试平台为例,只有将它集成在企业日常应用的营销平台中,工作人员即可间接通过界面化配置的形式,疾速开启A/B试验,测试不同文案或落地页的成果。 对于生产人群而言,春节假期前后情绪愉悦、工夫绝对闲暇,有足够的精力参加各种类型的流动。因而此时无论是企业拉新还是促活都是黄金时间段。品牌能够围绕“年味”相干热点我的项目、热点词,策动业务相干的页面改版、链路优化、召回促活、裂变拉新等春节玩法,用数据驱动晋升企业效率,用科学决策减少企业效益。在这个过程中迷信牢靠的A/B试验平台助益也非常重要。 火山引擎数智平台VeDI推出的A/B试验平台DataTester源自字节跳动长期积淀,2023年中数据显示,字节已通过DataTester累计做过240万余次AB试验,日新增试验 4000余个,同时运行试验5万余个。DataTester目前服务了包含华泰证券、博西家电、美的、乐刻等数百家企业,为业务的用户增长、转化、产品迭代、经营流动等多环节提供迷信的决策依据,将成熟的“数据驱动增长”教训赋能给各行业。 点击跳转火山引擎A/B测试理解更多

February 23, 2024 · 1 min · jiezi

关于大数据:开源大数据集群部署十一Ranger-集成Hadoop集群

作者:櫰木1、节点抉择部署在两个namenode节点 cd /opt/bigdata tar -xzvf ranger-2.3.0-hdfs-plugin.tar.gz -C /opt/ cd /opt/ranger-2.3.0-hdfs-plugin vim install.properties # Licensed to the Apache Software Foundation (ASF) under one or more# contributor license agreements. See the NOTICE file distributed with# this work for additional information regarding copyright ownership.# The ASF licenses this file to You under the Apache License, Version 2.0# (the "License"); you may not use this file except in compliance with# the License. You may obtain a copy of the License at## http://www.apache.org/licenses/LICENSE-2.0## Unless required by applicable law or agreed to in writing, software# distributed under the License is distributed on an "AS IS" BASIS,# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.# See the License for the specific language governing permissions and# limitations under the License. ## Location of Policy Manager URL ## Example:# POLICY_MGR_URL=http://policymanager.xasecure.net:6080#POLICY_MGR_URL=http://hd1.dtstack.com:6080/ ## This is the repository name created within policy manager## Example:# REPOSITORY_NAME=hadoopdev#REPOSITORY_NAME=hadoopdev ## Set hadoop home when hadoop program and Ranger HDFS Plugin are not in the# same path.#COMPONENT_INSTALL_DIR_NAME=/opt/hadoop # AUDIT configuration with V3 properties# Enable audit logs to Solr#Example#XAAUDIT.SOLR.ENABLE=true#XAAUDIT.SOLR.URL=http://localhost:6083/solr/ranger_audits#XAAUDIT.SOLR.ZOOKEEPER=#XAAUDIT.SOLR.FILE_SPOOL_DIR=/var/log/hadoop/hdfs/audit/solr/spool XAAUDIT.SOLR.ENABLE=falseXAAUDIT.SOLR.URL=NONEXAAUDIT.SOLR.USER=NONEXAAUDIT.SOLR.PASSWORD=NONEXAAUDIT.SOLR.ZOOKEEPER=NONEXAAUDIT.SOLR.FILE_SPOOL_DIR=/var/log/hadoop/hdfs/audit/solr/spool # Enable audit logs to ElasticSearch#Example#XAAUDIT.ELASTICSEARCH.ENABLE=true#XAAUDIT.ELASTICSEARCH.URL=localhost#XAAUDIT.ELASTICSEARCH.INDEX=audit XAAUDIT.ELASTICSEARCH.ENABLE=falseXAAUDIT.ELASTICSEARCH.URL=NONEXAAUDIT.ELASTICSEARCH.USER=NONEXAAUDIT.ELASTICSEARCH.PASSWORD=NONEXAAUDIT.ELASTICSEARCH.INDEX=NONEXAAUDIT.ELASTICSEARCH.PORT=NONEXAAUDIT.ELASTICSEARCH.PROTOCOL=NONE # Enable audit logs to HDFS#Example#XAAUDIT.HDFS.ENABLE=true#XAAUDIT.HDFS.HDFS_DIR=hdfs://node-1.example.com:8020/ranger/audit#XAAUDIT.HDFS.FILE_SPOOL_DIR=/var/log/hadoop/hdfs/audit/hdfs/spool# If using Azure Blob Storage#XAAUDIT.HDFS.HDFS_DIR=wasb[s]://<containername>@<accountname>.blob.core.windows.net/<path>#XAAUDIT.HDFS.HDFS_DIR=wasb://ranger_audit_container@my-azure-account.blob.core.windows.net/ranger/audit XAAUDIT.HDFS.ENABLE=falseXAAUDIT.HDFS.HDFS_DIR=hdfs://__REPLACE__NAME_NODE_HOST:8020/ranger/auditXAAUDIT.HDFS.FILE_SPOOL_DIR=/var/log/hadoop/hdfs/audit/hdfs/spool # Following additional propertis are needed When auditing to Azure Blob Storage via HDFS# Get these values from your /etc/hadoop/conf/core-site.xml#XAAUDIT.HDFS.HDFS_DIR=wasb[s]://<containername>@<accountname>.blob.core.windows.net/<path>XAAUDIT.HDFS.AZURE_ACCOUNTNAME=__REPLACE_AZURE_ACCOUNT_NAMEXAAUDIT.HDFS.AZURE_ACCOUNTKEY=__REPLACE_AZURE_ACCOUNT_KEYXAAUDIT.HDFS.AZURE_SHELL_KEY_PROVIDER=__REPLACE_AZURE_SHELL_KEY_PROVIDERXAAUDIT.HDFS.AZURE_ACCOUNTKEY_PROVIDER=__REPLACE_AZURE_ACCOUNT_KEY_PROVIDER #Log4j Audit ProviderXAAUDIT.LOG4J.ENABLE=falseXAAUDIT.LOG4J.IS_ASYNC=falseXAAUDIT.LOG4J.ASYNC.MAX.QUEUE.SIZE=10240XAAUDIT.LOG4J.ASYNC.MAX.FLUSH.INTERVAL.MS=30000XAAUDIT.LOG4J.DESTINATION.LOG4J=trueXAAUDIT.LOG4J.DESTINATION.LOG4J.LOGGER=xaaudit # Enable audit logs to Amazon CloudWatch Logs#Example#XAAUDIT.AMAZON_CLOUDWATCH.ENABLE=true#XAAUDIT.AMAZON_CLOUDWATCH.LOG_GROUP=ranger_audits#XAAUDIT.AMAZON_CLOUDWATCH.LOG_STREAM={instance_id}#XAAUDIT.AMAZON_CLOUDWATCH.FILE_SPOOL_DIR=/var/log/hive/audit/amazon_cloudwatch/spool XAAUDIT.AMAZON_CLOUDWATCH.ENABLE=falseXAAUDIT.AMAZON_CLOUDWATCH.LOG_GROUP=NONEXAAUDIT.AMAZON_CLOUDWATCH.LOG_STREAM_PREFIX=NONEXAAUDIT.AMAZON_CLOUDWATCH.FILE_SPOOL_DIR=NONEXAAUDIT.AMAZON_CLOUDWATCH.REGION=NONE # End of V3 properties ## Audit to HDFS Configuration## If XAAUDIT.HDFS.IS_ENABLED is set to true, please replace tokens# that start with __REPLACE__ with appropriate values# XAAUDIT.HDFS.IS_ENABLED=true# XAAUDIT.HDFS.DESTINATION_DIRECTORY=hdfs://__REPLACE__NAME_NODE_HOST:8020/ranger/audit/%app-type%/%time:yyyyMMdd%# XAAUDIT.HDFS.LOCAL_BUFFER_DIRECTORY=__REPLACE__LOG_DIR/hadoop/%app-type%/audit# XAAUDIT.HDFS.LOCAL_ARCHIVE_DIRECTORY=__REPLACE__LOG_DIR/hadoop/%app-type%/audit/archive## Example:# XAAUDIT.HDFS.IS_ENABLED=true# XAAUDIT.HDFS.DESTINATION_DIRECTORY=hdfs://namenode.example.com:8020/ranger/audit/%app-type%/%time:yyyyMMdd%# XAAUDIT.HDFS.LOCAL_BUFFER_DIRECTORY=/var/log/hadoop/%app-type%/audit# XAAUDIT.HDFS.LOCAL_ARCHIVE_DIRECTORY=/var/log/hadoop/%app-type%/audit/archive#XAAUDIT.HDFS.IS_ENABLED=falseXAAUDIT.HDFS.DESTINATION_DIRECTORY=hdfs://__REPLACE__NAME_NODE_HOST:8020/ranger/audit/%app-type%/%time:yyyyMMdd%XAAUDIT.HDFS.LOCAL_BUFFER_DIRECTORY=__REPLACE__LOG_DIR/hadoop/%app-type%/auditXAAUDIT.HDFS.LOCAL_ARCHIVE_DIRECTORY=__REPLACE__LOG_DIR/hadoop/%app-type%/audit/archive XAAUDIT.HDFS.DESTINTATION_FILE=%hostname%-audit.logXAAUDIT.HDFS.DESTINTATION_FLUSH_INTERVAL_SECONDS=900XAAUDIT.HDFS.DESTINTATION_ROLLOVER_INTERVAL_SECONDS=86400XAAUDIT.HDFS.DESTINTATION_OPEN_RETRY_INTERVAL_SECONDS=60XAAUDIT.HDFS.LOCAL_BUFFER_FILE=%time:yyyyMMdd-HHmm.ss%.logXAAUDIT.HDFS.LOCAL_BUFFER_FLUSH_INTERVAL_SECONDS=60XAAUDIT.HDFS.LOCAL_BUFFER_ROLLOVER_INTERVAL_SECONDS=600XAAUDIT.HDFS.LOCAL_ARCHIVE_MAX_FILE_COUNT=10 #Solr Audit ProviderXAAUDIT.SOLR.IS_ENABLED=falseXAAUDIT.SOLR.MAX_QUEUE_SIZE=1XAAUDIT.SOLR.MAX_FLUSH_INTERVAL_MS=1000XAAUDIT.SOLR.SOLR_URL=http://localhost:6083/solr/ranger_audits # End of V2 properties ## SSL Client Certificate Information## Example:# SSL_KEYSTORE_FILE_PATH=/etc/hadoop/conf/ranger-plugin-keystore.jks# SSL_KEYSTORE_PASSWORD=none# SSL_TRUSTSTORE_FILE_PATH=/etc/hadoop/conf/ranger-plugin-truststore.jks# SSL_TRUSTSTORE_PASSWORD=none## You do not need use SSL between agent and security admin tool, please leave these sample value as it is.#SSL_KEYSTORE_FILE_PATH=/etc/hadoop/conf/ranger-plugin-keystore.jksSSL_KEYSTORE_PASSWORD=myKeyFilePasswordSSL_TRUSTSTORE_FILE_PATH=/etc/hadoop/conf/ranger-plugin-truststore.jksSSL_TRUSTSTORE_PASSWORD=changeit # Custom component user# CUSTOM_COMPONENT_USER=<custom-user># keep blank if component user is defaultCUSTOM_USER=hdfs# Custom component group# CUSTOM_COMPONENT_GROUP=<custom-group># keep blank if component group is defaultCUSTOM_GROUP=hadoopranger hdfs初始化 ...

February 22, 2024 · 2 min · jiezi

关于大数据:ByConity-替换-ClickHouse-构建-OLAP-数据平台资源成本大幅降低

作者|程伟,MetaAPP 大数据研发工程师【我的项目地址】GitHub |https://github.com/ByConity/ByConity ByConity 是字节跳动开源的云原生数据仓库,在满足数仓用户对资源弹性扩缩容,读写拆散,资源隔离,数据强一致性等多种需要的同时,并提供优异的查问,写入性能。 MetaApp 是国内当先的游戏开发与运营商,专一挪动端信息高效散发,致力于构建面向全年龄段的虚拟世界。截至 2023 年,MetaApp 注册用户已超 2 亿,联运单干 20 万款游戏,累计散发量过 10 亿。MetaApp 在 ByConity 开源晚期便放弃关注,是最早进行测试并在生产环境上线的用户之一。抱着理解开源数仓我的项目能力的想法,MetaApp 大数据研发团队对 ByConity 进行了初步测试。其存算拆散的架构、优良的性能,尤其在日志剖析场景中,对于大规模数据简单查问的反对,吸引 MetaApp 对 ByConity 进行了深刻测试,最终在生产环境全量替换 ClickHouse,使资源老本升高超 50%。本文将次要介绍 MetaApp 数据分析平台的性能,业务场景中遇到的问题及解决方案以及引入 ByConity 对其业务的帮忙。 MetaApp OLAP 数据分析平台架构及性能随着业务的增长,精细化经营的提出,产品对数据部门提出了更高的要求,包含须要对实时数据进行查问剖析,疾速调整经营策略;对小局部人群做 AB 试验,验证新性能的有效性;缩小数据查问工夫,升高数据查问难度,让非专业人员能够自主剖析、探查数据等。为满足业务需要,MateApp 实现了集事件剖析、转化剖析、自定义留存、用户分群、行为流剖析等性能于一体的 OLAP 数据分析平台。 这是一个典型的 OLAP 的架构,分成两局部,一部分是离线,一部分是实时。在离线场景中,咱们应用 DataX 把 Kafka 的数据集成到 Hive 数仓,再生成 BI 报表。BI 报表应用了 Superset 组件来进行后果展现;在实时场景中,一条线应用 GoSink 进行数据集成,把 GoSink 的数据集成到 ClickHouse,另外一条线应用 CnchKafka 把数据集成到 ByConity。最初通过 OLAP 查问平台获取数据进行查问。 ByConity 和 ClickHouse 性能比照ByConity 是基于 ClickHouse 内核研发的开源云原生数据仓库,采纳存算拆散的架构。两者都具备以下特点: ...

February 21, 2024 · 3 min · jiezi

关于大数据:企业级大数据安全架构十DBeaver连接Hive的Kerberos认证配置

一、DBeaver连贯Kerberos认证下的hive1.配置本地hosts因为Kerberos认证过程及集群服务中,很多是以主机名的模式进行拜访的,所以工作机要设置hosts. 域名映射,咱们通过部署CDH的集群的每一台机器都曾经配置了host(文件为/etc/hosts),工作机也须要配置window的host文件,如果提醒无奈批改,个别是须要管理员权限的起因,比较简单的形式是先将文件移出来,批改实现之后再放进去。 hosts文件门路为: 2.配置window环境(变量和配置文件)2.1装置Kerberos客户端下载地址:https://web.mit.edu/kerberos/dist/index.html抉择msi安装包,而后一路next即可装置实现。抉择是否要重启电脑的时候抉择no,稍后对立重启。 2.2配置window环境(变量和配置文件)2.2.1配置krb5.ini在上一步装置实现的Kerberos客户端的时候,会默认生成C:\ProgramData\MIT\Kerberos5\krb5.ini文件,依据曾经存在的KDC Server上的/etc/krb5.conf,拷贝局部内容到krb5.ini中,如果间接将krb5.conf文件更名为krb5.ini并替换krb5.ini,会呈现文件格式问题导致MIT Kerberos客户端无奈失常启动。 2.2.2 配置环境变量配置环境变量krb5.ini以及Kerberos Credential Cache File的门路, 变量名:KRB5_CONFIG 变量值:C:\ProgramData\MIT\Kerberos5\krb5.ini。 变量名:KRB5CCNAME,变量值:C:\temp\krb5cache。 KRB5CCNAME的门路默认是不存在的,因而须要在C盘下创立temp文件夹,krb5cache文件则不须要创立。 2.3 DBeaver 配置2.3.1 DBeaver配置批改因为DBeaver是通过JDBC的形式拜访Hive,底层也是基于Java环境,所以这里须要在DBeaver的配置中减少JVM的参数,增加对于Kerberos相干的配置。进入DBeaver的装置目录,找到dbeaver.ini配置文件,在配置文件开端减少如下配置,重新启动DBeaver客户端。 2.3.2 DBeaver 连贯配置批改测试通过基于Cloudera驱动创立的连贯,上面以这种形式下载驱动地址如下:https://www.cloudera.com/downloads/connectors/hive/jdbc/2-6-5.html 下载实现后,解压失去外面的HiveJDBC41.jar 这个驱动包,这个包外面蕴含了残缺的依赖,而后进入DBeaver的驱动设置界面。 设置完驱动之后,批改URL模板,在URL模板中减少如下参数: ;AuthMech=1;KrbRealm=MYCDH.COM;KrbHostFQDN={host};KrbServiceName=hive;KrbAuthType=2 2.4 进行Kerberos认证2.4.1 关上Kerberos客户端从桌面的快捷方式进入,进入后如下 2.4.2 调整Kerberos环境变量地位因为kinit命令跟JDK有抵触,所以要将环境变量Path中,dbeaver的程序放到JDK之前 2.4.3 DOS端口进行Kerberos认证登录 该步骤须要先将hive.keytab 放入F盘下,登录之后Kerberos客户端会显示登录的票据。 2.4.4 重启工作机而后再从新关上DBeaver 连贯测试。 更多技术信息请查看云掣官网https://yunche.pro/?t=yrgw

February 21, 2024 · 1 min · jiezi

关于大数据:开源大数据集群部署十Ranger-usersync部署

作者:櫰木 ranger usersync部署解压包 [root@hd1.dtstack.com ranger]# pwd/opt/ranger[root@hd1.dtstack.com ranger]# tar -zxvf ranger-2.3.0-usersync.tar.gz -C /opt/[root@hd1.dtstack.com ranger]# cd ranger-2.3.0-usersync批改配置install.properties,须要批改内容如下: POLICY_MGR_URL = http://hd1.dtstack.com:6080SYNC_INTERVAL = 5rangerUsersync_password=Ranger@123usersync_principal=rangerusersync/hd1.dtstack.com@DTSTACK.COMusersync_keytab=/etc/security/keytab/rangerusersync.keytabhadoop_conf=/opt/hadoop/etc/hadoop初始化 [root@hd2.dtstack.com ranger-2.3.0-usersync]# ./setup.sh启动 [root@hd2.dtstack.com ranger-2.3.0-usersync]# ranger-usersync start验证页面验证是否装置胜利:在Ranger控制台能够看到users中同步的用户信息。 FQA问题一在install.properties中的keytab必须配置以下principal的 usersync_principal=rangerusersync/hd1.dtstack.com@DTSTACK.COMusersync_keytab=/etc/security/keytab/rangerusersync.keytab因为这个有两种认证形式。帐号密码和keytab的形式。用户必须为rangerusersync这个特定帐号,其余帐号会呈现无奈获取json的状况。问题2须要留神rangeradmin的install.properties中的keytab和principal必须统一。不然会呈现此谬误 集成ldap 使其同步ldap用户到ranger1、批改配置 cd /opt/ranger-2.3.0-usersync/SYNC_SOURCE = ldapSYNC_LDAP_URL = ldap://hd.dtstack.com:389SYNC_LDAP_BIND_DN = uid=admin,cn=users,cn=accounts,dc=dtstack,dc=comSYNC_LDAP_BIND_PASSWORD = Admin@123SYNC_LDAP_DELTASYNC =SYNC_LDAP_SEARCH_BASE = cn=accounts,dc=dtstack,dc=comSYNC_LDAP_USER_S EARCH_BASE = cn=users,cn=accounts,dc=dtstack,dc=comSYNC_LDAP_USER_SEARCH_SCOPE = subSYNC_LDAP_USER_OBJECT_CLASS = personSYNC_LDAP_USER_SEARCH_FILTER =SYNC_LDAP_USER_NAME_ATTRIBUTE = uidSYNC_LDAP_USER_GROUP_NAME_ATTRIBUTE = memberof,ismemberofSYNC_LDAP_USERNAME_CASE_CONVERSION=lowerSYNC_LDAP_GROUPNAME_CASE_CONVERSION=lower SYNC_GROUP_SEARCH_ENABLED= trueSYNC_GROUP_USER_MAP_SYNC_ENABLED= trueSYNC_GROUP_SEARCH_BASE= cn=groups,cn=accounts,dc=dtstack,dc=comSYNC_LDAP_URL #ldpa地址SYNC_LDAP_BIND_DN #查问用户SYNC_LDAP_BIND_PASSWORD #明码SYNC_LDAP_SEARCH_BASE #搜寻域SYNC_LDAP_USER_SEARCH_BASE #搜寻用户的域SYNC_LDAP_USER_NAME_ATTRIBUTE #用户名属性SYNC_GROUP_SEARCH_BASE #搜寻组的域 通过ldapsearch进行查问 ldapsearch -x -H ldap://hd.dtstack.com:389 -b cn=users,cn=accounts,dc=dtstack,dc=com -D "uid=admin,cn=users,cn=accounts,dc=dtstack,dc=com" -w Admin@123配置实现后,执行setup.sh生成新的配置确认ranger.usersync.enabled 为truecat conf/ranger-ugsync-site.xml ...

February 20, 2024 · 1 min · jiezi

关于大数据:从零开始快速构建自己的Flink应用

本文介绍如何在 mac 下疾速构建属于本人的 Flink 利用。 1. 本地装置 flink在 mac 上应用homebrew装置 flink: brew install apache-flink查看装置的地位: brew info apache-flink进入装置目录,启动 flink 集群: cd /usr/local/Cellar/apache-flink/1.18.0./libexec/bin/start-cluster.sh进入 web 页面:http://localhost:8081/ 2. 构建我的项目基于模板间接构建一个我的项目: curl https://flink.apache.org/q/quickstart.sh | bash -s 1.18.0cd quickstart在我的项目的 DataStreamJob 类实现如下计数的性能: package org.myorg.quickstart;import org.apache.flink.api.common.functions.FlatMapFunction;import org.apache.flink.api.java.tuple.Tuple2;import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;import org.apache.flink.util.Collector;public class DataStreamJob { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.socketTextStream("127.0.0.1", 9000) .flatMap(new LineSplitter()) .keyBy(0) .sum(1) .print(); env.execute("WordCount"); } public static final class LineSplitter implements FlatMapFunction<String, Tuple2<String, Integer>> { @Override public void flatMap(String s, Collector<Tuple2<String, Integer>> collector) { String[] tokens = s.toLowerCase().split("\\W+"); for (String token : tokens) { if (token.length() > 0) { collector.collect(new Tuple2<>(token, 1)); } } } }}在下面的例子中,咱们应用 DataStream API 构建了一个 Flink 利用,数据源(source)为本地的 socket 9000 端口,通过 flatMap、keyBy、sum 三个转换操作之后,最初打印到规范输入流。整体流程如下图: ...

February 19, 2024 · 1 min · jiezi

关于大数据:技术创新再被认可Smartbi荣获2023大数据产业年度创新技术突破大奖

近日,由金猿、数据猿、上海大数据联盟主办,上海市经济和信息化委员会、上海科学技术委员会领导的“第六届金猿季&魔方论坛——大数据产业倒退论坛”在上海举办。思迈特软件凭借“基于数据模型的自然语言数据查问零碎“荣获“2023大数据产业年度翻新技术冲破”奖。 除此之外,此次由思迈特软件董事长吴华夫率领的开发团队也取得了本次大奖的荣誉认可,此份奖项不仅是对思迈特软件产品整体创新能力的认可,更是对开发团队智慧结晶与辛勤付出的高度肯定。吴华夫学生以其前瞻性的战略眼光和百折不挠的科研精力,率领开发团队一直攻坚克难,推动NLA技术研发与利用实际深度交融,胜利实现了从理念到产品的逾越,无力助推了商业智能与大数据分析产业的技术提高和翻新倒退。           基于数据模型的自然语言数据查问零碎的倒退背景是次要源于解决在经典自然语言查问利用计划中发现的痛点,这类零碎依靠于数据模型构建,其中端到端的语言模型充当中间层将用户输出的自然语言转化为 SQL 执行语句,数据库作为底层存储和数据处理的引擎,负责承受和执行从大模型发送过去的 SQL 语句,对数据进行聚合、筛选、排序等操作,满足基于数据集的查问剖析需要。 然而,这类零碎在理论落地过程中经常面临着不少挑战,比如说数据口径凌乱,用户表白歧义,尤其在解决简单关联和跨表查问时准确性受限;性能呈现瓶颈,仅依赖数据库导致查问效率低下;私域常识辨认问题在于模型不足畛域常识,难以深刻了解业务语义。 针对以上难点,Smartbi解决思路是将以上挑战逐个拆解,通过组件叠加分阶段欠缺智能问答的架构构建:第一,利用数据模型减少语义层,无效解决了简单数据处理中的口径不统一问题,通过简化多表关联至单表查问晋升了语义转换精确度,并使业务分析师可能灵便定义多源数据的规范语义信息。其次,针对大数据量下的查问问题,Smartbi采纳了Clickhouse作为查问引擎,并基于数据模型建模进行了指标的预聚合,并增加了数据查问的缓存库,显著晋升了数据查问响应速度。再来,针对私域常识的问题,提供了配置的同义词知识库和一个用户行为知识库。在查问过程中为语言模型提供个性化补充信息,从而加强了对私域常识的了解和解决成果,晋升了整体语言解决品质。因而,基于数据模型的自然语言数据查问零碎通过构建层次化数据模型、集成高性能查问引擎及个性化知识库,胜利应答了业务语义在理论利用中的复杂性挑战,实现了数据口径统一到查问性能优化再到私域常识了解的全面晋升,确保了对话式剖析性能在各类业务场景中可能精确、高效地为用户提供深度洞察和决策反对。 这一成就不仅体现了Smartbi在BI畛域的深厚积攒与技术实力,也活泼诠释了AI+BI交融对于推动企业数字化转型及晋升数据决策效率的重要性。展望未来,随着人工智能与大数据模型等新兴科技继续重塑各行各业的生产力格局,作为国内当先的BI厂商,Smartbi将持续深耕BI畛域,一直摸索AI与BI技术交融的可能性,致力构建翻新且实用的技术办法,为客户提供更优质的解决方案和服务。

February 18, 2024 · 1 min · jiezi

关于大数据:MySQL到TiDBHive-Metastore横向扩展之路

作者:vivo 互联网大数据团队 - Wang Zhiwen本文介绍了vivo在大数据元数据服务横向扩大路线上的摸索历程,由理论面临的问题登程,对以后支流的横向扩大计划进行了调研及比照测试,通过多方面比照数据择优抉择TiDB计划。其次分享了整个扩大计划流程、施行遇到的问题及解决方案,对于在大数据元数据性能上面临同样窘境的开发者本篇文章具备十分高的参考借鉴价值。 一、背景大数据元数据服务Hive Metastore Service(以下简称HMS),存储着数据仓库中所依赖的所有元数据并提供相应的查问服务,使得计算引擎(Hive、Spark、Presto)能在海量数据中精确拜访到须要拜访的具体数据,其在离线数仓的稳固构建上扮演着无足轻重的角色。vivo离线数仓的Hadoop集群基于CDH 5.14.4版本构建,HMS的版本抉择追随CDH大版本,以后应用版本为1.1.0-cdh5.14.4。 vivo在HMS底层存储架构未降级前应用的是MySQL存储引擎,但随着vivo业务倒退,数据爆炸式增长,存储的元数据也相应的增长到亿级别(PARTITION_PARAMS:8.1亿、PARTITION_KEY_VALS:3.5亿、PARTITIONS:1.4亿),在如此大量的数据基数下,咱们团队常常面临机器资源的性能瓶颈,往往用户多并发的去查问某些大分区表(50w+分区),机器资源的使用率就会被打满,从而导致元数据查问超时,重大时甚至整个HMS集群不可用,此时复原伎俩只能临时停服所有HMS节点,直到MySQL机器负载降下来后在逐渐复原服务。为此,针对以后MySQL计划存在的重大性能瓶颈,HMS急需一套欠缺的横向扩大计划来解决以后当务之急。 二、横向扩大技术计划选型为解决HMS的性能问题,咱们团队对HMS横向扩大计划做了大量的调研工作,总体下来业内在HMS的横向扩大思路上次要分为对MySQL进行拆库扩大或用高性能的分布式引擎代替MySQL。在第一种思路上做的比拟成熟的计划有Hotels.com公司开源的Waggle Dance,实现了一个跨集群的Hive Metastore代理网关,他容许用户同时拜访多个集群的数据,这些集群能够部署在不同的平台上,特地是云平台。第二种思路以后支流的做法是用分布式存储引擎TiDB替换传统的MySQL引擎,在Hive社区中有不少公司对hive 2.x接入TiDB做了大量的测试并利用到生产中(详情点击)。 2.1 Waggle DanceWaggle-dance向用户提供对立的入口,将来自Metastore客户端的申请路由到底层对应的Metastore服务,同时向用户暗藏了底层的Metastore散布,从而在逻辑层面整合了多个Metastore的Hive库表信息。Waggle-dance实现了Metastore的Thrift API,客户端无需改变,对用户来说,Waggle-dance就是一个Metastore。其整体架构如下: Waggle Dance架构 从Waggle-dance的架构中最突出的个性是其采纳了多个不同的MySQL实例分担了原单MySQL实例的压力,除此之外其还有如下劣势: 用户侧能够沿用Metastore客户端的用法,配置多台Waggle-dance的连贯,在以后Waggle-dance连贯服务不可用的时候切换到其余的Waggle-dance服务上。Waggle-dance只需几秒即可启动,加上其无状态服务的个性,使得Waggle-dance具备高效的动静伸缩性,能够在业务高峰期疾速上线新的服务节点扩散压力,在低峰期下线局部服务节点开释资源。Waggle-dance作为一个网关服务,除了路由性能外,还反对后续的定制化开发和差异化部署,平台可依据须要增加诸如鉴权、防火墙过滤等性能。2.2 TiDBTiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库,是一款同时反对在线事务处理与在线剖析解决 (Hybrid Transactional and Analytical Processing, HTAP) 的交融型分布式数据库产品,具备程度扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协定和 MySQL 生态等重要个性。在TiDB 4.x版本中,其性能及稳定性较与之前版本失去了很大的晋升并满足HMS的元数据查问性能需求。故咱们对TiDB也做了相应的调研及测试。联合HMS及大数据生态,采纳TiDB作为元数据存储整体的部署架构如下: HMS on TiDB架构  因为TiDB自身具备程度扩大能力,扩大后能均分查问压力,该个性就是咱们解决HMS查问性能瓶颈的大杀器。除此外该架构还有如下劣势: 用户无需任何改变;HMS侧面没有任何改变,只是其依赖的底层存储发生变化。不毁坏数据的完整性,无需将数据拆分多个实例来分担压力,对HMS来说其就是一个残缺、独立的数据库。除引入TiDB作为存储引擎外,不须要额定的其余服务撑持整个架构的运行。2.3 TiDB和Waggle Dance比照后面内容对Waggle-dance计划和TiDB计划做了简略的介绍及劣势总结,以下列举了这两个计划在多个维度的比照: 通过上述多个维度的比照,TiDB计划在性能体现、程度扩大、运维复杂度及机器老本上都优于waggle-dance计划,故咱们线上抉择了前者进行上线利用。  三、TiDB上线计划抉择TiDB引擎代替原MySQL存储引擎,因为TiDB与MySQL之间不能做双主架构,在切换过程中HMS服务须齐全停服后并重新启动切换至TiDB,为保障切换过程顺利及前面若有重大问题产生能及时回滚,在切换前做了如下数据同步架构以保障切换前MySQL与TiDB数据统一以及切换后仍有MySQL兜底。 TiDB&MySQL上线前后数据同步架构 在上述架构中,切换前惟一可写入的数据源只有源数据库主库,其余所有TiDB、MySQL节点都为只读状态,当且仅当所有HMS节点停服后,MySQL源数据库从库及TiDB源数据库主库的数据同步最大工夫戳与源数据库主库统一时,TiDB源数据库主库才凋谢可写入权限,并在批改HMS底层存储连贯串后逐个拉起HMS服务。 在上述架构实现后,即可开始具体的切换流程,切换整体流程如下: HMS切换底层存储流程 其中在保障源MySQL与TiDB数据失常同步前,须要对TiDB做以下配置: tidb_skip_isolation_level_check须要配置为1 ,否则启动HMS存在MetaException异样。tidb_txn_mode需配置为pessimistic ,晋升事务一致性强度。事务大小限度设置为3G,可依据本人业务理论状况进行调整。连贯限度设置为最大3000 ,可依据本人业务理论状况进行调整。此外在开启sentry服务状态下,需确认sentry元数据中NOTIFICATION_ID的值是否落后于HMS元数据库中NOTIFICATION_SEQUENCE表中的NEXT_EVENT_ID值,若落后需将后者替换为前者的值,否则可能会产生建表或创立分区超时异样。 以下为TiDB计划在在不同维度上的体现: 在对HQL的兼容性上TiDB计划齐全兼容线上所有引擎对元数据的查问,不存在语法兼容问题,对HQL语法兼容度达100% 在性能体现上查问类接口均匀耗时优于MySQL,性能整体晋升15%;建表耗时升高了80%,且反对更高的并发,TiDB性能体现不差于MySQL在机器资源应用状况上整体磁盘使用率在10%以下;在没有热点数据拜访的状况下,CPU均匀使用率在12%;CPU.WAIT.IO平均值在0.025%以下;集群不存在资源应用瓶颈。在可扩展性上TiDB反对一键程度扩缩容,且外部实现查问平衡算法,在数据达到平衡的状况下各节点可平摊查问压力。在容灾性上TiDB Binlog技术可稳固撑持TiDB与MySQL及TiDB之间的数据同步,实现残缺的数据备份及可回退抉择。在服务高可用性上TiDB可抉择LVS或HaProxy等服务实现负载平衡及故障转移。以下为上线后HMS次要API接口调用耗时状况统计: ...

September 28, 2023 · 2 min · jiezi

关于大数据:聚焦私域营销降本提效国联股份与火山引擎数智平台展开合作

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群北京国联视讯信息技术股份有限公司与火山引擎数智平台VeDI的单干进入新阶段,单方将持续聚焦国联股份自建的数字营销平台「国联云销通」,在市场数据洞察和数据实时计算两方面开启新摸索。 成立于2002年的北京国联视讯信息技术股份有限公司(以下简称“国联股份”)是国内当先的B2B电子商务和产业互联网平台,为多个行业提供工业品和原材料的网上商品交易、商业信息服务和互联网技术服务。 目前,国联股份曾经领有笼罩100多个工业畛域行业,超280.85万注册会员企业的B2B信息服务平台「国联资源网」,并先后上线了包含涂多多、卫多多、玻多多等在内的8个垂直电商平台。 在业务线日渐丰盛的过程中,国联股份为了进一步洞察用户需要,以及把握最新市场风向,还踊跃筹备自建营销中台「国联云销通」,并面向企业级市场输入。 国联云销通助力企业数字化营销转型,为企业私域流量管理体系提供平台构建所需的营销能力撑持,无效经营所需的数据洞察反对。通过销售赋能、客户营销旅程洞察,帮忙企业实现营销全链路的客户生命周期治理,实现继续晋升营销成果、效益和回报,让营销更有价值,助力企业营收增长。 然而贯通企业营销场景全链路,须要波及场景下的多套数据体系接入,这对数据的实时写入、去重、更新和集群运维等多个方面都提出了高要求,这也是国联股份此次单干火山引擎数智平台VeDI的关键因素。 据理解,火山引擎数智平台向国联股份输入的火山引擎ByteHouse,在架构上采纳了自研的高可用引擎表,同时在集群的运维和多表关联的场景都做了相应的加强。 即使是在面对国联云销通这类绝对简单的营销场景下,ByteHouse仍旧能放弃灵便高效的实时查问性能,同时丰盛的表引擎还能反对数据的疾速写入去重、更新、删除与剖析,为国联云销通的用户带来极速剖析体验。 在实现后端数据分析保障的根底上,火山引擎数智平台VeDI还能帮忙国联云销通在企业私域渠道中部署增长剖析DataFinder,以埋点上报的形式实现企业对业务场景中的数据进行实时洞察。值得一提的是,火山引擎数智平台DataFinder自带的多套数据分析模板,极大升高了企业员工的看数、用数门槛,从操作角度上真正帮忙企业实现了“即时看数,不便用数”。 国联股份技术总监魏立峰通知记者,国联股份与ByteHouse、DataFinder的单干只是一个开始,“我置信将来必定有更多单干机会,也心愿国联云销通可能借助像火山引擎数智平台VeDI这样成熟的合作伙伴,持续拓展服务边界,为更多企业带去营销场景下的降本提效能力。” 过来一年,火山引擎数智平台已面向企业级市场推出包含ByteHouse、DataFinder等在内的笼罩企业数据全生命周期的产品矩阵,让企业的数据生产、数据生产和业务倒退,造成数据飞轮,实现正向循环。 据理解,数据飞轮是火山引擎在数据驱动理念下积淀的教训模式,可能帮忙企业盘活转动数字化实际价值,实现降本增效。 点击跳转火山引擎数智平台VeDI理解更多

September 27, 2023 · 1 min · jiezi

关于大数据:一键登录是如何为应用开发者实现降本增效的

在一键登录诞生之前,传统登录形式通过了账号密码、第三方登录、短信验证码的技术迭代。但均难以实现账号安全性、便捷性和隐衷性的对立。因而,快捷、高效、平安的一键登录孕育而生。秒验是由寰球当先的挪动开发者服务平台MobTech推出的一键登录开发者工具,通过升高传统登录形式老本、避免歹意注册和利用平台破绽、晋升用户留存和裂变等形式,为利用开发者实现平台经营的降本增效。  1、节俭传统登录形式老本传统的登陆形式因原理差别所产生的老本各不相同。账号密码登录减少了利用开发者后盾明码治理老本和技术支持老本。第三方登录须要用户受权第三方提供商拜访其个人信息,因而对用户而言存在隐衷问题。此外用户若在多个第三方利用存在多个账号,则可能存在账号治理艰难或账号被合并等状况,此外,第三方登录服务商的变更可能会造成用户账号损失。而短信验证具备较高的资费,目前短信验证码平台的免费规范约在0.03-0.06元/条之间,“秒验”凭借对接三大运营商的“网关+短验能力”,实现了单次一键登录费用在0.02-0.03元/次之间,这对于领有千万级用户的挪动利用而言,仅注册登录老本就能够节俭数十万元,此外,若将传统账号密码登录全面降级为“秒验”一键登录,也将节俭企业后盾明码治理和重置以及技术支持所产生的费用,同时也杜绝了用户账号被盗和隐衷泄露的危险。  2、回绝歹意注册和羊毛党”薅羊毛“对于传统账号密码登录的平台而言,一个人能够批量注册多个账号,通过假冒新用户支付对应的优惠和服务,从而利用平台破绽歹意注册谋利。对于某些社交类app,传统账号密码登录也助长着歹意注册用户通过自导自演、歹意灌水、刷屏等形式影响站内生态。此外,对于某些领有付费增值服务的平台,可能会呈现一人注册账号随后将账号内增值内容分享、倒卖给其他人,从而造成”薅羊毛“的景象。”秒验“所提供的一键登录服务从根本上杜绝了上述可能,用户登录时零碎主动会通过挪动网络运营商或 SDK 获取用户手机上的本机号码,并将获取到的号码与用户账户绑定进行验证,只有卡机合一能力胜利登录,一键认证用户身份。 3、推动用户留存和裂变传统登录形式均在登录效率上难以保障,账号密码登录须要用户手动输出账号和明码,如果明码谬误可能重复尝试直至重置明码。短信验证则须要用户手动输出本人的手机号和收到的验证码,且验证码均具备肯定时效性,因而在登录效率上存在肯定有余。传统短信验证登录均匀耗时25秒左右,而采纳秒验提供的”一键登录“仅需期待三秒即可,相较于传统短信验证效率晋升了近十倍。这不仅极大的简化了存量用户的登录流程,同时也为平台拉新促活吸引的新注册用户优化了注册和登录体验,晋升了引流转化率,减速实现用户留存和用户裂变。  随着秒验在更多社交、领取、娱乐、电商、金融平台失去广泛应用,在将来用户将会深刻参加到秒验的泛滥利用场景之中。

September 26, 2023 · 1 min · jiezi

关于大数据:MobTech全面助力开发与运营用户进行APP生命周期智能管理

现在,许多互联网企业正放慢数智化降级的步调。通过“数据驱动”来开掘用户更深层次的价值,进步经营效率和成果,曾经成为互联网从业者的共识。MobTech袤博科技正致力于推动数据赋能,全面助力开发与经营用户进行APP生命周期智能治理。 MobTech袤博科技是一家在挪动互联网行业深耕十余年的公司,作为宽广APP的老朋友,他们曾经累计为150万APP开发者提供服务。以提供share社会化分享组件服务为终点,当初曾经倒退成为提供秒验一键登录认证、MobPush智能音讯推送等一系列开发者产品与服务的数智公司,并积攒了丰盛的数据驱动经营增长实战经验。 凭借弱小的数据能力,MobTech袤博科技在横向洞察和纵向晋升方面帮忙APP。他们可能帮忙APP分明地理解用户旅程中的行为特色,实时洞察用户在整个生命周期各阶段的需要偏好,以助力APP优化产品和经营策略,晋升用户体验和用户价值。 在横向洞察方面,MobTech袤博科技提供了数千种标签数据,帮忙APP从多个维度全面洞察用户,比方用户在不同生命周期阶段的散布和趋势变动,以及用户的特色画像等。通过这些数据,MobTech实现了精细化用户分组和分层,并且可能帮忙APP预测要害行为,举荐更高效的要害行为转化策略。另外,MobTech袤博科技还提供欠缺的后效验证机制,帮忙APP实现"策略调整-后效验证-数据回流"的闭环。 在纵向晋升方面,MobTech袤博科技为APP在不同的用户生命周期治理场景中提供增能服务,通过经营策略领导帮忙客户进步要害指标。举例来说,在新用户冷启动场景中,MobTech袤博科技帮忙APP对新注册用户群进行多维度剖析,理解他们的内容偏好,欠缺内容举荐体系,以晋升新用户对APP的好感度,促成留存。 在老客户精细化经营场景中,MobTech袤博科技提供了数据分析模型,如事件剖析、漏斗剖析、SQL模板剖析、散失剖析和存量剖析等。这些模型让APP经营人员可能通过可视化剖析看板便捷、灵便地搭建,疾速剖析外围指标状况,发现和定位问题。相较于以前手动拉取数据的形式,MobTech袤博科技的可视化统计分析能力使得APP经营人员可能自助式地对用户旅程中的各个经营指标进行剖析,大幅晋升存量用户的精细化经营效率。 在缄默用户促活和散失用户挽留场景中,MobTech袤博科技可能通过标签、规定和模型智能预测高潜缄默及散失用户,使APP在用户趋于缄默和散失前,有策略地进行定向促活和挽留,从而晋升用户活跃度,缩小用户散失。 此外,MobTech袤博科技还以本身的数智能力为撑持,帮忙APP创立"高潜付费用户"标签,搭建"预测模型",以助力APP高效辨认高价值用户群体,并更无效地疏导用户进行付费转化,实现商业增长指标。

September 26, 2023 · 1 min · jiezi

关于大数据:线下Meetup在数智化转型背景下火山引擎VeDI的大数据技术揭秘

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群近日,联结火山引擎开发者社区,火山引擎数智平台(VeDI)《数智化转型背景下的火山引擎大数据技术揭秘》主题Meetup暨超话数据特地场正式在深圳举办,邀请到了Datasail、DataLeap、 ByteHouse、EMR、LAS等多条数智平台(VeDI)产品线的专家带来大数据技术干货分享。 现在各个企业面临的是更变幻莫测的市场、更简单的外部架构、更进退失据的现状。在这种现状下,各个企业如何顺利的实现数字化转型? 往年4月上海举办的秋季 FORCE 原动力大会上,火山引擎正式提出了“数据飞轮”的数字化建设模式,取得了业界宽泛关注。火山引擎数据飞轮是企业数智化降级的新范式,基于对字节跳动十余年数据驱动实践经验的提炼,以数据生产为外围驱动力,使企业数据流充沛融入业务流,实现数据资产的业务利用的飞轮效应。其中数据资产轮的理念是在被频繁数据生产的推动下,变得更高质量、更低成本、更快响应的撑持业务利用。 这里波及资产丰盛、品质优化、研发提效三个外围齿轮: 资产丰盛:数据生产推动更丰盛的数据资产交融对立的建设品质优化:数据生产推动数据资产建设治理具备更高的品质研发提效:数据根底建设过程中的老本优化和效率晋升全域数据集成 DataSail是火山引擎数智平台下数据采集和同步引擎,反对全场景异构数据源集成,助力企业数据资产交融对立建设,本次流动上火山引擎DataSail高级研发工程师李延加分享了DataSail CDC数据整库实时入仓入湖方面的实际。 在线数据库数据导入到数仓剖析的链路曾经存在多年,随着近年来实时计算的倒退,业界期待有提早更低、运维更便捷、效率更高的CDC同步通道。李延加在现场介绍了DataSail实现CDC整库实时同步的技术计划和业务实际。 随着数字化转型的推动以及业务数仓建设不断完善,大数据开发体量及复杂性逐渐回升,如何保证数据稳固、正确、继续产出成为数据开发者外围诉求,也成为平台建设面临的挑战之一。 火山引擎DataLeap 产品经理黄虹现场分享了字节跳动基于大数据研发治理套件DataLeap的DataOps实际,论述了DataOps理念在字节的具象以及DataOps麻利标准研发平台。DataOps是数据开发的新范式,通过对数据相干人员、工具和流程的从新组织,突破合作壁垒,构建集开发、治理、经营于一体的自动化数据流水线,一直进步数据产品交付效率与品质,能力实现高质量数字化倒退。 数据根底建设过程中的老本优化和效率晋升是困扰在很多大数据相干企业的难题,本次流动上基于研发提效的角度,来自 ByteHouse、EMR、LAS研发和产品专家从不同技术细节方向给大家带来干货分享。 在线数据库数据导入到数仓剖析的链路曾经存在多年,随着近年来实时计算的倒退,业界期待有提早更低、运维更便捷、效率更高的CDC同步通道。李延加在现场介绍了DataSail实现CDC整库实时同步的技术计划和业务实际。 随着数字化转型的推动以及业务数仓建设不断完善,大数据开发体量及复杂性逐渐回升,如何保证数据稳固、正确、继续产出成为数据开发者外围诉求,也成为平台建设面临的挑战之一。 火山引擎DataLeap 产品经理黄虹现场分享了字节跳动基于大数据研发治理套件DataLeap的DataOps实际,论述了DataOps理念在字节的具象以及DataOps麻利标准研发平台。DataOps是数据开发的新范式,通过对数据相干人员、工具和流程的从新组织,突破合作壁垒,构建集开发、治理、经营于一体的自动化数据流水线,一直进步数据产品交付效率与品质,能力实现高质量数字化倒退。 数据根底建设过程中的老本优化和效率晋升是困扰在很多大数据相干企业的难题,本次流动上基于研发提效的角度,来自 ByteHouse、EMR、LAS研发和产品专家从不同技术细节方向给大家带来干货分享。 火山引擎 ByteHouse 产品经理孔柏林现场分享了基于ByteHouse引擎的增强型数据导入技术实际,作为一款云原生数据仓库ByteHouse基于自研引擎HaUniqueMergeTree,构建加强MaterializedMySQL、HaKafka引擎,实现数据生产-利用一体化,通过案例剖析与总结让与会者了解一体化解决方案的实际及业务价值。 目前大数据量剖析场景下面临着如下外围挑战:HDFS与对象存储之间的语义差别;存算拆散之后带来的较大性能损耗。火山引擎 EMR 研发工程师吴志平从基于Proton的存算拆散角度带来了相干技术实际。云原生开源大数据平台EMR团队针对这些挑战自研了Proton减速引擎,深度优化对象存储读写能力,与Hive/Spark/Trino等计算引擎集成后,在不扭转用户应用习惯的前提条件下,可提供对象存储数据集的通明减速服务。在离线场景下,其性能根本持平存算一体架构。 以后Spark、Presto等引擎原Java执行的性能优化进入瓶颈期,无奈满足业务需要,而基于向量化和编译优化的native引擎,可获两倍性能减速比,升高资源老本。 火山引擎LAS高级研发工程师杨嘉义在现场向大家介绍了火山引擎LAS底层的湖仓一体减速引擎Bolt的架构及在在LAS的利用实际,据理解Bolt曾经在字节跳动外部SparkSQL、Presto大规模上线,减速效果显著,其特色有:面向多场景对立减速、端到端向量化执行。 本次 Meetup 不仅为技术爱好者们提供了一个互动交换的平台,也让大家更深刻地理解了火山引擎数智平台(VeDI)各产品在数智化转型时代背景下,如何更高质量、更低成本、更快响应的撑持业务利用。 期待下一次的 Meetup,让咱们再次相聚,独特探讨技术的魅力。 点击跳转大数据研发治理套件 DataLeap理解更多

September 26, 2023 · 1 min · jiezi

关于大数据:DataWorks-增强分析发布一站式数据查询分析与可视化

8月31日阿里云郑州峰会,阿里云行业解决方案研发部总经理曾震宇在主论坛飞天公布时刻重磅公布DataWorks与DataV-Card单干推出的AI加强剖析产品,一站式实现从数据查问、剖析、可视化、共享的残缺链路,1分钟即可造成数据报告,帮忙互联网、金融、政务等各个行业客户表白数据观点,讲好数据故事。 在以往的数据分析工作流中,从数据仓库取数查问、到数据可视化、数据共享,往往要横跨多个产品,步骤繁琐,产品学习老本高。基于MaxCompute等计算引擎弱小的剖析计算能力,DataWorks可间接针对海量数仓数据进行SQL取数查问,剖析后果同时在DataWorks加强剖析中进行可视化,造成数据「报告」并进行后果共享,能够极大进步了企业数据分析的效率。大会现场,阿里云行业解决方案研发部总经理曾震宇同时演示了DataWorks加强剖析中数据查问、数据卡片、数据报告三个外围性能。在数据查问阶段,DataWorks全新推出大数据公共数据集,提供了MaxCompute/Hologres/EMR等多个计算引擎的SQL剖析样例,新用户能够间接基于公共数据集体验加强剖析能力,运行失去剖析后果。 数据卡片是一个个数据运行后果的可视化资产,DataWorks加强剖析中内置了常见的柱状图、折线图、饼图、词云等组件,用户能够将数据观点间接备注到卡片中,同步保留“图表+观点”。通过分类进行治理和保护,面向业务人员,逐渐构建了企业可了解的活泼的的数据资产。 数据报告由一个个数据卡片组成,多个卡片能够自在调整程序与可视化格调,造成残缺的数据可视化报告,对外分享报告链接能够灵便适配PC、大屏、挪动端的展现。同时,在DataWorks中可进行分享的权限管控。 扫码查看残缺报告《Demo-某电商网站行为剖析报告》 在以上能力根底上,随着大模型在各个行业的利用,DataWorks正在摸索基于大语言模型来更加精确了解用户数据分析需要,进一步升高数据分析应用门槛,晋升剖析效率。不久之后,DataWorks行将推出联合大模型的智能剖析能力,欢送大家继续关注DataWorks产品官网。 如果想试用DataWorks加强剖析与MaxCompute计算能力,点击返回。 点击立刻收费试用云产品 开启云上实际之旅!原文链接 本文为阿里云原创内容,未经容许不得转载。

September 25, 2023 · 1 min · jiezi

关于大数据:火山引擎DataLeap推出两款大模型应用-对话式检索与开发-打破代码语言屏障

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群自上世50年代,以“计算机”作为代表性象征的信息反动开始,社会对于先进生产力的认知便开始逐渐更迭——从信息化(通常认为是把企业中的信息资源与信息技术有机联合,从而进步企业的管理水平和效率)到数字化(普遍认为是以数据分析为外围,利用各种业务数据去反哺和优化业务过程)转变。 企业心愿通过数字化来冲破业务瓶颈,实现转型降级。而这期间,数据作为新的生产因素,其重要性毋庸置疑。 9月19日,2023火山引擎数据驱动科技峰会公布数据产品大语言模型(Large Language Models)利用:DataLeap-找数助手、DataLeap-开发助手和DataWind-剖析助手,为企业提供从数据资产的检索、到数据开发,再到数据利用的全链路AI能力。 上述能力的公布,其目标就是让企业能更便捷地生产数据、利用数据,实现更普惠的数据生产,为数字化提供事实根底。 DataLeap是火山引擎数智平台(VeDI)推出的大数据研发治理套件,外围是帮忙企业疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设。 DataLeap此次降级公布的两款大模型利用能力“DataLeap-找数助手”与“DataLeap-开发助手”,次要聚焦在企业数据资产查问与数据开发运维两大外围场景,通过大模型能力的加持,升高企业数据资产检索和数据开发的准入门槛。 “DataLeap-找数助手”:AI+数据资产查问 晋升数据资产检索效率利用“DataLeap-找数助手”,能够实现多种数据类型及相干业务知识的问答式检索。 从企业数据生产的链路来看,数据资产的检索、治理能够看作是生产的第一环。找到正确的数据资产,继而能力实现数据的生产。 数据的查找和应用自身强依赖业务专业知识的输出。过来传统技术计划下,数据资产检索重依赖数据结构化治理,须要大量的人力保障,且不够灵便。同时,非结构化数据与数据资产的关联缺失,会导致大量业务信息缺失,而以往基于关键词在结构化及非结构化数据中的检索,因为检索链路割裂,会大大降低基于业务场景的数据查找和生产效率。此外,检索提供的是基于关键词的候选答案汇合,须要人为再次筛选确认,不是间接的答案,导致用户很难有良好体验。 与大语言模型(LLM)联合后,资产查问的形式变得更“拟人化”:在与用户对话式的过程中,大语言模型(LLM)能够了解用户实在用意,让搜寻过程更聚焦,节约了人为判断的老本。同时,伴随模型语义了解剖析能力的逐渐晋升,对话式检索相比单纯地用关键词检索的形式,其全链路的检索效率也更高。 在性能上,“DataLeap-找数助手”目前次要提供三类: 找数据,表、数据集、仪表盘等问含意,指标的口径信息、维度枚举值含意等业务征询,业务知识征询,如业务常见术语含意,业务分类等信息 其外围劣势在于: 问答式查问形式,查问效率更高;轻量化接入能力,反对自助接入企业知识库;语料充沛,元数据中心能力欠缺可提供企业级服务能力公布后,“DataLeap-找数助手”将让企业的数据资产检索变得更快,使得低成本治理、真正的自助式数据生产变得可行。 “DataLeap-开发助手”:AI+数据生产 升高数据开发门槛利用“DataLeap-开发助手”,能够实现通过自然语言形容,主动生成代码;针对已有的代码能够主动实现Bug修复,代码优化、解释与正文等;对话式形式进行文档搜寻、函数应用、代码示例等问题征询。 过来,研发人员必须充沛相熟SQL等数据开发语言,能力高效反对数据分析背地的开发需要。但在事实场景中,数据分析师、依赖数据的业务经营人员都会有大量的数据生产诉求,也就意味着须要大量的业余数据研发人员来反对一些看似根底但仍须要人为染指的开发工作。 “DataLeap-开发助手”底层采纳大语言模型,通过海量的代码和语料训练,能够依据用户的自然语言输出,主动关联包含表Schema在内的元数据信息,生成高质量的数据加工代码,并具备代码的了解、改写以及畛域常识的问答能力。 目前看,“DataLeap-开发助手”次要提供以下3个细分场景的服务: 生成代码:形容须要解决的问题能够主动生成代码,例如:从多张数据表中,通过关联,主动查问、统计指标数据;智能问答:依据你形容的问题进行答疑,例如遗记 Spark 函数怎么写,唤起智能开发助手,询问函数应用形式;修复/优化代码:用户能够间接在SQL 编辑器中通过AI修复性能,理解具体的报错起因,并基于修复倡议“一键实现”选中代码的修复/优化。“DataLeap-开发助手”的外围劣势在于: 适配多场景数据开发,简略场景主动开发,简单场景辅助提效内置于编辑器,灵便唤起,缩小多工具切换老本,交互体验对齐桌面原生 IDE(集成开发环境)模型起源可扩大,反对企业自有模型接入其外围价值是突破了语言障碍,极大水平升高了数据开发的准入门槛,同时让业余数据研发人员更聚焦简单场景的需要,利用开发助手优化代码,进步研发生产效率与代码品质。 以DataLeap为代表的火山引擎多个数据产品拥抱AI,实质是为了升高数据生产门槛,通过数据生产来实现企业数据资产与业务利用的飞轮效应,晋升企业生机。 点击跳转大数据研发治理套件 DataLeap理解更多

September 25, 2023 · 1 min · jiezi

关于大数据:定制化精准推送与用户分组策略数智营销的硬技能

对于挪动利用开发者和运营者而言,推送是保持良好客户互动,实现用户裂变增长的重要形式,在理论推送服务设计中,往往会依据不同的需要和利用场景,针对性的选取特定对象发送特定内容的推送。具体而言,支流的智能数据推送服务商采纳多种用户分组办法,实现最优化目标群体抉择策略,其中包含:播送、注册ID、别名、标签、用户分群五种形式。本文将介绍这些办法,它们在理论APP推送中的利用场景,并比拟它们之间的不同之处。 1、播送播送是一种简略而宽泛应用的推送办法,它将音讯发送给所有已装置利用的用户。这种办法实用于重要的布告、全局更新或流动告诉。例如,一个社交媒体利用能够应用播送来告诉用户对于利用的重大更新。但理论使用中很少有既能笼罩整体APP用户趣味和注意力,又不会造成过多打搅的推送,同时过于频繁的全局推送会引发用户恶感,起到大失所望的成果,因而理论中较少使用。 长处: 实用于全局性音讯,确保所有用户都能收到。简单明了,不须要额定的分组或标签。毛病:不具备个性化,可能会打搅一些用户。不适用于特定趣味或行为的指标推送。2、注册ID注册ID是惟一标识每个利用实例的标识符,通常与设施相关联。通过应用注册ID,开发者能够将音讯发送到特定设施,而不思考用户的属性或行为。这在须要向单个设施发送音讯时很有用,例如明码重置告诉。 长处: 能够间接与设施通信,实用于设施相干的告诉。实用于用户无关的音讯。毛病:不反对准确的用户定制,因为它不关注用户自身。须要治理设施标识符。3、别名别名是与用户相关联的自定义标识符,能够是用户的用户名、电子邮件地址或其余个人信息。别名容许开发者将音讯发送给特定用户,而不用思考设施。这在须要与特定用户进行一对一交换时十分有用,如个性化揭示或客户反对。 长处: 容许与特定用户进行一对一通信,反对个性化推送。用户敌对,易于治理。毛病:须要确保别名的唯一性。不适用于群发或大规模推送。4、标签标签是用于形容用户属性或行为的标记,能够依据用户的趣味、流动或属性来定义。开发者能够将用户分组到不同的标签中,以便将相干内容发送给特定用户群体。例如,一个电子商务利用能够应用标签将用户分为“折扣爱好者”和“新产品关注者”。 长处: 反对将用户划分到不同的目标群体,进行个性化推送。灵便,容许依据用户的属性和行为动静治理标签。毛病:须要定期更新和保护标签。标签可能重叠,不适用于高度特定的定制。5、用户分群用户分群是一种更宽泛的用户组织形式,它将用户依据共享的特色或属性聚合在一起。这些特色能够包含标签、注册工夫、沉闷水平等。用户分群通常用于发送统一的音讯或策略给一组类似的用户,如发送激励流动给沉闷用户群体。长处: 能够更宽泛地影响一组类似的用户,提高效率。实用于发送一致性音讯或策略。毛病:不如标签灵便,不能准确地划分用户。须要保护多个分群。总而言之,以上五种用户分组办法的利用场景和外围差别如下: 播送实用于全局性告诉,但不具备个性化。注册ID实用于设施相干告诉,但不思考用户属性。别名实用于一对一通信,反对个性化,但不适用于群发。标签反对个性化,容许动静治理,但可能须要更多保护。用户分群实用于影响一组类似用户,效率高,但不如标签准确。综上所述,不同的用户分组办法在APP推送中有各自的利用场景和优缺点。而Mobpush对以上五种用户分组形式均可能予以反对,从而帮忙开发者应依据具体需要和策略抉择适合的办法或组合多种办法,以实现更无效的用户互动和个性化体验。

September 23, 2023 · 1 min · jiezi

关于大数据:个性化精准推送服务Mobpush引领用户深度参与度的新纪元

在当今这个突飞猛进的世界,用户群体的兴趣爱好和生产偏向出现多元化、宽畛域、一直细分的特点,此时传统的广而告之式的信息推送和宣传往往无奈获得现实成果,这是因为用户的需要和趣味各不相同,“千人一面”的音讯无奈实用于所有用户,此时定制化推送服务对进步用户参与度、留存率和用户满意度至关重要。 Mobpush是国内行业头部大数据服务商Mobtech旗下一款业余的推送服务工具,基于对用户地理位置、设施信息、生产偏好等各个维度的信息进行剖析,智能化筛选并推送最可能被用户承受的推送内容,从而实现精准、定制化的推送服务。而这就离不开用户标签、分组测试、灵便触发策略的深刻联合。 1、用户画像剖析与标签化:实现用户精准划分和标签化依赖于两个要害路径:即利用内操作数据和用户属性信息。用户属性信息包含用户的地理位置、设施信息以及其余相干属性。Mobpush基于上述信息,为APP利用实现定制化推送提供了更多的决策依据,使得推送音讯可能更好地适应用户的理论情境。例如,泛滥“天气”服务须要晓得用户的地理位置,从而依据用户所在地天气情况和用户是否处于出行状态,推送及时精确的天气预报服务。此外,用户的设施信息,包含用户设施机型、操作系统、零碎语言来决定推送如何抉择适合的厂商通道,以及应用什么语言发送推送,此外,App 版本、App获取渠道、App活跃度等也为APP开发者制订智能化推送策略提供了必不可少的根据和参考。 2、A/B 测试Mobpush智能推送服务通常也反对A/B测试以用于优化和进步音讯推送的成果。A/B测试通过随机将用户分为两个或多个不同的组,每组接管不同的音讯内容或策略,而后剖析用户响应数据,以确定哪个组的推送形式最无效。从而筛选出最为适合的推送内容。 3、灵便触发策略:除了推送群体和推送内容以外,何时何地推送也须要被认真思考。例如中午将推送发送给劳动的用户,或在中国的用户推送美国的实时新闻,都会引发用户恶感,MobPush通过反对定时推送、亮屏推送、触发推送等多种门路,在适合的机会将推送发送给用户。其中触发式推送是基于用户的实时行为触发的,例如,当用户实现了一笔购物交易或达到了某个游戏成就时,能够触发相应的推送音讯,或只有用户进入某个商场的天文围栏内,才会收到该商场的折扣等信息推送。而定时推送则能够依据用户的时区和沉闷工夫来发送音讯,以确保音讯在用户最有可能查看的时候达到,实现寰球用户同步笼罩。 通过用户标签、分组测试、灵便触发策略相结合,Mobpush正帮忙越来越多的APP开发者实现向不同的用户群体发送个性化的音讯,最终进步用户参与度和满意度,从而实现用户裂变增长。

September 23, 2023 · 1 min · jiezi

关于大数据:推送翻车名场面Mobpush的推送修改撤回帮你避免翻车

推送对APP而言在放弃客户分割、传播即时信息、吸引用户参加等方面施展着极为重要的作用,然而一旦推送内容或模式呈现问题,就很可能大失所望的引发用户恶感,导致用户卸载甚至转向成为竞品用户。而一旦推送呈现重大的“翻车事变”,则须要付出代价昂扬的解救措施和公关老本。  对于某些庄重、正式的推送内容因为文案谬误可能会造成歧义和误会,例如电商app推送的商品价格,以及社媒类app推送的时政新闻等,此类场景下不合时宜的谬误推送往往会造成极为顽劣的影响。  2019年8月12日,腾讯视频App推送的一条头条音讯为“山东省应急厅音讯:台风利奇马已致全省人死亡,7人失踪”,霎时被顶上热搜,只管时候腾讯视频紧急致歉,但依然对品牌造成了重大的负面影响。  此外,局部利用开发者在设置推送内容时,可能因为将预发(即预生产环境)和线上(正式生产环境)的环境配置为同一套,导致测试和开发不受隔离,将测试文案谬误的发送给整体用户,对用户造成不必要的惊动和纳闷,产生挥之不去的负面影响。  2018年6月5日上午,36氪APP弹窗因为测试人员失误,间断推送“何文辉,是二笔”等音讯。网友纷纷对事件主人公调侃,微博话题“何文辉C位出道”一度冲上热搜榜,预先36氪紧急公布致歉信,并颁布考察起因为“内部供应商呈现问题“,这不仅阐明一个牢靠稳固的第三方推送服务商是如许重要,同时也阐明对谬误推送内容的及时修改和撤回是也该当是每一个推送服务商的应有之义。    MobPush作为国内出名的挪动推送畛域的破局者,长期以来反对利用开发者对推送内容进行撤回和批改,对于因测试失误产生的推送,当通过MobPush通道下发的音讯达到终端用户后,发现了错发或者误发等状况,该音讯仍可被撤回,而用户端也将不再展现撤回的信息,该性能可能无效升高操作失误带来的经营危险。对于要害文案和内容的失误,能够对推送文案再次编辑,最大水平及时挽回推送失误造成的损失。

September 22, 2023 · 1 min · jiezi

关于大数据:APP开发者的得力助手Mobpush六大功能助力实现精准推动服务

在挪动利用的竞争强烈市场中,无效的音讯推送服务是与用户建立联系、提供即时信息的要害。MobPush作为当先的音讯推送服务提供商,在一直开辟欠缺已有推送服务和性能的同时,正一直挖掘创新性的性能和更加智能化的推送策略,从而为利用开发者坚固客情关系、唤醒沉睡用户、实现用户裂变、带来价值增值发明了有限可能。 1. A/B测试:准确触达,晋升用户参与度MobPush的A/B测试性能容许利用开发者在指标用户群体中进行准确测试。通过随机分组和不同素材的触达,能够轻松测试素材点击率,以在正式推送时找到最优的触达成果。这意味着APP开发者能够更精准地满足用户的需要,进步用户参与度和留存率。 2. 用户行为剖析:数据驱动的决策MobPush基于大数据分析,提供了丰盛的用户行为数据统计。挪动利用开发者能够轻松理解用户的沉闷时段、留存率、卸载状况以及告诉权限开关的应用状况。这些数据为利用开发者和经营人员提供了粗浅的洞察,帮忙挪动利用开发者更好地理解用户行为,调整策略,提供更个性化的服务。 3. 智能推送:千人千面的定制化MobPush的智能推送性能反对多种款式的音讯推送。无论挪动利用开发者的利用类型、利用增值模式、指标用户群体如何,MobPush都能满足挪动利用开发者的需要。反对TCP通道和厂商反对,以及全量播送、自定义标签、用户别名、分群等多种推送策略,帮忙挪动利用开发者实现千人千面的推送,进步用户满意度。 4. 全链路统计:数据保障经营决策MobPush提供弱小的推送数据统计性能,笼罩整个推送链路的36个业务系节点。这意味着挪动利用开发者能够精准地追踪音讯的传递过程,理解音讯的达到状况和用户互动状况。此外,MobPush还反对API回调,为经营团队提供了牢靠的数据保障,帮忙他们做出理智的决策。 5. 敏感词过滤:合规推送,用户安心MobPush具备高效的敏感词过滤性能,能够辨认和过滤色情、广告、政治敏感等多类垃圾文字及敏感词。这确保了挪动利用开发者的音讯推送合规,不会触犯法规,同时提供给用户一个安心的应用环境。 6. 寰球推送:连贯寰球用户,无缝触达无论挪动利用开发者的利用指标是国内还是国内市场,MobPush都能满足挪动利用开发者的需要。它反对国内外音讯触达,并领有寰球服务器推送能力。这意味着挪动利用开发者能够轻松地将音讯传播给寰球用户,无缝连贯不同国家和地区的受众。 总之,MobPush不仅提供了弱小的音讯推送性能,还提供了丰盛的数据分析工具,帮忙挪动利用开发者更好地了解用户行为,进步用户互动率,提供卓越的用户体验。不管挪动利用开发者的应用领域是什么,MobPush都能帮忙挪动利用开发者更好的连贯用户,从而在竞争强烈的挪动利用市场中怀才不遇。

September 22, 2023 · 1 min · jiezi

关于大数据:选择MobPush的三大理由

以后越来越多的挪动利用开发者意识到了与用户保持稳定分割的重要性,以后市场上涌现了泛滥第三方推送服务商,如何甄别并择优选用适合的推送工具对挪动利用实现用户裂变增长至关重要。MobPush智能多通道推送服务作为MobTech袤博科技开发的一款高效便捷的音讯推送产品,曾经被宽泛的使用到电商、游戏、新批发、金融等行业。本文将揭秘泛滥客户抉择MobPush的三大理由 1、反对收费应用开发者可享受MobTech提供的收费技术服务,开发者可收费应用推送服务。目前,Mobpush推送服务分为免费版,VIP版和公有云服务,其中免费版反对利用治理数量高达100个,同时推送形式、推送对象、数据统计等方面为开发者提供了多种抉择,依据推送模式的不同,Mobpush收费反对透传和告诉,推送接口同时反对单推和播送,单推每日限额200万次/天,播送反对100次/天。同时Mobpush还能够收费提供推送内容的根底数据,帮忙APP开发者智能决策。Mobpush是市面上可能提供收费应用且能实现推送全功能笼罩的智能推送服务之一。 2、极速高效稳固MobTech袤博科技领有成熟的互联网技术服务教训,因而Mobpush领有较为先进、稳固的技术架构,可能实现推送音讯毫秒级精准触达终端用户,提供的推送服务稳固牢靠,音讯推送速度高达每秒100万条。同时凭借成熟的技术教训,Mobpush实现了推送服务在线达到率99.99%,综合达到率90%,日均耗电量最低5mAh,日均流量70kb,在市场上泛滥第三方推送平台中获得了遥遥领先的问题。同时,Mobpush在泛滥推送服务利用中领有最小的SDK体积,Android SDK 只有463k,iOS Ipa只有0.5M,因而Mobpush领有最简略的接入形式,最快仅需3分钟即可实现SDK的集成测试。 3、数智化推送多利用场景全笼罩推送服务须要在适合的机会将适合的内容推送给适合的用户,并对推送数据实时统计、反馈。Mobpush基于弱小的用户标签治理能力,依据用户生产习惯、浏览偏好等因素预测用户喜爱的推送类型,同时对应的为利用开发者提供多种类型、多种款式、多种文案的推送服务。此外,Mobpush也反对亮屏推送、定时定期推送、音讯重弹等性能,助力推送内容尽可能被用户所留神到。此外,Mobpush反对推送推送的实时数据统计和剖析,实时将推送的达到率、点击率、成交转化率、卸载率等数据指标传播给利用开发者,实现推送音讯的全链路智能剖析。 Mobpush始终基于利用开发者的理论需要,与时俱进放弃利用性能的更新,专一成为推送服务服务商中的佼佼者。

September 22, 2023 · 1 min · jiezi

关于大数据:ELT-in-ByteHouse-实践与展望

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群谈到数据仓库, 肯定离不开应用Extract-Transform-Load (ETL)或 Extract-Load-Transform (ELT)。 将起源不同、格局各异的数据提取到数据仓库中,并进行解决加工。 传统的数据转换过程个别采纳Extract-Transform-Load (ETL)来将业务数据转换为适宜数仓的数据模型,然而,这依赖于独立于数仓外的ETL零碎,因此保护老本较高。当初,以火山引擎ByteHouse为例的云原生数据仓库,凭借其弱小的计算能力、可扩展性,开始全面反对Extract-Load-Transform (ELT)的能力,从而使用户免于保护多套异构零碎。具体而言,用户能够将数据导入后,通过自定义的SQL语句,在ByteHouse外部进行数据转换,而无需依赖独立的ETL零碎及资源。 火山引擎ByteHouse是一款基于开源ClickHouse推出的云原生数据仓库,本篇文章将介绍ByteHouse团队如何在ClickHouse的根底上,构建并优化ELT能力,具体包含四局部:ByteHouse在字节的利用、ByteHouse团队做ELT的初衷、ELT in ByteHouse实现计划、将来布局。 ByteHouse在字节的利用对于ByteHouseByteHouse的倒退从2017年开始,字节外部的整体数据量一直上涨,为了撑持实时剖析的业务,字节外部开始了对各种数据库的选型。通过屡次试验,在实时剖析版块,字节外部决定开始试水ClickHouse。 2018年到2019年,字节外部的ClickHouse业务从繁多业务,逐渐倒退到了多个不同业务,实用到更多的场景,包含BI 剖析、A/B测试、模型预估等。 在上述这些业务场景的一直实际之下,研发团队基于原生ClickHouse做了大量的优化,同时又开发了十分多的个性。 2020年, ByteHouse正式在字节跳动外部立项,2021年通过火山引擎对外服务。 截止2022年3月,ByteHouse在字节外部总节点数达到18000个,而繁多集群的最大规模是2400个节点。 ByteHouse产品在火山引擎官网的产品页中,咱们能够搜到ByteHouse产品(如下图): ByteHouse产品能够分为两个状态: 企业版:PaaS模式、全托管、租户专属资源。数仓版:SaaS模式,在这个模式中,使用者能够免运维。用户通过控制台建表、导数据以及应用查问性能。在数据量较小、应用较为简单的状况下,用户能够先试用企业版本,如果之后集群规模变大、运维压力较大,亦或是扩大能力要求变高,那么就能够转用到纯算拆散、运维能力更强的CDW上来,也就是咱们刚刚提及的数仓版。 利用场景数据洞察 数据洞察是反对千亿级别数据自助剖析的一站式数据分析及合作平台,包含数据导入以及整合查问剖析,最终以数据门户、数字大屏、治理驾驶舱的可视化状态出现给业务用户,为一个比拟典型的场景。 增长剖析 用户行为剖析,即多场景决策的数据分析平台。而在增长剖析当中,分为了以下三个内容: 数据采集:采集用户行为、经营剖析以及平台的数据,全埋点与可视化圈选,广告及其他触点数据接入。数据分析: 行为剖析:包含一个行为的单点事件、路径分析以及热图等用户剖析:对用户的客户群体、用户画像以及用户的具体查问等内容分析:包含抖音视频、电商商品等智能利用:对于一些异样的检测与诊断、资源位归因以及推送经营与广告策略的利用。一站式指标剖析平台 以懂车帝为例,懂车帝次要给用户提供实在、业余汽车的内容分享和高效的选车服务,同时基于营销需要,他们会依据用户增长的模型以及销售方法论,收集用户在端内的操作行为,进行后盾的查问剖析。 而这种查问剖析底层对接了ByteHouse的大数据引擎,最初实现秒级甚至是亚秒级剖析的决策。整个过程包含智能诊断、智能布局以及策略到投放成果评估闭环,最终实现智能营销和精细化经营。 ETL场景ELT与ETL的区别ETL是用来形容将材料从起源端通过抽取、转置、加载至目标端(数据仓库)的过程。Transform通常形容在数据仓库中的前置数据加工过程。ELT专一于将最小解决的数据加载到数据仓库中,而把大部分的转换操作留给分析阶段。相比起ETL,它不须要过多的数据建模,而给剖析者提供更灵便的选项。ELT曾经成为当今大数据的解决常态,它对数据仓库也提出了很多新的要求。上面表述上会有一些两个词语混用的场景,大家不用过分关注区别。 典型场景 一站式报表 传统大数据解决的计划有两大难点:慢和难。别离体现在传统大数据计划在及时性上达不到要求以及传统数仓ETL对人员要求高、定位难和链路简单。 然而ByteHouse能够轻松的解决上述问题:将hive数据间接导入到ByteHouse,造成大宽表,后续所有解决都在ByteHouse进行。 现有挑战资源重复 典型的数据链路如下:咱们将行为数据、日志、点击流等通过MQ/Kafka/Flink将其接入存储系统当中,存储系统又可分为域内的HDFS和云上的OSS&S3这种近程贮存零碎,而后进行一系列的数仓的ETL操作,提供给OLAP零碎实现剖析查问。 但有些业务须要从上述的存储中做一个分支,因而会在数据分析的某一阶段,从整体链路中将数据导出,做一些不同于主链路的ETL操作,会呈现两份数据存储。其次在这过程中也会呈现两套不同的ETL逻辑。 当数据质变大,计算冗余以及存储冗余所带来的老本压力也会愈发变大,同时,存储空间的收缩也会让弹性扩容变得不便当。 简单场景从OLAP场景扩大进来,随着数据量的增长和业务复杂度的晋升,ClickHouse慢慢不能满足要求,体现在以下几点: 业务变简单后,单纯大宽表不能满足业务需要。数据量逐步增多,进步性能的同时,须要进行一些数仓转换操作在ByteHouse下来做简单查问或ELT工作,能够扩大ClickHouse的能力,加强它的可用性、稳定性以及性能,同时还反对不同类型的混合负载。 业界解决思路在业界中,为了解决以上问题,有以下几类流派: 数据预计算流派:如Kylin等。如果Hadoop零碎中出报表较慢或聚合能力较差,能够去做一个数据的预计算,提前将配的指标的cube或一些视图算好。理论SQL查问时,能够间接用外面的cube或视图做替换,之后间接返回。流批一体 派:如Flink、Risingwave。在数据流进时,针对一些须要出报表或者须要做大屏的数据间接内存中做聚合。聚合实现后,将后果写入HBase或MySQL中再去取数据,将数据取出后作展现。Flink还会去间接裸露中间状态的接口,即queryable state,让用户更好的应用状态数据。然而最初还会与批计算的后果实现对数,如果不统一,须要进行回查操作,整个过程考验运维/开发同学的功力。湖仓 一体&HxxP:将数据湖与数据仓库联合起来。ELT in ByteHouse整体流程 ELT工作对系统的要求: 整体易扩大:导入和转换通常须要大量的资源,零碎须要通过程度扩大的形式来满足数据量的快速增长。可靠性和容错能力:大量的job能有序调度;呈现task偶尔失败(OOM)、container失败时,可能拉起重试;能解决肯定的数据歪斜效率&性能:无效利用多核多机并发能力;数据疾速导入;内存应用无效(内存治理);CPU优化(向量化、codegen)生态& 可观测性:可对接多种工具;工作状态感知;工作进度感知;失败日志查问;有肯定可视化能力ByteHouse针对ELT工作的要求,以及以后场景遇到的艰难,做了如下个性和改良。 存储服务化 计划: ETL后先贮存为Parquet通过存储服务化对外提供查问服务Parque转Part文件删掉Parquet文件对立通过Part提供服务 val df = spark.read.format("CnchPart").options(Map("table" -> "cnch_db.c1")).load()val spark = SparkSession.builder() .appName("CNCH-Reader") .config("spark.sql.extensions", "CnchAutoConvertExtension") .enableHiveSupport() .getOrCreate() val df = spark.sql("select * from cnch_db.c1")收益: ...

September 21, 2023 · 1 min · jiezi

关于大数据:Mobpush上线跨时区推送功能助力中国开发者应用出海

近年来随着国内挪动利用存量市场饱和,国内挪动利用厂商转向”挪动出海“,把握国内市场中存在结构性倒退机会,晋升中国品牌挪动利用的知名度和影响力。依据公开材料显示,中国利用开发者中有79.1%打算出海,其中43%的开发者曾经将本人的利用推广至海内。然而,因为海内用户和利用开发者处在不同时区,如何抉择适合的工夫发送推送和告诉成为困扰着利用开发者的难题。  近日,MobPush智能音讯推送服务全新上线了寰球多时区推送解决方案。这一解决方案帮忙APP运营者一键生成、发送实用于寰球不同时区用户的推送内容,助力开发者全面、高效的服务和唤醒位于不同时区的利用和终端用户。此外,MobPush还反对勾销推送和音讯撤回,以防止对其余时区的用户产生不必要的打搅,从而使得音讯推送变得更加智能化和更具灵活性。   在对推送内容进行设置时,能够对发送工夫抉择“立刻发送”和“定时发送”,其中定时发送反对挪动利用开发者手动抉择对方接管到推送的工夫。此时利用开发者能够在mobpush上同时看到开发者所在所在时区工夫和收到推送的用户所在时区工夫,从而防止因为时区换算而导致失误。 此时依据推送内容和目标的不同,在推送工夫抉择上赋予了利用开发者肯定的自主权。例如,对于须要寰球同一时刻发送的推送和告诉音讯,例如某些商品、游戏和服务的寰球同步限量发售预约流动,此时为了保障流动机会对于各个时区的参与者都是偏心的,就必须在同一时间发送抢购链接,而此时mobpush可能帮忙app开发者抉择最佳公布工夫,以尽可能全面笼罩次要市场用户。此外,对于某些时效性不强的推送音讯,仅仅是为了唤醒用户,此时则须要抉择用户违心看到推送的最佳时机,此时挪动利用开发者能够抉择在各个时区的白天早8-9点,中午12-13点,早晨19-22点这些非工作时间段公布推送,吸引用户点击。而领有mobpush的跨时区推送服务的反对,对于开发者而言都能轻松做到。此外,如果推送的内容失去时效性,或者呈现内容上的谬误,开发者也能够对推送进行近程撤回或批改,防止造成不必要的损失。  这一智能多时区推送解决方案的引入,显著进步了APP运营者与寰球用户之间的沟通效率,在加重了利用开发者和经营老本和精力的同时,优化了所处不同时区终端用户的体验。Mobpush通过一直的性能迭代,无力反对了挪动利用厂商全球化策略的无缝推动,始终充当中国移动利用开发者出海松软的助力者。

September 21, 2023 · 1 min · jiezi

关于大数据:企业诊断屋二手车交易平台-APP-如何用-AB-测试赋能业务

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群2023年汽车行业新车市场低靡,由新车提价引发的车辆价格稳定很快传导到二手车市场,二手车的交易也受到了冲击,收车验车更加审慎,诸多二手交易平台想要保障平台的交易率也变得竞争强烈。二手车交易平台须要吸引各方平台上交易,既要有卖家又要有买家,各方的体验在平台上均须要保障良好,能力顺利完成交易,因而想要优化平台的流程以及各类性能成为十分的关键点。 本期火山引擎AB测试企业诊断屋,将分析一个汽车二手交易平台,在开发了本人的APP之后如何一直优化满足消费者需要的企业案例,看二手车交易平台如何利用AB试验优化产品满足个性化需要、晋升成单转化。企业诊断屋是由火山引擎Datatester测试推出的AB测试行业科普系列内容。千行百业用AB,每个行业、每个职能、业务的每一环节,都有多种AB试验的利用场景;数据能够帮忙企业优化业务效率,迷信的AB试验能够帮忙企业晋升效益。 该二手车交易平台在业务倒退中遇到了两个瓶颈问题:已注册却沉睡的用户过多,用户留存率不够现实,平台内二手车交易转化流程中用户终止率过高。 针对上述痛点,火山引擎AB测试对该二手车交易平台业务的3大场景发展剖析,定位到该平台营销不到位、用户体验不佳以及会员转化率低的问题;而后通过多组AB试验的设计,帮忙企业优化了包含投放素材匹配、用户权利减少以及UI排布和交易链路的优化等场景,帮忙企业实现了平台的继续良好经营。 AB测试优化经营策略吸引用户是第一步,只有让用户来到平台,才有下一步的留存与转化。该二手车交易平台有很大一批注册后不沉闷的“沉睡”用户,通过经营伎俩让他们沉闷起来,是企业要做的第一步。在这个环节中,有几个场景能够通过AB测试大幅晋升经营效率。 广告试验推动新用户进量: 广告投放是付费获取新用户的最重要伎俩之一,无论是面对车主还是购车者,DataTester的广告试验能够清晰看到在多个投放素材、落地页、人群包、估算等设置条件下,到底哪个投放成果更好,从而实现在同策略同素材的试验环境下产出更迷信的成果差别,论证后果。因为不同地区的消费水平不同,对汽车的品牌的抉择偏向也不同,该二手车交易平台能够通过广告试验,针对不同区域的人进行不同的广告素材投放,晋升在不同地区的新用户转化。 可视化试验 利用: 一般来说少数二手车交易平台在产品研发投入上绝对缓和,如果有节约研发老本便晋升流动成果或推广成果的工具,收益会十分可观。火山引擎DataTester 提供的可视化试验性能,无需研发和设计人员染指即可随时开启试验,非开发人员能够在可视化编辑器中对网站进行拖拽式编辑,也可随时更换文案并开启AB测试。该性能反对在APP内嵌H5、流动落地页中疾速进行试验,选取最优转化成果的计划。 推送数值策略优化试验和推送文案优化试验: 该二手交易平台能够依据用户历史交易记录的多少,针对不同粘性的用户投放不同的优惠策略,进行惯性造就;同时能够使用短信、APP push、产品内弹窗等渠道设计人群宫格试验,进行优惠推送音讯设置。 分享 裂变 试验: 在减速产品分享裂变上,该平台也能够通过AB试验测试不同分享策略,如A计划是“减少用户权利以进步分享转化”,B计划是“调整页面布局以晋升分享转化”,能够通过试验选出裂变后果最优计划。 AB测试优化用户体验当用户被胜利吸引进入平台,他们的留存很大水平上受平台应用体验影响。该二手车交易平台在登录页面和首页icon方面有优化空间。 晋升登录转化: 在推动用户在平台交易,如果不能保障登录率,那么后续的交易更无从谈起,因而登录率的晋升十分要害。AB试验能够帮忙产品测试进去,哪些环节的减少或缩小,能够让用户更加顺滑地登录产品要,如能够在支付新用户处分时提醒用户必须登录,能够在用户看到感兴趣的商品时,点击查看详情时提醒用户登录。 首页icon举荐算法优化: 无论是车型、车品牌、还是价位区间,不同用户可能关注点略有差别,该二手交易平台通过火山引擎AB测试进行试验,依据试验成果逐渐减少流量,小步迭代,最终凋谢全流量长期算法优化。能够一直优化首页举荐功能区展现的入口地位,实现收益最大化。 AB测试减速商业化过程会员转化试验: 该二手交易平台在推广降级会员服务时发现,用户在会员中心无奈理解到不同等级的会员权利是怎么的,会员降级带来的益处没有体现,因而没有能源降级会员。企业能够尝试减少疏导策略并利用AB测试进行试验,比照不同的会员降级疏导策略对于转化率的影响,选出更优计划,减速平台商业化过程。 火山引擎DataTester源自字节跳动长期积淀,作为助力企业科学决策的AB测试平台,DataTester目前服务了包含美的、失去、凯叔讲故事等在内的上百家企业,为业务的用户增长、转化、产品迭代、经营流动等各个环节提供迷信的决策依据,将成熟的“数据驱动增长”教训赋能给各行业。 点击跳转火山引擎A/B测试理解更多

September 21, 2023 · 1 min · jiezi

关于大数据:火山引擎AB测试在消费行业的案例实践

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群近日,火山引擎数智平台举办了“走进火山-全链路增长:数据飞轮转动生产新生力”的流动,其中火山引擎数智平台DataTester产品负责人分享了火山引擎AB测试(DataTester)在生产行业的利用实际,并公布了产品近期降级的全新性能——MAB智能调优试验。 在过来,一个产品新性能的成果评估往往会依据性能上线前后的数据比照得出。这种形式其实存在很多缺点,比方,在实践中很多影响因素并未被剔除,导致数据不谨严、不可信,从而评估后果不精确。A/B测试则是通过迷信设计的随机抽样试验,齐全剔除其余因素,从而失去一个更加准确的论断,被称为成果评估的金规范。 目前,A/B试验曾经成为很多企业进行业务决策前的重要一环。其外围价值是帮忙企业在业务决策时更正当的归因以及更加迷信的决策。在整个过程中,如果每次决策都能够给业务带来正向收益,那么随着复利效应,企业是可能实现稳定增长的。 在字节,A/B试验平台是融入业务的基础设施,也是长期利用的增长决策利器。目前,字节已将外部的A/B试验平台通过火山引擎对外,取名DataTester。DataTester反对在试验及评估门路上的全链路智能化能力,为企业用户提供了一站式、场景化的智能调优平台。与业内其余产品不同的是,DataTeter分外留神在业务上的实际利用,提供了很多与业务场景深度交融的试验评估模板。 A/B试验晋升企业多触点营销效率在生产行业,A/B测试最集中的利用场景是多触点营销和私域经营。在多触点营销方面,企业能够通过A/B测试做广告投放的成果评估,包含成果广告和品牌广告;也能够通过A/B试验,做新品公布时的策略测试。 火山引擎DataTester能够通过一系列的场景试验,再加上场景模板和凋谢集成的能力,来为企业提供深度嵌入企业业务平台的一站式解决方案。 火山引擎DataTester提供了广告的根底投放和监测链路,并汇总成为广告场景的试验能力,还能和VeCDP等产品数据进行买通。在这样的数据关联实现后,经营人员在营销投放的任何阶段,都能够实现一站式人群圈选、内容策略选型以及一站式创立营销素材。投放过程中也能够疾速开启试验,从而实现了迷信的评估的同时,又实现了整体提效。 广告素材拆分比照试验。广告投放能够通过素材的拆分比照试验和人群的拆分比照试验,疾速判断哪一类素材的调性更贴合产品本次推广的卖点,同时剖析以及哪一类人群对哪一类素材更加敏感。品牌增效度量试验。将投广告和不投广告的人群,构建成虚构试验,通过试验比照的数据,再联合通过问卷等一系列的伎俩回收相似于品牌记忆度、举荐水平主观的数据量化,剖析投放广告之后,是否有给品牌带来增效。如此判断广告是否值得持续投入。营销落地页试验。联合达人共创的概念测试和A/B测试,针对营销素材、投放人群和关注本次新品,内部的包装特点和内核的关怀点进行测试。同时对概念自身的营销成果也进行A/B测试。 除此之外,还能够联合渠道,线下渠道能够把投放的新品和不投放的新品这两类渠道数据回收,并且通过一系列统计的办法,虚构建设一个试验。通过试验数据的比照,能够失去后链路营销和理论销售的转化数据到,评估公布新品对整体销售有没有正向影响,如果有,就能够在所有的渠道推出新产品。 A/B试验晋升私域转化效率在生产行业的私域经营中,企业每上线一个新玩法,一个新性能,都能够通过线上A/B测试取得反馈,从而通晓所做的改变是不是可能取得正向收益。如试验商品最佳价格、最佳页面摆放地位等,通过策略优化晋升用户触达的效率。 小程序性能布局试验。奢品用户对小程序整体展现的布局进行改变,左边新增混搭的板块和经典搭配的板块,并且在偏下方新增了热门产品板块。在试验后发现效果显著,在减少了这些入口之后,详情的点击率晋升了70%以上,每个模块的加购转化率有了30%的晋升。阐明在首页应该进步调性做的更简洁,且减少曝光度是比拟无效的营销伎俩。注册/登录链路试验。品牌客户在官网登陆的链路作出改变,改变之前流程更加强调注册,改变之后,在优先级上更强调登陆,这种优先级的调换,减少了对用户的主观疏导。举荐算法试验。这类试验是能够长期继续进行,比方购物车底下“猜你喜爱”,增加的算法使整体有了非常明显的晋升。理论应用时,不仅能够对现有算法进行试验,同时也和火山引擎的举荐平台进行互相集成和联动。且在购买火山引擎的智能举荐服务之后,能够间接在火山引擎举荐平台里应用A/B测验。 此外,还能通过A/B测试优化用户触达场景,如企业自有的APP、小程序、官网触点等,均可通过A/B试验晋升用户转化链路的效率。 短信营销试验。比如说企业有一个短信营销的平台,只须要在这个平台外面集成A/B的模块,只有集中在平台上,不扭转原有的工作形式,能够疾速配制文案和落地页,从而测试哪种文案的成果更佳。如果有外部经营治理的后盾,也是同理,能够疾速测试不同的素材带来的成果。App Push推送试验同理短信营销试验。经营资源位试验。针对客群划分圈选人群,再针对不同客群测试其对于不同素材的反馈,如此就能够把A/B测试的论断固化下来,从而实现线上主动的千人多面。这个性能能够和企业自有的经营后盾、第三方采买的营销平台进行买通。从而在公布时实现千人多面差异化的公布。 在分享的最初,火山引擎DataTester公布了最新性能——MAB智能调优试验(Multi-Armed Bandit),这是一种能依据以后试验数据体现,来智能调整试验内不同实验组的流量比例调配的试验类型。 传统A/B试验依赖于统计显著性的经典假设检验,为对照版本和试验版本调配相应的流量,但在试验期间不可能变更每个子版本的流量。因而这类试验须要专门的预留周期(至多7天),必须有足够的样本进入试验,并且在试验开始后不能有任何变动,能力得出显著后果。 而火山引擎DataTester的MAB智能调优试验,克服了传统A/B试验的上述限度,它在回收了数据之后,会实时调整算法主动为下一次调配流量做解决,从而实现高效的决策。这个过程中,既能够节省时间,又不须要在这外面引入人为判断的失误,实现最终成果的最大化。 MAB智能调优试验大幅拓展了AB试验能够利用的场景。在冷启动、流量少、短周期的业务场景中,均可通过MAB试验进行优化,此外在一些特定场景下,如波及到App文案题目、缩略图、视频内容等的A/B试验优化测试,须要在短的窗口期内取得最大点击量时,也可应用MAB智能调优试验。 此次的分享虽短,但从产品概念到具体实际都有所笼罩,流动参与者不仅得以理解了A/B测试及其新性能,还更加深刻获悉了A/B测试的利用笼罩和将来趋势,对未来A/B测试的理论应用也会有更加深刻的挖掘。 点击跳转火山引擎A/B测试理解更多

September 20, 2023 · 1 min · jiezi

关于大数据:数据探索神器火山引擎-DataLeap-Notebook-揭秘

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群背景介绍Notebook 解决的问题局部工作类型(python、spark等)在创立配置阶段,须要进行分步调试;因为摸索查问能力较弱,局部用户只能通过其余平台 or 其余路径进行开发调试,但部署到 Dorado时,又发现行为不统一等问题(运行环境问题),整体体验较差,须要晋升摸索查问模块的能力;目前摸索查问仅反对 SQL,可反对更多语言类型,扩大数据开发伎俩;总体架构介绍火山引擎DataLeap notebook 次要是基于 JupyterHub、notebook、lab、enterprise kernel gateway 等开源我的项目实现,并在这些我的项目的根底上进行深度批改与定制化,以满足 火山引擎DataLeap用户的需要。 根底组件方面,次要是基于 TCE、YARN、MYSQL、TLB、TOS。 外围指标是提供反对大规模用户、稳固的、容易扩大的 Notebook 服务。 零碎总体架构如下图所示,次要包含 Hub、notebook server(nbsvr)、kernel gateway(eg) 等组件。 多用户治理HubJupyterHub 是一个反对 “多用户” notebook 的 Server,通过治理 & 代理多个单用户的 notebook server 实现多用户 notebook。 JupyterHub 服务次要三个组件形成: a Hub (tornado process), which is the heart of JupyterHub;a configurable http proxy (node-http-proxy): 动静路由用户的申请到 Hub 或者 Notebook server;multiple single-user Jupyter notebook servers (Python/IPython/tornado) that are monitored by Spawners;an authentication class that manages how users can access the system;整个零碎架构图如下所示: ...

September 20, 2023 · 5 min · jiezi

关于大数据:直击火山引擎VTech峰会仅需简单登录即可极速体验数据引擎ByteHouse

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群9月19日,火山引擎“数据飞轮·V-Tech数据驱动科技峰会”在上海举办。会上重磅公布数智平台VeDI利用大模型(Large Language Models)能力,并进一步解读了数据飞轮的行业利用与实际。作为外围参展产品之一,火山引擎ByteHouse提供了“开箱即用”的产品能力展现,让观众通过展区的上手实操环节,更直观体验到ByteHouse欠缺的产品能力和易用性。 数据作为新型生产因素,正撑持企业的数智化转型。但企业数字化建设也存在治理老本高、数据产品应用门槛高、数据资产价值不够的问题,其起因在于业务和数据之间没有造成双向良性驱动。 往年4月,火山引擎基于字节跳动十余年数据驱动的实践经验,对外公布企业数智化降级新范式“数据飞轮”,帮忙企业实现数据驱动。在本次峰会中,火山引擎数据产品负责人郭东东介绍到,“数据飞轮是数据中台模式的降级,把过来‘重资产’的理念降级为‘更重生产’”。 具体来说,数据生产是数据飞轮的外围,通过一个又一个具体业务中的数据生产,在下层“业务利用轮”实现决策迷信、行动敏捷,带来业务价值晋升;在上层“数据资产轮”,也通过频繁的数据生产和业务收益,对症下药建设高质量、低成本的数据资产,更好撑持业务利用。作为数据资产轮的撑持产品之一,火山引擎ByteHouse次要在“研发提效”环节助力企业数据飞轮转起来。 面对企业级数据处理需要,火山引擎ByteHouse基于独家自研的高可用引擎及查问优化器,能够为企业提供疾速、稳固、平安的查问服务和数据写入性能。在云原生架构下,火山引擎ByteHouse提供了极致扩大的对立数据分析平台,具备杰出的弹性伸缩和可扩展性,确保资源能够灵便地程度扩大;同时,ByteHouse反对多级资源隔离,为用户资源提供更安心的平安保障。除了高可用的根底能力,火山引擎ByteHouse还从业务角度登程设计了免运维的托管服务,帮忙企业轻松理解业务状态,更加不便地进行故障排查与问题诊断,升高企业运维老本,从而专一于本身业务逻辑的实现。 ByteHouse的产品能力也在峰会展区中凋谢给用户体验。在现场,用户能够基于规范测试集和汽车行业样例数据上手体验ByteHouse的各类性能。 除此之外,火山引擎ByteHouse在一直进行产品迭代和降级,其中ByteHouse 在云数仓版的全新版本中反对了残缺的离线加工能力,使得作为轻载数仓的 ByteHouse能同时兼顾实时数据的查问效率和离线加工工作的稳定性,大大降低运维压力,简化数据开发链路,为用户提供更优越的企业级数仓体验。近期,ByteHouse 还发表与MySQL的正式兼容, 通过对 MySQL 数据类型、函数等提供欠缺的反对,防止用户重复进行查问改写,极大升高迁徙老本。 不仅仅具备弱小的技术能力和易用的产品个性,火山引擎ByteHouse在游戏、广告、气象等畛域曾经积攒丰盛的落地教训。比方,ByteHouse与中国头部游戏公司莉莉丝游戏的单干,帮忙莉莉丝游戏构建广告经营剖析平台外围 OLAP 引擎,解决广告投放和经营剖析中数据查问超时、稳定性差的问题,晋升海量的实时数据能力和计算能力,实现广告投放策略灵便调整,以及基于数据老本和成果剖析的研发、经营、发行等团队的精细化治理。 研发效率是企业在数字化时代的重要竞争力,研发提效力让企业更好施展本身数据资产价值,火山引擎ByteHouse能够帮忙企业实现低成本、高效率地打造优质数据资产,减速写入与剖析减速数据洞察和业务决策,进一步推动企业在数字化转型路线中抢占先机。 点击跳转火山引擎ByteHouse理解更多

September 20, 2023 · 1 min · jiezi

关于大数据:DataWorks-全新发布增强分析数据建模个人版等新能力

阿里云ODPS系列产品以MaxCompute、DataWorks、Hologres为外围,致力于解决用户多元化数据的计算需要问题,实现存储、调度、元数据管理上的一体化架构交融,撑持交通、金融、科研、等多场景数据的高效解决,是目前国内最早自研、利用最为宽泛的一体化大数据平台。 DataWorks新重点能力介绍新产品-DataWorks加强剖析新产品-DataWorks智能数据建模个人版新性能-DataWorks反对EMR on ACK(Spark)新性能-DataWorks数据集成入湖新性能-DataWorks数据治理核心反对EMR新产品新产品 - DataWorks加强剖析DataWorks与DataV-Card单干推出的AI加强剖析产品,一站式实现从数据查问、剖析、可视化、共享的残缺链路。1分钟即可造成数据报告,帮忙互联网、金融、政务等各个行业客户表白数据观点,讲好数据故事。 利用场景:简化程序,降低成本: 以往数据分析工作流中,从数据仓库取数查问、到数据可视化、数据共享,须要要横跨多个产品,以致用户应用步骤繁琐,产品学习老本高。海量数据查问: 基于MaxCompute等计算引擎弱小的剖析计算能力,DataWorks可间接针对海量数仓数据进行SQL取数查问,剖析后果同时在DataWorks加强剖析中进行可视化,造成数据「报告」并进行后果共享,极大进步了企业数据分析的效率。性能个性:数据查问: 基于MaxCompute等具备弱小剖析计算能力计算引擎,反对用户面向海量数仓数据进行SQL取数查问,具备谋求极致简便、轻量化等特点。数据卡片: 卡片内置常见图表,词云等组件。其作为数据运行后果的可视化资产,反对用户将观点备注至数据卡片中,造成专属数据可视化知识库,具备个性化,长久化等特点。数据报告: 由多个数据卡片组成的数据可视化报告能够调整卡片程序,筛选适合的报告主题。报告链接适配不同的展现需要,反对各行业用户表白本身数据观点,讲好数据故事,具备灵活性,多样化等特点。产品demo演示 - DataWorks加强剖析以公共数据集为例,浏览数仓数据进行SQL取数查问——开启DataWorks加强剖析,对于查问数据后果通过图表,主题等调整,保留为可视化的数据卡片——卡片备注本身数据灵感,筛选数据卡片搭建数据报告,造成专属集体知识库——数据报告一键分享。 点击观看<加强剖析>:https://cloud.video.taobao.com/play/u/null/p/1/e/6/t/1/428094...新产品 - DataWorks智能数据建模个人版DataWorks智能数据建模产品,从数仓布局、数据规范、维度建模、数据指标四个方面,以业务视角对业务的数据进行诠释,让数据仓库的建设向规范化,可继续倒退方向演进。产品内置批发电子商务数据仓库行业模型模板,集体能够一键导入模板,DataWorks智能数据建模个人版6个月60元,开明后能够收费获取批发模型模板,并依照文档进行学习操作 。 利用场景:找数用数: 解决业务指标呈现“同名不同义,同义不同名”,业务找数难,找到的数不会不敢用,从而导致业务无奈通过数据决策工作等用户痛点,并且解决数据异样,无奈疾速定位等业务问题。降低成本: 数仓建模启动初期工作量微小,人力老本高;线下建模效率低,短少适合的工具;模型设计与数据研发、数据查找、数据生产工作脱节等痛点针对性解决。性能个性:与企业版性能统一: 数仓分层/维度建模/数据指标等性能与企业版性能均无区别,仅限主账号应用,为用户集体学习建模提供服务。内置收费行业模型模版: 提供收费批发电子商务模型模板,数仓建模实践与实际联合,为用户集体学习数仓建模提供便当,晋升学习效率。与数据开发流程集成: 一站式模型设计与数据开发,多种建模形式,为用户集体疾速实现多引擎模型物化与模型架构图绘制,主动生成ETL代码。产品demo演示 - 基于批发电商模板实操流程登录阿里云官网关上DataWorks智能数据建模寻找行业模型模板——载入模板,查看数仓分层查看数据域,查看数据集市和主题域——在维度建模中能够看到从模板导入的模型。也可抉择创立模型,抑或通过代码模式来批改模型——将模型与数据开发买通,通过模型物化的物理表能够主动生成模型对应的ETL代码。 点击观看<智能集体数据建模>:https://cloud.video.taobao.com/play/u/null/p/1/e/6/t/1/428093...新性能新性能 - DataWorks反对EMR on ACK(Spark)存量已适配EMR on ECS(DataLake/Custom)以及开源 利用场景:集群切换或者双跑能够进行工作的无缝迁徙: 如果用户之前用的是ECS集群,想切换成ACK集群,或者两种集群同时运行,Spark工作都能够平滑的运行在这两种集群之上。 大数据的开发调度、剖析和治理: 只须要开明一个DataWorks,就能够造成这个大数据的全家桶的生态。数据集成模块能够实现数据入户、数据开发和调度、数据分析和治理等等,一应俱全,能够实现须要多个开源组件能力实现的产品性能,来助力企业的数仓团队实现研发的提效和体验的晋升。 性能个性:DataWorks适配EMR on ACK(Spark)具备以下个性 节省成本:依据ACK容器服务弹性能力按需灵便调整计算资源 ,若之前已保有ACK服务撑持在线服务和利用,那么本次就无需为大数据引擎独自购买ACK; EMR Spark集群部署在ACK容器服务中,在创立EMR集群间接抉择曾经有的ACK,实现大数据服务和在线应用程序共享集群资源 ; ACK容器服务自身具备良好弹性扩大能力,无论是程度、定时还是垂直伸缩,都可能通过丰盛的弹性扩容计划来充沛应答计算高峰期,整体达到资源正当利用、节省成本的成果。 简化开发,稳固调度:专一Spark原生开发模式,无需关怀底层集群差别 ; 反对多种调度周期,提供超大规模稳固调度,每日能够撑持千万量级的实力调度,并提供丰盛的工作运维伎俩帮忙用户及时处理工作执行异样,并发送相应监控告警; 基于ECS Spot抢占式实例进行调度适配与优化,本次DataWorks适配Spark集群,依据ACK抢占式实例做了专门的调度优化。 事先查看,预先治理:DataWorks数据治理核心提供丰盛查看项,融入大数据开发流程,并且涵盖研发、存储、计算等多个方面的治理倡议,造成了可量化的衰弱分指标,能够帮忙企业在整个大数据过程中进行继续治理优化。 DataWorks相比开源大数据组件劣势DataWorks作为阿里云一站式开发和治理平台,是一款云上全托管产品,能够即开即用,无需像开源一样通过后期产品部署、环境部署等繁琐的流程。DataWorks相比开源具备以下几点劣势: 数据集成 (DataX / Sqoop) :基于DataX构建离线同步链路基于Flink构建实时同步链路封装多样化数据同步解决方案:提供多样化数据同步解决方案,笼罩整库同步、一次性全量同步、周期性增量同步等场景数据通道丰盛,配置链路简略,网络计划齐备:在各种数据类型之间构建数据同步通道,让数据工具不再简单和繁琐。开发与调度(DolphinScheduler / Airflow):丰盛的原子工作类型 : DataWorks面向各种计算引擎提供多样化的工作类型智能Web IDE + 可视化工作流编排:开发者能够通过可视化拖拽形式疾速构建工作运行工作流,通过智能Web IDE高效编写工作代码细粒度调度打算:对工作配置灵便的调度打算,无论是调度频率、重跑策略、简单场景的依赖关系等等,都提供了十分欠缺和粗疏的性能;全局运维大屏 & 单任务运维详情:工作上线当前,还能够通过运维大屏和运维伎俩来监控和解决运行的状况。智能基线及时捕获生产链路的异样数据品质性能—严格监控管制脏数据净化上游数据治理(Atalas等):全面元数据纳管(技术/业务/操作元数据等)支持系统主动解析/用户自助上报数据血统数据目录增强数据管理/晋升找数效率提供衰弱重量化体系、多维评估治理功效敏感数据无效辨认与爱护等这一系列丰盛产品性能和生态来造成组合拳的成果新性能 - DataWorks数据集成入湖离线及实时同步数据至OSS/Hive 利用场景:运维层面: 解决flink/spark streaming/kafka等运维优化调优,湖文件的治理:compaction, 清理历史文件, 清理过期分区,整个作业的施行性和高吞吐保障,开发/调试/部署/运维全生命周期等等都须要用户治理,运维难度大的痛点。 学习老本: 升高数据库binlog多样性解析须要专业知识储备,工作运维治理,flink、spark、kafka等技术引擎用户学习老本。 性能个性:DataWorks数据集成入湖OSS具备以下个性 MySQL整库同步至Hive: 反对实例模式、全量数据与增量过滤,增量过滤靠增量条件拉取增量,增量条件做出MySQL的VR条件过滤数据,其数据能够设置同步周期,用户也能够依照需要拉取数据。上手简略: 全白屏向导化操作 ,反对用户直观入湖同步配置。元数据主动买通: 与阿里云DLF深度买通交融 ,数据能够在入湖同步时主动注入DLF中,无需用户人为干涉。实时同步: 反对数据实时同步至OSS湖中,实现秒级提早 ,并且反对用户同步过程中进行数据处理。DataWorks入湖OSS能力反对的链路个性 MySQL实时入湖OSS:反对MySQL数据增量实时入湖,秒级提早 反对MySQL历史存量数据离线入湖,能够管制同步速率,防止影响源端业务 反对MySQL实例级别配置工作,同时同步一个实例下多库多表 反对依照正则感知MySQL端的库表变动,将减少的库表主动退出OSS湖端 反对OSS湖端主动建设元数据表 反对对接阿里云DLF,入湖元数据主动导入,实时可查 ...

September 19, 2023 · 1 min · jiezi

关于大数据:穿越人海遇见你精细化运营神器Mobpush是如何实现智能化精准投放的

精准投放的概念由来已久,在这个“内容为王”的信息爆炸时代,曾经不仅仅是用户在单向的凭着本人的爱好筛选推送,同时也是推送运营者在被动的依据推文内容筛选其潜在的受众,对客户在支出、生产习惯、年纪、兴趣爱好的理解越多,就越可能激发用户点击推送的趣味,从而晋升成交转化率,实现推送投放带来的效益最大化。但其中的关键在于精准刻画用户画像,也是精准投放的难点和堵点,而Mobpush就是一款能够畅通堵点,中转用户的智能化推送工具。  1、多维度用户标签赋能精准刻画用户画像“家人们谁懂啊,集美们都在穿的新款潮鞋,速戳”,“百年品牌鞋类年内最低价,快快抢购吧”.....两条格调迥异的推送链接指向同一商品的链接,但对于APP开发者和运营者而言,前者是为了捕捉年老、酷爱潮流、具备肯定经济能力的女性群体的趣味,而后者则次要推送给经济能力较为个别,更加关注产品实用性和性价比的群体。 事实上,这就是差异化推送策略在电商类APP推送中的一个典型利用场景。Mobpush通过实时追踪用户在应用智能设施时的轨迹特色和青睐偏好,联合综合剖析用户所处的天文围栏、性别、年龄、生产能力、生产习惯、偏好品牌等标签信息,对用户画像进行精准刻画,在用户应用设施高峰期,将合乎用户趣味偏好、价格位于用户均匀生产价格区间的产品予以包装推送,实现精准触达,直抵用户。  2、人工智能和AIGC技术助力实现定制化推送内容但即便晓得了泛滥用户的不同喜好,如何分门别类的提供合乎用户喜好的定制化推送内容也是一大难题。对于百万级用户的APP而言,仅仅依附经营人员无奈笼罩波及到各个行业,各个领域的专业知识和行业背景,此外,泛滥不同内容,不同模式的推送仅仅依附人力可能难以在长期保持稳定继续高质量的输入。此时,人工智能内容生成技术(AIGC)这一新兴技术的诞生将极大的升高经营人员构思、撰写推送内容时所破费的工夫和精力。 MobPush利用自身丰盛的大数据资源和海量精准的用户画像,联合chatGPT为代表的人工智能生成技术,围绕用户趣味和生产偏好,定制化创立个性化的推送音讯,同时还能够依据用户的行为和趣味实时调整内容。这种技术的簇新利用,在节俭了推送经营老本的同时,也为APP开发者提供了一个前所未有的机会,将他们的产品、服务和信息以更具吸引力和关联性的形式传播给指标用户。 借助MobPush,能够帮忙APP开发者实现以更智能、更无效的形式放弃用户新鲜感、晋升用户参与度、晋升用户留存率。置信在将来随着人工智能技术的进一步倒退,Mobpush肯定会为APP推送服务带来更多翻新和冲破。

September 19, 2023 · 1 min · jiezi

关于大数据:基于异常上线场景的实时拦截与问题分发策略

作者 | 彭阳 导读  性能中台负责MEG端研发数据的接入、传输、治理、利用等各个环节。为了应答挪动应用领域中端技术的疾速迭代和线上突增问题的挑战,中台提出了实时拦挡与问题的散发机制,旨在在端上线的不同阶段及时发现并拦挡异样上线,最大水平缩小线上变更对用户体验的不良影响。本文在数据建设的时效性和准确性上进行深刻的探讨,包含:变更上线的染色过程、基于染色ID的性能外围数据指标的监控、线上问题实时散发至相干模块组件和人员等。 全文7719字,预计浏览工夫20分钟。 01 背景1.1 业务背景在疾速倒退的挪动应用领域中,继续的技术迭代是放弃APP竞争力的关键因素。然而,对于规模宏大、用户泛滥的APP利用,每一次的变更上线都存在引入线上问题的危险。APP的各个组件模块相互交织,一旦某处出现异常,往往会像连锁反应一样影响整个零碎的稳定性,导致用户体验的降落。在以往的教训中,即使在开发和测试阶段充沛验证,也难免会有一些问题在实在用户环境中裸露进去。这些问题可能体现为解体、卡顿、性能生效等,重大影响用户的应用体验。在过来,应答这些问题通常是预先进行问题修复,然而这种形式并不能完全避免线上问题对用户体验的不良影响。因而咱们心愿在业务迭代变更上线的过程中,尽可能早的发现和拦挡问题,最大水平的升高问题对用户的影响。因而,性能中台引入了多级拦挡和问题散发的机制,这一机制旨在在变更上线的不同灰度放量阶段,对每次上线或者放量操作进行染色造成惟一染色ID,通过对每个染色ID的外围性能数据指标进行监控,一旦发现异常,多级拦挡机制将会被触发,拦挡本次上线以及后续放量。同时,问题实时散发机制可能间接将问题指向导致该问题产生的模块和组件以及开发和测试人员。从而精确定位问题,并迅速修复,防止问题在更大范畴内扩散。 1.2 技术背景实时UV计算:在解决异样上线的拦挡过程中,数据的实时生产以及数据的时效性的要求特地高,必须在分钟级别内实现。同时,业务方不仅须要取得异样的PV数,同时也须要取得在各个维度下异样影响的用户数(UV)。但实时UV计算不能简略地累加,这波及到同维度间用户交加的解决。例如:A版本和B版本异样影响的用户数别离是100,但整体用户数实际上可能有余200。然而也不能间接存储用户ID,例如通过应用HashSet或者HashMap存储所有的用户ID进行去重,这面对大量用户时,会占用大量的计算节点内存资源。因而,咱们采取一种计算的时效性和准确性较高的数据结构Bitmap来计算实时UV。 Bitmap 的底层数据结构用的是 String 类型的 SDS 数据结构来保留位数组,把每个字节数组的 8 个 bit 位利用起来,每个 bit 位 示意一个元素的二值状态。该数据结构能节约大量的存储,同时在用户群做交加和并集运算的时候也有极大的便当。例如,每个用户ID如果存储在HashSet或者HashMap中,须要占4个字节即32bit,而一个用户在Bitmap中只占一个bit。在做交并集运算时,例如,员工1、员工2都是程序员,员工1应用苹果手机,那么如何查找应用苹果手机的程序员用户? 间接应用位运算,应用苹果手机的程序员用户:(0000000110B & 0000000010B = 0000000010B) 异样反混同:次要用于问题散发阶段。APP厂商在公布利用程序包时,通常会对包进行混同操作,这是为了进步APP利用的安全性和缩小反编译的危险。混同是将源代码中的符号、名称和构造等转换为难以了解的模式,使得反编译后的代码难以还原为原始的源代码,然而APP上报的异样信息也被混同了。反混同操作是将混同后的异样信息还原为可读的模式,使开发人员可能更精确地剖析问题的起因,并迅速采取正确的修复措施。在APP产出利用程序包时,同时也会产生一份用于反混同异样信息的映射文件(密码本),通过映射文件 + 解析算法对混同的异样进行解析,即可失去已读的异样堆栈。 △异样信息反混同过程 1.3 名词解释性能中台:性能中台是APP性能追踪的一站式解决方案平台,为APP提供全面、实时的性能剖析服务与工具链。 挪动线上品质平台: 挪动线上品质平台是挪动端APP发包后,用来查看、剖析包品质数据、进行外围指标监控/报警、变更异样拦挡。 日志中台:指端日志中台,包含端日志全生命周期的能力建设。包含打点SDK / 打点server/ 日志治理平台等外围组件。 Tekes平台:App端研发平台,提供包组件治理等基础设施。 02 零碎设计2.1 整体流程在以往的流程中,针对客户端上线变更,咱们通常应用大盘性能指标来进行监控,以便进行问题定位和止损。然而,在灰度用户数量较少的状况下,线上问题往往无奈在大盘性能指标中产生显著稳定。当业务决定全量上线或扩充灰度用户规模时,问题就可能显现出来了。在问题定位和解决的阶段,咱们过多地依赖人工干预和手动排查,这导致问题定位和解决的工夫较长,并可能降级为事变。因而,在旧流程中,线上问题影响面大小次要取决于灰度用户的规模以及问题排查人员对客户端各个模块和相干人员的理解水平,这是不合理的。因而,零碎设计的关键在于解决两个外围问题:首先,如何在灰度阶段拦挡问题,防止其进一步扩充;其次,一旦线上问题呈现,如何可能迅速进行问题召回与解决。 △线上异样实时拦挡与问题散发整体流程设计图 因而,在新流程中,引入了两个要害模块:"变更拦挡模块"和"问题散发模块"。对于每次平台的上线变更,必须先在变更拦挡模块中进行注册,从而生成一个惟一的上线染色ID。同时,将染色ID下发至本次变更上线的用户客户端。尔后,该数据集的用户日志将携带染色ID进行上报。变更拦挡模块将基于染色ID的粒度进行监控和拦挡,以保障在上线过程中问题的及时发现。同时,问题散发模块建设了问题主动散发机制。当一个上线变更被拦挡或者在线上呈现问题时,该模块将间接将问题指派给波及问题的模块、组件,以及相干的研发和测试人员。帮助业务方疾速精确的定位问题,人工再染指修复。 2.2 异样上线变更拦挡异样上线变更拦挡的外围思路是:为每次上线变更生成独特的染色ID,通过对每个染色ID的性能外围数据进行拦挡与监控。 △异样上线变更拦挡流程设计图 变更拦挡流程的具体步骤如下: ① 变更上线注册: 针对厂内各个配置变更平台,须要在每次上线配置失效之前,将上线信息在染色通用服务进行注册。 ② 获取染色ID: 染色通用服务通过HTTP接口为每次上线注册生成通用的染色ID,并将其返回给上线变更平台。 ③ 下发染色配置: 在圈定的用户群范畴内,上线变更平台将新配置和染色信息同时下发到端上的业务SDK(如AB-SDK)中。 ④ 染色日志上报: 业务SDK会断定染色是否失效,如果失效,则在波及性能外围场景的日志中附加染色ID信息,而后通过UBC-SDK上报。这些日志会通过日志中台实时转发,并写入音讯队列。 ⑤ 实时指标计算: 性能中台会实时订阅音讯队列中的外围性能数据,例如解体、APP启动次数等,而后针对每个染色ID,依据多个维度(如产品线、APP版本、操作系统、地区等)造成性能聚合指标,并将其写入长久存储。 ⑥ 异样拦挡服务: 基于存储中的染色数据,异样拦挡服务通过配置监控项来检测数据是否出现异常。一旦染色数据异样,零碎会触发拦挡措施并收回告警。 ⑦ 异样止损: 在触发拦挡和告警后,零碎会通过关联染色ID和变更上线的关系,拦挡持续放量以及告诉业务方针对本次上线的配置回滚。 针对每次线上配置的变更,都会有一段观察期。这个观察期的长短须要适度,以确保数据的可靠性。过短的观察期会影响数据的置信度,而过长则可能升高研发效率。一般而言,每次变更后须要期待10分钟的观察期,而后再逐渐减少线上流量。因而,变更拦挡模块对数据时效性的要求十分高,要求数据的端到端传输时效在3分钟以内,以确保有足够的数据累积工夫,从而晋升监控指标的可信度。同时,染色ID的数据指标项不仅涵盖了根底的PV指标(如解体次数和APP启动用户数),还扩大至UV级别的指标(如受解体影响的用户数收敛状况和APP用户启动数)。多个指标维度下UV的计算也给数据链路的时效性和准确性带来了挑战。具体的数据流设计如下所示: △变图更拦挡数据流设计 ...

September 19, 2023 · 1 min · jiezi

关于大数据:智能金融决策策略规则引擎在大数据金融行业的实战案例

在金融风控场景中,规定引擎是一个外围风险管理的利器,它事后设定一系列规定设定,用于便捷的评估和解决各种交易、客户行为或其余须要自动化决策、计算、推理判断的状况。 以下是一个具体的示例,阐明规定引擎在金融风控中的应用。 场景形容:假如咱们是一家金融公司,提供企业贷款服务。咱们心愿通过一个系列的规定判断来自动化决定是否批准一笔贷款申请(在线决策)。 规定引擎的应用:1.规定定义和建模:规定1: 资格审查要求规定形容:命中黑名单数据时回绝。条件:客户的黑名单校验通过数据起源:本地黑名单数据与三方黑名单数据规定2: 信用评分要求规定形容:客户的信用评分必须大于等于700分。条件:客户的信用评分 >= 700数据起源:行业内某业余数据供应商规定3: 营收规模要求规定形容:客户的月营收必须大于等于100000元条件:客户的月支出 >= 100000数据起源:通过体系外部数据库,汇总客户的月营收订单数据,加工汇总 规定4: 贷款额度限度规定形容:贷款金额不能超过客户月营业支出的50%。条件:贷款金额 <= 客户的月支出 * 0.5数据起源:用户申请规定5: 历史贷款记录查看规定形容:客户在过来6个月内不能有超过两次的守约记录。条件:客户的守约记录数 <= 22.数据输出和验证:当客户提交贷款申请时,零碎将会主动采集客户互联网大数据信息,包含信用评分、黑名单数据等。这些数据将被传递给规定引擎进行验证。 3.决策输入:依据规定引擎的执行后果,零碎将决定是否批准贷款申请。如果所有规定都满足,贷款申请被批准。如果有任何一个规定未满足,贷款申请被回绝。记录审计和日志:每次规定引擎执行时,零碎会记录执行的后果,以便后续审计和跟踪。 劣势和注意事项:劣势:灵活性:所有的规定配置均采纳可视化拖拽配置,灵便调整便捷上线。自动化:规定引擎能够主动解决大量的申请,进步了工作效率。一致性:规定引擎确保了决策的一致性,不受主管的集体偏好或情感因素影响。疾速响应:规定引擎可能在霎时内做出决策,晋升了客户体验。简略集成:所有决策的应用十分便捷,可间接通过HTTP的形式调用即可。 注意事项:规定的制订须要审慎,过于严格的规定可能会导致潜在的客户散失。规定引擎的保护和更新是必要的,以保障其与市场和公司政策保持一致。在线demo:http://rules.bctools.cn/gitee地址:https://gitee.com/software-minister/jvs-rulesJVS-rules相干介绍jvs-rules(规定引擎)新增性能介绍jvs-rules(规定引擎)API数据源配置阐明(含配置demo视频)Java源码规定引擎:jvs-rules 8月新增性能介绍jvs-rules(规定引擎)决策流如何管制权限?Java源码规定引擎:jvs-rules 2.1.8 新版本性能清单

September 19, 2023 · 1 min · jiezi

关于大数据:如何快速从-ETL-到-ELT火山引擎-ByteHouse-做了这三件事

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群前言当波及到企业剖析场景时,所应用的数据通常源自多样的业务数据,这些数据系统大多采纳以行为主的存储构造,比方领取交易记录、用户购买行为、传感器报警等。 在数仓及剖析畛域,海量数据则次要采按列的形式贮存。因而,将数据从行级转换成列级存储是建设企业数仓的根底能力。传统形式是采纳 Extract-Transform-Load (ETL)来将业务数据转换为适宜数仓的数据模型,然而,这依赖于独立于数仓外的 ETL 零碎,因此保护老本较高。 但随着云计算时代的到来,云数据仓库具备更强扩展性和计算能力,也要求改变传统的 ELT 流程。火山引擎 ByteHouse 是一款基于开源 ClickHouse 推出的云原生数据仓库,为用户提供极速剖析体验,可能撑持实时数据分析和海量数据离线剖析,同时还具备便捷的弹性扩缩容能力,极致剖析性能和丰盛的企业级个性。 凭借其弱小的计算能力,能够全面反对 Extract-Load-Transform (ELT)的能力,从而使用户免于保护多套异构零碎。 具体而言,用户能够将数据导入后,通过自定义的 SQL 语句,在 ByteHouse 外部进行数据转换,而无需依赖独立的 ETL 零碎及资源。这样,用户只须要采纳对立的 SQL 形式来实现数据转换操作。 在本文中,咱们将重点介绍 ByteHouse 遇到的挑战,以及如何通过 3 大能力建设实现齐备的 ELT 能力。 痛点以及挑战咱们先从一个简略的 SSB(start-schema-benchmark)场景登程, 其中蕴含: 1 个事实表: lineorder4 个维度表:customer, part, supplier, dwdate 在 SSB 的查问剖析中,咱们发现大部分的查问都波及到事实表和维表的 join,因而能够通过 Transform 的步骤,将事实表“打平”。 打平所用到的 SQL 如下: insert into ssb_flat select * fromlineorder ljoin customer c on l.lo_custkey = c.c_custkeyjoin part p on l.lo_partkey = p.p_partkeyjoin supplier s on l.lo_suppkey = s.s_suppkeywhere l.lo_orderdate = <bizdate>之后的查问剖析能够通过对ssb_flat 的单表扫描来躲避很多join操作,其性能能有显著晋升。 这个“打平”的过程,就是“Transform”的一种。 ...

September 18, 2023 · 2 min · jiezi

关于大数据:火山引擎-ByteHouse两个关键技术揭秘-OLAP-引擎中的数据导入技术

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群数据导入是掂量 OLAP 引擎性能及易用性的重要规范之一,高效的数据导入能力可能减速数据实时处理和剖析的效率。 作为一款 OLAP 引擎,火山引擎云原生数据仓库 ByteHouse 源于开源 ClickHouse,在字节跳动多年打磨下,提供更丰盛的能力和更强性能,能为用户带来极速剖析体验,撑持实时数据分析和海量离线数据分析,具备便捷的弹性扩缩容能力,极致的剖析性能和丰盛的企业级个性。 随着 ByteHouse 内外部用户规模不断扩大, 越来越多用户对数据导入提出更高的要求,这也为 ByteHouse 的数据导入能力带来了更大的挑战。 从字节跳动外部来看,ByteHouse 次要还是以 Kafka 为实时导入的次要数据源。对于大部分外部用户而言,其数据体量偏大,用户更看重数据导入的性能、服务的稳定性以及导入能力的可扩展性。 在数据延时性方面,用户的需要个别为秒级左右。基于以上场景和需要,ByteHouse 也进行了一系列定制性优化,次要包含两个方面,第一为 MaterializedMySQL 加强;第二个是 HaKafka 引擎。 社区版 ClickHouse 推出了 MaterializedMySQL 数据库引擎,用于将 MySQL 中的表映射到 ClickHouse 中。ClickHouse 服务作为 MySQL 正本,读取 Binlog 并执行 DDL 和 DML 申请,实现了基于 MySQL Binlog 机制的业务数据库实时同步性能。这样不依赖其余数据同步工具,就能将 MySQL 整库数据实时同步到 ClickHouse,从而能基于 ClickHouse 构建实时数据仓库。 而 HaKafka 引擎则是 ByteHouse 推出的一种非凡的表引擎,次要基于 ClickHouse 社区的 Kafka engine 进行了优化。用户能够通过一个 Kafka 生产表、分布式存储表、物化视图表,三元组实现数据生产、数据转换、数据写入性能。 9 月 16 日 14:00,火山引擎开发者社区与超话数据联结举办的线下沙龙,将邀请到火山引擎 ByteHouse 产品专家围绕《基于 ByteHouse 引擎的增强型数据导入技术实际》开展分享,为大家揭秘 MaterializedMySQL 和 HaKafka 的设计原理和技术实现,教你如何更好在 OLAP 引擎中实现高性能、高易用性的数据导入。 ...

September 12, 2023 · 1 min · jiezi

关于大数据:MaxCompute半结构化数据思考与创新

作者: 周宇睿 阿里云高级技术专家 本文将介绍MaxCompute在半结构化数据方面的一些思考与翻新,介绍会围绕上面四点开展: 1.半结构化数据简析 2.传统计划优劣比照 3.MaxCompute半结构化数据解决方案 4.收益剖析 半结构化数据简析首先来介绍一下什么是半结构化数据。 半结构化数据是绝对结构化数据和非结构化数据而言的,所以先来看一下什么是结构化数据和非结构化数据。 结构化数据的概念大家都比拟相熟。传统的关系型数据库是用表的形式对数据进行组织,表的外部定义了字段的数量、类型,以及各种各样字段的属性信息,这些定义自身就蕴含了丰盛的信息。因为在结构化数据的场景中,字段属性被当时严格地定义,所以数据库也好,各种数据引擎、存储引擎都能够通过这些定义取得的信息,有针对性的对数据进行解决。这些解决包含但不限于建设索引,对数据进行排序,对数据进行列存化,也包含向量化执行等等,从而达到一个升高存储老本,晋升拜访效率的目标。通常来说,结构化数据能够达到十分好的数据读写性能,它的存储效率、压缩效率也能够做得十分好,然而它的灵活性会受到很大的限度。在很多的数据库或者数据仓库当中,如果想扭转数据表的构造,通常来说是一个十分高风险的操作,可能会带来很多额定的数据管理老本。 相比之下,非结构化数据自身也是一个很容易了解的概念,咱们日常生活中会接触到的,比如说视频、音频、图片、文章等等,都能够算作是一个比拟典型的非结构化数据。非结构化数据外面很一个很重要的特色就是没有一个清晰的对立的协定对这些数据外部的构造进行束缚,数据自身的内容也没有对立的法则。非结构化数据具备的劣势就是简直是有限的数据灵活性。当然这种有限的灵活性自身也是会有代价的,就是因为没有方法当时对数据自身的构造进行解析,因而很在大部分场景外面,数据引擎没有方法对数据结构进行无效的信息提取,所以一般来说非结构化数据的存储效率和拜访性能都是比拟差的。 说分明了结构化数据和非结构化数据,咱们再回过头来看看什么是半结构化数据,半结构化数据最重要的一个特色就是数据外部一般来说会蕴含数据自身的一个构造信息,咱们会说它是一个自蕴含的数据结构。通过当时的一个约定的协定,咱们能够很容易地对数据结构这个数据进行解析和数据内容的提取。 相比于传统的结构化数据,半结构化数据并没有受到来自内部的、来自数据仓库或者数据库的这种表级别的强束缚。因而一般来说,半结构化数据会更加的灵便,它能够更好地依据具体的用户场景,用户需要进行动静的变动。也正是因为这个特色,通常来说半结构化数据会有多层嵌套的构造,比如说 Json,Xml,都是很典型的半结构化数据。从非结构化数据到半结构化数据,最初再到结构化数据,数据的灵活性是在一直降落的,然而数据的存储效率、拜访性能也在一直地晋升。半结构化数据在某种程度上能够说是兼顾了两种类型的长处,一方面它具备比拟好的灵活性,另外一方面通过协定自身的结构化的束缚,也为高效率的拜访和解析提供了帮忙。 半结构化数据是一种通用的数据传输和存储构造,被宽泛地应用在日志剖析、IoT设施的信息采集、挪动设施的事件上报,以及主动驾驶等多样化的数据场景中。这也体现了半结构化数据的一个很大的特点,就是它的通用性十分好。同时因为半结构化数据自身的灵活性,它们能够在大部分数据场景上面承载和传递丰盛的原始数据的信息。因为其解析协定非常简单,也可能反对咱们疾速地对数据进行解析和拜访。所以一般来说,半结构化数据自身就是一个十分丰盛的数据信息的载体。另一方面,比方Json、Xml,具备十分丰盛和欠缺的数据生态,咱们能够很不便地在各种语言、各种框架、各种平台上面对这些数据进行解析、生产和生产。多平台的通用性也让半结构化数据这种协定成为了事实上的一种数据的通信规范,能够宽泛地承受和应用。从数据仓库解决的角度来说,半结构化数据自身的这种灵活性,也会给上游的业务部门以及两头的数据中台和上游的数据生产决策部门的独立运行,提供一个很好的缓冲。在一个比拟大的公司或者团队中,上游是产生数据的业务部门,两头是负责数据处理保护的数据仓库的数据中台部门,还有上游负责决策和生产的决策部门,通常是独立运行的,有着截然不同的运行模式和指标。半结构化数据以其灵活性和易解析的个性能够很好地帮忙各个部门进行独立的业务演进,防止因为上游部门频繁的业务迭代带来昂扬的跨部门沟通以及数据保护的老本。 传统计划优劣比照 在传统的数据仓库中,半结构化数据解决方案分为schema on read和 schema on write两种模式。实质上来讲的就是数据引擎在数据读写的哪一个环节对数据结构进行解析。schema on read,顾名思义就是在数据导入的过程中不对数据做任何解析和解决,间接将数据进行存储,而后只有在数据拜访的时候会依据用户具体的申请,依赖引擎的动静解析能力对数据进行解析。因为在数据写入的过程中咱们没有对数据自身做出任何束缚,因而schema on read的计划一般来说会提供比拟好的数据灵活性。和schema on read相同,schema on write计划就是咱们在数据写入的时候,就须要依据当时定义好的构造对数据进行解析,将这种半结构化数据的构造转换成传统的结构化数据,而后再导入到数据仓库当中。相比于schema on read,schema on write的灵活性较差,然而可能提供更好的存储和拜访性能。 当用户将数据写入到数据仓库中,因为没有对数据进行任何解析,间接是以字符串的形式导入到数据仓库的,因而是以一种行式的数据结构进行存储的。当用户要对这个数据进行查找和解析,比方上图的案例,用户心愿统计年纪在18岁以上的用户数量的时候,须要先提取年纪在18岁以上这个特色,因为在数据写入的时候没有提前对数据进行拆分,所以须要对整个数据进行全表扫描,拿到了所有的数据之后进行解压解码,而后取得具体的JSON数据结构,再进一步地依据用户的需要对这个JSON 构造进行解决,最终取得年龄字段。在整个执行链路当中,一方面数据的存储开销十分大,另外一方面整个查问效率因为须要full scan,还须要破费额定的CPU进行解压,同时对这个JSON的数据结构进行解析,所以它的数据解析效率,拜访性能都是十分差的。 同样的一个查问申请,在schema on write的场景外面,咱们能够只对用户的年龄字段进行读取,而后间接进行数据解压解码,取得残缺的数据结构,再进行数据的解析和查问,它的存储效率和查问效率都会更高。 然而 schema on write的计划也不是白璧无瑕的。一般来说,采纳 schema on write计划的时候,会假设上游业务部门不会对这些字段进行频繁的改变,整个数据结构处于一个绝对稳固的状态。如果上游的业务部门处于一种疾速迭代、疾速适应的阶段,那么可能会一直地有减少字段、批改字段的需要。 在上游业务疾速迭代的状况下,如果依然抉择应用schema on write 计划,上游的数据中台或者数据保护部门就须要一直地依据上游业务部门的改变,对数表的构造进行适配,一直地、频繁地执行表字段的减少或者批改,这将消耗微小的业务保护老本。因而咱们思考有没有可能在容许上游业务部门频繁迭代、自在迭代的状况下,既取得比拟好的查问效率和比拟低的存储老本,又尽可能地升高数据仓库或者数据保护部门的数据保护老本。 这也就是咱们提出来的数据仓库半结构化数据场景的一个外围的需要。心愿可能同时兼顾数据查问的高性能、数据存储的低成本以及数据演进的灵活性。联合 schema on write和schema on read的劣势,一方面在数据写入的过程中进行数据结构的提取和转换,同时也反对对数据读取过程中动静的自适应的拜访,从而达到一个升高存储老本和放弃灵活性的成果。 MaxCompute半结构化数据解决方案 MaxCompute是一个实用于数据分析场景的企业级的云服务数仓,以serverless 的架构提供疾速的全托管的在线的数据仓库服务。它打消了传统数据平台在扩展性和弹性方面的限度,可能最小化用户运维投入,能够使用户以较低的老本高效地剖析和解决海量数据。随着以后数据收集伎俩的不断丰富,各个行业数据的大量积攒,数据规模曾经增长到了传统的数据库或者软件行业无奈承载的PB甚至EB的级别。MaxCompute提供了离线和流式的数据接入,可能反对超大规模的数据计算和查问减速能力,能够为用户提供包含面向多种计算场景的数据仓库解决方案以及剖析建模的服务。MaxCompute还提供欠缺的数据导入计划和分布式计算的模型。用户不须要关怀具体的分布式计算和保护细节,就能够实现大数据分析。通常来说 MaxCompute实用于100GB以上存储规模的计算需求量,最大能够到EB级别。MaxCompute在阿里巴巴团体外部失去了大规模的利用,实用于大型互联网企业的数据仓库和BI剖析,网站的日志剖析,电子商务场景的交易剖析,以及用户特色和趣味的开掘。 上图展现了MaxCompute半结构化数据的一个具体场景。用户会将前端的业务数据和业务日志,通过实时或者分批次的形式导入数据仓库,而后与业务数据进行联合。从用户的诉求来看,他们心愿可能最大限度地缩小入仓过程中数据转换的链路,并晋升数据导入的实时性。另一方面数据中台也会对数据进行定时的监控,保证数据品质,同时进行定时的报警触发。在数据的上游,多个不同的业务部门会对数据有不同的解析需要,用户会通过交互式剖析、减速查问的形式生成可视化的数据报表。 ...

September 12, 2023 · 1 min · jiezi

关于大数据:火山引擎DataLeap的数据血缘用例与设计概述

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群数据血统形容了数据的起源和去向,以及数据在多个处理过程中的转换。数据血统是组织内使数据施展价值的重要根底能力。本文从字节的数据链路详情开始,介绍了数据血统在字节的利用场景,总体设计,数据模型以及掂量指标。 字节数据链路介绍为了明确问题的探讨范畴,咱们首先介绍一下字节的数据链路。 字节的数据的起源分为两种: 端数据:APP和Web端通过埋点SDK发送的,通过LogService,最终落入MQ业务数据:APP,Web和第三方服务所进行的业务操作,通过各种利用的服务,最终落入RDS,RDS中的数据,通过Binlog的形式,汇入MQMQ中的数据,在MQ之间有分流的过程,做转换格局,流量拆分等离线数仓的外围是Hive,数据通过各种伎俩最终汇入其中,应用支流的HiveSQL或SparkJob做业务解决,流入上游Clickhouse等其余存储实时数仓的外围是MQ,应用支流的FlinkSQL或通用FlinkJob做解决,期间与各种存储做SideJoin丰盛数据,最终写入各种存储典型的数据进口有三类: 指标零碎:业务属性强烈的一组数据,比方“抖音日活”报表零碎:以可视化的模式,各种维度展现加工前或加工后的数据数据服务:以API调用的模式进一步加工和获取数据在字节,数据血统的零碎边界是:从RDS和MQ开始,一路路径各种计算和存储,最终汇入指标、报表和数据服务零碎。血统的利用场景在探讨技术细节之前,须要先讲清楚血统的利用场景与业务价值,进一步明确数据血统须要解决的问题。不同的利用场景,对于血统数据的生产形式,血统的覆盖范围,血统的品质诉求,都会有所差异。 数据血统零碎的整体设计概览通过对字节血统链路和利用场景的探讨,能够总结出血统整体设计时须要思考的两个关键点: 可扩展性:在字节,业务简单而宏大,整条数据链路中,应用到的各种存储有几十种,细分的工作类型也是几十种,血统零碎须要能够灵便的反对各种存储和工作类型凋谢的集成形式:生产血统时,有实时查问的场景,也有离线生产的场景,还有可能上游零碎会基于以后数据做扩大字节数据血统零碎的整体架构能够分为三局部: 工作接入:以某种形式,从工作管理系统中获取工作信息血统解析:通过解析工作中的信息,获取到血统数据数据导出:负责将血统数据存储到Data Catalog零碎中,并供上游零碎生产 工作接入有两个要害的设计思考: 提供两种可选的链路,以应答不同上游零碎对于数据实时性的不同要求: 近实时链路:工作管理系统将工作的批改的音讯写入MQ,供血统模块生产离线链路:血统模块周期性的调用工作管理系统的API接口,拉取全量(或增量)工作信息,进行解决定义对立的Task模型,并通过TaskType来辨别不同类型工作,确保后续解决的可扩展性: 不同工作管理系统,可能治理雷同类型的工作,比方都反对FlinkSQL类型的工作;同一工作管理系统,有时会反对不同类型的工作,比方同时反对编写FlinkSQL和HiveSQL新增工作管理系统或者工作类型,能够增加TaskType 血统解析有两个要害的设计思考: 定义对立的血统数据模型LineageInfo,将在下一章节中展开讨论针对不同的TaskType,灵便定制不同的解析实现,也反对不同TaskType可服用的兜底解析策略。比方: SQL类工作:比方HiveSQL与FlinkSQL,会调用SQL类的解析服务Data Transfer Service(DTS)类:解析工作中的配置,建设源与指标之间的血缘关系其余类工作:比方一些通用工作会注销依赖和产出,报表类零碎的管制面会提供报表起源的库表信息等 数据导出血统解析所产出的LineageInfo,会首先送入DataCatalog零碎反对三种集成形式: 对于Data Catalog中血统相干API调用,实时拉取须要的血统数据生产MQ中的血统批改增量音讯,以近实时能力结构其余周边零碎生产数仓中的离线血统导出数据,做剖析梳理等业务 血统的数据模型血统数据模型的定义,是确保零碎可扩展性和不便上游生产集成的要害设计之一。 概览咱们以图的数据模型来建模整套血统零碎。图中蕴含两类节点和两类边: 数据节点:对于存储数据的介质的形象,比方一张Hive表,或者是Hive表的一列工作节点:对于工作(或链路)的形象,比方一个HiveSQL脚本从数据节点指向工作节点的边:代表一种生产关系,工作读取了这个数据节点的数据从工作节点指向数据节点的边:代表一种生产关系,工作生产了这个数据节点的数据将工作节点和数据节点对立到一张图上的2点劣势:将血统的生命周期与工作的生命周期对立,通过更新工作关联的边来更新血缘关系能够灵便的反对从工作切入和从数据节点切入的不同场景。比方数据资产畛域从数据节点切入的居多,而数据开发畛域从工作切入的场景居多,不同的利用场景能够在一张大图上灵便遍历 字段(Column)级血统字段血统是血统模型中的边界状况,独自拿进去简略探讨。在实现时,有两种可供选择的思路:咱们最终采纳了第2种计划。 血统掂量指标理论推广血统时,最常被用户问到的问题就是,血统品质怎么样,他们的场景能不能用。面对这种灵魂拷问,每个用户都独自评估一遍的开销过大,所以咱们花了很多精力探讨摸索出了最罕用的三个技术指标,以佐证血统品质。用户能够依据这些指标,判断本人的场景是否实用。 准确率定义:假如一个工作理论的输出和产出与血统中该工作的上游和上游相符,既不缺失也不多余,则认为这个工作的血统是精确的,血统精确的工作占全量工作的比例即为血统准确率。准确率是用户最关注的指标,像数据开发的影响剖析场景,血统的缺失有可能会造成重要工作没有被告诉,造成线上事变。不同类型的工作,血统解析的逻辑不同,计算准确率的逻辑也有区别: SQL类工作:比方HiveSQL和FlinkSQL工作,血统来源于SQL的解析,当SQL解析服务给出的质量保证是,胜利解析的SQL工作,产生的血缘关系就肯定是精确的,那么这类工作的血统准确率,就能够转化成SQL解析的成功率。数据集成(DTS)类工作:比方MySQL->Hive这类通道工作,血统来源于对用户注销上下游映射关系的配置,这类血统的准确率,能够转化成对于工作配置解析的成功率。脚本类工作:比方shell,python工作等,这些血统来源于用户注销的工作产出,这类血统的准确率,能够转化成注销产出中正确的比例。留神一个问题,下面所讲的准确率计算,转化的时候都有一个前提假如,是程序依照咱们假设的形式运行,理论状况并不一定总是这样。其实这件事件没必要特地纠结,血统就像咱们在运行的其余程序一样,都可能因程序bug,环境配置,边界输出等,产生不合乎预期的后果。作为准确率的补充,咱们在实践中通过三种路径,尽早发现有问题的血统:人工校验:通过结构测试用例来验证其余零碎一样,血统的准确性问题也能够通过结构用例来验证。实际操作时,咱们会从线上运行的工作中采样出一部分,人工校验解析后果是否正确,有必要的时候,会mock掉输入,继续运行校验。埋点数据验证:字节中的局部存储会产生拜访埋点数据,通过荡涤这些埋点数据,能够剖析出局部场景的血统链路,以此来校验程序中血统产出的正确性。比方,HDFS的埋点数据能够用来校验很多Hive相干链路的血统产出。用户反馈:全量血统汇合的准确性验证是个浩瀚的过程,然而具体到某个用户的某个业务场景,问题就简化多了。实际操作中,咱们会与一些业务方深刻的单干,一起校验血统准确性,并修复问题。 覆盖率定义:当至多有一条血统链路与资产相干时,称为资产被血统笼罩到了。被血统笼罩到的资产占关注资产的比例即为血统覆盖率。血统覆盖率是比拟粗粒度的指标。作为准确率的补充,用户通过覆盖率能够晓得以后曾经反对的资产类型和工作类型,以及每种笼罩的范畴。团队外部,咱们定义覆盖率指标的目标有两个,一是圈定出咱们比拟关注的资产汇合,二是寻找零碎中缺失的整块的工作类型。以Hive表为例,字节生产环境的Hive表曾经达到了几十万级别,其中有很大一部分,是不会被长期应用与关注的。计算血统覆盖率时,咱们会依据规定圈选出其中的局部,比方,过来7天有数据写入的,作为分母,在这之上,看血统覆盖率是多少。当血统覆盖率低时,通常阐明咱们漏掉了某种工作类型或者圈选的资产范畴不合理。举个例子,在初期时,咱们发现MQ的血统覆盖率只有个位数,剖析后发现,咱们漏掉了以另外一种格局定义的流式数据集成工作。 时效性定义:从工作产生批改,到最终反馈到血统存储系统的端到端延时。对于一些用户场景来说,血统的时效性并没有特地重要,属于加分项,然而有一些场景是强依赖。不同工作类型的时效性会有差别。数据开发畛域的影响剖析场景,是对血统实时性要求很高的场景之一。用户在圈定批改的影响范畴时,如果只能拉取到昨天为止的状态,是会产生重大业务事变的。晋升时效性的瓶颈,通常不在血统服务方,而是工作管理系统是否能够近实时的将工作相干的批改,以告诉模式发送进去。 将来工作局部数据血统技术曾经通过火山引擎大数据研发治理套件DataLeap对外开放。接下来,字节数据血统方面的工作,会次要集中在三个方向:首先,是继续晋升血统的准确性。以后咱们的血统准确性曾经晋升到了可用的状态,然而仍然须要人工的校验与修复。如何继续稳固的晋升准确性,是摸索的重要方向。其次,是血统的标准化建设。除了数据血统之外,利用级别的血统其实也很重要,在解决方案上,咱们心愿做到通用与规范。以后业务方会基于数据血统拼接一些本人业务畛域的链路,实现标准化后,这部分用例能够复用整套基础设施,定制产品层面的展示就好了。最初,是增强对外部生态的反对。细分下来有两个方向,一是摸索通用的SQL类血统解析引擎,以后,新接入一种SQL类的引擎血统,老本是比拟高的;二是反对开源或私有云上产品的端到端血统。 点击跳转大数据研发治理套件DataLeap理解更多

September 11, 2023 · 1 min · jiezi

关于大数据:从13天到0天延时揭秘幸福里离线SLA保障最佳实践

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群“幸福里”是抖音团体旗下集内容、社区、工具于一体的房产媒体综合信息平台,致力于提供多样化房产资讯、定制找房需要。随着幸福里业务倒退,为了满足业务对于数据应用、指标观测等需要,团队疾速落地了数仓建设。但因为晚期“先建后治”,导致现阶段数据治理难题频发。 其中,异样突出的是离线数仓SLA提早大,高达13天。对于须要实时看到数据状况的经纪人、用户等人来说,延时可能会影响到数据价值的产出。在抖音团体外部广泛应用“0987”高质量服务评估体系,即从多个维度综合论证数据中台的价值,位列第一的“0”,指的是数据中台必须保障数据稳固,实现SLA故障清零。而对于幸福里团队来说,SLA高延时显然曾经成为数据治理中未解决的外围问题。 基于此背景,幸福里团队通过引入火山引擎大数据研发治理套件DataLeap,综合推动离线数仓的SLA治理,将离线数仓SLA从13天升高为0天。本文将从策略制订、工作摸排收集、标准确定,宣贯推动等方向还原我的项目推动过程,冀望为更多企业带来SLA治理思考和解决方案。 业务痛点据相干业务同学介绍,幸福里团队与其余面临SLA治理难题大同小异,次要蕴含以下两个方面: 第一,随着楼盘、房源、经纪人、营销等数据一直增长,在数据工作开发场景中,业务多样化、数据量大、数据工作简单等问题,导致数据工作链路依赖简单、链路长、依赖多,具体体现在: 幸福里离线数仓数据源包含中台型数据,这类数据没有SLA保障。幸福里离线数仓数据源还包含业务DA以及算法类数据。以算法类数据为例,数据自身在算法团队本身队列当中,因为无奈别离出业务须要的重要数据,队列工作可能产生提早、时效性不强,另外还存在工作交接或权限到期等问题,导致这些数据无奈失去无效保障。幸福里离线数仓SLA链路长。相干业务人员提到,“外部最长的链路上游包含800多张表,这里的上游仅局限在幸福里业务外部,还不包含中台”。由此可见,上游工作数之多,且可能波及逾越多个团队沟通,要最终达成约定SLA,老本将十分高。第二,数据建设主导方变更,业务状态转变,导致历史包袱重、存量工作优化工作量大,这与幸福里离线数据建设历程强关联。在幸福里数仓1.0阶段,数据仓库由业务方DA与RD自建,未有明确的数仓标准,数据模型较凌乱。2021年3月份,幸福里业务过程及业务状态产生转变,业务主体由流量转为交易,为了满足业务高速倒退需要,数据建设以疾速落地、指标精确产出为次要指标,历史遗留问题治理较少。随着业务倒退逐步稳固,数仓建设进入2.0阶段。因为数仓中大量线上数据和重要指标仍然应用1.0阶段的老表,导致指标口径不对立,同时也存在历史表数据无人保护的问题,导致时效性差。另外,幸福里数仓也面临存量工作优化的问题。有些存量工作运行工夫长、资源占用重大,团队亟需排查这部分问题。 解决方案为了解决SLA延时问题,幸福里团队引入了火山引擎大数据研发治理套件DataLeap,通过DataLeap的三大能力,造成一套连贯、可复用的治理计划,最终造成SLA保障全链路高效治理。具体来看: 通过数据治理能力,解决工作上游承诺并签订保障SLA的问题。数据治理平台反对工作负责人申报工作,并疾速拉起上游实现SLA签订承诺,从而保障链路稳定性,这也是幸福里团队应用的外围性能。通过数据研发能力,解决SLA工作的基线监控问题。在工作多,依赖关系简单的状况下,很难查找到重要工作的所有上游工作并进行监控。如果监控所有工作,又会产生很多无用报警,导致有用报警被疏忽。因而,幸福里团队通过应用DataLeap的数据研发能力,将上游节点作为保障工作退出基线,造成须要监控的工作链路。通过数据品质监控能力,解决Hive表监控问题。针对某些卡点工作进行表监控,一方面保障 SLA 及时性,另一方面保障整体工作准确性。下文三个步骤,带你还原幸福里离线数仓治理我的项目全过程!第一步:圈定SLA保障外围工作幸福里团队首先依据业务需要,圈定出须要被SLA保障的外围工作,具体包含以下三类: 线上外围工作,即间接展现给B端经纪人或C端用户的数据。治理驾驶舱数据,包含日报、周报、月报等。重点业务外围看板。例如,2022年幸福里重点业务在福州,因而对须要对福州数据提供优先保障,确保当地经纪人、店长等业务角色能精确、疾速获取数据,以便制订相应推广策略。第二步:制订全局保障计划幸福里团队通过引入DataLeap数据治理平台,推动对外围工作的SLA治理工作。对于工作运行中的异样数据或突发事变,基于配置基线监控的运维能力,增强报警能力,另外通过数据品质监控平台实现外围维表及外围指标表监控,以提供更加稳固的数据服务。 在SLA治理环节,存在外围工作SLA保障有余,有产生线上业务事变的隐患问题。除此之外,SLA工作运维报警能力有余或者SLA签订工夫不合理等,有SLA提早隐患,造成破线事变。 对于新增SLA工作,数据治理平台【SLA保障】-> 【SLA治理】页面,点击【发动申报】,以申报单签订的模式达成SLA协定,在申报签订环节中,各个环节的变动将通过告诉模块传递信息给相应负责人,实时告诉升高信息交换老本,减速了SLA的达成。 火山引擎DataLeap数据治理平台SLA申报页面幸福里团队工作签订SLA步骤 在基线报警环节,据相干业务人员介绍,只有34%的外围工作配置了基线监控,导致有产生线上业务事变的隐患,同时有效报警较多,造成有效起夜、运维压力较大。 火山引擎DataLeap反对圈选外围工作,并依据工作近30天产出体现,依据近30天75分位产出工夫,产出工夫稳定方差、链路最长工作均匀时长、上游工作总数、业务冀望产出工夫等作为输出数据,产出正当基线预期产出工夫及预警buffer配置基线,还反对校准基线监控范畴。 幸福里团队基线报警治理思路 幸福里平台有一个关系到经纪人外围利益的“幸福分”指标。当经纪人实现相应工作时,幸福分值减少。但当维表中数据缺失,在前台反映的后果则是“幸福分”不更新,对经纪人造成困扰。另外,据业务同学介绍,之前还呈现过这样的案例:小李在数据库中的外围维度是“经纪人”,但在维表中,可能测试数据误导入或反复数据导入,导致小李对应到多个门店或对应到谬误房源。 为了解决以上问题,幸福里团队在Hive表监控环节,引入了火山引擎DataLeap数据品质监控能力。对于业务外围关注的线上工作、治理驾驶舱数据以及重点业务外围看板等数据,通过数据品质监控平台实现数据稳定监控、异样报警,防止因为数据品质导致的数据失信、决策失误等事变。 数据品质整体策略 第三步:量化SLA成果并复盘在DataLeap数据治理平台中,SLA大盘展板反对提供当日SLA整体统计信息、SLA提早趋势剖析信息、SLA等级散布明细、工作衰弱度明细、团队SLA达成信息统计等丰盛信息,是很多团队数据治理指标重要参照起源。 幸福里我的项目中的外围数据指标如SLA工作数量、报警数、起夜率等都体现在大盘展板中,量化我的项目推动成果,为危险判断、后续措施提供数据反对。 最终成果自2022年6月-12月,幸福里离线SLA保障曾经实现SLA事变天数0、SLA提早天数为0,实现“0987”高质量服务评估体系指标。除此之外,线上外围工作基线覆盖率达到97.4%(较我的项目启动前晋升63%)、电话报警量较我的项目启动前升高28.4%,大大降低运维老本,保证数据稳定性。 火山引擎DataLeap不仅解决了离线SLA保障的当务之急,更为幸福里团队造成了一套规范流程和标准。在事先,应用申报流程,标准SLA签订;在事中,欠缺报警及时性和准确性,升高误报率;在预先,及时跟踪报警状况,欠缺问题复盘及监控机制,积淀公共解决方案,推动幸福里SLA治理衰弱、可继续倒退。 数据品质施行过程 点击跳转大数据研发治理套件 DataLeap理解更多

September 8, 2023 · 1 min · jiezi

关于大数据:火山引擎-DataTester-首推AB实验经验库帮助企业高效优化实验设计能力

援用更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群近日,火山引擎 DataTester 推出了重要性能——A/B试验教训库。 基于在字节跳动已实现150万余次A/B试验的教训,DataTester 独创了A/B试验教训库性能。该性能可帮忙业务人员将历史的A/B试验教训积淀,并通过条件筛选,疾速找到所需试验信息并进行数据分析。吸取过往在A/B实验设计和后果方面的教训,并理解优化方向,更好为后续的业务赋能。 以往,当企业须要去查看往期A/B试验信息时,只能通过试验列表去挨个点击查看,这样做对于业务人员来说不仅仅很耗时耗力,而且无奈全面理解过往A/B实验所积攒的无效信息。 A/B试验教训库性能上线后,企业可能自主筛选、高效调用以往A/B试验的数据及详情,并查阅 DataTester 以教训报告模式做的形象和总结。该性能让 DataTester 从单纯反对A/B试验的数据工具平台,降级成为了企业业务信息积淀的零碎,能够帮忙企业一直迭代优化A/B试验的设计与成果。在 DataTester 的教训库中,用户能够通过检索多类标签,查看业务历史上A/B试验的目标群体、试验策略、试验论断: 试验信息:反对检索试验名称、试验形容、试验版本名称、翻新人等信息;运行工夫:反对对运行工夫、开始工夫、进行工夫进行工夫范畴筛选;展现指标:反对输出须要所需查问的任意数据指标,如点击率、转化率、DAU等;指标受众:反对筛选试验指标人群包,可按公共属性和用户分群等维度进行筛选。以具体的利用场景举例,假如业务经营有一个指标:冀望减少产品在“北上广深”的女性用户群体的应用活跃度。那么业务经营首先要理解在过往,产品针对“北上广深”的女性群体做过哪些经营动作,在A/B测试中,哪些经营动作成效显著,哪些成果不好。在 DataTester 的教训库中,业务经营人员能够抉择指标受众为“女性”标签,再抉择城市标签为“北京、上海、广州、深圳”;此时,即可查看以往针对上述人群的有成果的试验有哪些。如果想进一步拆分针对上述人群中与“应用活跃度”无关的试验,那么能够在指标选取上更加细分和灵便。例如可选取“新增用户数”指标,来查看往期试验中,晋升了目标群体日活的试验;与此同时还可选取“订购”指标,查看往期试验中晋升了目标群体生产状况的试验。这样一个满足业务经营所需条件的往期试验就全副筛选进去了。经营人员能够具体的查看和剖析往期试验的数据,在此基础上持续设计深入新的A/B试验策略。DataTester 的A/B试验教训库,让企业的每一次A/B试验都不再是各自独立的个体,而可能层层递进,每一次都在上一次的试验成果根底上进一步调优,能够帮忙企业缩小“反复造轮子”的状况,大幅晋升效率。DataTester 是字节跳动外部利用多年的A/B试验平台,以后已通过火山引擎面向内部企业凋谢服务,能基于先进的底层算法,提供迷信分流能力和智能的统计引擎,反对多种简单的A/B试验类型。在利用和剖析场景上,火山引擎 DataTester 深度耦合举荐、广告、搜寻、UI、产品性能等多种业务场景需要,为业务增长、转化、产品迭代,策略优化,经营提效等各个环节提供迷信的决策依据,让业务真正做到数据驱动。目前,火山引擎 DataTester 曾经服务了美的、失去、凯叔讲故事等在内的上百家标杆客户,将成熟的“数据驱动增长”教训赋能给各行业。 点击跳转火山引擎 DataTester理解更多

September 7, 2023 · 1 min · jiezi

关于大数据:国商佳美合作火山引擎数智平台-助推深圳餐博会及美博会数字化升级

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群近日,深圳市国商佳美展览有限公司(以下简称“深圳国商佳美”)与火山引擎数智平台VeDI达成单干,单方将聚焦于2023年11月7-9日第六届深圳餐饮博览会,摸索直播场景下的数字化服务拓展。 作为国内会展行业的头部主办方之一,深圳国商佳美近年已打造包含“深圳餐饮博览会”、“深圳国内大衰弱漂亮产业博览会”、“深圳国内芬芳产业博览会”等在内多个垂直畛域业余展会,帮忙中上游中央产业带、品牌厂家、及上游经销渠道商、终端门店经营等实现多方资源链接,累计五届深圳餐博会、美博会、芳博会现场到展人流量超50万人次。通过历年展期及展期外的精准需要匹配,深圳国商佳美促成上游供应链企业和上游买家之间交易额超百亿元。 图注:第五届深圳餐饮博览会 “与批发、金融等行业相比,咱们会展行业的数字化转型要走的路还比拟久远,除了会展经营本体的数字化利用与降级,咱们也更关注在带动市场需求转化和有助展商成长方面如何更好的推动数字智能化工具”,深圳国商佳美市场部负责人、深圳餐博会我的项目总监金晶示意,“随着互联网新技术一直倒退,人们的生存形式、生产习惯都产生了很大扭转,在满足行业倒退无奈代替的线下传统交换展根底上,要让数字工具晋升展会成果,让买卖双方感触到便捷、精准与高效的碰撞,这是会展主办方应踏踏实实去思考和推动的事件。” 直播技术近年来在会展行业利用宽泛——作为线下会展的展示模式补充,直播可能冲破空间和工夫的限度,让无奈现场参展观展的行业人士参加到会展中来,在线浏览动向商品;同时局部直播还可反对「回看」性能,帮忙未能及时加入展会的企业回看展会内容。 “看”,让更多业内人“看见”,仿佛是现阶段直播对于会展行业而言最大的价值。 “但这个‘看’的价值,未必是展商真正须要的,”金晶对于直播技术和会展业交融,提出不同认识,“很多展会当初的确会做一些直播,发展日有一些直播受众,但对参展商来说理论收效甚微,实质性的转化率很低,最大的问题还是在于既没有借助业余的平台和数字工具;也没有笼罩精准的指标对象,因而难以进行无效的推流。国商佳美旗下的深圳餐博会和美博会,意在为优质产业带、供应商、和业余买家搭建一个精准展现和采销平台。比起观看量,其实咱们更关注可能给客户(参展商)带来多少单干机会,多少转化。这就关系到咱们要去布局搭什么台子,演什么戏,以及指标的观众是谁等等。” 往年4月,火山引擎推出企业数智化降级新范式【数据飞轮】,以数据生产为外围驱动力,使企业数据流充沛融入业务流,实现数据资产和业务利用的飞轮效应;并可通过火山引擎数智平台(VeDI)增长剖析DataFinder、客户数据平台VeCDP等数智产品落地。 基于深圳餐博会和美博会积淀多年的行业数据,深圳国商佳美联结火山引擎数智平台搭建了数据增值服务平台、数字展会新基建平台两大平台,其中数据增值服务平台蕴含直播营销,品牌营销等六个服务包;数字展会新基建平台蕴含四个数字核心作为撑持,为数据增值服务平台提供数据技术支持。 “抉择和火山引擎数智平台单干,是因为平台齐全基于会展行业定制,针对性更强,解决方案更业余、更全面,”金晶说道,“而经由深圳餐博会及美博会的行业积淀数据、及火山引擎的精准工具,咱们的直播能够做到精准的笼罩。” 在I期单干中,火山引擎e展平台(火山引擎面向会展行业推出的行业解决方案)将输入包含增长剖析DataFinder、客户数据平台VeCDP、增长营销平台GMP等在内的系列数据产品,围绕直播场景中包含市场洞察、营销触达、实时反馈、高效剖析等数据全链路进行精细化经营。 深圳餐博会及美博会通过接入客户数据平台VeCDP,即可实现自有客户特征分析,造成特定标签;而在直播引流阶段,所有深圳餐博会及美博会的展商就能够依据标签更精准地寻找高潜人群(对会展直播内容高趣味人群),以此晋升进入直播间的人群与展会内容的符合度。 而在直播过程中,通过增长剖析DataFinder,深圳餐博会及美博会能实现人群在直播不同阶段的实时反馈洞察,比方在直播介绍A展区商品时,直播间用户对限时跳出的A展区商品相干材料有更多点击、查看行为,这些数据都可反映在DataFinder上对立记录,帮助深圳餐博会及美博会实时或者在直播完结后对立剖析,并制订进一步经营策略。 在进一步经营策略中,深圳餐博会及美博会又能通过VeCDP对不同特色的市场数据进行分层治理和二次特色提炼,造成新的特色标签,继续精细化经营;同时,在确定不同标签分类和经营策略之后,还能通过增长营销平台GMP实现多种形式的营销触达——不同市场特色人群采纳不同营销形式,晋升营销效率。 “这对咱们来说是一次大胆尝试,但咱们看到了这套产品组合在其它行业的成功经验,”金晶示意,“咱们有信念能把这件事做好,期待与火山引擎数智平台一起摸索在会展行业的落地。让展商能在展会服务中失去更大的价值。” 点击跳转火山引擎数智平台VeDI理解更多

September 6, 2023 · 1 min · jiezi

关于大数据:火山引擎DataLeap数据血缘技术建设实践

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群DataLeap是火山引擎数智平台VeDI旗下的大数据研发治理套件产品,帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设,升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。 数据血统是帮忙用户找数据、了解数据以及使数据施展价值的根底能力。本文将聚焦数据血统存储和血统导出,分享数据血统的模型设计以及优化,并介绍字节跳动在数据血统建设过程中所遇到的挑战和技术实现以及数据血统的具体用例,具体包含数据血统模型、数据血统优化、数据血统用例、将来瞻望四个局部。 本文介绍的数据血统能力和实际,目前大部分已通过火山引擎DataLeap对外提供服务。 ▌教训一:数据血统模型的分层架构1. 挑战首先介绍一下字节外部数据血统遇到的挑战。 随着公司业务扩张、用户数量持续增长以及数仓建设不断完善,元数据品种和数量也经验了非线性增长,并在此期间涌现出一些问题。 第一,扩展性。好的扩展性能够在面对新型元数据血统时保障疾速接入和迭代,而扩展性不佳则会导致在业务变动时须要不停地重构来适应业务,对业务造成很多影响。 第二,性能。一个模型自身的插入和更新效率会间接影响数据的导入导出的流程,这些都会带来更直观的业务上的感触,所以须要思考如何保障环节高效性。 第三,时效性。很多利用场景对正确率分外敏感,如果血统数据有提早,其实就等于血统的不精确,会对业务造成影响。 最初,赋能业务。技术服务于业务,业务增长会帮忙技术升级迭代,技术创新也会促成业务倒退。在字节外部,咱们会依据业务特点,思考业务须要,将技术老本与业务收益做均衡,最终做出数据模型决策。总而言之,数据模型没有完满的计划,只有最适宜企业本身业务、适宜以后阶段的数据血统计划。 2. 数据血统模型-展现层字节外部有很多种元数据类型,包含线上传统的离线数仓Hive、OLAP剖析引擎ClickHouse,以及实时侧元数据,如Kafka和ES以及Redis。这些元数据所对应的表/Topic都对立保护在元数据平台上,目前血统展现层是以这些数据资产作为主视角。 如下图所示,核心数据资产蕴含一般字段和分区字段等信息,还能够从图中看到核心资产上下游资产信息。图中资产和资产之间连贯的边,代表的是生产关系:1个工作读取了上游的资产,产生了上游的资产。 3. 数据血统模型-形象层接下来介绍,火山引擎DataLeap如何设计形象层。 形象层是整个数据血统的数据模型,次要蕴含两种节点,一种是资产节点,另外一种是工作节点。 在图中,资产节点用圆形示意,工作节点用菱形示意。具体举个例子: 一个FlinkSQL工作生产了Kafka的topic,而后写入到一个Hive的表里,那么Kafka的topic和hive表就是表资产节点,而FlinkSQL生产工作就是两头的工作节点。一个Kafka的topic外面可能会定义本人的schema,包含多个字段,例如schema里蕴含字段a、b、c,通过FlinkSQL工作,比方一个SQL:insert into hiveTable select a,b,c from kafka Topic,通过进行这样的解决,字段a、b、c和这个hive的字段d就产生了血缘关系。创立子工作的节点,把几个字段节点连接起来,每个子工作节点会和子工作节点通过从属关系的边来进行连贯,字段节点和每一个表资产节点也会通过从属关系的边进行连贯。自身这个工作和资产之间会有生产生产关系的边连贯。以上就是整个血统数据模型在形象层的展示。 这样设计有以下益处: 首先,工作资产的形象是对生产平台上和在各种工作平台上宽泛间接的工作关系的形象,当再去接入新元数据或新工作类型时,咱们只须要扩大以后形象的资产节点和工作节点,即可把新退出进来的工作链路所对应的血统接入到存储中。这种数据模型也能不便地更新和删除血统链路,维持时效性。 其次,在字节外部的血统建设中,还存在接入各种血统链路的难点。基于目前设计能够缩小开发成本,在更新血统的时只须要更新核心工作节点,并且把核心工作节点所对应的子工作节点的边也做相应的更新和删除,就实现了血统信息的插入和更新。 4. 数据血统模型-实现层在实现层,火山引擎DataLeap次要基于Apache Atlas来实现。Apache Atlas自身也是一个数据治理的产品,它预约义了一些元数据的类型,整个类型零碎有比拟好的扩展性。在Atlas自身的DataSet和Process元数据定义上,咱们引入了字节外部独有的业务元数据的属性和子工作定义,最终把工作相干的元数据存储起来。 Atlas自身也反对血统的查问能力,通过Apache Atlas裸露的接口来转换成图上查找某个节点对应血缘关系的边,以此实现血统查问。 5. 数据血统模型-存储层在存储层,目前次要基于Apache Atlas原生图数据库——JanusGraph。JanusGraph底层反对HBase。咱们将每条边的关系作为两边的资产节点的属性,存入到对应RowKey的独立cell中。 另外,咱们也对存储做了相干的革新,如字节外部自研的存算拆散key-value存储。咱们也在独立环境中会做轻量级部署,同时基于性能或老本,以及部署复杂度,把存储切换为OLTP数据库,比方MYSQL数据库。 以上就是整个数据血统模型的设计局部。通过这样的数据血统模型,咱们能够缩小新的数据血统链路接入开发成本,同时也很不便更新和删除血统。 ▌教训二:三个数据血统优化方向第二局部将次要介绍在火山引擎DataLeap中典型的数据血统优化,包含实时数据血统更新优化、血统查问优化和血统数据开放式导出。 1.实时数据血统优化首先,实时数据血统的更新。字节外部当初数据血统的更新形式是通过T+1的链路和实时链路来更新。因为外部有很多场景对时效性的要求特地高,如果数据血统更新不太及时,就会影响血统准确率,甚至影响业务应用。 在数据血统的架构设计之初就曾经反对了T+1的导入,不过时效性始终是按天为周期的。 数据血统工作周期性的拉取所有在运行工作的配置信息,调用平台的API拉取对应工作相干的配置或者SQL对于SQL类型的工作会调用另外一个解析引擎服务提供的解析能力来去解析数据血统的信息再和元数据平台注销的资产信息相匹配,最初构建出一个工作资产节点的上下游,把这个工作资产节点和表资产节点之间的边更新到图数据库中去。在实时更新的时候,咱们有两种计划: 计划一:是在引擎侧,即在工作运行时,通过工作执行引擎把该工作在构建DAG后生成的血统信息通过Hook送入。 长处:在引擎侧的血统采集是绝对独立的,每个引擎在采集血统的时候不会相互影响。毛病: 每个引擎都须要适配一个血统采集的Hook,一些中小企业在引擎侧都可能面临的一个问题是同一个引擎可能在线上运行会有多个版本,那么适配的老本就会比拟高,须要每个版本都适配一次。Hook还有肯定的侵入性,会对自身的作业有肯定的累赘。计划二:在工作开发的平台上把这个工作变更的音讯送出,当工作的生命周期变动的时候,通过Hook音讯把工作状态变更音讯通过调用API进行注销或者发送到MQ进行解耦,血统服务收到这份告诉之后,再被动调用解析服务来更新这个工作血统。 长处:扩展性好,不会受到引擎侧限度,将来要接入新的引擎时,只须要在这个工作平台下来创立对应的工作,把这个工作变更的音讯送出,就能够失去这个血统更新的告诉,而后去更新血统。毛病:对血统解析服务平台会有肯定的革新老本,工作间的音讯可能会相互影响综合比拟,咱们采纳了第二种计划,并且引入了MQ进一步的升高工作平台和血统平台的耦合,这种做法可能就义了局部的提早,然而会让整个链路变得更加牢靠,最终减低了血统这边整体的提早,工夫周期从天减低到了分钟级别。 以上就是咱们在血统时效性上的优化。 2.数据查问优化第二个优化点是查问。目前字节数据血统查问依赖Apache Atlas。在应用该血统查问服务时,有一个很广泛的场景,就是多节点查问的场景。在影响剖析的过程中,咱们常常会查问一张表的全副字段血统,会转化成查问多个节点的血统上下游关系,须要解决查问效率的问题。 有两种根本的解决方案: 一种是间接在应用层进行封装,对Apache Atlas血统服务的裸露层新增一个接口,比方通过循环遍历去执行单个查问,这样革新的内容是很少的,然而其实性能并没有晋升,而且实现比拟暴力。 另外一种形式是革新Apache Atlas血统服务对图库查问的调用。因为Atlas应用JanusGraph作为底层的实现,提供了一部分的形象,然而只裸露了单节点的查问,而没有批量查问的办法,咱们还须要适配JanusGraph这边批量查问的接口,才能够达到提速的成果。 所以咱们在图数据库的操作入口减少了一个新的批量查问的办法,通过这种形式对血统节点进行批量查问,来进一步晋升性能。同时Atlas在查问血统节点回来之后,须要进行一个映射,映射到具体的实体下来拿回它的一些属性,在这个过程中咱们也退出了异步批量的操作形式来进一步的晋升性能。通过优化之后,咱们在对一些援用热度比拟高的表资产节点或者查问表资产或者对应列的时候,效率都能够失去显著晋升。 3.血统数据开放式导出第三个优化点是在血统的导出上提供了多种形式,除了在页面上可视化的查问血统的能力之上,咱们也陆续提供了很多应用血统的形式,包含下载到Excel或者查问这个血统数据导出的数仓表,或者间接应用服务平台侧凋谢的API,还能够订阅血统变更的topic,来间接监听血统的变更,上游的用户能够依据本人的开发场景,以及业务对准确率、覆盖率的要求,来决定到底应用哪种形式来生产血统数据。 ▌教训三:四大数据血统用例解析接下来第三局部次要介绍数据血统的具体用例,介绍字节外部是如何应用数据血统的。在字节外部数据血统用例的典型应用畛域次要包含:资产畛域、开发畛域、治理畛域和平安畛域。 1.数据血统用例 – 资产畛域首先在资产畛域,数据血统次要利用在资产热度的计算。在资产热度计算时,有些资产会被频繁生产和宽泛援用。某个资产被泛滥上游援用,是其本身权威性的体现,而这种权威性的证实须要一种定量的度量,因而须要引入“资产热度”的概念。资产热度自身是参考网页排名算法PageRank算法实现的,同时咱们也提供了资产热度值,依据资产的上游血统依赖的状况,定义了资产援用的热度值,如果某个资产援用热度值越高,就代表了这个资产更应该被信赖,数据更牢靠。 另外,血统也能够帮忙咱们了解数据。比方用户在元数据平台或者血统平台上查问数据资产节点的时候,可能是想要进行下一步的作业开发或者是排查一些问题,那么他就须要首先找到这个数据资产。用户不理解数据产生的过程,就无奈理解数据的过来和将来。也就是哲学上经典的问题:这个表到底是怎么来的?它具体有哪些含意?咱们就能够通过数据血统来找到具体表的上下游信息。 ...

September 4, 2023 · 1 min · jiezi

关于大数据:Connector开发详解系列四SinkWriter

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群Sink ConnectorBitSail Sink Connector交互流程介绍 Sink:数据写入组件的生命周期治理,次要负责和框架的交互,构架作业,它不参加作业真正的执行。Writer:负责将接管到的数据写到内部存储。WriterCommitter(可选):对数据进行提交操作,来实现两阶段提交的操作;实现exactly-once的语义。开发者首先须要创立Sink类,实现Sink接口,次要负责数据写入组件的生命周期治理,构架作业。通过configure办法定义writerConfiguration的配置,通过createTypeInfoConverter办法来进行数据类型转换,将外部类型进行转换写到内部零碎,同Source局部。之后咱们再定义Writer类实现具体的数据写入逻辑,在write办法调用时将BitSail Row类型把数据写到缓存队列中,在flush办法调用时将缓存队列中的数据刷写到指标数据源中。 Sink数据写入组件的生命周期治理,次要负责和框架的交互,构架作业,它不参加作业真正的执行。 对于每一个Sink工作,咱们要实现一个继承Sink接口的类。 Sink接口public interface Sink<InputT, CommitT extends Serializable, WriterStateT extends Serializable> extends Serializable { /*** @return The name of writer operation.*/String getWriterName(); /*** Configure writer with user defined options.** @param commonConfiguration Common options.* @param writerConfiguration Options for writer.*/void configure(BitSailConfiguration commonConfiguration, BitSailConfiguration writerConfiguration) throws Exception; /*** Create a writer for processing elements.** @return An initialized writer.*/Writer<InputT, CommitT, WriterStateT> createWriter(Writer.Context<WriterStateT> context) throws IOException; /*** @return A converter which supports conversion from BitSail { @link TypeInfo}* and external engine type.*/default TypeInfoConverter createTypeInfoConverter() { return new BitSailTypeInfoConverter(); } /*** @return A committer for commit committable objects.*/default Optional<WriterCommitter<CommitT>> createCommitter() { return Optional.empty(); } /*** @return A serializer which convert committable object to byte array.*/default BinarySerializer<CommitT> getCommittableSerializer() { return new SimpleBinarySerializer<CommitT>(); } /*** @return A serializer which convert state object to byte array.*/default BinarySerializer<WriterStateT> getWriteStateSerializer() { return new SimpleBinarySerializer<WriterStateT>(); }}configure办法负责configuration的初始化,通过commonConfiguration中的配置辨别流式工作或者批式工作,向Writer类传递writerConfiguration。 ...

September 1, 2023 · 5 min · jiezi

关于大数据:DataWorks增强分析发布一站式数据查询分析与可视化

8月31日阿里云郑州峰会,阿里云行业解决方案研发部总经理曾震宇在主论坛飞天公布时刻重磅公布DataWorks与DataV-Card单干推出的AI加强剖析产品,一站式实现从数据查问、剖析、可视化、共享的残缺链路,1分钟即可造成数据报告,帮忙互联网、金融、政务等各个行业客户表白数据观点,讲好数据故事。 在以往的数据分析工作流中,从数据仓库取数查问、到数据可视化、数据共享,往往要横跨多个产品,步骤繁琐,产品学习老本高。基于MaxCompute等计算引擎弱小的剖析计算能力,DataWorks可间接针对海量数仓数据进行SQL取数查问,剖析后果同时在DataWorks加强剖析中进行可视化,造成数据「报告」并进行后果共享,能够极大进步了企业数据分析的效率。 大会现场,阿里云行业解决方案研发部总经理曾震宇同时演示了DataWorks加强剖析中数据查问、数据卡片、数据报告三个外围性能。在数据查问阶段,DataWorks全新推出大数据公共数据集,提供了MaxCompute/Hologres/EMR等多个计算引擎的SQL剖析样例,新用户能够间接基于公共数据集体验加强剖析能力,运行失去剖析后果。 大会现场,阿里云行业解决方案研发部总经理曾震宇同时演示了DataWorks加强剖析中数据查问、数据卡片、数据报告三个外围性能。在数据查问阶段,DataWorks全新推出大数据公共数据集,提供了MaxCompute/Hologres/EMR等多个计算引擎的SQL剖析样例,新用户能够间接基于公共数据集体验加强剖析能力,运行失去剖析后果。 视频查看 数据卡片是一个个数据运行后果的可视化资产,DataWorks加强剖析中内置了常见的柱状图、折线图、饼图、词云等组件,用户能够将数据观点间接备注到卡片中,同步保留“图表+观点”。通过分类进行治理和保护,面向业务人员,逐渐构建了企业可了解的活泼的的数据资产。 视频查看 数据报告由一个个数据卡片组成,多个卡片能够自在调整程序与可视化格调,造成残缺的数据可视化报告,对外分享报告链接能够灵便适配PC、大屏、挪动端的展现。同时,在DataWorks中可进行分享的权限管控。 视频查看 扫码查看残缺报告《Demo-某电商网站行为剖析报告》 在以上能力根底上,随着大模型在各个行业的利用,DataWorks正在摸索基于大语言模型来更加精确了解用户数据分析需要,进一步升高数据分析应用门槛,晋升剖析效率。不久之后,DataWorks行将推出联合大模型的智能剖析能力,欢送大家继续关注DataWorks产品官网。如果想试用DataWorks加强剖析与MaxCompute计算能力,能够返回DataWorks产品文档核心查阅具体操作步骤。

September 1, 2023 · 1 min · jiezi

关于大数据:数据流水线的成本自适应算子

简介披露一个大数据处理技术。 现在咱们构建很多的数据流水线(data pipeline)来把数据从一处挪动到另一处,并且能够在其中做一些转换解决。数据的挪动是有老本的,对此老本的优化能够为数据流水线的拥有者带来老本效益。 数据流水线个别至多蕴含一个Source组件和一个Sink组件,有时在Source和Sink两头还有一或多个顺次执行的两头计算组件(Flume称之为Channel,Flink称之为Transform),这些两头计算组件个别被建模为函数式“算子”(Operator)。有一些算子能缩小传给下一个组件的数据量,例如过滤器(Filter)算子,这就是老本优化的要害。在分布式数据库畛域有一个查问优化技术叫做“谓词下推”(Predicate Push-down),咱们所做的与之相像,是把算子往上游Source的方向推。或者可称之为“算子上推”,这与“谓词下推”不矛盾,因为在分布式数据库查问的图示中,数据是从下向上流动的,Source在下,下推也就是往Source推。 实践上来说,算子越凑近Source越好,因为能缩小从Source一路传下来的数据量。然而实际上要思考算子的效率。Source可能是可伸缩性不强的资源(例如数据库),部署太多的计算在下面会使其变慢,因而不应该把低效率的算子推到Source。 咱们对算子效率的定义是:效率=抉择度/老本。算子的抉择度越高,老本越低,那么就认为其效率越高。抉择度的定义是“数据量的缩小率”:有的算子类型并不能缩小数据量(例如大多数Transformer算子),而即便Filter算子也不肯定能无效缩小数据量(若数据100%通过Filter,就没有缩小数据量)。若一个Filter只容许20%的数据通过,则它让数据缩小了5倍,它的抉择度是1/0.2=5。Filter不是惟一能缩小数据量的算子类型,咱们已知的还有Projector(通过去掉几个字段来缩小数据量)和Compressor(通过压缩来缩小数据量)。老本的定义是“计算所消耗的资源”,例如算子的执行所用的CPU工夫。基于对算子效率的监控,很容易想到能够配置一个效率阈值,只把效率高于阈值的算子推到Source。 这么做的实际效果还不够好,因为效率不是惟一的考量,Source的资源利用率也很重要。如果Source的资源不够(例如CPU使用率100%),即便是高效率算子也可能要被推到上游去,以加重Source的压力。如果Source的资源富余,那么即便是低效率算子也能够被放在上游以进步整体效率。 设计依据以上的需要,能够设计一个算子调度框架来动静治理数据流水线中的算子散布了。我会用一些示例代码来展现相应设计。 监控第一步是监控。 对于如下的算子API: interface Operator<T, R> { R apply(T t);}作如下批改,增加一个SelectivityCalculator工厂办法,每一种算子能够提供一个适宜本人的SelectivityCalculator实例: interface Operator<T, R> { R apply(T t); // 若返回null,示意此算子不反对计算抉择度,也无奈被调度 default SelectivityCalculator<T, R> selectivityCalculator() { return null; }}interface SelectivityCalculator<T, R> { // 为每次调用的输入输出作记录 void record(T input, R output); // 此办法会被定时调用,返回依据已记录数据计算失去的抉择度 double selectivity();}这个新办法怎么在算子上实现呢?例如Filter会这么定义SelectivityCalculator: interface Filter<T> extends Operator<T,T> { FilterSelectivityCalculator<T> selectivityCalculator() { return new FilterSelectivityCalculator<>(); }}class FilterSelectivityCalculator<T> implements SelectivityCalculator<T, Boolean> { private long inputTotal; private long outputTotal; void record(T input, Boolean output) { inputTotal++; if (output == true) { outputTotal++; } } double selectivity() { if (outputTotal == 0) { return Double.MAX_VALUE; } return ((double) inputTotal) / outputTotal; }}能够编写这样的监控程序,记录每一种算子的执行次数和累计执行工夫: ...

August 31, 2023 · 2 min · jiezi

关于大数据:人力家用-MaxCompute-事务表20主键模型去重数据持续降本增效

业务简介人力家是由阿里钉钉和人力窝独特投资成立,帮忙客户进入人力资源数字化,依附产品技术创新驱动策略的互联网公司。公司次要提供包含人事管理、薪酬治理、社保治理、增值服务在内的人力资源SaaS服务,减速对人力资源畛域赋能,实现人力资源新工作形式。目前已服务电子商务、批发服务等畛域的多行业客户。 人力家是一家典型的守业公司,目前处于一个竞争强烈的市场环境中,公司具备多产品性质,每个产品的数据具备独立性,同时为了配合外部CRM数据需要,更好地把数据整合,对于数仓团队来说是一个不小的挑战,对于数仓团队要求的是稳,准,及时响应。须要数仓团队既要满足外部的数据需要,也须要在计算的老本上实现优化。 业务痛点在应用阿里云大数据计算服务MaxCompute过程中发现随着存量数据减少,增量数据去重老本越来越大,具体分析发现有如下4个起因 增量数据量级少公司尽管是多产品,但每天新增的用户数据和历史变动的数据量绝对于历史全量数据的量级(GB)比拟下处于较小的数据量级(MB)。 历史数据二次计算对于增量数据去重,每天利用昨日历史全量+今日新增数据开窗去重计算,但历史全量数据须要更新的数据局部其实很少,每次都须要把历史数据拉进去进行开窗去重计算,这无疑一笔比拟大的计算成本。 开窗去重计算成本大应用row_number函数开窗去重获得业务主键的最新数据须要把昨日历史数据+今日数据合并计算,用户表有亿级别大小,但为了数据去重节俭存储老本和后续的建模运算,这部分老本是偏大的,其实大部分历史数据没有更新,实质上是不须要再次参加运算解决,每天一次的用户表去重单条SQL预估费用达到4.63元(按量付费)。 全量拉取老本大如果每天全量拉取业务库数据,数据量是亿级别,但其实更新的数据量级少,对于业务端的db压力大,重大影响业务端db性能。 Transaction Table2.0数据去重改良MaxCompute新增Transaction Table2.0(下文简称事务表2.0)表类型在2023年6月27日开始邀测,MaxCompute反对基于事务表2.0实现近实时的增全量一体的数据存储、计算解决方案。人力家数仓研发团队开始第一工夫理解其个性和性能,人力家数仓团队发现其个性主键模型能够用来进行数据去重,缩小开窗计算成本问题,次要实现形式如下。 每日增量用户根底信息开窗去重;因为主键表的主键不能为空,须要过滤出业务主键为空的数据;把每日增量数据开窗去重后的数据间接insert into 主键表,零碎会主动进行依照业务主键进行去重计算。具体改良实际措施整体比照 老本和计算工夫比照1、建表语句和插入更新语句 更新语句 2、老本和计算 分区表去重运行预估老本: 预估费用,不能作为理论计费规范,仅供参考,理论费用请以账单为准。 主键表去重运行预估老本: 预估费用,不能作为理论计费规范,仅供参考,理论费用请以账单为准。 分区表计算工夫和资源 事务表2.0主键表计算工夫和资源 通过上述比照,用户表每天的计算SQL老本从4.63元降落到0.06元,计算工夫缩短一半,reduce_num明显增加,map端缩小,reduce端的数据量显著变多。 合并小文件事务表2.0反对近实时增量写入和timetravel查问个性,在数据频繁写入的场景中,必然会引入大量的小文件,须要设计正当高效的合并策略来对小文件进行合并以及数据去重,解决大量小文件读写IO低效以及缓解存储系统的压力,但也要防止频繁Compact引发重大的写放大和抵触失败。 目前次要反对两种数据合并形式: Clustering:只是把Commit的DeltaFile合并成一个大文件,不扭转数据内容。零碎外部会依据新增的文件大小、文件数量等因素周期性地执行,不须要用户手动操作。次要解决小文件IO读写效率和稳定性问题。 Compaction:会把所有的数据文件依照肯定策略进行Merge操作,生成一批新的BaseFile,雷同PK的数据行只存储最新的状态,不蕴含任何历史状态,也不会蕴含任何零碎列信息,因而BaseFile自身不反对timetravel操作,次要用于晋升查问效率。反对用户依据业务场景被动触发,也反对通过设置表属性由零碎周期性主动触发。 综上面对主键外表对增量数据时,并不会马上对其进行小文件合并,这样会有大量的小文件产生,小文件会占有大量的存储空间且不利于数据查问速度,针对以上状况,咱们能够在insert into 后减少手动合并下主键表的小文件或者也可通过配置表属性依照工夫频率、Commit次数等维度主动触发Compaction机制,或期待零碎进行的Clustering合并。如果是每日的新增仅一次的数据更新,这里更举荐应用零碎的Clustering机制。 留神点: desc extend table_name显示进去的file_num 和 size是蕴含回收站数据的,目前没方法精确显示,能够清空回收站数据或者Compaction 察看日志结尾的filenum数量。 数据时空旅行查问和历史数据修复对于事务表2.0类型的表,MaxCompute反对查问回溯到源表某个历史工夫或者版本进行历史Snapshot查问(TimeTravel查问),也反对指定源表某个历史工夫区间或者版本区间进行历史增量查问(Incremental查问), 须要设置acid.data.retain.hours才能够应用TimeTravel查问和Incremental查问。 数据时空旅行查问1、基于TimeTravel 查问截止到指定工夫(例如datetime格局的字符串常量)的所有历史数据(须要设置) select * from mf_tt2 timestamp as of '2023-06-26 09:33:00' where dd='01' and hh='01';查问历史数据和版本号 show history for table mf_tt2 partition(dd='01',hh='01');查问截止到指定version常量的所有历史数据 select * from mf_tt2 version as of 2 where dd='01' and hh='01';2、基于Incremental 查问指定工夫(例如datetime格局的字符串常量)区间的历史增量数据,常量值须要依据具体操作的工夫来配置 ...

August 31, 2023 · 1 min · jiezi

关于大数据:深入MaxCompute-第十二弹-PIVOTUNPIVOT

简介:  MaxCompute推出新语法 - PIVOT/UNPIVOT:通过PIVOT关键字基于聚合将一个或者多个指定值的行转换为列;通过UNPIVOT关键字可将一个或者多个列转换为行。以更简洁易用的形式满足行转列和列转行的需要,简化了查问语句,进步了宽广大数据开发者的生产力。 MaxCompute(原ODPS)是阿里云自主研发的具备业界领先水平的分布式大数据处理平台, 尤其在团体外部失去广泛应用,撑持了多个 BU 的外围业务。MaxCompute 除了继续优化性能外,也致力于晋升 SQL 语言的用户体验和表达能力,进步宽广 MaxCompute 开发者的生产力。 MaxCompute 基于 MaxCompute2.0 新一代的 SQL 引擎,显著晋升了 SQL 语言编译过程的易用性与语言的表达能力。咱们在此推出深刻 MaxCompute 系列文章 第一弹 - 善用MaxCompute编译器的谬误和正告 第二弹 - 新的根本数据类型与内建函数 第三弹 - 简单类型 第四弹 - CTE,VALUES,SEMIJOIN 第五弹 - SELECT TRANSFORM 第六弹 - User Defined Type 第七弹 - Grouping Set, Cube and Rollup 第八弹 - 动静类型函数 第九弹 - 脚本模式与参数视图 第十弹 - IF ELSE分支语句 第十一弹 - QUALIFY 本文将向您介绍MaxCompute反对的新语法 - PIVOT/UNPIVOT,即通过PIVOT关键字基于聚合将一个或者多个指定值的行转换为列;通过UNPIVOT关键字可将一个或者多个列转换为行。常见的场景入下: 场景1 某个业务表,须要把表中的值当做新的列,并且依据每个值聚合现有的后果,从而实现行转列的成果。在没有反对PIVOT前,要实现这个需要,须要联合GROUP BY语法+聚合函数+Filter语法过滤来实现。场景2 某个业务表,须要结构一个新的列,把原有的几个列名合并在这个列外面,并且用另一个新列来搁置原来几个列的值,从而实现列转行的成果。在没有反对UNPIVOT前,要实现这个需要,须要联合CROSS JOIN语法+CASE WHEN表达式来结构实现。PIVOT/UNPIVOT性能PIVOTPIVOT概述PIVOT语法将指定的行旋转为多列,并且对其余列值聚合失去后果并旋转表。PIVOT语法是FROM子句的一部分。 ...

August 31, 2023 · 9 min · jiezi

关于大数据:深入MaxCompute-第十一弹-QUALIFY

简介:  MaxCompute反对QUALIFY语法过滤Window函数的后果,使得查问语句更简洁易了解。Window函数和QUALIFY语法之间的关系能够类比聚合函数+GROUP BY语法和HAVING语法。 MaxCompute(原ODPS)是阿里云自主研发的具备业界领先水平的分布式大数据处理平台, 尤其在团体外部失去广泛应用,撑持了多个 BU 的外围业务。MaxCompute 除了继续优化性能外,也致力于晋升 SQL 语言的用户体验和表达能力,进步宽广 MaxCompute 开发者的生产力。 MaxCompute 基于 MaxCompute2.0 新一代的 SQL 引擎,显著晋升了 SQL 语言编译过程的易用性与语言的表达能力。咱们在此推出深刻 MaxCompute 系列文章 第一弹 - 善用MaxCompute编译器的谬误和正告 第二弹 - 新的根本数据类型与内建函数 第三弹 - 简单类型 第四弹 - CTE,VALUES,SEMIJOIN 第五弹 - SELECT TRANSFORM 第六弹 - User Defined Type 第七弹 - Grouping Set, Cube and Rollup 第八弹 - 动静类型函数 第九弹 - 脚本模式与参数视图 第十弹 - IF ELSE分支语句 本文将介绍MaxCompute反对QUALIFY语法,QUALIFY语法反对指定过滤条件过滤窗口(Window)函数的后果,相似于HAVING语法解决通过聚合函数和GROUP BY后的数据。 QUALIFY性能简介语法格局 QUALIFY [expression]QUALIFY语法过滤Window函数的后果,Window函数和QUALIFY语法之间的关系能够类比聚合函数+GROUP BY语法和HAVING语法。 典型的查问语句的执行程序如下: FROMWHEREGROUP BY和Aggregation FunctionHAVINGWINDOWQUALIFYDISTINCTORDER BYLIMIT通常在一个查问语句中QUALIFY语法的执行程序在WINDOW函数之后,用于对窗函数解决后的数据进行筛选。 应用场景 须要对Window函数的后果进行过滤,没有QUALIFY语法前,个别是在FROM语句中应用SubQuery,并通过WHERE条件来配合实现过滤。如下: SELECT col1, col2FROM(SELECTt.a as col1,sum(t.a) over (partition by t.b) as col2FROM values (1, 2),(2,3),(2,2),(1,3),(4,2) t(a, b))WHERE col2 > 4;改写后的查问语句: ...

August 31, 2023 · 2 min · jiezi

关于大数据:火山引擎ByteHouseClickHouse如何保证海量数据一致性

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群背景ClickHouse是一个开源的OLAP引擎,不仅被寰球开发者宽泛应用,在字节各个利用场景中也能够看到它的身影。基于高性能、分布式特点,ClickHouse能够满足大规模数据的剖析和查问需要,因而字节研发团队以开源ClickHouse为根底,推出火山引擎云原生数据仓库ByteHouse。 在日常工作中,研发人员常常会遇到业务链路过长,导致流程稳定性和数据一致性难保障的问题,这在分布式、跨服务的场景中更为显著。本篇文章提出针对这一问题的解决思路:在火山引擎ByteHouse中构建轻量级流程引擎,来解决数据一致性问题。 应用轻量级流程引擎能够帮咱们应用对立的规范来解决简单业务链路的编排问题,不仅进步业务代码的可读性和复用性,还能更专一业务外围逻辑的开发,让整体流程更加标准化、规范化。 总结来说,应用流程引擎有以下劣势: 轻量级,接入不便,内存操作,性能有保障易保护,流程配置与业务拆散,反对热更新易扩大,丰盛的执行策略及算子反对大体思路上图为ByteHouse企业版治理平台性能架构图。从该性能架构图能够看出,ByteHouse外围能力都是依赖ClickHouse集群,对于集群节点多、数据计算量大的业务场景,容易呈现节点状态不统一的问题,因而保障ClickHouse集群间的状态一致性是咱们的外围诉求。 为了保证数据一致性,ByteHouse提供了以下能力: event engine: 事件处理核心workflow engine:轻量级流程引擎对账零碎保障数据一致性最简略的形式是通过状态机来监听流程执行过程: 首先,将所有的工作申请下发到event engine,由event engine将工作散发对应的handler执行,对立治理所有下发工作的生命周期,并提供异步重试、回滚弥补等性能。流量汇总到event engine当前,会让服务后续的业务扩大更加便捷。其次,对于比较复杂的工作申请,咱们能够下发到workflow engine执行,由workflow生成实例,并编排工作队列,治理流程执行实例的生命周期,对立失败回滚,失败重试。最初,对于服务不可用等非凡场景产生的脏数据,由对账服务兜底。 架构设计在流程监控的架构设计中,次要蕴含以下: 流程管理层:次要负责流程配置的解析初始化,并实现编排策略的工作策略behavior层:编排执行节点,并下发执行工作到执行器执行器:治理执行节点执行执行节点:负责业务具体实现 实现计划执行节点 流程引擎的外围为“责任链”,依照责任链上的节点程序顺次执行所有工作,所以咱们须要的三个根本单元别离为: request:入参processlist:流程执行节点listresponse:出参在研发工作中,咱们时常会遇到以下问题: 如果同时呈现了一个问题,node1、node2、node3之间的数据交互如何实现?如果node1入参、出参加node2,node3不一样该如何解决?参数类型不同的node又该如何对立调度?最简略的解决方法,是让node应用雷同的上下文信息,将整个执行node模版化。咱们让所有的执行节点node实现雷同的接口Delegation,对立应用雷同的上下文executionContext作为执行办法的入参。 对于流程中的request和response,咱们能够放入executionContext中,让每个执行节点都能够通过上下文操作response。 // Delegation -type Delegation interface { Execute(ctx context.Context, executionContext ExecutionContextInterface) apperror.AppError TryExecute(ctx context.Context, executionContext ExecutionContextInterface) apperror.AppError ConfirmExecute(ctx context.Context, executionContext ExecutionContextInterface) apperror.AppError CancelExecute(ctx context.Context, executionContext ExecutionContextInterface) apperror.AppError Code() string Type() value.DelegationType}执行策略如果确定好了最小的执行节点,咱们须要思考到,业务场景并不会永远程序执行node,再返回后果,流程执行过程中跳转、循环、并发执行都是比拟常见的操作。思考不同业务场景复用性,咱们在执行节点之上加了一层执行策略,用策略behaivor来从新编排触发执行节点的工作。 下图将流程分成了behavior1和behavior2,别离对应不同的策略。简略的策略举例:按程序执行、并发执行、循环执行、条件跳转执行等。咱们能够依据本身业务理论须要定制,后续会有实例介绍。 // ActivityBehavior -type ActivityBehavior interface { Enter(ctx context.Context, executionContext ExecutionContextInterface, pvmActivity PvmActivity) apperror.AppError Execute(ctx context.Context, executionContext ExecutionContextInterface, pvmActivity PvmActivity) apperror.AppError Leave(ctx context.Context, executionContext ExecutionContextInterface, pvmActivity PvmActivity) apperror.AppError Code() value.ActivityBehaviorCode}策略behavior提供有Enter,Execute,Leave三个接口,Enter负责生成执行节点工作instance,Execute负责编排并触发执行工作instance操作,Leave负责跳转到下一个behavior。 ...

August 31, 2023 · 2 min · jiezi

关于大数据:让快更快火山引擎ByteHouse为ClickHouse提速

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群近日,火山引擎数智平台VeDI与DataFun联结举办以“OLAP计算引擎”为主题的直播流动,来自火山引擎数智平台VeDI的产品专家从技术选型、能力剖析、性能优化以及利用场景落地多个角度,介绍火山引擎ByteHouse如何基于ClickHouse实现实时计算能力降级。 据介绍,火山引擎ByteHouse来源于字节跳动多年外部积淀。因为场景越来越丰盛以及数据分析需要增长,业务对于实时数仓的要求也越来越高。首先是数据体量大以及一直增长的问题。早在2019 年,字节外部每天新增的数据量就达到了100TB。其次,在海量数据根底上,因为数据类型多样(包含批式数据和流式数据)、查问需要多样、交互式剖析简单,数据引擎须要具备灵活性。目前,行业Redis、 SparkSQL 等开源计划能够从不同角度满足上述两个需要,然而保护多个开源数据库将导致老本高,抉择一款能够防止老本有限扩大的计算引擎成为字节数据研发首要思考的问题。 ClickHouse性能高、灵活性强,且次要依赖磁盘、老本绝对可控,成为字节跳动外部计算引擎的首选。但原生 ClickHouse 能力难以反对 upset 、实时数据更新等一些场景,在很多层面有局限性,例如: 单表性能强劲,但多表能力局限,且对规范 SQL 兼容性低。不足成熟运维管理工具,运维复杂程度高。ClickHouse 为 MPP 架构(存算一体架构),性能强,但横向扩容老本十分高、数据隔离性差。ByteHouse产品专家在直播中介绍到,“为了解决以上问题,咱们次要从4个方向进行优化,让OLAP引擎能力、性能、运维、架构进一步降级。” 第一,丰盛的自研表引擎,实现OLAP引擎能力进化。 ByteHouse 补救了ClickHouse表引擎的有余,并衍生出全新的表引擎,包含使高可用表引擎、实时数据引擎、Unique 引擎、Bitmap 引擎。以Unique 引擎为例,它解决了社区版 ReplacingMergeTree 实时更新提早问题,真正做到实时 upset。 第二,新增优化器、字典、索引反对能力,实现OLAP引擎性能进化。ClickHouse在多表场景中性能存在缺点,而ByteHouse 通过自研CBO 和 RBO(基于代价和基于规定的优化器),反对了多层嵌套的下推、Join 子查问的下推、Join-Reorder、Bucket Join、Runtime Filter 等优化器个性,做到 TPC-DS 的性能能够达到 99 条sql100%笼罩,极大晋升多表场景下的性能。另外,ByteHouse还反对了全局字典以及更多索引,如 Bitmap index,让查问效率更快。 第三, 自动化、可视化,实现OLAP引擎运维进化。ByteHouse 提供标准化运维、集群衰弱度检测、问题产生时的诊断工具,帮忙运维人员提高效率。例如,集群衰弱度的检测工具,相似于集群的实时巡检,可能报告以后集群状态、呈现了什么问题、问题如何解决,最大水平把问题前置化,升高运维危险。从成果上看, 18000 个节点只须要不到 10 个运维人员来反对。 第四, 存算拆散,实现OLAP引擎架构进化。ByteHouse推出了 MPP 2. 0 即存算拆散架构。一方面, 存算拆散能够更好实现资源隔离,每一个计算工作都会提交到不同的计算资源中,做到用户之间互不影响,还能灵便扩容、缩容存储计算资源;另一方面,存算拆散能做到真正云原生(Cloud native),ByteHouse 存储层既反对 HDFS,也反对 S3 对象或者其余的对象存储,实现云原生部署。 目前,ByteHouse曾经在行为剖析、精准营销、实时监控等业务场景中落地。以实时监控为例,很多互联网APP有线上经营流动、直播电商等业务,数据实时性分外重要。数据从生产到展示在大屏上,提早往往要管制在分钟级甚至秒级以内。而ByteHouse高吞吐性能、查问性能,使数据从输出端到输入端的流程达到秒级。在数据保障层面,ByteHouse 也能精密到Exactly Once 的语义,保证数据不失落、不反复,最终达到数据是高效存储、精确查问。 点击跳转火山引擎ByteHouse理解更多

August 30, 2023 · 1 min · jiezi

关于大数据:企业诊断屋在线小说企业如何用AB测试赋能业务

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群近两年来,在线小说畛域业务倒退“降速”,相较于几年前的疾速扩张,2022年后国内在线小说企业步入瓶颈期。但与此同,新的小说平台层出不穷,对市场和用户的竞争也日益强烈。本期火山引擎A/B测试企业诊断屋,将分享在线小说业务设计A/B试验的思路。 本期火山引擎A/B测试企业诊断屋,将分析一个在线小说品牌,如何一直优化满足消费者需要的企业案例,看在线小说如何利用A/B试验优化产品满足个性化需要、晋升成单转化。企业诊断屋是由火山引擎Datatester测试推出的AB测试行业科普系列内容。千行百业用AB,每个行业、每个职能、业务的每一环节,都有多种AB试验的利用场景;数据能够帮忙企业优化业务效率,迷信的AB试验能够帮忙企业晋升效益。 该小说APP在业务倒退中遇到了三个瓶颈问题:小说内容流传不到位,吸引流量少于预期;同时APP内用户留存和活跃度不够现实;此外,APP内的商业变现始终体现疲软。 针对以上痛点,火山引擎A/B测试帮忙该企业开启了诊断,首先对该在线小说浏览企业业务的5个增长阶段发展剖析,定位到该平台营销不到位、用户体验不佳、会员转化率低的问题;而后通过多组A/B试验的设计,帮忙企业优化了包含人群的精准定位、投放素材匹配、UI及页面的小说举荐排布、会员交易链路的优化等场景,晋升了企业盈利。 火山引擎DataTester助力在线小说企业优化四部曲A/B测试优化用户体验当用户被胜利吸引进入产品,他们的留存很大水平上是受产品应用体验的影响。而企业在火山引擎A/B测试的帮忙下,针对用户体验进行了性能优化和疾速解决用户需要的优化。在线小说产品的用户,第一需要是疾速找到感兴趣的小说,帮忙用户顺利找到想要的作品,给用户举荐合乎情意的作品体验尤为重要。 登录链路优化:用户登录率始终是小说平台须要均衡的问题。如果强制登录能力应用全副性能,会散失不违心登录的用户;如果容许用户不登录即可应用全副性能,登录率低下,则会损失个性化服务的机会成本,使平台无奈提供向用户个性化举荐小说等服务。所以如何在放弃用户应用的前提下,晋升登录率,是一个值得剖析的问题。小说企业为了做到用户体验和晋升登录的均衡,针对有无登录提醒以及不同的登录提醒地位利用火山引擎A/B测试设计试验进行对照,再依据试验后果得出的登录率和小说浏览率等指标进行比照。 首页UI排布优化:首页是拜访用户最多的页面,展现优质的小说,能够让用户疾速获取本人感兴趣的小说内容,实现小说浏览以及后续的付费动作。好的首页布局能够让用户疾速get到APP价值,晋升用户对平台的趣味和用户粘性。 内容举荐优化:好的内容排布可能晋升用户体验,可能更精确地疏导用户。小说APP的小说内容排布等各种设计须要优化时,都能够通过试验来验证,通过试验的数据来评估计划、进行决策。 搜寻优化:当用户在举荐的小说中未找到感兴趣的内容时,或者有本人的明确指标爱好后,会通过搜寻来疾速找到本人所需内容,所以通过搜寻举荐的内容对在线小说平台十分重要。小说企业通过火山引擎A/B测试设计试验,比照决定是否在搜寻页减少其余小说举荐内容,也能够通过试验验证不同的搜寻页举荐不同的搜寻内容是否对指标晋升有帮忙。 性能优化:新性能的摸索能够保障产品的继续优化。小说企业通过A/B试验验证新的签到性能上线是否达到了预期成果。通过试验失去的后果是——“7日签到”策略次日支付率晋升近22%,预估策略最终成果,用户多日留存稳固晋升0.4%+,LT将晋升2%。基于试验后果,该小说企业才将该签到性能上新,对APP进行了进一步的优化。加载性能优化和拜访性能优化同理,小说企业针对加载页面做技术指标的关注,利用火山引擎A/B测试进行了一些技术优化类试验。 A/B测试减速商业化过程在要害的商业化转化环节中,任何一个小的优化都对业务帮忙微小。小说企业须要通过试验,来一直验证每一次小扭转对业务的帮忙。为了抉择出可能更好突出不同的开明会员重要信息、开卡益处等的UI以及文案,以此减少用户开卡志愿。火山引擎A/B测试帮忙企业进行了UI类试验和文案类试验,帮忙企业进行决策。 A/B测试优化经营策略吸引用户是第一步,只有让用户来到APP,才有下一步的留存与转化。该在线小说APP有很大一批注册后不沉闷的“沉睡”用户,通过经营伎俩让他们沉闷起来,是企业要做的第一步。在这个环节中,有几个场景能够通过A/B测试大幅晋升经营效率。 推送优化:不同的文案,对于用户的吸引力是不一样的,好的文案可能让用户有趣味理解并点击下载。小说企业应用火山引擎A/B测验进行试验,比照不同文案和不同推送渠道的转化成果,通过最终试验后果得出文案和推送渠道的最优推送形式。 弹窗优化:弹窗作为在产品内强触达的揭示,是十分大的流量导入渠道,每一个细节的调整和优化都意义重大。该小说企业针对弹窗UI设计和文案,通过火山引擎A/B测试设置试验,同时针对用户进入APP后的动作指标设置试验。以此达到比拟不同弹窗素材对用户行为的影响以及确定哪种素材对用户更有吸引力的目标。 火山引擎DataTester源自字节跳动长期积淀,作为助力企业科学决策的A/B测试平台,DataTester目前服务了包含美的、失去、凯叔讲故事等在内的上百家企业,为业务的用户增长、转化、产品迭代、经营流动等各个环节提供迷信的决策依据,将成熟的“数据驱动增长”教训赋能给各行业。 点击跳转火山引擎A/B测试理解更多

August 30, 2023 · 1 min · jiezi

关于大数据:火山引擎-DataLeap-助你拥有-Notebook-交互式的开发体验

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群Notebook 是一种反对 REPL 模式的开发环境。所谓「REPL」,即「读取-求值-输入」循环:输出一段代码,立即失去相应的后果,并持续期待下一次输出。Notebook通常使得探索性的开发和调试更加便捷,在 Notebook 环境,用户能够交互式地在其中编写你的代码、运行代码、查看输入、可视化数据并查看后果,应用起来非常灵活。 在数据开发畛域,Notebook 广泛应用于数据清理和转换、数值模仿、统计建模、数据可视化、构建和训练机器学习模型等方面。 然而显然做数据开发,只有 Notebook 是不够的。目前,火山引擎 DataLeap 数据研发平台提供了工作开发、公布调度、监控运维等一系列能力,并将 Notebook 作为一种工作类型,退出进 DataLeap 数据研发平台,使用户既能领有 Notebook 交互式的开发体验,又能享受一站式大数据研发治理套件提供的便当。 在火山引擎 DataLeap 数据研发平台,开发过程围绕的外围是工作。用户能够在我的项目下的工作开发目录创立子目录和工作,像 IDE (集成开发环境)一样通过目录树治理其工作。Notebook 也是一种工作类型,用户能够启动一个独立的工作 Kernel 环境,像开发其余一般工作一样应用 Notebook。 图:火山引擎 DataLeap 数据开发 Notebook 工作界面 基于简化运维老本、升高架构复杂性,以及进步用户体验的思考,2021 上半年,火山引擎 DataLeap研发人员对整体架构进行了一次改进。新的架构次要做了以下改良,大抵简化为下图 移除 JupyterHub(https://jupyterhub.readthedocs.io/en/stable/),将 JupyterLab (https://jupyterlab.readthedocs.io/en/stable/getting_started/o...)改为多实例无状态常驻服务,并实现对接 火山引擎DataLeap 的多用户鉴权。革新本来落在 JupyterLab 本地的数据存储,包含用户自定义配置、Session 保护和代码文件读写。Enterprise Gateway(EG)反对长久化 Kernel,将 Kernel 近程环境元信息长久化在远端存储(MySQL)上,使其重启时能够重连,且 JupyterLab 能够晓得某个 Kernel 须要通过哪个 EG(https://jupyter-enterprise-gateway.readthedocs.io/en/latest/) 连贯。图:火山引擎 DataLeap 下改进版 Notebook 整体架构 架构降级简化后,整套 Notebook 服务的稳定性取得了极大的晋升。因为实现了用户无感知的降级, DataLeap不仅晋升了用户的应用体验,运维、算力、人力等老本也失去了极大地升高。 据理解,Notebook 工作已成为字节跳动外部应用较为高频的工作类型。内部用户能够购买火山引擎 DataLeap,即一站式大数据研发治理套件,开明交互式剖析的版本,应用到 DataLeap 的 Notebook 工作。 ...

August 30, 2023 · 1 min · jiezi

关于大数据:基于预测的云资源弹性伸缩框架MagicScaler实现高QoS低成本双丰收

开篇近日,由阿里云计算平台大数据根底工程技术团队主导,与计算平台MaxCompute团队、华东师范大学数据迷信与工程学院、达摩院单干,基于预测的云计算平台资源弹性伸缩框架论文《MagicScaler: Uncertainty-aware, Predictive Autoscaling 》被数据库畛域顶会VLDB 2023接管。 MagicScaler论文提出了一种翻新的基于预测的云资源被动弹性伸缩框架 MagicScaler,该框架次要蕴含一个基于多尺度注意力高斯过程的预测模型和一个思考需要不确定性的弹性伸缩优化决策器。论文在阿里云云原生大数据计算服务MaxCompute 3个集群的实在数据集上进行了试验,综合老本和QoS两个层面,MagicScaler要显著优于其余经典的弹性伸缩算法,实现了“高QoS(Quality of Service),低成本”的双丰收。 背景云计算需要的日益倒退,基于用户需要正当地进行云资源分配是保障稳定性和管制老本的重要因素。图1所示是三种易于了解的扩缩容策略,激进(Conservative)策略会提供“激进、虚高”的 ECS 供应量,但会造成较高的资源节约;被动(Passive)策略是用户的需要达到后才执行扩缩容决策,会因为资源“冷启动”问题导致 QoS 守约的危险;为集成这两种策略的长处,预测式主动扩缩容(Predictive Autoscaling)策略能够了解为“提前晓得用户需要”后执行扩缩容决策,这将最有可能作为实现图 1 中现实境况的路径。 $$图 1:三种易于了解的 AutoScaling 策略:a) 激进策略:高老本,低 QoS 危险;b) 被动策略:较低成本,高 QoS 危险;c) 现实策略:低成本,低 QoS 危险。$$ 现有的主动扩缩框架次要基于管制实践、强化学习、排队实践或基于规定生成扩所容决策,这些办法要么仅应用了较为简单的预测算法,如历史一段时间的均匀需要,并未思考需要可能存在的周期性以及需要的不确定性,使得预测精度不高,且难以应答需要的多变性。局部现有钻研仅以启发式办法解决需要的不确定性,难以失去持重的扩缩容决策。现实的扩缩容框架须要在预测和扩缩容决策阶段都充分考虑需要的不确定性。此外,现有的主动扩缩容框架并未思考云资源弹性伸缩场景中的一些业务属性和实在束缚,例如弹性资源在扩缩容阶段会经验的冷启动、退回老本,云平台场景下QoS和老本之间的衡量束缚等,因而现有的这些主动扩缩容框架难以间接利用于阿里云计算平台的弹性伸缩场景中。 挑战云计算需要的日益倒退,基于用户需要正当地进行云资源分配是保障稳定性和管制老本的重要因素。图2展现了阿里云云原生大数据计算服务某个集群在不同数据粒度下的资源申请状况(数据已作脱敏解决),能够看出云上用户需要往往具备高度复杂性、不确定性和粒度敏感的工夫依赖性,这给将来需要的精确预测带来了肯定艰难,也使得被动弹性伸缩更具挑战性。一个好的被动弹性伸缩策略须要在思考需要不确定性的同时,放弃云平台低运行老本和高QoS之间的正当均衡。 $$图2 某集群不同数据粒度下的资源申请状况$$ 破局本文提出了一种翻新的基于预测的云资源弹性伸缩框架 MagicScaler。该框架次要蕴含一个基于多尺度注意力高斯过程的预测模型和一个思考需要不确定性的弹性扩缩容优化决策器,以实现“高QoS(Quality of Service),低成本”双丰收的指标。图3形容了 MagicScaler 的整体框架,蕴含预测器和调度器两局部。 $$图3 MagicScaler整体框架$$ (1)预测器:预测器局部次要构建了基于多尺度注意力机制的高斯回归预测模型。该预测模型设计有机交融了两种高效的预测策略:一是多尺度注意力机制,可能捕获简单的多尺度特色;二是随机过程回归,以量化预测后果不确定性。这使得预测模型能够实现准确的需求预测,联合量化的不确定性为后续的弹性伸缩打下基础。图4形容了预测器的整体框架,预测器的输出为 时刻回看的历史需要序列 。通过 MAFE(多尺度特征提取)组件提取这个工夫序列特色,记为 。将 输出至 GPR(高斯过程回归)模型,并以此预测将来 步工夫的需求量。 $$图4 预测器流程$$ (2)调度器:调度器局部设计了基于预测后果和量化不确定性的弹性扩缩容优化决策器。将简单业务场景建模为马尔可夫决策(MDP)过程,并利用滚动时域优化的办法近似求解最优策略,实现了资源老本与 QoS 违规危险之间的灵便均衡。图5展现了调度器流程,包含马尔可夫决策过程(MDP)、优化器和弹性伸缩决策执行器。咱们的弹性伸缩器以概率需求预测散布作为输出,将弹性伸缩问题建模为马尔可夫决策过程。因为思考到MDP优化是一个有限域贝尔曼方程优化问题,咱们应用滚动时域优化策略,将贝尔曼方程在有限时域内的求解转换为无限时域内的随机布局,从而使得可能找到最佳策略来近似贝尔曼方程的最优解。 $$图5 调度器流程$$ 论文在阿里云云原生大数据计算服务MaxCompute 3个集群的实在数据集上进行了试验,综合老本和QoS两个层面,MagicScaler要显著优于其余经典的弹性伸缩算法,更多试验后果请参阅咱们的论文原文。 利用后续将进一步钻研如何将MagicScaler技术与MaxCompute现有调度策略联合。 论文题目:MagicScaler: Uncertainty-aware, Predictive Autoscaling论文作者:潘志诚,王益杭,张颖莹,杨斌,程云爻,陈鹏,郭晨娟,文青松,田西夺,窦云亮,周志强,杨程程,周傲英,杨彬论文链接:https://www.vldb.org/pvldb/vol16/p3808-yang.pdf点击立刻收费试用云产品 开启云上实际之旅!原文链接 本文为阿里云原创内容,未经容许不得转载。

August 29, 2023 · 1 min · jiezi

关于大数据:for-字节跳动数据平台数智化转型背景下的火山引擎大数据技术揭秘

摘要:线上面基+学习火山引擎大数据技术干货+精美礼品支付!快来报名参加吧!往年4月,火山引擎在上海举办了秋季 FORCE 原动力大会,正式提出了“数据飞轮”的数字化建设模式。现如今,越来越多的企业也正围绕数据进行深度的价值开掘,用数据全方位地驱动业务增长。如何让数据“谈话”,更好的帮忙企业实现科学决策,并助力企业实现数字化转型?9 月 16 日,火山引擎开发者社区 Meetup 第 12 期暨超话数据专场邀请到了火山引擎数据平台的 5 位专家,将从数据分析、数据治理、研发提效等角度,为大家带来干货分享,帮你全面理解数智化转型背景下的火山引擎数据飞轮模式在数据资产建设上的技术与实际。现场更有火山引擎定制双肩包、抱枕、水杯、帆布袋等超多精美礼品,线下参加才可支付哦,期待与大家现场面基! ⏰ 工夫:2023/9/16(周六)14:00-17:30 模式:线下+线上直播 地点:深圳市南山区高新南九道深圳湾翻新科技核心2栋B座F6-31&32(科苑地铁站C口步行340米) 精彩议程《DataSail CDC数据整库实时入仓入湖实际》 李延加|火山引擎 DataSail 高级研发工程师 演讲介绍:在线数据库数据导入到数仓剖析的链路曾经存在多年,随着近年来实时计算的倒退,业务心愿有提早更低、运维更便捷、效率更高的CDC同步通道。本次分享次要介绍DataSail实现CDC整库实时同步的技术计划和业务实际。 次要内容: CDC数据同步对业务的价值DataSail CDC同步实现技术计划业务最佳实际听众受害: 理解DataSail整库实时同步背地的技术理解DataSail整库实时同步产品的能力《火山引擎 EMR 基于 Proton 的存算拆散实际 》吴志平|火山引擎 EMR 研发工程师 演讲介绍:基于对象存储的存算拆散架构,在晋升零碎稳定性,进步资源利用率,升高运维老本的同时,在大数据量剖析场景下也面临着一些外围挑战:HDFS与对象存储之间的语义差别;存算拆散之后带来的较大性能损耗。EMR团队针对这些挑战自研了Proton减速引擎,深度优化对象存储读写能力,与Hive/Spark/Trino等计算引擎集成后,在不扭转用户应用习惯的前提条件下,可提供对象存储数据集的通明减速服务。在离线场景下,其性能根本持平存算一体架构。本次分享将介绍Proton技术能力和最佳实际。 次要内容: 存算拆散的挑战以及解决方案Proton介绍以及原理剖析Proton最佳实际听众受害: 理解对象存储和HDFS的差别理解Proton的根本能力以及实际形式《字节跳动基于 DataLeap 的 DataOps 实际》黄虹|火山引擎 DataLeap 产品经理 演讲介绍:随着数字化转型的推动以及业务数仓建设不断完善,大数据开发体量及复杂性逐渐回升,如何保证数据稳固、正确、继续产出成为数据开发者外围诉求,也成为平台建设面临的挑战之一。本次分享次要介绍字节对于DataOps的了解 以及 DataOps在外部业务如何落地实际。 次要内容: 字节数据研发面临的挑战字节 DataOps 定义DataOps 产品化计划业务最佳实际听众受害: 理解 DataOps 理念理解 DataOps在字节业务的最佳实际《基于 ByteHouse 引擎的增强型数据导入技术实际》孔柏林|火山引擎 ByteHouse 产品经理 演讲介绍:ByteHouse基于自研HaMergeTree,构建增强型物化MySQL、HaKafka引擎,实现数据疾速集成,减速业务数据分析性能与效率,本次talk次要介绍物化MySQL与HaKafka数据导入计划和业务实际。 次要内容: ByteHouse数据库架构演进加强HaKafka引擎实现计划加强MaterializedMySQL实现计划案例实际与将来瞻望听众受害: 理解Bytehouse基于引擎层数据导入能力MaterializedMySQL和HaKafka在业务中的实际《湖仓一体减速引擎 Bolt 及在 LAS 的利用实际》杨嘉义|火山引擎 LAS 高级研发工程师 ...

August 29, 2023 · 1 min · jiezi

关于大数据:智定义易调整火山引擎DataLeap助力企业轻松实现全流程值班管理

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群近日,火山引擎大数据研发治理套件DataLeap全新上线值班治理模块,企业可通过该模块体系化智能化创立值班打算、治理值班人员,实用于运维排班、值班揭示、打算治理、监控报警等理论利用场景。 值班工作是确保数字化企业及时高效运行的重要伎俩和基础性工作,也是突发事件产生后确保疾速响应、及时报告的关键环节。相比起传统的值班计划表的“牵一发而动全身”,火山引擎DataLeap值班治理能力更加智能灵便易调整。 当有值班打算或假期调整,或在非工作日值班排期中,火山引擎DataLeap可反对将工夫进行细颗粒度的周期性拆分,实现不同的值班工夫配置、来回晦涩切换多组主备值班人。 图:火山引擎DataLeap值班治理能力页面 除了根底的配置主备值班人小组之外,对于值班打算者来说,火山引擎DataLeap可提供自定义值班列表能力,灵便设置繁多值班组的值班工夫、轮转周期和值班人员,依据工夫和周期对值班人员进行排序。 而对于理论值班人来说,火山引擎Dataleap反对值班揭示性能,可自定义抉择邮件、飞书、短信、电话和 Webhook 的形式发送揭示告诉,同时反对附带值班罕用文档、值班人需注意的事项等阐明,给值班打算的交接和按时运行加上了又一层保障。 另外,本次更新的值班治理能力拓展性强,值班管理者能够做到多个值班打算集中管理,看到租户下其余所有值班组排班打算详情、查看值班进度,值班创建人与参加人,可对打算进行编辑操作;同时,反对凋谢API,能够嵌入到程序中调用,也能够应用 API 动静查看值班信息。 值班治理是企业数字化根底能力之一,间接关系到数据运维的安全性、稳定性和可靠性,更须要企业加大投入和长期建设。除了值班治理能力,火山引擎DataLeap还能够提供数据集成、治理、开发、运维、资产等能力,帮忙用户晋升数据研发效率、升高治理老本,减速推动企业的数字化转型,目前曾经利用于泛互联网、制作、新批发、汽车等畛域。 点击跳转大数据研发治理套件 DataLeap理解更多

August 28, 2023 · 1 min · jiezi

关于大数据:合合信息启信宝与全国性股份制商业银行达成合作聚焦产业链数字化管理

实体经济是推动经济增长、保障国家平安的重要根底,产业链供应链则是撑持实体经济倒退的“筋骨血脉”。对于银行等金融机构而言,在盘根错节的供应链体系之下,供应链金融服务须要解决“一对多”关联危险,对业务人员很难具备对应的专业知识、调研精力去把控危险。基于此,合合信息旗下启信宝基于商业大数据技术,优化产业链、供应链数据服务,继续晋升金融服务实体经济质效。 年新增客群超3000户,打消银企“信息差”是要害 为了进一步晋升服务实体经济程度,在政策的指引下,银行围绕重大项目、重点企业和重要产业链,增强场景聚合、生态对接,推出了系列产业金融、普惠金融、绿色金融、科创信贷等专项信贷服务。然而,实际操作中,因为局部中小型银行外部对于新型、中小微企业的数据维度不够丰盛,再加上业务人员不足相干畛域的专业知识,导致了银行“想贷不敢贷”,企业“融资难、融资贵”的恶性循环。 加强资金流动性,让金融服务精准搀扶到实体经济,须要尽力消解银行与企业之间存在的“信息差”,数据在其中表演了重要角色。合合信息是一家人工智能及大数据科技企业,旗下启信宝通过产业链数据库与供应链数据库来帮忙银行补充多维度产业大数据,丰盛行内数据资产,让银行深刻洞察重点产业链龙头企业的上下游产业链关系及供应链关系,推动供应链融资业务数字化降级,更好地服务实体经济高质量倒退。 据悉,相干数据产品已被利用于某全国性股份制商业银行中。该股份行以综合金融反对稳链强链,积极开展供应链融资业务,聚焦汽车、电子、高端制作等产业链纵深较长的实体经济畛域,已推出多款优质产品,以及全流程在线服务、智能审批、主动出账等便捷性能,为供应链的交易主体提供结算、融资、跨境领取、现金管理等综合金融服务,保障重要产业链供应链平安,助力畅通国民经济循环。2022年,该行新增供应链客群超3000户。 商业大数据绘就“产业地图”,助力银行落地精准服务 合合信息旗下启信宝基于商业大数据技术,深度开掘产业链数据与企业供应链数据,构建透明化的产业链供应链交易关系网络,针对产业钻研、对公营销、风险管理等银行各业务条线需要,推出了涵盖产业链关系图谱、供应链关系图谱、区域产业倒退指数、行业景气度指数等多款数据产品,从宏观、中观、宏观各层面助力银行智能化开掘产业商机、洞察产业危险,构建数字化的动静“产业地图”。 银行相干部门可基于数据深度剖析相干产业政策,研判产业倒退现状及变化趋势,评估行业整体及重点企业财务程度,监控行业舆情危险,多维度高效洞察本地重点行业倒退基本面与将来趋势,辅助策略制订与行业定制金融产品设计。 此外,银行还可通过供应链数据库获取外围企业客户的上下游企业名单,通过查看重点产业链上中下游各个环节、对应企业、地区散布等状况,精确把握产业链整体布局,联合多种评分、标签体系,确定龙头骨干企业、重点配套企业、单项劣势企业,并判断其是否为外围供应商及客户,评估主体的市场认可度及综合实力,实现名单制精准对接,晋升服务效率。 目前,启信宝产业链数据库现已蕴含超过280条产业链,笼罩上千万家公司,涵盖新基建、新一代信息技术、高端配备、先进环保、新能源、新资料、大娱乐、大生产、大衰弱等产业板块,根本笼罩了政策反对力度大、发展前景好的重点产业链。

August 28, 2023 · 1 min · jiezi

关于大数据:火山引擎-DataLeap从短视频-APP-实践看如何统一数据指标口径

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群短视频正在成为越来越多人发现世界的窗口,其背地的创作者生态建设是各大短视频 APP 不可漠视的重要组成部分。 为了激励更多优质内容生产,某短视频 APP 常常面向创作者主办投稿流动,而在复盘投稿数据过程中,该团队音乐经营人员在查找「音乐投稿率」指标时,同时搜寻到了「音乐投稿率(音乐元素投稿比例)」,两个指标名称类似,但细究之下含意却天壤之别。 图:某短视频平台举办的创作者流动 不仅仅是「音乐投稿率」这一个指标,该短视频 APP 外部每天都会产生很多相似问题。因为该短视频 APP 旗下业务线比拟多,包含工具、社交等,每个流动协同的业务方多、人员简单,而各业务指标都由本人独自定义,并独立交由不同研发人员开发,由此导致指标扩散、口径不统一。 即便曾经实现研发、经营、策略等各个团队对齐,也可能存在某团队因业务需要调整口径,又未周知其余团队,导致指标再次对不上,影响工作效率,甚至呈现数据误差。为了解决数据指标中存在的种种难题,数据团队基于火山引擎 DataLeap,把建设对立的数据指标治理平台纳入团队重点工作。 据理解,火山引擎 DataLeap 可能解决“灵便数据分析”场景下的找数据、找口径的问题,帮忙客户建设可共享、可视化、服务化的业务指标体系。在机制层面,数据团队自上而下发动数据指标看板建设需要,从各业务指标诉求中形象出对立的标准,并建设投稿数据应用标准。当收到一个新指标开发需要时,先明确指标负责人,其余方向同学则对齐该指标。 举个例子,主端投稿“投稿数”业务指标建设,影像、图文投稿则要对齐该“投稿数”指标的口径。在工具层面,数据团队通过 DataLeap 建设了对立的指标治理平台,辅助以上机制落地。首先,数据团队建设了一个跨业务团队的公共层数据,各业务方的数据均依赖公共层数据表进行加工。其次,基于火山引擎 DataLeap 的“指标平台”能力,将投稿外围指标分类管理,保障指标口径进口一致性。 DataLeap 指标可视化能力,间接屏蔽了底层物理表,帮忙经营等非研发人员,更清晰获取数据指标信息、操作指标变更、实现指标进一步剖析。通过以上办法,该短视频 APP 外部对于数据指标口径的答疑会和讨论会大大减少,一方面进步团队工作效率、指标应用效率,另一方面,也很大水平躲避由指标口径不对立导致的上游数据问题。 随着越来越多公司数据规模的扩充,垂直业务单元会越来越多,而在跨垂直单元数据建设过程中,各种数据不对立、指标集中梳理难、指标对立定义难、指标追溯难等问题更加突出。火山引擎 DataLeap 将提供从指标定义、经营、发现、洞察、品质到生产与反馈的全流程,晋升指标应用效率、升高指标反复开发成本和数据答疑老本,为更多有数据指标建设的企业、行业提供服务。 点击跳转 火山引擎大数据研发治理套件DataLeap 理解更多

August 27, 2023 · 1 min · jiezi

关于大数据:火山引擎DataLeap基于Apache-Atlas自研异步消息处理框架

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群字节数据中台DataLeap的Data Catalog零碎通过接管MQ中的近实时音讯来同步局部元数据。Apache Atlas对于实时音讯的生产解决不满足性能要求,外部应用Flink工作的解决计划在ToB场景中也存在诸多限度,所以团队自研了轻量级异步音讯解决框架,反对了字节外部和火山引擎上同步元数据的诉求。本文定义了需要场景,并具体介绍框架的设计与实现。背景字节数据中台DataLeap的Data Catalog零碎基于Apache Atlas搭建,其中Atlas通过Kafka获取内部零碎的元数据变更音讯。在开源版本中,每台服务器反对的Kafka Consumer数量无限,在每日百万级音讯体量下,常常有长延时等问题,影响用户体验。在2020年底,火山引擎DataLeap研发人员针对Atlas的音讯生产局部做了重构,将音讯的生产和解决从后端服务中剥离进去,并编写了Flink工作承当这部分工作,比拟好的解决了扩展性和性能问题。然而,到2021年年中,团队开始重点投入私有化部署和火山私有云反对,对于Flink集群的依赖引入了可维护性的痛点。在认真的剖析了应用场景和需要,并调研了现成的解决方案后,火山引擎DataLeap研发人员决定投入人力自研一个音讯解决框架。以后这个框架很好的反对了字节外部以及ToB场景中Data Catalog对于音讯生产和解决的场景。本文会具体介绍框架解决的问题,整体的设计,以及实现中的要害决定。 需要定义应用上面的表格将具体场景定义分明。 相干工作在启动自研之前,火山引擎DataLeap研发团队评估了两个比拟相干的计划,别离是Flink和Kafka Streaming。Flink是团队之前生产上应用的计划,在能力上是符合要求的,最次要的问题是长期的可维护性。在私有云场景,那个阶段Flink服务在火山云上还没有公布,外部本人的服务又有严格的工夫线,所以必须思考代替;在私有化场景,火山引擎DataLeap研发团队不确认客户的环境肯定有Flink集群,即便部署的数据底座中带有Flink,后续的保护也是个头疼的问题。另外一个角度,作为通用流式解决框架,Flink的大部分性能其实团队并没有用到,对于单条音讯的流转门路,其实只是简略的读取和解决,应用Flink有些“杀鸡用牛刀”了。另外一个比拟规范的计划是Kafka Streaming。作为Kafka官网提供的框架,对于流式解决的语义有较好的反对,也满足团队对于轻量的诉求。最终没有采纳的次要思考点是两个: 对于Offset的保护不够灵便:外部的场景不能应用主动提交(会丢音讯),而对于同一个Partition中的数据又要求肯定水平的并行处理,应用Kafka Streaming的原生接口较难反对。与Kafka强绑定:大部分场景下,团队不是元数据音讯队列的拥有者,也有团队应用RocketMQ等提供元数据变更,在应用层,团队心愿应用同一套框架兼容。设计概念阐明MQ Type:Message Queue的类型,比方Kafka与RocketMQ。后续内容以Kafka为主,设计肯定水平兼容其余MQ。Topic:一批音讯的汇合,蕴含多个Partition,能够被多个Consumer Group生产。Consumer Group:一组Consumer,同一Group内的Consumer数据不会反复生产。Consumer:生产音讯的最小单位,属于某个Consumer Group。Partition:Topic中的一部分数据,同一Partition内音讯有序。同一Consumer Group内,一个Partition只会被其中一个Consumer生产。Event:由Topic中的音讯转换而来,局部属性如下。 Event Type:音讯的类型定义,会与Processor有对应关系;Event Key:蕴含音讯Topic、Partition、Offset等元数据,用来对音讯进行Hash操作;Processor:音讯解决的单元,针对某个Event Type定制的业务逻辑。Task:生产音讯并解决的一条Pipeline,Task之间资源是互相独立的。框架架构整个框架次要由MQ Consumer, Message Processor和State Manager组成。 MQ Consumer:负责从Kafka Topic拉取音讯,并依据Event Key将音讯投放到外部队列,如果音讯须要延时生产,会被投放到对应的延时队列;该模块还负责定时查问State Manager中记录的音讯状态,并依据返回提交音讯Offset;上报与音讯生产相干的Metric。Message Processor:负责从队列中拉取音讯并异步进行解决,它会将音讯的处理结果更新给State Manager,同时上报与音讯解决相干的Metric。State Manager:负责保护每个Kafka Partition的音讯状态,并裸露以后应提交的Offset信息给MQ Consumer。下一篇将分享此异步音讯框架的实现过程以及线上运维case举例。实现线程模型每个Task能够运行在一台或多台实例,倡议部署到多台机器,以取得更好的性能和容错能力。每台实例中,存在两组线程池: Consumer Pool:负责管理MQ Consumer Thread的生命周期,当服务启动时,依据配置拉起肯定规模的线程,并在服务敞开时确保每个Thread平安退出或者超时进行。整体无效Thread的下限与Topic的Partition的总数无关。Processor Pool:负责管理Message Processor Thread的生命周期,当服务启动时,依据配置拉起肯定规模的线程,并在服务敞开时确保每个Thread平安退出或者超时进行。能够依据Event Type所须要解决的并行度来灵便配置。两类Thread的性质别离如下:Consumer Thread:每个MQ Consumer会封装一个Kafka Consumer,能够生产0个或者多个Partition。依据Kafka的机制,当MQ Consumer Thread的个数超过Partition的个数时,以后Thread不会有理论流量。Processor Thread:惟一对应一个外部的队列,并以FIFO的形式生产和解决其中的音讯。StateManager在State Manager中,会为每个Partition保护一个优先队列(最小堆),队列中的信息是Offset,两个优先队列的职责如下: 解决中的队列:一条音讯转化为Event后,MQ Consumer会调用StateManager接口,将音讯Offset 插入该队列。解决完的队列:一条音讯解决完结或最终失败,Message Processor会调用StateManager接口,将音讯Offset插入该队列。MQ Consumer会周期性的查看以后能够Commit的Offset,状况枚举如下:解决中的队列堆顶 < 解决完的队列堆顶或者解决完的队列为空:代表以后生产回来的音讯还在处理过程中,本轮不做Offset提交。解决中的队列堆顶 = 解决完的队列堆顶:示意以后音讯曾经解决完,两边同时出队,并记录以后堆顶为可提交的Offset,反复查看过程。解决中的队列堆顶 > 解决完的队列堆顶:异常情况,通常是数据回放到某些中间状态,将解决完的队列堆顶出堆。留神:当产生Consumer的Rebalance时,须要将对应Partition的队列清空KeyBy与Delay Processing的反对因源头的Topic和音讯格局有可能不可管制,所以MQ Consumer的职责之一是将音讯对立封装为Event。依据需要,会从原始音讯中拼装出Event Key,对Key取Hash后,雷同后果的Event会进入同一个队列,能够保障分区内的此类事件处理程序的稳固,同时将音讯的生产与处了解耦,反对增大外部队列数量来减少吞吐。Event中也反对设置是否提早解决属性,能够依据Event Time提早固定工夫后处理,须要被提早解决的事件会被发送到有界提早队列中,有界提早队列的实现继承了DelayQueue,限度DelayQueue长度, 达到限定值入队会被阻塞。 异样解决Processor在音讯处理过程中,可能遇到各种异常情况,设计框架的动机之一就是为业务逻辑的编写者屏蔽掉这种复杂度。Processor相干框架的逻辑会与State Manager合作,解决异样并充沛裸露状态。比拟典型的异常情况以及解决策略如下: ...

August 25, 2023 · 1 min · jiezi

关于大数据:途牛科技与火山引擎数智平台合作-打造企业大数据系统降本新范式

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群近日,南京途牛科技有限公司与火山引擎数智平台(VeDI)的单干取得新进展:途牛大数据系统全面迁徙至火山引擎开源大数据平台E-MapReduce。作为国内专一休闲游览的数字一体化游览服务商,南京途牛科技有限公司(以下简称“途牛”)旗下的【途牛旅游网】能够为线上、线下消费者提供包含跟团、自助、自驾、邮轮、景区门票以及公司游览、机票、酒店等在内的产品和服务——“要游览,找途牛”的企业口号,更是被泛滥消费者熟知。 全面精细化的服务背地,是海量数据的积淀和利用。 过来,为了应答蓬勃发展的火线业务,途牛通过IDC(Internet Data Center ,互联网数据中心)自主建设大数据平台,笼罩离线计算、实时计算和OLAP剖析等多个大数据体系,用以撑持包含市场画像剖析、业务计收统计等场景下的业务数据分析需要。 “过后的大数据平台建设次要聚焦于如何更快地解决晚期业务需要,”途牛大数据团队负责人魏超通知记者,“但随着业务本身倒退,一些弊病也逐渐显现出来。” 首先,游览市场近年来产生了比拟大的变动,目前整个市场仍处于恢复期。对途牛来说,如何追随行业环境实现数据建设层面的“降本”正在成为新课题。 其次,本来基于IDC搭建的大数据平台,其数据集群存在单点部署状况,在呈现故障的状况下,易呈现数据失落、复原周期长等问题。 再次,途牛自主建设的大数据平台组件版本较旧,甚至存在不再保护的版本,当问题呈现时难以高效找到解决方案。 最初,途牛也心愿有业余的服务团队,可能一站式帮助运维大数据平台,进一步管制人力老本。 在充沛沟通并拆解途牛的外围诉求后,火山引擎数智平台为其引入了火山引擎开源大数据平台E-MapReduce(以下简称“EMR”): 通过可弹性膨胀的数据存储、查问和剖析服务,途牛能够依据本身变动的业务需要按需应用,实现理论应用和产品服务规格上的匹配,正当管制老本。 在数据集群部署上,EMR反对一键创立多个数据集群,并将生产集群和开发集群作出区隔,避免其中某个集群呈现问题影响其余集群数据。 当途牛在平台运维上遇到问题时,火山引擎EMR团队可提供24小时运维反对服务,更好更快地帮忙解决问题。 目前,途牛曾经将原来的大数据系统全面迁徙至EMR,在综合比拟前后运维数据后发现,通过EMR的使用,途牛的大数据作业效率晋升一倍以上。 点击跳转火山引擎数智平台VeDI理解更多

August 23, 2023 · 1 min · jiezi

关于大数据:字节跳动基于DataLeap的DataOps实践

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群本文依据 ArchSummit 寰球架构师峰会(深圳站)来自抖音数据研发负责人王洋的现场分享实录整顿而成(有删减),本次分享次要蕴含字节跳动数据研发的模式与挑战、DataOps理念在字节的具象 、DataOps产品化及落地、最佳实际、将来瞻望五个局部,分享内容皆来自于字节跳动业务实践经验。字节跳动数据研发的模式与挑战中台工具+数据BP模式字节在落地DataOps的过程当中,与咱们数据反对所采纳的中台工具+数据BP的组织模式相结合,由中台工具团队负责打造性能的基座,实现了数据开发的各项根底能力并提供开放平台,对数据BP团队提供贴身的技术支持,同时也将这些能力通过火山引擎以内外一体的模式输入。所谓的内外一体是指字节的各类数据工具如DataLeap在面向内外部用户应用上实现了一致性。对于数据BP团队来说,在落地DataOps的过程中,重点做了三件事件:第一件事是标准的制订,在字节外部长期实践过程中,咱们认为实际团队才是标准的最佳发源地;第二件事是基于中台工具的开放平台实现插件的开发,数据 BP并不是一个纯数仓团队,其中也蕴含了局部工程团队,与数仓一体的工程团队能够将数仓日常的痛点以插件的模式实现并落地,不同数据BP团队能够依据本人的特点开发不同插件;最初一件事是收益评估,DataOps推广完了之后,也是放在 BP 来评估,而不是放在平台来评估,中台工具团队就能够专一于能力自身,开发数据 BP 团队专一于整个标准跟价值。最初内部客户能够同时享受到咱们的平台能力,以及积淀下来的 BP 模式,这就是字节整个团队在DataOps上落地的合作模式。 数据BP的外围指标:0987数据BP团队做的好坏与否如何来评估,咱们用了一套浅显易懂的指标0987来评估0指不要出数据事变,这里的事变包含了时效、品质等问题,因为咱们反对了较多线上和资损场景,事变在咱们的评估体系中是生命线;9指需要满足率,咱们承接了来自多方的数据需要,心愿能达成90%以上的需要咱们都能按期交付的指标;8指剖析覆盖率,这个指标指内部团队基于数仓的查问能80%应用到通过咱们建设和汇聚的表,而非原始表;7指NPS 指标,咱们每个季度会面向所有提需用户和数据应用用户发放问卷,收集对应的反馈信息,70%意味着大部分的同学对咱们持正向评估且负向评估趋近于0; 来自品质挑战在字节数据团队以后的反对模式下,因为反对模式多种多样,笼罩了各类外围决策及线上场景,咱们遇到的首要挑战是来自数据品质的: 链路简单:最长工作全链路节点数量上千个,单个工作的的上游数量最大也达到了千级别变更频繁:每周仅直播数据团队数据链路变更次数就能达到上千次,波及危险场景上百次事变易发:质量事故时有发生,22年全年数据研发事变波及到研发标准的占比56%来自硬件老本的挑战在降本增效大背景下硬件老本也逐渐变成数据团队的一个外围挑战,在过来咱们管制老本与大多数公司统一,次要基于估算,先测算出一个全年计算和存储资源指标,而后基于估算发展治理动作,清理有效工作或升高TTL;然而当初须要朝着需要的精细化管制方向后退,须要进一步看清楚我做这个需要须要多少硬件老本,从而将硬件老本的管控精细化到需要层面 来自人效的挑战除去硬件老本外,咱们的另一个老本大头就是人力老本,我当初带一个数据研发团队,在每次进行HC盘点的时候我都会遇到两个灵魂发问: 如何证实团队以后的状态是高效的?如何用更少的人员发明更大的业务价值?这其实是一个很事实的挑战,咱们如何证实一个数据团队它的价值是什么? DataOps理念在字节的具象既然面临着这么多的挑战,咱们就要去思考如何可能冲破这些挑战,从业内取经,咱们发现DataOps就是一种可能无效帮忙咱们解决上述问题的计划 信通院对于DataOps的定义数据研发经营一体化(DataOps):是数据开发的新范式,将麻利、精益等理念融入数据开发过程,通过对数据相干人员、工具和流程的从新组织,突破合作壁垒,构建集开发、治理、经营于一体的自动化数据流水线,一直进步数据产品交付效率与品质,实现高质量数字化倒退。 咱们的了解DataOps是作用于人+流程+工具的一套方法论,指标是进步数据品质和开发效率,次要通过麻利合作、自动化/智能化、以及清晰的度量监测,让数据流水线达到继续集成、部署、交付(CI/CD),在DataLeap体系内,DataOps次要以标准研发流程为目标,涵盖对标准研发流程的“已有能力集成”,造成一站式研发体验,同时也包含标准研发流程所需要害的“新能力建设+集成”,除此以外的数据开发根底能力迭代不作为DataOps的一部分咱们认为 DataOps 的外围包含以下局部第一个是链接,所谓的链接是要买通从需要、开发、资产、用户整个数据全链条的绑定关系。从性能上来讲它比较简单,解决了需要与代码的关系问题,业务研发侧早就曾经实现了这个能力,研发人员提交的每一段代码,都能晓得是哪个需要。然而在数据开发这件事件上,过来不足关注,所以首先须要做的事件是连贯需要跟数据全环节。第二个是标准,过来数据研发整个全流程较为不足标准的产品化,次要通过团队外部的文档要求来承载,包含提需评审、模型开发测试、上线验收这些环节,咱们认为 DataOps在标准下面最首要的事件是要把所有数据研发过程中的这些散落的标准产品化并嵌入到日常的开发链路中 DataOps产品化及落地-DataLeap这张图展示的是字节数据开发的dataleap套件能力,涵盖了计算引擎、全链路开发、全域治理、资产等工具,这样的一站式大数据开发套件,可能帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据研发工作,帮忙数据团队无效的升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。DataLeap不是一个产品,是一个套件(Suite)。形象的类比就是相似Office,多个产品相互配合,解决同一个大的问题或者叫解决方案,产品之间是相互合作辅助的关系。 DataOps麻利标准研发平台这是字节整个 DataOps 的产品化的整体框架图,外围提供的一套DataOps麻利标准研发平台。以前有一种模式是平台团队本人全包,把这些所有的标准全副给制订好,由平台团队推给数据开发团队,但这种模式不太适宜咱们,因为平台团队离业务远。咱们认为在这种状况下平台应该抉择优先提供凋谢的能力,这里的凋谢能力包含凋谢数据与接口、凋谢流程等等,有了这套凋谢能力,意味着所有的数据开发团队能够本人去编排流程,去做本人的规定标准。另外咱们发现开发团队做好之后,这套DataOps麻利标准研发平台在所有的数据开发团队都通用,举个例子,测试的能力在字节不是在平台做的,有专门的数据 BP 团队,实时这块有非凡诉求:公布完了之后数据要做盯盘,盯住实时数据的变动。依靠开放平台提供的数据反对,在直播场景下会提供给到主播一些实时的数据,去辅助他们做及时的决策。这些实时数据包含用户的数据、用户的画像等等,主播能够基于这些用户的画像去调整话术。基于开放平台 ,数据BP团队做工作的整个公布能力,之后咱们发现这套能力能够通用。 需要治理简略的给大家看一下字节当初曾经上线的外部版本的性能,包含了需要治理的各个维度,当然需要治理这里其实外围的思路是让需要可能进入到数据研发的全流程当中,大家能够看到咱们会做需要的准入要求,以及跟开发过程以及交付绑定,而后需要的进度追踪、价值评估等相干的一些事件,这是一个规范需要流水线,是字节需要治理平台上的一套流程,就是从需要开始,初评、详评、排期、研发验收、价值反馈完结。这是需要绑定页面,在做工作开发的时候须要对以后的一些需要做绑定,当然这只是提供了需要绑定开发环节的一个图,咱们也会有包,比如说资产环节以及工作环节等各种批改环节都会跟需要做绑定。这个性能很简略,然而需要的全链路串联为字节带来的收益十分大,解决了第一个是可度量所有全流程的问题。 流水线治理第二个是流水线治理,字节的流水线治理包含测试流水线、公布、离线、实时工作治理、工作优先级治理等相干的能力,这是当初线上跑的一个工作,跑完的流水线的状态,就发布会做注销、检测、查看、review,而后定时公布工作、盯盘等确认等相干的动作。重点讲一下这里的公布跟测试环节,这两块在很多公司其实是有测试环境的,然而在数据量特地大的场景和数据,或者较为简单的场景下测试环境是没数据的。测试环境跟业务研发相比,没方法涵盖各种各样的问题,比如说银行场景下测试环境和生产环境必定是隔离的,然而在字节这种互联网场景下咱们的抉择是不拆散,咱们的公布和测试其实是基于的是同一套数据,同一套环境,那如何做测试跟生产的一个隔离?外围点在于咱们要求所有没有通过公布流水线的工作是不能写生产的表的,读任何生产的表,然而不能写任何生产的表。这样带来的益处是咱们的测试和生产是完全一致的,同时也能保障测试完了之后间接推到生产下来,这样下来前面的测试、 QA 染指的老本是极其低的,这是字节采纳的一种形式。 最佳实际推广经营:如何在公司范畴内大规模落地DataOps?做了这些工具之后要如何去推广?这也是今年初字节面临的问题,就是如何在公司内大范畴去落地 DataOps 的能力。最早开始推得很辛苦,也遭逢了很多挑战,不过也总结了一些教训。 鲶鱼效应第一个叫做鲶鱼效应,所谓的鲶鱼效应因为是数据BP 在主导这件事件,所以主导团队能够先推起来。比如说在直播场景下先试用拿到十分多的指标,总结经验,咱们能够带着这些指标和教训去和其余团队沟通,以进步人效的角度切入,在这种状况之下,有的团队就会违心来学习试用。 拆箱即用第二个是拆箱即用,咱们向其余 BP 团队提供的时候,其余 BP 团队不须要多做任何其余的事件,只须要关上他的流程开关就 OK 了,切换门路老本是非常低的。 自顶向下第三个是自顶向下,相似的像 DataOps 这种工具跟能力,肯定是须要先拿到自顶向上,或者是来自于业务侧更高层的认可之后,才可能继续一直地往下推,相似标准的事件,不是一个自下往上能推得起来的。 指标牵引一个研发 leader 必定会关注研发效力问题,这里给大家分享一套字节基于研发效力的指标牵引体系,该体系有四个维度的度量指标,包含效率、品质、资源投入、收益等相干的一些指标。这些指标是咱们参照业务研发来造成了一套数据研发指标体系,咱们会去关注数据需要的交付周期、定容率、交付数、缺点修复时长、线上事变、业务研发的配比。最初是重点专项相干的一些事件。这外面除了最初一个是须要人工去干涉的,其余的当初都能做到线上化的统计,这是十分不便的。 管理者视角所谓管理者视角是围绕数据开发团队的价值和将来,通过凋谢让数据团队有可输入的业余价值。对于数据团队来讲有两类价值,一类叫做业务价值,一类叫做业余价值。业务价值很好讲,是我为业务做了多少个需要,其中哪些重点项目重点参加了,最初是为业务带来了多少效率上的晋升,通过某些数据的伎俩让业务拿到了多少收益。其次是专业性的价值,这个事件对于很多数据团队来讲是一个很困扰的难题,数据团队到底在业界、在公司外部有哪些是不可代替的?有哪些是专业性的货色?这里咱们在做 Datops 实际的时候,发现通过凋谢让数据团队本人有可输入的专业性价值,这十分要害,这能让数据团队很充沛地来参加到这件事件当中来。 开发者视角在开发者视角层面,外围的事件是如何取得工作当中的成就感,这一点是留住人的要害: 认可&执行:标准自身是反兽性的,在团队内落地DataOps须要充沛沟通,联合团队调整与集体倒退,讲清为什么,防止粗犷落地参加&奉献:构建人人可参加的开发环境,让数据开发能够深度的参加到流程制订与落地的过程中来,促成集体影响力的晋升 收益度量落地DataOps的收益次要蕴含标准、品质、效率三局部,具体来看: 标准:在不同方向上标准制订与复用,保障流程100%落地品质:系统性的解决危险场景上的研发流程问题,因研发流程导致的数据质量事故数归0效率:通过更牢靠的交付防止返工,同时叠加提效能力,预计可晋升研发在业务需要满足中的开发效率10%+ 将来瞻望业务价值最初是对于数据研发将来的瞻望,首先想谈谈业务价值: 数据需要价值度量规范基于需要价值最大化的调度策略数据需要的价值度量绝对性能需要而言更为简单,所以下一阶段咱们是心愿可能度量分明数据需要的具体价值,而后实现基于需要价值最大化的调度策略,从而达成咱们对于人效和老本的控制目标。 品质与效率关于品质与效率,将来咱们会次要关注以下三点: 基于大模型的需要对接能力基于大模型辅助开发的能力低成本的数据测试及验证能力最近大模型特地火,咱们认为大模型参加数据研发是十分具备现实意义且具备挑战的事件,不管从需要对接还是辅助开发视角上,大模型都能为咱们提供更多自动化计划应答过来须要依赖教训积淀能力解决的问题;同时咱们发现在字节的数据规模下数据测试的老本是十分高的,将来也心愿摸索低成本的数据测试的验证计划。 对外开放DataOps理念在字节落地的成绩后续也会通过火山引擎DataLeap对外输入。火山引擎DataLeap是一站式数据中台套件,可能帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设,帮忙数据团队无效的升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。 点击跳转火山引擎DataLeap理解更多

August 23, 2023 · 1 min · jiezi

关于大数据:查询速度最高提升50倍火山引擎ByteHouse在广告投放领域实践分享

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群据QuestMobile报告显示,挪动互联网曾经进入了下半场,在应用人数和应用时长方面曾经没有显著增长,互联网曾经流量趋于饱和。 作为广告投放次要阵地,因为互联网平台流量红利逐步消退,越来越多的广告企业和从业者开始摸索精细化营销的新门路,取代以往的全流量、粗放式的广告轰炸。精细化营销意味着要在数以亿计的人群中优选出那些最具后劲的指标受众,这无疑对提供根底引擎反对的数据仓库能力,提出了极大的技术挑战。 在人群圈选剖析中, 分析师个别利用各种标签组合,挑选出最合适的人群,进而实现广告推送,达到精准投放的成果。但因为人群查问在不同标签组合下的后果集大小不同,在一次广告投放中,分析师须要通过屡次的逻辑调整,以取得"最好"的人群包。抖音团体领有宽泛的广告投放场景,在日常实际中,咱们发现以下痛点问题: 首先,数据预估。广告主须要对选定的人群组合进行预估,以便判断投放状况并确定投放估算。但广告平台用户越来越多,有的平台DAU达到上亿,使得人群包数据量过大,技术上只能采纳1/10抽样存储,将导致10%误差。其次,性能问题。为了保障人群圈选精准度,广告主往往会设定多样、简单的人群圈选条件,导致底层计算逻辑简单,比方单次计算可能蕴含几百,甚至上千个人群包。Hive和Elasticsearch等计划在解决大数据量时,查问速度慢。如果研发人员查问某个广告主的所有用户,该计划须要扫描整个用户库,整个过程须要几分钟甚至几个小时,无奈满足广告主实时性要求。最初,存储问题。Hive和Elasticsearch等计划须要额定的索引构造,使得存储空间变大,导致成本增加。在以往,研发团队通常应用两种计划来解决以上问题:计划一:将每个人群包存储为一个Array类型的数据结构,每次查问须要从Array中找到某一个特定ID。计划二:应用一个表来存储用户ID,在查问的时应用In/Join计算多个人群的交加。 通过外部长期应用教训,无论是计划一或计划二,都存在当数据量逐步增大,查问速度无奈满足实时剖析需要的问题。基于高性能、分布式特点,ClickHouse能够满足大规模数据的剖析和查问需要,因而研发团队以开源ClickHouse为根底,研发出火山引擎云原生数据仓库ByteHouse,并在其中定制一套解决模型——BitEngine,用于解决汇合的交并补计算在实时剖析场景中的性能晋升问题。 据介绍,BitEngine是一个高效汇合数据处理模型,底层基于MergeTree Family存储引擎,并在此基础上引入了BitMap64类型,开发了系列相干运算函数。BitEngine提供的BitMap64类型适宜表白具备特定关系的大量实体ID的汇合,将汇合的交并补运算转化为bitmap之间的交并补运算,从而达到远超一般查问的性能指标。 那么,BitEngine如何利用在人群圈选场景中?举个例子,广告主需要为圈选出“人群包A”和“人群包B”的交加人群,实现广告精准投放。 人群包状况: 人群包A = [10001, 20001,30001,40001,50001],人群包B = [10001, 20001,20002,20003,20004]冀望后果:通过BitEngine计算A&B = [10001, 20001]首先,人群包依照肯定规定划分为多个区间,任意两个区间之间的人群包没有交加,由BitEngine保障数据的读取和计算是严格依照区间进行;其次,BitEngine在数据读取时会为每一个文件构建一个读工作,由一个线程调度模块实现整个任务调度和读取;最初,BitEngine实现所有两头后果计算后,依照后果的输入要求做一次数据合并,由此实现交加计算。已上线业务的测试表明,相比一般和Array或者用户表形式,BitEngine在查问速度上有10-50倍晋升。 BitEngine上线前后查问耗时监控 BitEngine不仅仅在抖音团体海量广告投放场景中应用,目前更是集成在火山引擎云原生数据仓库ByteHouse中对外输入。火山引擎ByteHouse次要为用户提供极速剖析体验,可能撑持实时数据分析和海量数据离线剖析,具备便捷的弹性扩缩容能力,极致剖析性能和丰盛的企业级个性,目前曾经与中国地震台网核心、海王团体、莉莉丝游戏、极客邦科技等诸多行业企业达成单干,深度助力各个行业数字化转型。 点击跳转火山引擎ByteHouse理解更多

August 22, 2023 · 1 min · jiezi

关于大数据:高效试错敏捷迭代火山引擎AB测试帮助这个企业掌握关键能力

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群最近,乐刻的“百城万店”策略在行业激发了许多探讨。在传统健身馆经营承压、服务业难标准化的语境里,这家守业公司的实际值得被一再钻研。乐刻创建至今已有8年,目前领有乐刻健身、FEELINGME、YOGAPOD小瑜荚、闪电熊猫多个品牌,还有冷落的线上社区和商城,以及居家健身品牌。乐刻已在24个城市开出超1200家门店,注册会员数冲破800万人。 市面上曾经有不少对于乐刻模式的剖析,比方“产业互联网”、“数字化经营”,这些概念解释了乐刻的逻辑,但更令人关注的是,业务的倒退是一连串正确的决策促成的,守业公司最大难题莫过于在一条没有人走过的路上继续“做对”,在这一点上乐刻是如何做到的? 实际上,对乐刻而言,所谓的正确决策,其实都是一直试错的后果,新业务如何命名更吸引人?内容关联商品占比为多少时,用户购买转化效率最高?大促到了,如何在多个营销计划中分别成果最好的那个计划?一个个或大或小的决策影响着最终终局,却都有试错老本。此时,如果没有数据驱动下的麻利试错的能力,公司会浪费资源,贻误战机,重大时可能还会被谬误的决策拖垮。 乐刻对此的解决思路是,和火山引擎单干,引入其数智平台旗下的的A/B测试产品——DataTester,帮忙业务麻利试错。 A/B测试在乐刻的倒退中屡次施展关键作用。例如,乐刻想在APP里上线电商场景,但拿不准该把模块命名为“集市”还是“商城”。综合A/B测试后果,乐刻疾速从试验中确定了“商城”的命名,将被解放的工夫精力投入后续的经营中。 乐刻APP在从4.0版本到5.0版本迭代时,退出了一个全新模块——首页内容个性化举荐。这个模块波及产品板块散布、内容展现模式、举荐算法设置等多个环节,每个环节都须要找到“最优解”。以内容展现为例,据记者理解,乐刻过后心愿找到转化率最高的内容关联商品最佳占比,为此团队将原有策略作为对照组(占比20%),设置了三个阶梯实验组(占比30%、50%、80%)。基于A/B测试,乐刻方面发现,内容关联商品占比为30%时用户转化率最高,因而最终采纳了占比30%的策略,转化率因而显著晋升。 据理解,乐刻引入火山引擎A/B测试DataTester已有一年半工夫,A/B测试目前曾经是公司的“数字基建”。成为“基建”意味着,乐刻不只是在某个重大业务降级时才会用到A/B测试。A/B测试曾经融入了乐刻的工作流,乐刻也因而摸索出了“疾速灰度、疾速拿后果,而后扩充人群”的高效决策门路。 火山引擎DataTester源自字节跳动长期积淀,截至2023年6月,字节已通过DataTester累计做过240万余次AB试验,日新增试验 4000余个,同时运行试验5万余个。DataTester目前服务了包含美的、失去、凯叔讲故事等在内的上百家企业,为业务的用户增长、转化、产品迭代、经营流动等各个环节提供迷信的决策依据,将成熟的“数据驱动增长”教训赋能给各行业。 点击跳转火山引擎DataTester理解更多

August 21, 2023 · 1 min · jiezi

关于大数据:开发调试更便捷火山引擎-DataLeap-提供-Notebook-交互式开发体验

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群Notebook 是一种反对 REPL 模式的开发环境。 所谓「REPL」,即「读取-求值-输入」循环:输出一段代码,立即失去相应的后果,并持续期待下一次输出。Notebook 通常使得探索性的开发和调试更加便捷,在 Notebook 环境,用户能够交互式地在其中编写你的代码、运行代码、查看输入、可视化数据并查看后果,应用起来非常灵活。 在数据开发畛域,Notebook 广泛应用于数据清理和转换、数值模仿、统计建模、数据可视化、构建和训练机器学习模型等方面。然而显然做数据开发,只有 Notebook 是不够的。 目前,火山引擎 DataLeap 数据研发平台提供了工作开发、公布调度、监控运维等一系列能力,并将 Notebook 作为一种工作类型,退出进 DataLeap 数据研发平台,使用户既能领有 Notebook 交互式的开发体验,又能享受一站式大数据研发治理套件提供的便当。 在火山引擎 DataLeap 数据研发平台,开发过程围绕的外围是工作。用户能够在我的项目下的工作开发目录创立子目录和工作,像 IDE (集成开发环境)一样通过目录树治理其工作。 Notebook 也是一种工作类型,用户能够启动一个独立的工作 Kernel 环境,像开发其余一般工作一样应用 Notebook。 图:火山引擎 DataLeap 数据开发 Notebook 工作界面 基于简化运维老本、升高架构复杂性,以及进步用户体验的思考,2021 上半年,火山引擎 DataLeap 研发人员对整体架构进行了一次改进。新的架构次要做了以下改良,大抵简化为下图移除 JupyterHub(https://jupyterhub.readthedocs.io/en/stable/),将 JupyterLab (https://jupyterlab.readthedocs.io/en/stable/getting_started/o...) 改为多实例无状态常驻服务,并实现对接 火山引擎 DataLeap 的多用户鉴权。革新本来落在 JupyterLab 本地的数据存储,包含用户自定义配置、Session 保护和代码文件读写。Enterprise Gateway(EG)反对长久化 Kernel,将 Kernel 近程环境元信息长久化在远端存储(MySQL)上,使其重启时能够重连,且 JupyterLab 能够晓得某个 Kernel 须要通过哪个 EG(https://jupyter-enterprise-gateway.readthedocs.io/en/latest/) 连贯。 图:火山引擎 DataLeap 下改进版 Notebook 整体架构 架构降级简化后,整套 Notebook 服务的稳定性取得了极大的晋升。因为实现了用户无感知的降级, DataLeap 不仅晋升了用户的应用体验,运维、算力、人力等老本也失去了极大地升高。 ...

August 20, 2023 · 1 min · jiezi

关于大数据:慕课大数据工程师2023版-雪虐风饕愈凛然

download:慕课大数据工程师2023版 雪虐风饕愈凛然大数据工程师的职责和技能大数据工程师的主要职责是构建和保护大数据平台,包含数据采集、存储、解决、剖析、开掘、可视化等环节。他们须要应用各种编程语言、框架、库和工具,如Java、Python、Scala、Hadoop、Spark、Hive、HBase、Kafka、Flume、Sqoop等,来实现对结构化和非结构化数据的高效治理和利用。 大数据工程师须要具备以下技能: 编程能力:把握至多一种罕用的编程语言,如Java、Python或Scala,可能编写高质量的代码,遵循编码标准和格调,进行单元测试和调试。数据库能力:相熟关系型数据库和非关系型数据库的原理和应用,如MySQL、Oracle、MongoDB、Redis等,可能进行数据建模、查问优化、索引设计等。分布式系统能力:理解分布式系统的基本概念和原理,如集群、负载平衡、容错、一致性等,相熟分布式计算框架和存储系统的应用和优化,如Hadoop、Spark、HBase等。数据分析能力:把握根本的数据分析办法和技巧,如统计分析、机器学习、深度学习等,可能应用相干的工具和库,如Pandas、NumPy、SciPy、Scikit-learn、TensorFlow等,进行数据荡涤、预处理、特色工程、模型训练和评估等。数据可视化能力:把握根本的数据可视化原理和技术,如图表类型抉择、色彩搭配、交互设计等,可能应用相干的工具和库,如Matplotlib、Seaborn、Plotly等,进行数据展现和报告。大数据工程师的薪资待遇依据我从网络上搜寻到的信息12345678910 ,大数据工程师的薪资待遇受到多方面因素的影响,如地区差别、行业差别、学历差别、教训差别等。以下是我为您整顿的一些参考数据: 地区差别:一般来说,一线城市(北京、上海、广州、深圳)的薪资程度要高于二线城市(杭州、成都、武汉等)和三线城市(长沙、西安等),这与城市的经济倒退程度和人才需求量无关。依据某招聘网站1 的统计,2020年11月份,大数据开发工程师在北京的均匀月薪为23.8K,在上海为22.5K,在广州为18.7K,在深圳为21.4K,在杭州为19.9K,在成都为16.3K,在武汉为15.8K,在长沙为14.8K,在西安为13.9K。行业差别:一般来说,互联网、金融、电商等行业对大数据的利用需要较高,因而也会给予大数据工程师较高的薪资待遇。依据某招聘网站2 的统计,2020年11月份,大数据开发工程师在互联网/电子商务行业的均匀月薪为22.3K,在计算机软件行业为20.7K,在金融/银行/保险行业为20.5K,在教育/培训/院校行业为17.4K,在医疗/制药/生物行业为16.9K。学历差别:一般来说,学历越高,薪资待遇越高,这与学历所代表的常识程度和技能程度无关。依据某招聘网站3 的统计,2020年11月份,大数据开发工程师中,本科学历的均匀月薪为19.6K,硕士学历的均匀月薪为23.1K,博士学历的均匀月薪为28.8K。教训差别:一般来说,教训越丰盛,薪资待遇越高,这与教训所代表的我的项目经验和解决问题的能力无关。依据某招聘网站4 的统计,2020年11月份,大数据开发工程师中,1年以下教训的均匀月薪为12.4K,1-3年教训的均匀月薪为18.2K,3-5年教训的均匀月薪为24.2K,5-10年教训的均匀月薪为30.6K。大数据工程师的发展前景大数据工程师是一个前景非常广阔的职业。随着大数据技术的一直倒退和翻新,以及大数据在各个领域和行业的广泛应用和深刻开掘,大数据工程师的需求量和价值将会持续增长。同时,随着人工智能、云计算、物联网等新兴技术的倒退和交融,大数据工程师的职能和技能也将一直扩大和晋升。将来,大数据工程师将会面临更多的时机和挑战。 大数据工程师能够有以下几种倒退方向: 业余方向:深入研究某个畛域或行业的数据问题,成为该畛域或行业的数据专家或参谋。例如,成为金融畛域的风控专家、医疗畛域的诊断专家、教育领域的评估专家等。治理方向:负责管理一个或多个数据我的项目或团队,成为数据项目经理或团队负责人。例如,负责制订数据我的项目的指标、打算、进度、估算等,并监督我的项目的执行和品质;或者负责管理一个或多个数据团队的人员、资源、沟通、合作等,并晋升团队的效率和能力。翻新方向:摸索新的数据技术或办法,成为数据技术或办法的创造者或创新者。例如,开发新的数据处理框架或零碎、设计新的数据分析模型或算法、创造新

August 20, 2023 · 1 min · jiezi

关于大数据:火山引擎DataLeap助力PICO落地数据流程规范提升开发效率

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群作为目前中国市场领跑的头部XR品牌之一,字节跳动旗下的PICO曾经领有了超百万客户。 过来一年,PICO在XR场景中一直建设和发力,为静止、娱乐等生产级场景带来了全新体验,并广泛应用在教育、医疗和企业培训等商用场景。 在视频畛域中,PICO联合时下热点,出品了多个亮眼VR+场景,受到观众及业界多方好评。往年五月,PICO携手北京国内电影节·第30届大学生电影节举办“大影节 x PICO VR影展”流动,用户可通过“PICO视频”利用观看一系列优良VR影视作品;在卡塔尔世界杯期间,PICO用户不仅能够沉迷观看64场较量,还能通过虚构形象与天南海北的球迷互动侃球,解锁“VR+体育”新观赛模式;而在娱乐上演方面,PICO与多个演唱会的胜利联动,也向行业展现了“VR+上演”的更多可能,为线下上演市场带来全新生机。大影节 x PICO VR影展现场 PICO作为一个硬零碎+软件的生态业务,不论是研发层、操作系统层、还是用户体验层,将海量业务数据利用充沛,及时取得全面数据反馈,这些根底能力是不可或缺的。 在数据团队建设初期,PICO的数据建设层面始终不足必要的流程标准。例如,当使用者建设一个数据表的时候,一些表的命名比拟粗放,且元信息填写不够残缺,导致使用者在查问相干数据的时候,很难从表的元信息当中,去感知到这些数据资产,到底服务的是哪一个数据指标。缺失的流程标准给PICO数据团队造成了多重困扰,也成为了数据利用中的一个亟待解决的痛点。 为了建设更规范的流程标准,同时做到疾速、高质量的响应业务多样化的诉求,PICO团队开始接入火山引擎大数据开发套件DataLeap,利用DataLeap的大数据研发平台及数据地图功能,建设起了PICO数仓建表标准,晋升数据利用率及数据价值。 在数仓建表标准中,首先PICO数据团队可通过火山引擎DataLeap的表格治理性能做到疾速建表,帮忙使用者辨认每个字段,及它对应的字段类型,大幅度晋升了开发工作效率;同时,实现建表后,能够通过DataLeap再进一步筛选元数据标签,获取如业务域、产品线、层级、主题等相干信息;最终,正式上线前,相干的管理人员会进行穿插review,保证数据应用平安。火山引擎DataLeap元数据标签界面 此外,PICO还通过火山引擎智能数据洞察DataWind疾速搭建起数据门户,基于业务场景无效组织数据内容,主动刷新的可视化查问性能,能疾速满足使用者的数据应用需要。 多个火山引擎数据产品的联合应用,让PICO数据资产应用变的清晰且可感知,用数效率大幅晋升。而除了建设数据流程标准,火山引擎DataLeap大数据研发治理套件还可帮忙用户疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设,升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。 点击跳转大数据研发治理套件 DataLeap理解更多

August 18, 2023 · 1 min · jiezi

关于大数据:挖掘优质短视频超百万条火山引擎DataLeap助力电商平台生态治理

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群在人们的日常生活中,网购曾经成为人们生存中不可或缺的购物模式。 依据《中国社交电商行业倒退白皮书(2022)》的数据显示,2022年社交电商市场交易规模达到28542.8亿元,预计2023年中国社交电商行业交易规模将达34165.8亿元。 这么宏大的市场规模背地,如何解决电商场景下的各项生态治理问题显得尤为重要,某电商平台的治理团队就提供了一个优良实际范本。 在该电商平台的社交电商场景下,以短视频优质我的项目为例,平台治理团队会对当天公布的挂购物车类短视频进行标签辨认,判断其优质水平及具体起因。通过算法模型辨认后,视频将被提交至奖惩核心,依据优质水平进行流量搀扶或限度。而在治理过程中,数据处理流程也存在很多的挑战和痛点。 首先是数量挑战:大数据量的训练集,难以疾速进行数据预处理。业务算法模型的训练集通常很大,达到百万甚至千万级。如果将这些海量数据放在本地或其余开发机上解决,速度会很慢,无奈满足业务需要,即便应用多线程解决,并发度也难以达到业务需要。其次是准确度挑战:难以验证算法模型准确度。算法模型的准确性通常通过有偏和无偏两个维度进行验证。模仿算法模型上线后的召回状况和准确率,以及对业务的影响,无论是有偏还是无偏测试集,都须要确保测试集标签的准确性。如果测试集标签的准确性不高,会影响模型评估的准确性。最初是监控挑战。要想做好后续的指标监控,首先须要建设本人平台的统计指标,如召回率、漏放率、审出率、驳回率等。这些指标须要做成数据集,再建设本人的监控看板。同时,如果平台呈现背面案例,须要团队进行深刻的剖析,并优化算法模型。如果没有高效的工具或平台进行辅助,会消耗大量的人力和资源。为了解决这些痛难点,该电商平台治理团队接入了火山引擎DataLeap的大数据研发平台能力,三步搭建起了高效的算法模型数据处理流程。 第一步:在算法开发阶段,进行数据预处理,产出训练数据集。在应用 DataLeap 之前,因为算法模型的测试集量级较大,数据处理效率低;而当初,该电商平台治理团队利用火山引擎 DataLeap 的 Notebook 工作进行数据预处理,解决后的数据会被存储在 Hive 表或 HDFS 上,这些数据能够在 HDFS 上短暂保留,满足了理论利用场景中收集长时间数据的需要,不用受存储有效期为 7 天的限度。 团队能够离线解决这些数据,生成训练集,进行模型训练。因为火山引擎 DataLeap 的 Notebook 能力能够反对工作的主动运行,无需人工搭建 Notebook 环境进行数据训练,大大节俭了人力老本,进步了数据处理和统计效率。(图:DataLeap数据开发平台示例) 第二步:算法上线,验证模型成果训练好的模型须要进行评估,以便理解其成果如何。团队可利用DataLeap将线上的 Kafka 数据写入 Hive 中,而后离线剖析 Hive 表中的数据,用来理解模型的成果。不同模型平台治理团队关注的指标可能有所不同,借助DataLeap能够应用不同的指标来评估模型的成果,例如准确率、召回率、AUC 或 ACC 等。 第三步:利用火山引擎DataWind搭建监控看板而在监控板块,DataLeap可与火山引擎智能数据洞察DataWind晦涩配合,搭建监控看板,监控人员每日能够及时地获取到数据后果,同时也会对背面案例进行深刻的剖析,进而优化算法模型。 在火山引擎DataLeap的助力下,该平台治理团队去年全年累计开掘辨认优质短视频超147万条,助力超26万名电商作者均匀流量增长56%;累计处罚违规低质短视频超3280万条、违规低质直播超1500万场。整体内容品质有显著改观,消费者好感度回升7.2%。 除数据处理能力之外,火山引擎DataLeap还能够提供数据集成、开发、运维、资产等能力,帮忙用户晋升数据研发效率、升高治理老本,减速推动企业的数字化转型,目前曾经利用于泛互联网、制作、新批发、汽车等畛域,帮忙数据团队无效的升高工作老本和数据保护老本、开掘数据价值、为企业决策提供数据撑持。 点击跳转大数据研发治理套件 DataLeap理解更多

August 17, 2023 · 1 min · jiezi

关于大数据:BitSail-Connector开发详解系列三SourceReader

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群Source Connector本文将次要介绍负责数据读取的组件SourceReader: SourceReader每个SourceReader都在独立的线程中执行,只有咱们保障SourceSplitCoordinator调配给不同SourceReader的切片没有交加,在SourceReader的执行周期中,咱们就能够不思考任何无关并发的细节。 SourceReader接口public interface SourceReader<T, SplitT extends SourceSplit> extends Serializable, AutoCloseable { void start(); void pollNext(SourcePipeline<T> pipeline) throws Exception; void addSplits(List<SplitT> splits); /*** Check source reader has more elements or not.*/boolean hasMoreElements(); /*** There will no more split will send to this source reader.* Source reader could be exited after process all assigned split.*/default void notifyNoMoreSplits() { } /*** Process all events which from { @link SourceSplitCoordinator}.*/default void handleSourceEvent(SourceEvent sourceEvent) { } /*** Store the split to the external system to recover when task failed.*/List<SplitT> snapshotState(long checkpointId); /*** When all tasks finished snapshot, notify checkpoint complete will be invoked.*/default void notifyCheckpointComplete(long checkpointId) throws Exception { } interface Context { TypeInfo<?>[] getTypeInfos(); String[] getFieldNames(); int getIndexOfSubtask(); void sendSplitRequest(); }}构造方法这里须要实现和数据源拜访各种配置的提取,比方数据库库名表名、音讯队列cluster和topic、身份认证的配置等等。 ...

August 17, 2023 · 6 min · jiezi

关于大数据:MaxCompute-发布按量付费闲时版计算成本最高节省6666

什么是按量付费闲时版开明MaxCompute按量付费闲时版,意味着用户能够应用MaxCompute闲时计算资源(os_SpotQuota),它是一种共享型按量付费计算资源,闲时计算资源池与按量付费标准版计算资源共享,与包年包月计算资源隔离,不可指定用量。 通过闲时计算资源运行的作业被称为Spot作业(SpotJob),绝对于按量付费标准版作业具备更低的单价。如遇整体资源池资源水位高,产生资源竞争时,Spot作业(应用os_SpotQuota运行的作业,蕴含SpotSQL、SpotMapReduce、SpotSpark等类型)的资源可能会被挤压或者抢占,甚至作业被终止,如下图所示。 实用场景按量付费闲时版旨在为用户升高开发、测试等提早不敏感场景下应用MaxCompute的老本。实用于冀望极低成本、但对实现工夫不敏感的作业。例如用户行为日志、系统日志等低价值、海量数据的剖析场景。 此类业务通常须要耗费大量计算资源,但对产出工夫并不敏感,此时应用包年包月资源会造成独享资源大量闲暇,而应用按量付费标准版老本又过高,对作业的实现工夫敏感性越低,越适宜应用按量付费闲时版以节俭计算成本。 (注:用于生产、要求长期稳固、资源有保障的作业不宜应用按量付费闲时版,因为资源竞争会导致作业资源被挤压、抢占,造成作业长时间期待或运行工夫变长、甚至被迫终止,进而影响用户的理论业务。) 计量计费按量付费闲时版实用于SQL、MapReduce、Spark、Mars(数据迷信)计算类型,计费公式与标准版作业统一,但单价更低。 $$SpotJob与规范作业单价(公共云)比照$$ 参考示例小K同学是公司A的数仓开发人员,开发工夫在10:00-18:00之间,因为开发阶段须要频繁的历史数据重刷比照,每天要跑几百个作业,数据扫描量较高,应用按量付费标准版,一天作业生产高达861元,计算成本较高。小K同学理解到MaxCompute推出了按量付费闲时版,很快试用起来,原有的作业采纳SpotJob后,只管作业延时有减少,但根本都能在上班前实现业务的开发,在数据扫描量雷同的状况下,一天作业的老本升高为289元,一个月累计下来给公司带来了将近2万元的老本升高。 $$SpotJob与规范作业账单金额比照$$ MaxCompute按量付费闲时版可能为用户大大降低开发、测试等提早不敏感场景下的计算成本。 点击立刻收费试用云产品 开启云上实际之旅!原文链接 本文为阿里云原创内容,未经容许不得转载

August 16, 2023 · 1 min · jiezi

关于大数据:火山引擎ByteHouse一套方案让OLAP引擎在精准投放场景更高效

更多技术交换、求职机会,欢送关注字节跳动数据平台微信公众号,回复【1】进入官网交换群因为流量红利逐步消退,越来越多的广告企业和从业者开始摸索精细化营销的新门路,取代以往的全流量、粗放式的广告轰炸。精细化营销意味着要在数以亿计的人群中优选出那些最具后劲的指标受众,这无疑对提供根底引擎反对的数据仓库能力,提出了极大的技术挑战。 本篇内容将聚焦字节跳动OLAP引擎技术和落地教训,从广告营销场景登程,上篇解说利用ByteHouse 减速实时人群包剖析查问的技术原理;下篇以字节跳动外部场景为例,具体拆解广告业务的实现逻辑和业务成果。(文本为下篇) 广告精准投放场景广告投放过程个别蕴含数据收集->数据整合->人群圈选->广告投放->反馈剖析等要害流程,人群圈选是广告精准投放的关键步骤,它帮忙确定广告指标受众,辅助投放平台依据不同受众和广告指标优化投放策略,晋升广告收益; 人群预估人群预估次要是依据肯定的圈选条件,确认命中的用户数目。在广告精准投放过程中,广告主须要晓得以后选定的人群组合中大略会有多少人,用于辅助判断投放状况进而确定投放估算,通常要求计算工夫不能超过 5 秒。 广告投放 广告精准投放过程中遇到的问题与痛点:数据预估:广告主须要对选定的人群组合进行预估,以便判断投放状况并确定投放估算。但人群包数据量多,基数大。平台的用户数上亿,仅抖音的 DAU 就几亿,抖音、头条对应的人群包在亿级别,晚期的预估版本采纳ElasticSearch,但因为数据过于宏大,只能采纳1/10抽样存储,导致10%的误差,业务难以承受。 查问性能:广告主能够设定一个非常复杂的圈选条件,导致计算简单(单次计算可能蕴含几百上千个人群包),Hive和ES等计划在解决大数据量时,查问速度会变得十分慢,如果须要查问某个广告主的所有用户,须要扫描整个用户库,而这个过程可能须要几分钟甚至几个小时,无奈满足实时性要求。 存储空间大:Hive和ES等计划须要额定的索引构造,导致存储空间变大,从而减少了存储老本。例如,如果须要对用户属性进行索引,就须要额定的存储空间来存储索引数据。 不反对高并发:Hive和ES等计划在解决高并发申请时,容易呈现性能问题,无奈反对高效的广告投放。例如,如果同时有多个广告主须要查问用户信息,就可能会呈现查问阻塞或响应提早等问题。 数据查问效率:采纳ClickHouse反对预估,但随着数据量的增长,ClickHouse在以后存储引擎的反对下也难以保障查问工夫。这导致了数据查问效率的问题,影响了用户体验。 ByteHouse BitEngine计划计划简介新查问引擎针对广告人群预估业务开发的新查问引擎,基于ClickHouse提供的MergeTree Family系列引擎,增加了新的bitmap64类型和一系列的相干聚合函数。BitEngine提供的bitmap64类型适宜存储和计算大量的用户ID之间的关系;在广告人群预估业务中,bitmap64类型用于存储人群包数据,而后将人群包之间的交并补计算转化为bitmap之间的交并补,从而达到远超一般查问的性能指标。 实现步骤创立一个bitmap64类型,能够将用户ID间接存储在bitmap中,提供一系列交并补的聚合计算,并且还心愿能够充分利用多核CPU的并行计算能力,由此咱们设计了BitEngine。示例如下 CREATE TABLE cdp.tag_uids_map (tags String,uids BitMap64 BitEngineEncode)ENGINE = HaMergeTree('/clickhouse/xxxx/{shard}', '{replica}')ORDER BY tagtag_uids_map存储格局如下 要查问 A&B 的后果 SQL 为 SELECT bitmapCount('A&B') FROM tag_uids_mapBitEngine实现逻辑核心思想对数据做分区划分和编码,保障每个区间的数据之间不存在交加,而后应用roaring bitmap保留数据;计算时每个分区的数据能够独立的做聚合计算,充分利用机器的并行能力,每个分区外部的聚合计算就是多个bitmap之间的交并补,利用roaring bitmap高效的交并补计算升高CPU和内存的应用;通过字典将编码的后果反解回来,数据编码是为了让数据的散布尽可能浓密,roaring bitmap在存储和计算的时候就能够取得更好的性能。业务利用业务要害因素 人群包:广告主自定义规定计算出来的人群数据,标签是dmp团队依据市场需求定义的人群数据。标签ID:每天定时依据产出规定更新一次,人群ID是自增的,每天依据广告主需要进行新建计算。对立编码 为了对标签数据和人群数据的uid对立编码,编码服务先将标签数据中的uid和人群数据中的uid提取进去进行对立编码,将全量uid平均hash到一万个桶中,桶编号为i[0<=i<=9999],uid在每个桶内由1开始程序编码,每个桶的范畴为i2^40 - (i+1)2^40。uid数据每天都在减少,因而须要反对增量编码, 编码服务每天会先获取增量uid,hash后程序搁置到每个桶中。数据存储实现编码后,会先把字典数据对立写入hive表中,便于字典的各种应用场景。在数据通过分区和编码之后,ClickHouse能够以多种数据导入格局将数据以bitmap64类型存入磁盘。数据计算BitEngine如何充沛利用计算机的并行能力实现每个分区多个bitmap之间的交并补计算? 存在问题:假如存在四个bitmap,别离为a,b,c,d;则(a | c) & (b | d)不肯定等于(a & b) | (c & d)。人群包人群包A = [10001, 20001,30001,40001,50001],人群包B = [10001, 20001,20002,20003,20004]冀望后果通过BitEngine计算A&B = [10001, 20001] ...

August 16, 2023 · 1 min · jiezi

关于大数据:数据治理是什么该如何入门呢

大家好,我是独孤风,一位已经的港口煤炭工人,目前在某国企任大数据负责人,公众号大数据流动主理人。 在最近的两年的工夫里,因为公司的需要,还有大数据的发展趋势所在,我开始学习数据治理的相干常识。 随着互联网热潮的退去,互联网开始由生产互联网向产业互联网转移。这也让大数据开始在传统企业发挥作用。目前数据治理的相干岗位曾经越来越多了。而有肯定大数据技术根底,数据分析根底也更容易从事数据治理的相干岗位工作,待遇也是会进步很多。而数据相干从业人员也是数据治理的从业人员的次要起源,因为目前也没有间接大学毕业就从事数据治理工作的,也都是通过学习转过去的。 这是某大厂对于数据治理的岗位要求,大家能够简略看一下。而且目前很多公司对于数据架构师的要求,也蕴含了数据治理的相干能力要求。数据架构师始终都是将来一段时间高薪的岗位之一。 数据治理是什么?当今数字化时代,数据扮演着至关重要的角色,因而数据治理变得越来越重要。数据治理能够了解为一套标准和流程,用于治理和保护组织内的数据资产。 数据治理的目标是确保数据的准确性、完整性、一致性和可靠性。它涵盖了数据的收集、存储、解决、共享和应用等方方面面。通过数据治理,组织可能标准数据的定义、命名和分类,确保数据的标准化和一致性。此外,数据治理还关注数据的品质,包含数据的准确性、完整性和可靠性,通过数据荡涤和验证等措施,确保数据的高质量。同时,数据治理还波及数据的平安和隐衷爱护,确保数据的机密性和合规性,避免数据泄露和滥用。 数据治理的重要性体现在几个方面。首先,数据是组织的重要资产,对于决策制定和业务经营至关重要。良好的数据治理能够确保数据的准确性和一致性,进步决策的可靠性和准确性。数据驱动的决策可能帮忙组织更好地应答市场变动、优化经营和翻新倒退。其次,随着数据规模和复杂性的减少,数据的合规性和安全性成为关键问题。数据治理能够帮忙组织确保数据的合规性,恪守相干法规和行业标准,缩小数据泄露和危险。同时,数据治理还能晋升组织的数据安全性,确保敏感数据的机密性和保密性。 此外,数据治理还能够促成数据共享和合作。在一个组织外部,不同部门和团队可能会应用不同的数据源和定义,导致数据不统一和抵触。通过数据治理,能够建设共享的数据字典和标准,促成数据的对立和合作。这有助于跨部门的沟通和合作,防止数据孤岛和信息孤立,进步组织的效率和创新能力。 数据治理是一种要害的实际,用于治理和保护组织内的数据资产。它不仅关注数据的准确性、一致性和可靠性,还关注数据的安全性和合规性。通过良好的数据治理,组织能够确保数据的品质和可靠性,反对决策制定和业务经营,提高效率和创新能力。在当今数据驱动的时代,数据治理的重要性不可漠视,它对于组织的胜利和竞争劣势具备重要的意义。 举个例子让咱们以一个跨国批发企业为例来阐明数据治理的概念。 假如该跨国批发企业在多个国家经营,领有在线商店和实体店面。该企业收集大量的数据,包含销售数据、顾客数据、库存数据等。在这种状况下,数据治理是确保数据管理和应用的一致性和可靠性的要害实际。 首先,数据治理包含规定数据定义和规范。在这个例子中,数据治理会明确定义不同类型的数据,如销售数据、顾客数据和产品数据等。例如,销售数据可能包含订单号、日期、销售金额等字段。这些定义和规范确保了不同团队和零碎之间对数据的统一了解,防止了混同和谬误。 其次,数据治理关注数据品质和数据荡涤。这意味着对数据进行验证、校验和荡涤,以确保数据的准确性和完整性。在这个例子中,数据治理能够辨认并纠正错误的销售记录,革除反复或不残缺的顾客数据,以进步数据品质并防止基于不精确数据做出谬误的决策。 此外,数据治理还波及数据安全和隐衷爱护。对于跨国批发企业来说,数据治理须要确保顾客数据的机密性和合规性。这可能波及采取安全措施来避免数据泄露和未经受权的拜访,同时恪守实用的隐衷法规和法律。 另外,数据治理还波及数据拜访和共享的管制。在这个例子中,数据治理能够确保只有通过受权的员工可能拜访特定类型的数据,并设置拜访权限和角色。此外,数据治理还能够建设数据共享的规定和流程,以便不同团队或部门之间能够平安地共享数据,促成单干和决策制定。 数据治理在这个跨国批发企业中起到关键作用。它确保数据的一致性、准确性和完整性,进步数据品质和可靠性。数据治理还确保数据安全和隐衷爱护,恪守相干法规和合规要求。通过数据治理,这个企业可能更好地治理和利用数据资产,反对决策制定、优化经营,并在竞争强烈的市场中取得成功。 如何入门呢?入门数据治理并不容易,咱们须要做大量工作,比方: 理解数据治理的基本概念:开始学习数据治理之前,理解数据治理的定义、指标和根本准则是很重要的。能够浏览相干的书籍、文章或在线资源,获取对数据治理的根本了解。学习数据治理的最佳实际:钻研数据治理的最佳实际和行业标准,理解胜利的数据治理框架和办法。理解数据治理的要害组件,例如数据品质治理、元数据管理、平安与隐衷爱护等。评估组织的现状:理解您所在组织的数据管理状况,评估现有的数据管理流程、数据品质和安全性等方面的情况。辨认数据治理的痛点和机会,以确定改良的重点。制订数据治理策略:基于组织的需要和指标,制订适宜组织的数据治理策略和打算。这包含明确数据治理的指标、范畴、流程和责任调配等方面。建设数据治理团队:组建跨职能的数据治理团队,包含业务代表、数据管理专家和技术人员。确保团队具备数据治理所需的技能和常识,并负责推动数据治理打算的执行。确定数据治理流程:制订数据治理的流程和标准,包含数据收集、存储、荡涤、共享和平安等方面。确保数据流程合乎数据治理策略和最佳实际。施行数据品质治理:建设数据品质管理机制,包含数据品质评估、数据荡涤和纠正、数据监控和报告等。确保数据的准确性、一致性和完整性。采纳元数据管理:建设元数据管理系统,记录和治理数据的定义、构造、关系和用处等信息。元数据管理有助于更好地了解和利用数据,并反对数据治理流程。增强数据安全与隐衷爱护:制订数据安全策略和措施,确保数据的机密性、完整性和可用性。同时,恪守相干法规和合规要求,爱护用户的隐衷。继续监控和改良:数据治理是一个继续的过程。建设监控机制,定期评估数据治理的绩效,并依据评估后果进行改良和优化。可见数据治理要学习的货色十分多。所以学习数据治理应该实践与实际并行。 实践上,国内上,支流的数据治理框架次要有ISO数据治理规范、DGI数据治理框架、DAMA数据管理框架等。对国内支流数据治理框架的了解有助于咱们建设合乎企业本身业务需要的数据治理体系。 DAMA(国内数据管理协会)是一个由全球性数据管理和业务业余的意愿人士组成的非营利协会,致力于数据管理的钻研和实际。其出版的《DAMA数据管理常识体系指南》(简称DAMA-DMBOK)一书被业界奉为“数据管理的圣经”,目前已出版第2版,即DAMA-DMBOK2。 国内数据治理在数据治理框架和规范体系的钻研方面,国内起步绝对较晚,目前次要有GB/T 34960和DCMM两个规范。 GB/T 36073—2018《数据管理能力成熟度评估模型》(Data Management Capability Maturity Assessment Model,DCMM)是在国家标准化治理委员会领导下,由全国信息技术标准化技术委员会编制的一份国家标准,于2018年公布并施行。 DCMM依照组织、制度、流程、技术对数据管理能力进行了剖析和总结,提炼出组织数据管理的8个过程域,即数据策略、数据治理、数据架构、数据利用、数据安全、数据品质、数据规范、数据生存周期。 DCMM将组织的数据能力成熟度划分为初始级、受治理级、持重级、量化治理级和优化级共5个倒退等级,以帮忙组织进行数据管理能力成熟度的评估。 目前最权威,也最接地气的,还是DAMA数据管理体系,这也是大家在学习数据治理的时候,为什么会频繁的听到DAMA相干词汇的起因。 作为最权限的数据治理框架,咱们只有把握了DAMA相干常识,最联合实际。做到数据治理的最根本入门是没有问题的,在通过几年企业中的积攒,您也能够成为数据治理专家。 实践学习实践学习方面倡议加入CDMP国内数据治理认证考试,有一个证书的确对于证实你在数据治理相干畛域的业余度很有帮忙。 其实当初对于数据治理的认证很多,我之前也分享过一些。比方某数据治理认证、某某数据管理师认证等等。 因为目前咱们国家工信部还没有出大数据或者数据治理的业余资格认证,相似于注册**工程师这种,所以当初比拟权威的数据治理认证还是国内的数据治理认证,这个国外国内都是比拟认可的。 DAMA数据管理业余认证CDMP 也请大家肯定要记住这个拼写CDMP,这个才是国内业余的数据治理认证。 一共分为四级,当然大部分公司对于等级没有要求,拿到A级就是很高的程度了。 这四级的区别如下: 目前招聘企业对于CDMP的认证也逐步增多了起来,其中对CDMP证书有了间接的要求。 证书长成这样: 通过考试的形式推动本人学习,在拿证的同时,学会相干理论知识也是十分重要的。 实际学习如何发展数据治理要走顶层开始,从业务端动手。但对于老手,更应该关注的是数据治理的理论工作。 元数据管理是数据治理的终点。 简略地说,元数据管理是为了对数据资产进行无效的组织。 它应用元数据来帮忙治理他们的数据。它还能够帮忙数据业余人员收集、组织、拜访和丰盛元数据,以反对数据治理。 三十年前,数据资产可能是 Oracle 数据库中的一张表。然而,在古代企业中,咱们领有一系列令人目迷五色的不同类型的数据资产。可能是关系数据库或 NoSQL 存储中的表、实时流数据、 AI 零碎中的性能、指标平台中的指标,数据可视化工具中的仪表板。 古代元数据管理应蕴含所有这些类型的数据资产,并使数据工作者可能更高效地应用这些资产实现工 作。 所以,元数据管理应具备的性能如下: 搜寻和发现:数据表、字段、标签、应用信息访问控制:访问控制组、用户、策略数据血统:管道执行、查问合规性:数据隐衷/合规性正文类型的分类数据管理:数据源配置、摄取配置、保留配置、数据革除策略AI 可解释性、再现性:特色定义、模型定义、训练运行执行、问题陈说数据操作:管道执行、解决的数据分区、数据统计数据品质:数据品质规定定义、规定执行后果、数据统计目前支流的元数据管理平台,包含Atlas,Datahub等等。以下是性能比照。 这方面的学习要以实际为主,多入手能力更纯熟的把握。 当然目前各种数据治理的开源框架层出不穷,我也始终在放弃关注。

July 10, 2023 · 1 min · jiezi

关于大数据:CDMP国际数据治理认证训练营来了78月

大家好,我是独孤风,一位已经的港口煤炭工人,目前在某国企任大数据负责人,公众号大数据流动主理人。在最近的两年的工夫里,因为公司的需要,还有大数据的发展趋势所在,我开始学习数据治理的相干常识。 通过一段时间的致力,我也终于通过了CDMP国内数据治理认证考试。 离我研究生开学还有两个月的工夫,应大家的要求,组织一下CDMP国内数据治理认证训练营(7-8月)。**** 指标是利用两个月的工夫,带大家胜利通过CDMP认证考试。 之前的自学群曾经成立一段时间,通过的同学简直没有。我也总结了一下,我尽管能够分享一些数据治理常识,然而备考还是须要刷题的。而且CDMP认证考试须要进行翻译,考试报告交费等等工作,这都是我不善于的。而且大家的自制力也是一个问题,没有人督促学习。 所以这次我通过当前,也跟DAMA官网培训班的人员沟通了。搞一下这种两个月的突击的模式,他们提供技术、报名、教材、课程的反对。我负责答疑、督促大家学习。大家共同努力,两个月后顺利上岸。 先做一些简略科普。 一、CDMP简介什么是CDMP? DAMA数据管理业余认证(Certified Data Management Professional,CDMP)是DAMA官网的一项国内业余认证。 在通过业余的数据治理常识考试,有的高级别还会做一些职业资格认证当前,就能够获取证书。 证书一共分为四个等级: 从业级(A)是最根底的级别,A级认证次要考试对整个常识体系的残缺理解, 考试的科目是DM根底。针对技术开发,数据安全,产品经理,业务人员,能够先获得A级证书,入门数据治理,后续再看本身状况。 我就是通过了A级,够用。 四个等级具体规定是什么呢? 如果一门业余考试考了60分,那么就有1个单科A级徽章,如果考了70分,就再有1个单科P级徽章,如果考了80分,就再有1个单科徽章M徽章。 所以通过A级的指标很简略,DM根底考试拿60分。 **** 考试科目是是什么呢? DM根底,就是一些DAMA里讲的基础知识了。 而专业课是什么呢? 其实就是DAMA车轮图的其余局部,比方元数据管理等等。 目前有七科专业课,别离是数据治理、数据建模、数据品质、元数据管理、主数据和参考数据、数据仓库和商务智能、数据集成和互操作。 这是一些通过人数的统计。 **** 二、CDMP考试规定介绍CDMP如何报名? 考试须要在官网进行报名,因为考试是机考,所以须要进行一系列的注册和插件装置,之后就能够随时参加考试了。 报名后,会有邮件提醒考试入口。 考试的费用是多少? 是的,考试须要肯定的费用。每一科是311美元。大家能够换算下,大略两千多一点人民币。 这里也顺便说一下其他费用,如果没通过想要重考是211美元。 而证书的有效期是三年,三年后须要更新证书,更新的费用是100美元。 如何考试呢? 考试的模式是什么呢? 考试是机考实现的,装置好浏览器插件,就能够在电脑上实现考试。 考试工夫是90+20分钟,100个单向选择题。 考试通过后,如何证实呢? 在通过考试后,会失去电子证书,当然这个电子证书是国内认证,所以目前是能够放在Facebook,Linkedin中的。 然而它不止是一个图片,是有电子签名认证的。 三、CDMP国内数据治理认证训练营(7-8月)也说过了自学群的成果很差。成立一段时间,通过的同学简直没有。大家的自制力也是一个问题,没有人督促学习。 这次咱们成立一个CDMP国内数据治理认证训练营(7-8月)。两个月的工夫,带大家顺利上岸。会有DAMA官网提供技术、报名、教材、课程的反对。我负责答疑、督促大家学习。大家共同努力,两个月后顺利上岸。 承诺的权利如下: 报名的费用目前看是5000左右,蕴含了一科DM根底的考试费。 也就是全考试流程大家都不必操心,只有安心学习就能够了。如果每天能拿出3-4小时工夫,一个月备考够用。 1-2小时的话,最好筹备两个月。 另外,我会把我的备考材料,整顿的笔记,思维导图分享给大家,心愿能帮忙到大家。 有动向报名的分割我一下。备注 “CDMP”

July 7, 2023 · 1 min · jiezi

关于大数据:隐语10正式发布|MVP部署体验包资源调度框架Kuscia全新亮相

2023 年 7 月 7 日,在世界人工智能大会组委会办公室领导下,隐语开源社区携手蚂蚁团体和机器之心独特主办的数据因素与隐衷计算论坛在上海世博会议核心举办。论坛上,蚂蚁团体隐衷计算部总经理、隐语社区负责人王磊公布了隐语 1.0 版本,并对隐语 1.0 版本框架拓展与降级进行了整体介绍。隐语 1.0 版本不仅进一步扩充了开源范畴,还对整体架构进行了调优拓展,核心内容波及产品层、资源层、互联互通等板块,总体成果涵盖性能优化、易用性跨越式晋升、互联互通状态丰盛。 图:隐语 1.0 架构图 产品层:平滑学习曲线 晋升易用性隐语开放平台已在过来一年内面向 50+ 机构凋谢体验。此次,隐语 1.0 版本带来全新的 MVP(Minimum Viable Product)部署体验包:一款面向隐衷计算初学用户的轻量级性能体验工具,内置节点、数据资源,节点间已互相受权,装置即可体验数据处理、数据分析、模型开发、模型评估等次要常见性能。相较于更侧重于生产场景的隐语开放平台,隐语 MVP 部署体验包通过多种形式升高应用门槛,为业务投产正式应用铺垫入门操作根底。(下载地址:https://www.secretflow.org.cn/docs/quickstart/mvp-platform) 1.MVP 部署体验包可能解决什么问题?隐语作为工业级高可用的隐衷计算框架,其性能和稳定性常播种称许。然而,对于许多隐衷计算潜在用户和初学用户而言,根底需要是疾速感知性能、理解残缺流程、取得直观成果,以此来进行判断或决策。隐语 MVP 部署体验包将用户体验反馈转化为成熟的产品能力,站在隐衷计算初学者的角度,尽可能将筹备步骤嵌入装置部署流程,进步用户与隐衷计算性能间接面对面的效率。此外,咱们还破除了原有的申请审核和资源反对限度,让翻新技术可能无门槛地惠及更宽泛的用户体验。 2.隐语 MVP 部署体验包的具体劣势劣势一:化繁为简 缩小筹备步骤中的卡点在本来的体验流程中,用户须要自行配置节点资源和数据资源。为了解决筹备链路长、卡点多的问题,隐语 MVP 部署体验包将这些筹备步骤封装在包内,并以“一键安装包”的模式提供给用户。其装置过程也涵盖了联结我的项目的前序筹备,因而用户能够更疾速地开始体验隐衷计算性能。 劣势二:模板配置 升高简单组件上手难度针对首次体验的用户,隐语 MVP 部署体验包提供场景化训练流模板选项,并已对各组件实现了配置。这些模板能够自动化运行直到后果,帮忙用户了解组件原理并升高自定义训练流中的配置难度。 劣势三:老手训练营 性能体验与性能解说同步进行隐语 MVP 部署体验包将性能与教程合二为一,减少了交互式老手疏导,让用户在学习的同时实现入手实际,进一步平滑隐衷计算的学习曲线。 资源层:解决跨机构计算工作中的多方面难题隐语 1.0 版本正式开源 Kuscia 隐衷计算工作编排框架:Kuscia 能够解决业务在应用隐语时端口合并、API 接入等集成问题,反对通过互联互通或者内置部署第三方零碎等不同模式和第三方零碎互通。(github地址:https://github.com/secretflow/kuscia) 1.什么是基础设施差别?在跨机构计算工作中将引发哪些难题?隐衷计算波及很多跨机构场景,联结我的项目中的各个参与方在数据存储、数据传输、计算资源、安全控制等泛滥方面都不尽相同,这些都能够统称为基础设施的差别。不同参与方在运行环境及网络链路两方面存在差别。网络链路指参与方在构建隐衷计算利用时节点间的通信地址、通信协议、报文加密、申请鉴权等状况,运行环境又可能分为物理机、虚拟机等。 跨机构的计算工作就波及多个机构的资源协同。在任务调度过程中,须要协调和治理各个机构的资源分配以确保工作可能按时实现,须要应用平安的通信协议和机制来爱护数据的传输过程中不被篡改或窃取。如果无奈保障资源的无效治理、迷信调度,就会引发计算工作低效、计算资源节约或冗余、利用不稳固甚至工作失败等一系列问题。 2.Kuscia 是如何解决这些问题的?在部署中,根底解决轻量化的需要(轻量节点最低反对 2C4G),外围关注业务机构接入时多样化的端口适配需要,既反对机构单端口,同时反对多任务端口合并。此外,业务机构以后重点关怀的隐衷计算部署问题还包含组网模式,Kuscia 反对去中心化的平等单干 P2P 模式、更便于对立管控的中心化模式以及多方单干带来两者并存的混合模式。 在工作编排中,除了 DAG 工作编排这类根底标配,Kuscia 重点反对多任务并发。因为隐衷计算工作通常是计算密集型,多机构同时执行及多任务并发会产生计算资源竞争,Kuscia 通过工作间资源隔离、工作优先级可控等形式保障资源的合理配置。 在内部零碎对接中,Kuscia 实现了任务调度层的互联互通,反对银联黑盒互联互通协定。Kuscia 为隐衷计算利用提供一个对立的运行接口,用户能够间接调用多种现有的隐衷计算引擎如 FATE 等。例如,业务方 A 在其业务平台中应用了某框架的联邦学习能力,但因为业务拓展降级,繁多能力已不能满足需要,应用隐语 Kuscia 业务方 A 就能够实现原框架计算能力的集成调用和能力拓展,两者兼得。 ...

July 7, 2023 · 1 min · jiezi

关于大数据:34岁上岸我终于圆了自己的考研梦

大家好,我是独孤风,一位已经的港口煤炭工人,目前在某国企任大数据负责人,公众号大数据流动的作者。 尽管通知本人要平静,然而当接到EMS录取通知书的那一刻,眼眶还是忍不住有些潮湿。往年正好是是东北大学的建校100周年,录取通知书还附赠了小礼物。 上一次接到录取通知书还是15年前的高考吧。尽管这次只是一个非全日制的工程硕士,但因为整个考研路的艰巨,这次录取还是对我意义重大。深夜难以入眠,写下这篇文章来聊聊我本人这贯通十余年的考研之路。 这一路上我曾多次想要放弃,我年纪曾经不小了,有了家庭和孩子。每一分钟的学习工夫对我来说都无比宝贵。而初试统考前三天确诊新冠更差点成为压死我所有心愿的最初一根稻草。 好在我保持到了最初一刻,靠着运气顺利上岸了!这些年来我曾奋斗过的幻想,能实现的终归是多数,大部分半路夭折。但每一次我都拼尽了本人的全力,这才换来了那一丝丝的心愿。而不论成败与否,当我再回首往事,内心中只有平静与喜悦,而不是懊悔与苦楚。这可能也是我一路转行、一直学习取得的最大播种。 人生中能够改变命运的机会并不常见,而机会到来能保持到最初的更是多数。但如果你对命运不服,那就究竟要奋力一搏,抗争到底! 海阔天空 在怯懦当前 要拿执着 将命运的锁突破 冷酷的人 谢谢你们已经看轻我 让我不抬头 更精彩的活 海阔天空 狂风暴雨当前 转过头 对旧心酸一笑而过 最懂我的人 谢谢一路默默地陪我 让我领有 好故事能够说 看将来 一步步来了 如果你也曾有失去过的幻想,心愿读完我这十余年的考研之路,心愿能为你带来一些帮忙。 一、迷茫的大学,考研梦碎 第一次考研梦应该是高考完结的时候,因为高中学业的旷废,我在高考完结的时候无奈给父母一个应有的交代。收到大学录取通知书的时候,大家并没有那么开心,他们也都晓得我本能够考一个更好的大学。那时候我尽管也有懊悔,但也只停留在设想中,没有任何口头,自认为上了大学再去通过考验实现本人的名校梦。 上了大学当前我很快在游戏中迷失了本人,每天的Dota成了日常我的项目。考研的事早已忘得一尘不染。 大三开始,筹备考研的同学曾经踊跃的备考,我也曾短暂的退出到他们的行列当中,然而过后的我自制力太差,断断续续的学了没多长时间。尽管最初和大家一起加入了研究生考试,当了炮灰。 当年的考研人数还是一百多万人,十多年过来后所有曾经翻天覆地。不得不抵赖,在大学期间还是考研的最佳时机,但大把的工夫都被我旷废了。 后续的故事很多敌人曾经晓得,我大学毕业后去了港口成为了一名港口工人,随后北漂重新学习编程、大数据。因为错过了近十年的学习与晋升。我唯有一直的向本人更年老的敌人学习,能力勉强跟上时代的脚本。 不理解我的敌人能够看一下我的工作经验: 从港口煤炭工人,到国企大数据负责人:已经的网瘾少年是怎么做到的? 之前也跟敌人说过,感觉这些年都始终在为年老的本人还债。年龄的增长、家庭的牵绊,学习曾经成为了一种奢求。但不持续学上来,生存的压力只会越来越大,可抉择的权力也将越来越少。所以没什么说的,唯有持续向前。 二、改变命运的机会不多,昙花一现 认真回忆这些年,能改变命运的机会并不多。当年趁互联网的热潮从港口跑了进去,曾经是抓住了最初的红利。当初的行情,如果还有大龄敌人想转行到互联网,我是不倡议的,危险太大了。 在我这些年转行和学习过程中,不是没有过考研的想法。我也能感觉到,本人来到港口当前整个人曾经扭转了。学习不再是苦楚,反而成了一种渴望。18年的时候,工作逐步稳固,我也感觉到本人在计算机专业常识的功底还是比拟单薄,我从新买了当年考研的材料,重新学习高数、英语、计算机基础知识,筹备再战一次。 但事实并不如我所愿,我尽管能够静下心来努力学习。但拥护我考研的声音切实太过弱小,我将在30岁的时候,放弃工作,在没有支出的状况上来攻读一个研究生,而后再从新找工作。这对我来说,又是一个逆天改命的壮举,但对我父母来说,将是一场噩梦。我能够边工作,边一直的尝试,但这样的事实恐怕无奈扭转,我还是抉择了放弃。 尽管考研梦再次幻灭,但我仍然保持学习英语期待幻想降临的那天。侥幸的是,去年共事分享的一则音讯引起了我的留神。东北大学开始招收非全日制工程治理硕士,与MBA不同,工程治理硕士更强调技术与治理的联合,东大也能够选修大数据相干的课程。这,正是我想要的。 尽管学费很贵,但好在周末和早晨上课,不影响下班。而且最近国家对非全日制研究生进行了改革,毕业要求与全日制一样,毕业后也是双证学信网可查。然而须要加入研究生全国统考,对我来说,难度并不低。但我晓得这是我35岁之前最初的机会了,当前想考只会更加艰巨。 机会来了,决不能错过!我成为了四百多万考研大军中的一员。 三、他人备考,我在玩命 备考非全日制研究生并没有设想中的那么简略。考试要考两门科目英语二和管综。英语通过这些年的积攒,再筹备下作文,应该问题不大。然而管综要考数学,逻辑,论文。这些都须要工夫筹备,问题来了,我没有工夫。 我能够工作工夫里抽时间调研新技术,学习大数据,学习数据治理,写写文章。但不能间接就学起数学来,那太嚣张了。而自从有了孩子当前,我上班的工夫简直全副留给了家庭,我不想占用这部分工夫。 就没有方法了吗?思前想后,我终于找到了解决办法,我还有午休和通勤的工夫,那是我平时看球,玩游戏,刷视频的工夫,尽管不舍,只能从这部分工夫里挤了,我没有别的抉择。 我从头开始背考研单词,背数学公式,学习逻辑题。我删掉了游戏,直播吧,各种短视频app,所有可能占用我一分钟工夫的货色都必须隐没。我抓住所有工夫,疯狂学习。 ...

July 3, 2023 · 1 min · jiezi

关于大数据:数据仓库13大数据数仓经典最值得阅读书籍推荐

从事数仓工作,在工作学习过程也看了很多数据仓库方面的数据,此处整顿了数仓中经典的,或者值得浏览的书籍,举荐给大家一下,心愿能帮忙到大家。倡议珍藏起来,后续有新的书籍清单会更新到这里。书籍举荐《数据仓库工具箱(第3版)——维度建模权威指南》本书会介绍基本知识,而后一一探讨具体实例内容,最初进行综合总体剖析,在内容的构造方面很有特色。本书波及的行业较多,但这些内容从不同角度体现了数据仓库的各个方面,因此对于残缺的学习与把握数据仓库常识显得十分必要。 这本书是数据维度建模的鼻祖,从这个意义上讲,就挺有理解的意义,当然外面的内容偏理论化,举的例子也比拟理想化,不过对于咱们对数仓有一个全面的外面,有很大的帮忙。 《Hadoop构建数据仓库实际》书中波及到应用Hadoop建设数据仓库应用到的简直所有的工具,并且介绍了建设数仓波及到的理论知识,比方维度建模中纬度技术事实表技术都解说的挺多,当然此书也更偏向于实际,书中波及到的各种工具的装置应用,装置过程看的很少,一带而过,甚至没看。理论知识挺有实战性,波及到各种工具的应用挺不错。此书最大的帮忙就是从0开始应用Hadoop建设数据仓库并且各种工具的应用。 《大数据之路:阿里巴巴大数据实际》这本书围绕阿里几大数据外围产品开展,横向论述了阿里数据从采集到产品落地的全过程,纵向论述了阿里数据实施方案的几经迭代历程。整书偏技术,适宜具备一些技术实践根底的人进行浏览。要害的技术发展都联合了阿里理论业务场景进行讲述,更易于了解。 读了这本书,会对数仓的具体的实现有一个更好的了解,毕竟能够看看行业外面比拟好的公司是怎么做的,能够给咱们领导一些思路。 《大数据大翻新-阿里巴巴云上数据中台之道》这本书基于大数据摸索的大趋势,讲述阿里巴巴云上数据中台顶层设计,再以理论案例详述阿里巴巴云上数据中台建设及其业务模式的造成过程,总结云上数据中台积淀的独特价值,并推心置腹地分享阿里巴巴以赋能为实质的大数据策略。 这本书有利于进步对数据中台的了解,适合有肯定教训的开发者。 材料分享整顿了数据仓库举荐经典书籍材料包,学习数据仓库必备,蕴含上面的内容,蕴含《阿里巴巴大数据之路》、《数据仓库工具箱》、《Hadoop构建数据仓库实际》等经典书籍PDF,带书签,快点去保留下来吧。 获取形式:【腾讯文档】大数据数仓经典最值得浏览书籍举荐材料分享 也能够间接VX搜“张飞的猪大数据分享”,会不定时分享技术学习的文章和材料,回复“数据仓库”获取下载链接。 分享的材料截图如下,共11本。

July 1, 2023 · 1 min · jiezi

关于大数据:Kafka优化

数新网络官网已全新上线,欢送点击拜访www.datacyber.com 数新网络_让每个人享受数据的价值Kafka介绍Kafka是最后由Linkedin公司开发,是一个分布式、反对分区的(partition)、多正本的(replica),基于zookeeper协调的分布式音讯零碎,它的最大的个性就是能够实时的解决大量数据以满足各种需要场景:比方基于hadoop的批处理零碎、低提早的实时零碎、Storm/Spark流式解决引擎,web/nginx日志、拜访日志,音讯服务等等,用scala语言编写,Linkedin于2010年奉献给了Apache基金会并成为顶级开源我的项目。 Kafka的应用场景日志收集:一个公司能够用Kafka收集各种服务的log,通过kafka以对立接口服务的形式凋谢给各种 consumer,例如hadoop、Hbase、Solr等。 音讯零碎:解耦和生产者和消费者、缓存音讯等。 用户流动跟踪:Kafka常常被用来记录web用户或者app用户的各种流动,如浏览网页、搜寻、点击等流动,这些流动信息被各个服务器公布到kafka的topic中,而后订阅者通过订阅这些topic来做实时的监控剖析,或者装载到 hadoop、数据仓库中做离线剖析和开掘。 经营指标:Kafka也常常用来记录经营监控数据。包含收集各种分布式应用的数据,生产各种操作的集中反馈,比方报警和报告。 Kafka优化Kafka作为一款高性能消息中间件被广泛应用于各大零碎中,然而同其余中间件一样,也会存在一些问题。音讯失落状况音讯在发送端和生产端都有可能会产生数据失落的状况。 音讯发送端: acks=0时,示意producer不须要期待任何broker确认收到音讯的回复,就能够持续发送下一条音讯。如果此时broker宕机,就会导致音讯失落。 acks=1时,至多要期待leader曾经胜利将数据写入本地log,然而不须要期待所有follower是否胜利写入。作为集群应用时,如果follower还未胜利写入,在leader写入后,follow还没有来得及fetch到leader的最新消息,leader宕机了,follower拉取失败,并开始进行leader选举,新的leader因为没有同步最新的音讯,导致该音讯失落。 acks=-1或all时,这意味着leader须要期待所有备份都胜利写入日志。这种策略会保障只有有一个备份存活就不会失落数据。然而须要min.insync.replicas配置的备份个数大于等于2,当leader宕机之后,会从新进行leader选举,选举lsr列表中的第一个broker作为leader,而lsr列表中的broker都是同步数据最多的,会保证数据不失落。音讯生产端: 如果音讯是主动提交,万一生产到数据还没解决完,就主动提交offset了,然而此时你consumer间接宕机了,未解决完的数据失落了,下次也生产不到了。 音讯反复生产音讯反复生产与音讯失落一样,在发送端和生产端都会产生数据反复生产的状况。 音讯发送端: 发送音讯如果配置了重试机制,服务端收到了音讯,并进行ack的时候,因为网络问题导致发送端始终没有收到服务端发送的返回音讯,就会启动重试机制再次发送。音讯生产端: 如果生产端配置了主动提交,刚拉取了一批数据处理了一部分,还没来得及提交,服务挂了,下次重启又会拉取雷同的一批数据反复解决。 个别生产端都要进行生产幂等解决。音讯乱序如果发送端配置了重试机制,Kafka不会等之前那条音讯齐全发送才去发送下一条音讯,这样可能会呈现,发送时程序为1,2,3的音讯,第一条超时后从新发送,前面两条发送胜利,最终生产端生产的程序是2,3,1。Kafka要保障全链路音讯程序生产,须要从发送端开始,将所有音讯有序发送到同一个分区,而后用一个消费者去生产,然而这种性能比拟低,能够在消费者端接管到音讯后将须要保障程序生产的几条生产发到内存队列,一个内存队列开启一个线程程序解决音讯。 如果须要将音讯发送到不同分区并保障程序生产。个别不倡议这么做。发送端在发送音讯时,在音讯中增加一个排序号,消费者端在接管时定义一个CountDownLatch,确保将须要程序生产的音讯收齐,依据排序号排序后再解决。 音讯积压线上有时因为发送端发送音讯速度过快,或者生产端解决音讯过慢,导致broker积压大量未生产音讯。这种状况能够批改生产端程序,让其将收到的音讯疾速转发到其余topic,而后再启动多个消费者同时生产新主题的不同分区。 因为音讯数据格式变动或生产端程序有bug,导致消费者统一生产不胜利,也会导致broker积压大量未生产音讯。这种状况能够配置一个topic作为死信队列,将生产不胜利的的音讯放入到死信队列,之后再缓缓剖析死信队列里的音讯解决问题。延时队列延时队列存储的对象是延时音讯。指音讯被发送当前,并不想让消费者立即获取,而是期待特定的工夫后,消费者能力获取这个音讯进行生产,延时队列的应用场景有很多,比方:在订单零碎中,一个用户下单之后通常有30分钟的工夫进行领取,如果30分钟之内没有领取胜利,那么这个订单将进行异样解决,这时就能够应用延时队列来解决这些订单了。订单实现1小时后告诉用户进行评估。 实现思路:发送延时音讯时先把音讯依照不同的延迟时间段发送到指定的队列中(topic_5s,topic30s…,topic_n,这个个别不能反对任意时间段的延时),而后通过定时器进行轮询生产这些topic,查看音讯是否到期,如果到期就把这个音讯发送到具体业务解决的topic中,队列中音讯越靠前的到期工夫越早,具体来说就是定时器在一次生产过程中,对音讯的发送工夫做判断,看下是否提早到对应工夫了,如果到了就转发,如果还没到这一次定时工作就能够提前结束了。音讯回溯如果某段时间对已生产音讯计算的后果感觉有问题,可能是因为程序bug导致的计算错误,当程序bug修复后,须要对之前已生产的音讯从新生产,能够指定从多久之前的音讯回溯音讯,这种能够用consumer的offsetForTimes、seek等办法制订从某个offset偏移的音讯开始生产。消息传递保障at most once(消费者最多收到一次音讯):acks=0能够实现at least once(消费者至多收到一次音讯):acks=all能够实现 exactly once(消费者刚好收到一次音讯):at least once加上消费者幂等性能够实现,还能够用Kafka生产者的幂等性来实现。 Kafka事务Kafka的事务不同于Rocketmq,Rocketmq是保障本地事务与mq音讯发送的事务一致性,Kafka的事务次要是保障一次发送多条音讯的事务一致性,个别在Kafka的流式计算场景用得多一点,比方,Kafka须要对一个topic里的音讯做不同的流式计算解决,解决完别离发到不同的topic里,这些topic别离被不同的上游零碎生产,这种咱们必定心愿零碎发送到多个topic的数据放弃事务一致性。Kafka要实现相似Rocketmq相似的分布式事务须要额定开发性能。本期分享就到这里,欢送关注咱们理解更多精彩内容~

June 29, 2023 · 1 min · jiezi

关于大数据:一年省七位数得物自建HFDS在-Flink-Checkpoint-场景下的应用实践

1 背景随着Flink实例的迁徙下云以及新增需要接入,自建Flink平台规模逐步壮大,以后总计已超4万核运行在自建的K8S集群中,然而 Flink 工作数的减少,特地是大状态工作,每次Checkpoint 时会产生脉冲式带宽占用,峰值流量超过100Gb/s,晚期应用OSS作为Checkpoint数据存储,单个Bucket 每 1P数据量只有收费带宽10Gb/s,超出局部独自计费,以后规模每月须要减少1x w+/月。 为了管制这部分老本,得物发展了自建HDFS在Flink Checkpoint场景下的落地工作,实现年度老本节俭xxx万元。 此次分享自建HDFS在实时计算checkpoint场景的实践经验,心愿能为读者提供一些参考。 2 Flink Checkpoint 介绍2.1 Flink里的Checkpoint是什么?Checkpoint:简略的说,在某一时刻,将 Flink 工作本地机器中存储在状态后端的状态去同步到近程文件存储系统(比方 HDFS)的过程就叫 Checkpoint。 状态后端:做状态数据长久化的工具就叫做状态后端。比方你在 Flink 中见到的 RocksDB、FileSystem 的概念就是指状态后端,再引申一下,也能够了解为:利用中有一份状态数据,把这份状态数据存储到 MySQL 中,这个 MySQL 就能叫做状态后端。 2.2 Checkpoint解决什么问题?其实在实时计算中的状态的性能次要体现在工作能够做到失败重启后没有数据品质、时效问题。 实时工作个别都是 7x24 小时 Long run 的,挂了之后,就会有以下两个问题,首先给一个理论场景:一个生产上游 Kafka,应用 Set 去重计算 DAU 的实时工作。 数据品质问题:当这个实时工作挂了之后复原,Set空了,这时候工作再持续从上次失败的 Offset 生产 Kafka 产出数据,则产出的数据就是谬误数据了 数据时效问题:一个实时工作,产出的指标是有时效性(次要是时延)要求的。你能够从明天 0 点开始从新生产,然而你回溯数据也是须要工夫的。举例:中午 12 点挂了,实时工作从新回溯 12 个小时的数据能在 1 分钟之内实现嘛?大多数场景下是不能的!个别都要回溯几个小时,这就是实时场景中的数据时效问题。 而 Flink的Checkpoint就是把 Set 定期的存储到近程 HDFS 上,当工作挂了,咱们的工作还能够从 HDFS 下面把这个数据给读回来,接着从最新的一个 Kafka Offset 持续计算就能够,这样即没有数据品质问题,也没有数据时效性问题。 2.3 Checkpoint的运行流程?JM 定时调度 Checkpoint 的触发,承受到 JM 做 Checkpoint 的申请后,开始做本地 Checkpoint,暂停解决新流入的数据,将新数据缓存起来。将工作的本地状态数据,复制到一个近程的长久化存储(HDFS)空间上。持续解决新流入的数据,包含方才缓存起来的数据。 ...

June 29, 2023 · 2 min · jiezi

关于大数据:Hologres弹性计算在OLAP分析上的实践和探索

作者:王奇 阿里云Hologres研发 简介: 1、本文介绍了OLAP剖析在大数据分析中的地位 2、剖析并介绍目前大数据OLAP遇到的剖析性能、资源隔离、高可用、弹性扩缩容等外围问题 3、解析阿里云Hologres是如何解决极致性能、弹性、业务永续、性价比等外围刚需的最佳实际 4、介绍阿里云Hologres弹性计算组在弹性计算、资源隔离上的摸索和翻新 一、 OLAP剖析在大数据分析中的地位目前业界将大数据分析次要分为四个阶段:描述性剖析、诊断性剖析、预测性剖析、规范性剖析。 目前OLAP剖析次要集中在描述性分析阶段,其中诊断性剖析、预测性剖析、规范性剖析属于高阶剖析畛域,后续OLAP剖析也会逐渐浸透于诊断性剖析和预测性剖析中。 二、Hologres如何解决OLAP剖析的外围问题OLAP剖析的外围问题剖析性能差,数据价值可望而不可及。 以后大数据在接受度、技术、利用等各方面趋于成熟,大数据逐渐利用于各行各业,这些行业在大数据应用领域面临的第一个问题和挑战就是剖析性能差,进而妨碍了开掘大数据中的微小价值。如何让用户更快的进行OLAP数据分析是广泛面临的一个问题。多种业务场景之间相互影响,隔离老本较高。 业务在线上常常会遇到不同业务场景之间的相互影响而带来的查问抖动的问题,比方写写之间、读写之间、大小查问间的相互影响,以及在线服务、多维分析、即席剖析等之间的相互影响。尤其是某些大数据引擎并不是存算拆散架构,个别会通过复制多正本去实现隔离,老本很高。无服务级高可用、 容灾和多活的计划。 业务个别通过双/多链路来实现高可用、容灾和多活,这其中波及的人力、计算资源等老本较高。不反对弹性扩容。 越来越多的业务对弹性能力有着强烈的诉求。当业务流量忽然增长能及时扩容扛住流量,否则对业务就意味着资损;在业务低峰时能及时缩容,降低成本。那么如何低成本的实现弹性扩缩容是大数据引擎面临的一个广泛问题,尤其是某些引擎不是存算拆散架构,个别是须要通过数据的复制来实现多正本,基本上很难实现及时的弹性扩容能力。 OLAP剖析的外围刚需:高性能、弹性、低成本随着业务的一直倒退,OLAP剖析也逐步进入大多数业务的外围在线场景。用户对其OLAP剖析有如下四大刚需: 业务永续:有高可用、容灾和多活的能力,晋升生产零碎的稳定性极致性能:数据的价值应该被最大水平的开掘,须要有更加极致的性能来满足业务需要弹性:弹性资源可能很好的反对业务的动态变化,满足业务的不同需要低成本:用更少的老本反对更多的业务,实现更高的性价比 Hologres如何解决OLAP剖析的外围问题Hologres是阿里云自研的一站式实时数仓引擎,反对数据的实时写入、实时更新,同时也反对OLAP剖析和在线服务查问,目前已广泛应用于阿里外部泛滥外围业务场景,包含菜鸟物流、淘宝搜寻举荐等,同时在云上也有着泛滥客户实际。那Hologres作为企业级的生产实时数仓,是如何解决OLAP剖析问题呢? 1、HSAP架构使用。 在解决OLAP剖析时使用 Hybrid Serving/Analytical Processing(HSAP)设计理念,通过对立的实时存储,数据无需复制就能一站式提供简略查问、OLAP 剖析、在线数据服务等多样化的数据查问和应用服务,满足数据利用方的拜访和接入需要。这种架构大大地升高了业务的复杂度,疾速应答新的业务需要。同时也提供的秒级甚至亚秒级实时性让决策更及时高效,从而让数据发明出更大的商业价值。 2、弹性能力晋升。 Hologres引入弹性计算组模式(Warehouse),每个Warehouse可按时按需创立销毁,重新配置,且可动静热扩缩容。计算和存储高度可扩大,具备双重弹性的能力。 3、云原生资源存储。 基于云原生资源存储的弹性扩大,按需应用,能够做到低成本、高可用,高牢靠,同时还具备弹性能力。 4、极致性能。 基于现有的C++ Native执行引擎+优化器,领有全异步框架(Thread-per-core 架构)、向量化计算、多种 Index 的实现、精细化的 Cache、基于代价的优化器模型,反对各种 predicted pushdown、runtime filter 等;轻量级用户态线程调度,同时反对多种查问负载(高并发、简单统计)、偏心调度算法(CFS)、高并发充分利用计算资源等次要个性。 5、实现流批对立存储。 具备业内当先的行列共存个性,列存对查问剖析敌对,行存对点查疾速;具备高效数据分片、分段、压缩、索引;LSM-like 写敌对数据结构,高吞吐数据写入,反对更新,写入即可见。 三、Hologres只读从实例(共享存储)解决隔离问题如上文所述,简直每个用户都会遇到不同业务场景之间的相互影响而带来的查问抖动的问题。不同的引擎因为架构不一样,对于隔离的实现也不一样,那Hologres又是如何解决隔离的问题呢,上面咱们以具体场景为例: 具体场景:场景一:多种业务场景之间相互影响 。 简直每个用户都会遇到不同业务场景之间相互影响而带来抖动。比方:读写、读读 相互影响;剖析、服务、离线加工 相互影响 场景二:在线业务须要通过多链路能力实现计算多活 。 具体挑战:挑战一:如何更好的解决系统资源隔离的问题 挑战二:如何让用户更简略低成本的实现计算多活,降本提效 具体措施: 通过Hologres只读实例(共享存储)来解决只读实例具备五大个性:基于物理WAL日志驱动、共享存储、物理文件的齐全复用、主实例 Failover 时从实例不受影响、只读实例 Failover 时可从最新地位开始复原。通过只读实例能够实现: 资源隔离:用户能够实现残缺的读写/读读拆散性能,保障不同业务场景的服务稳定性;计算多活:用户只需简略配置能够疾速实现同城计算多活,以更少的资源(8~10:1)实现多链路,并节俭用户的人力、计算资源等老本。 四、Hologres新一代弹性计算组实例解决弹性问题越来越多的业务对弹性能力有着强烈的诉求,那么Hologres又是如何解决弹性的问题呢? 具体场景:场景一:只读实例须要多个Endpoint,用户感知差 。业务须要配置新的Endpoint能力应用新的只读实例。 场景二:用户心愿业务高下峰弹性扩缩容 。用户冀望按需弹性扩缩容,节省成本。 场景三:用户心愿有更灵便更精细化的资源隔离计划 ,能够按业务等场景实现资源隔离。比方:写写隔离,业务隔离。 具体措施:建设新一代实时数仓Hologres弹性计算组实例为了更好的解决弹性问题,满足业务不同场景下对资源的正当应用,Hologres率先反对弹性计算组实例。弹性计算组实例采纳 Multi-cluster, Shared Data 架构,将计算资源合成为不同的计算组(Warehouse),每个计算组可独立弹性扩大,计算组之间共享数据、元数据。 ...

June 29, 2023 · 1 min · jiezi

关于大数据:终于肝完了全网最全最详细最全面的-Hadoop大数据学习教程-2023最新版

大家好,我是民工哥! 后面给大家介绍了:关系型数据库 MySQL 、 NoSQL 数据库 Redis 、 MongoDB 、搜索引擎 ElasticSearch 等常识体系学习的文章。 在当今这样的待业大背景下,卷是必定的,弱小本人也是必须的。所以,学习不能停,必须始终卷上来。截止明天,又一个常识体系的学习之旅:大数据 Hadoop 框架 卷完了。心愿大家可能从中播种多多!如有帮忙,请点在看、转发反对一波!!! 大数据概述大数据(big data),指的是在肯定工夫范畴内不能以惯例软件工具解决(存储和计算)的大而简单的数据集。说白了大数据就是应用单台计算机没法在规定工夫内解决完,或者压根就没法解决的数据集。 Hadoop 是用于解决大数据的工具之一。Hadoop 和其余软件产品通过特定的专有算法和办法来解释或解析大数据搜寻的后果。在大数据处理上,Hadoop并非是惟一的分布式解决架构,然而对于大部分的企业来说,基于Hadoop曾经可能满足绝大部分的数据需要,因而才会成为当初的支流抉择。 明天 ,终终终于卷完了!!!! 心愿大家可能从中播种多多!如有帮忙,请点在看、转发反对一波!!! 进击大数据系列(一):Hadoop 基本概念与生态介绍 进击大数据系列(二):Hadoop 装置(HDFS+YARN+MapReduce)实战操作 进击大数据系列(三):Hadoop 常用命令介绍 进击大数据系列(四):Hadoop 架构基石分布式文件系统 HDFS 进击大数据系列(五):Hadoop 对立资源管理和调度平台 YARN 进击大数据系列(六):Hadoop 分布式计算框架 MapReduce 进击大数据系列(七):Hadoop 数据仓库 Hive 进击大数据系列(八)Hadoop 通用计算引擎 Spark 进击大数据系列(九)Hadoop 实时计算流计算引擎 Flink 进击大数据系列(十)Hadoop 架构数据库 Hbase 进击大数据系列(十一)Hadoop 任务调度框架 Oozie 进击大数据系列(十二)Hadoop 数据同步工具 Sqoop 进击大数据系列(十三)Hadoop 分布式日志采集零碎 Flume 进击大数据系列(十四)Hadoop 数据分析引擎 Apache Pig 进击大数据系列(十五)Hadoop 图形化管理系统 Hue 进击大数据系列(十六)Hadoop 性能优化与运维 如果本文对你有帮忙的话,欢送点赞&转发,这对我持续分享&创作优质文章十分重要。感激 如有谬误或其它问题,欢送小伙伴留言评论、斧正。如有帮忙,欢送点赞+转发分享。 更多相干开源技术文章,请继续关注:民工哥技术专栏

June 28, 2023 · 1 min · jiezi

关于大数据:MaxCompute湖仓一体近实时增量处理技术架构揭秘

作者: 喻奎 阿里云智能 高级技术专家 本文次要从四局部介绍,阿里云云原生大数据计算服务MaxCompute湖仓一体近实时增量解决技术架构的外围设计和利用场景。 一、MaxCompute 湖仓一体倒退过程 MaxCompute作为阿里云自研的海量大数据处理平台曾经有十几年的倒退历史,在规模和扩展性方面始终体现比拟优良。其依靠阿里云飞天分布式操作系统,可能提供疾速,齐全托管的EB级数据仓库及数据湖解决方案,可经济高效的解决海量数据。目前,其承当着阿里团体绝大部分离线数据存储和计算力,是阿里云产品矩阵中最重要的自研外围平台之一。 MaxCompute倒退之初,次要聚焦数仓方面的大数据处理业务场景,并且解决的数据源次要为格式化数据。随着数据处理场景的多样化和业界数据湖架构的衰亡,加上阿里团体外部自身数据也十分多,反对多样化数据源也就成为了一个必选项。因而MaxCompute 设计了欠缺的表面机制,能够读取存储在内部多种格局的数据对象,例如Hadoop开源体系,OSS半结构化或非结构化数据,为此也尽可能设计开发对立的元数据处理架构,此阶段MaxCompute 在湖仓一体化解决方案中迈出了重要一步,极大的扩大了数据处理的业务场景,无效的突破数据孤岛,联动各方面的数据进行综合剖析来开掘整体数据价值。但时效性有余,通常是T+1离线场景。 随着用户数和数据规模一直减少,很多业务场景也越加简单,须要更加欠缺综合的整体解决方案。其中的关键环节之一就是数据须要更加高效的流转起来,为此MaxCompute 进一步设计欠缺凋谢存储和计算架构,更好的去交融生态,让数据可晦涩的进得来也出得去。此外,还有一个重要的业务场景是大规模批量解决和高时效高效率增量解决一体化解决方案,为简化用户数据处理链路,节俭不同零碎之间的数据迁徙老本以及冗余计算和存储老本,MaxCompute 团队设计开发了MaxCompute离线和近实时增量解决的一体化架构。总体来说,现阶段以及将来会基于对立的存储、对立的元数据、对立的计算引擎无效撑持湖仓一体的整体技术架构,让数据可能凋谢互通高效流转,并且计算和存储老本继续优化。 二、MaxCompute近实时增量解决技术架构简介MaxCompte离线 &近实时增量解决业务零碎架构现状 随着以后数据处理的业务场景日趋简单,对于时效性要求低的大规模数据全量批处理的场景,间接应用MaxCompute 足以很好的满足业务需要,对于时效性要求很高的秒级实时数据处理或者流解决,则须要应用实时零碎或流零碎来满足需要。 但其实对于大部份业务场景,并不要求秒级数据更新可见,更多的是分钟级或者小时级的增量数据处理场景,并且叠加海量数据批处理场景。 对于这类业务场景的解决方案,如果应用繁多的MaxCompute 离线批量解决链路,为了计算的高效性,须要将用户各种简单的一些链路和解决逻辑转化成T+1的批次解决,链路复杂度减少,也可能产生冗余的计算和存储老本,且时效性也较差。但如果应用繁多的实时零碎,资源耗费的老本比拟高,性价比也较低,并且大规模数据批处理的稳定性也有余。因而以后比拟典型的解决方案是Lambda架构,全量批处理应用MaxCompute链路,时效性要求比拟高的增量解决应用实时零碎链路,但该架构也存在大家所熟知的一些固有缺点,比方多套解决和存储引擎引发的数据不统一问题,多份数据冗余存储和计算引入的额定老本,架构简单以及开发周期长等。 针对这些问题近几年大数据开源生态也推出了各种解决方案,最风行的就是Spark/Flink/Presto开源数据处理引擎,深度集成开源数据湖Hudi、Delta Lake和Iceberg三剑客,来综合提供解决方案,解决Lamdba架构带来的一系列问题,而MaxCompute近一年自研开发的离线近实时增量解决一体化架构,同样是为了解决这些问题而设计,不仅仅具备分钟级的增全量数据读写以及数据处理的业务需要,也能提供Upsert,Timetravel等一系列实用功能,可大幅扩大业务场景,并且无效的节俭数据计算,存储和迁徙老本,切实进步用户体验。下文就将介绍该技术架构的一些典型的性能和设计。 MaxCompute近实时增量解决技术架构 MaxCompute近实时增量解决整体架构的设计改变次要集中在五个模块:数据接入、计算引擎、数据优化服务,元数据管理,数据文件组织。其余部份间接复用MaxCompute 已有的架构和计算流程,比方数据的分布式存储间接集成了阿里云基础设施盘古服务。 数据接入次要反对各种数据源全量和近实时增量导入性能。MaxCompute 联结相干产品定制开发多种数据接入工具,例如MaxCompute 定制开发的Flink Connector,DataWorks的数据集成等,用来反对高效的近实时增量数据导入。这些工具会对接MaxCompute 的数据通道服务Tunnel Server,次要反对高并发分钟级增量数据写入。此外,也反对MaxCompute SQL,以及其它一些接口用于反对全量数据高效写入。计算引擎次要蕴含MaxCompute 自研的SQL引擎,负责Timetravel和增量场景下的SQL DDL/DML/DQL的语法解析,优化和执行链路。此外,MaxCompute外部集成的Spark等引擎也在设计开发反对中。数据优化服务次要由MaxCompute 的Storage Service来负责智能的主动治理增量数据文件,其中包含小文件合并Clustering,数据Compaction,数据排序等优化服务。对于其中局部操作,Storage Service会依据数据特色,时序等多个维度综合评估,主动执行数据优化工作,尽可能放弃衰弱高效的数据存储和计算状态。元数据管理次要负责增量场景下数据版本治理,Timetravel治理,事务并发抵触治理,元数据更新和优化等。数据文件组织次要蕴含对全量和增量数据文件格式的治理以及读写相干的模块。三、外围设计解剖对立的数据文件组织格局 要反对全量和增量解决一体化架构首先须要设计对立的表类型以及对应的数据组织格局,这里称为Transactional Table2.0,简称TT2,根本能够反对一般表的所有性能,同时反对增量解决链路的新场景,包含timetravel查问、upsert操作等。 TT2要失效只须要在创立一般表时额定设置主键primary key(PK),以及表属性transactional为true即可。PK列用于反对Upsert链路性能,PK值雷同的多行记录在查问或者Compaction会merge成一行数据,只保留最新状态。transactional属性则代表反对ACID事务机制,满足读写快照隔离,并且每行数据会绑定事务属性,比方事务timestamp,用来反对timetravel查问,过滤出正确数据版本的记录。此外TT2的tblproperties还能够设置其余的一些可选的表属性,比方write.bucket.num用来配置数据写入的并发度,acid.data.retain.hours用来配置历史数据的无效查问工夫范畴等。 TT2表数据文件存在多种组织格局用来反对丰盛的读写场景。其中base file数据文件不保留Update/Delete中间状态,用来撑持全量批处理的读写效率,delta file增量数据文件会保留每行数据的中间状态,用于满足近实时增量读写需要。 为了进一步优化读写效率,TT2反对依照BucketIndex对数据进行切分存储,BucketIndex数据列默认复用PK列,bucket数量可通过配置表属性write.bucket.num指定,数据写入的高并发可通过bucket数量程度扩大,并且查问时,如果过滤条件为PK列,也可无效的进行Bucket裁剪查问优化。数据文件也可依照PK列进行排序,可无效晋升MergeSort的效率,并有助于DataSkipping查问优化。数据文件会依照列式压缩存储,可无效缩小存储的数据量,节省成本,也可无效的晋升IO读写效率。 数据近实时流入后面介绍了对立的数据组织格局,接下来须要思考数据如何高效写入TT2。 数据流入次要分成近实时增量写入和批量写入两种场景。这里先形容如何设计高并发的近实时增量写入场景。用户的数据源丰盛多样,可能存在数据库,日志零碎或者其余音讯队列等零碎中,为了不便用户迁徙数据写入TT2, MaxCompute定制开发了Flink Connector、Dataworks数据集成以及其它开源工具,并且针对TT2表做了很多专门的设计开发优化。这些工具外部会集成MaxCompute 数据通道服务Tunnel提供的客户端SDK,反对分钟级高并发写入数据到Tunnel Server,由它高并发把数据写入到每个Bucket的数据文件中。 写入并发度可通过后面提及的表属性write.bucket.num来配置,因而写入速度可程度扩大。对同一张表或分区的数据,写入数据会按pk值对数据进行切分,雷同pk值会落在同一个bucket桶中。此外,数据分桶的益处还有利于数据优化治理操作例如小文件clustering,compaction等都能够桶的粒度来并发计算,进步执行效率。分桶对于查问优化也十分有益处,可反对bucket裁剪、shuffle move等查问优化操作。 Tunnel SDK提供的数据写入接口目前反对upsert和delete两种数据格式,upsert蕴含insert / update两种隐含语义,如数据行不存在就代表insert,如已存在就代表update。commit接口代表原子提交这段时间写入的数据如返回胜利就代表写入数据查问可见,满足读写快照隔离级别,如返回失败,数据须要从新写入。 SQL批量写入 批量导入次要通过SQL进行操作。为了不便用户操作,实现了操作TT2所有的DDL / DML语法。SQL引擎内核模块包含Compiler、Optimizer、Runtime等都做了大量革新开发以反对相干性能,包含特定语法的解析,特定算子的Planner优化,针对pk列的去重逻辑,以及runtime结构Upsert格局数据写入等。数据计算写入实现之后,会由Meta Service来原子性更新Meta信息,此外,也做了大量革新来反对残缺的事务机制保障读写隔离、事务冲突检测等等。 小数据文件合并因为TT2自身反对分钟级近实时增量数据导入,高流量场景下可能会导致增量小文件数量收缩,从而引发存储拜访压力大、老本高,并且大量的小文件还会引发meta更新以及剖析执行慢,数据读写IO效率低下等问题,因而须要设计正当的小文件合并服务, 即Clustering服务来主动优化此类场景。 Clustering服务次要由MaxCompute 外部的Storage Service来负责执行,专门解决小文件合并的问题,须要留神的是,它并不会扭转任何数据的历史中间状态,即不会打消数据的Update/Delete中间状态。 ...

June 28, 2023 · 1 min · jiezi

关于大数据:MaxCompute-湖仓一体近实时增量处理技术架构揭秘

本文次要从四局部介绍,阿里云云原生大数据计算服务MaxCompute湖仓一体近实时增量解决技术架构的外围设计和利用场景。 一、MaxCompute 湖仓一体倒退过程 MaxCompute作为阿里云自研的海量大数据处理平台曾经有十几年的倒退历史,在规模和扩展性方面始终体现比拟优良。其依靠阿里云飞天分布式操作系统,可能提供疾速,齐全托管的EB级数据仓库及数据湖解决方案,可经济高效的解决海量数据。目前,其承当着阿里团体绝大部分离线数据存储和计算力,是阿里云产品矩阵中最重要的自研外围平台之一。 MaxCompute倒退之初,次要聚焦数仓方面的大数据处理业务场景,并且解决的数据源次要为格式化数据。随着数据处理场景的多样化和业界数据湖架构的衰亡,加上阿里团体外部自身数据也十分多,反对多样化数据源也就成为了一个必选项。因而MaxCompute 设计了欠缺的表面机制,能够读取存储在内部多种格局的数据对象,例如Hadoop开源体系,OSS半结构化或非结构化数据,为此也尽可能设计开发对立的元数据处理架构,此阶段MaxCompute 在湖仓一体化解决方案中迈出了重要一步,极大的扩大了数据处理的业务场景,无效的突破数据孤岛,联动各方面的数据进行综合剖析来开掘整体数据价值。但时效性有余,通常是T+1离线场景。 随着用户数和数据规模一直减少,很多业务场景也越加简单,须要更加欠缺综合的整体解决方案。其中的关键环节之一就是数据须要更加高效的流转起来,为此MaxCompute 进一步设计欠缺凋谢存储和计算架构,更好的去交融生态,让数据可晦涩的进得来也出得去。此外,还有一个重要的业务场景是大规模批量解决和高时效高效率增量解决一体化解决方案,为简化用户数据处理链路,节俭不同零碎之间的数据迁徙老本以及冗余计算和存储老本,MaxCompute 团队设计开发了MaxCompute离线和近实时增量解决的一体化架构。总体来说,现阶段以及将来会基于对立的存储、对立的元数据、对立的计算引擎无效撑持湖仓一体的整体技术架构,让数据可能凋谢互通高效流转,并且计算和存储老本继续优化。 二、MaxCompute近实时增量解决技术架构简介MaxCompte离线 &近实时增量解决业务零碎架构现状 随着以后数据处理的业务场景日趋简单,对于时效性要求低的大规模数据全量批处理的场景,间接应用MaxCompute 足以很好的满足业务需要,对于时效性要求很高的秒级实时数据处理或者流解决,则须要应用实时零碎或流零碎来满足需要。 但其实对于大部份业务场景,并不要求秒级数据更新可见,更多的是分钟级或者小时级的增量数据处理场景,并且叠加海量数据批处理场景。 对于这类业务场景的解决方案,如果应用繁多的MaxCompute 离线批量解决链路,为了计算的高效性,须要将用户各种简单的一些链路和解决逻辑转化成T+1的批次解决,链路复杂度减少,也可能产生冗余的计算和存储老本,且时效性也较差。但如果应用繁多的实时零碎,资源耗费的老本比拟高,性价比也较低,并且大规模数据批处理的稳定性也有余。因而以后比拟典型的解决方案是Lambda架构,全量批处理应用MaxCompute链路,时效性要求比拟高的增量解决应用实时零碎链路,但该架构也存在大家所熟知的一些固有缺点,比方多套解决和存储引擎引发的数据不统一问题,多份数据冗余存储和计算引入的额定老本,架构简单以及开发周期长等。 针对这些问题近几年大数据开源生态也推出了各种解决方案,最风行的就是Spark/Flink/Presto开源数据处理引擎,深度集成开源数据湖Hudi、Delta Lake和Iceberg三剑客,来综合提供解决方案,解决Lamdba架构带来的一系列问题,而MaxCompute近一年自研开发的离线近实时增量解决一体化架构,同样是为了解决这些问题而设计,不仅仅具备分钟级的增全量数据读写以及数据处理的业务需要,也能提供Upsert,Timetravel等一系列实用功能,可大幅扩大业务场景,并且无效的节俭数据计算,存储和迁徙老本,切实进步用户体验。下文就将介绍该技术架构的一些典型的性能和设计。 MaxCompute近实时增量解决技术架构 MaxCompute近实时增量解决整体架构的设计改变次要集中在五个模块:数据接入、计算引擎、数据优化服务,元数据管理,数据文件组织。其余部份间接复用MaxCompute 已有的架构和计算流程,比方数据的分布式存储间接集成了阿里云基础设施盘古服务。 数据接入次要反对各种数据源全量和近实时增量导入性能。MaxCompute 联结相干产品定制开发多种数据接入工具,例如MaxCompute 定制开发的Flink Connector,DataWorks的数据集成等,用来反对高效的近实时增量数据导入。这些工具会对接MaxCompute 的数据通道服务Tunnel Server,次要反对高并发分钟级增量数据写入。此外,也反对MaxCompute SQL,以及其它一些接口用于反对全量数据高效写入。计算引擎次要蕴含MaxCompute 自研的SQL引擎,负责Timetravel和增量场景下的SQL DDL/DML/DQL的语法解析,优化和执行链路。此外,MaxCompute外部集成的Spark等引擎也在设计开发反对中。数据优化服务次要由MaxCompute 的Storage Service来负责智能的主动治理增量数据文件,其中包含小文件合并Clustering,数据Compaction,数据排序等优化服务。对于其中局部操作,Storage Service会依据数据特色,时序等多个维度综合评估,主动执行数据优化工作,尽可能放弃衰弱高效的数据存储和计算状态。元数据管理次要负责增量场景下数据版本治理,Timetravel治理,事务并发抵触治理,元数据更新和优化等。数据文件组织次要蕴含对全量和增量数据文件格式的治理以及读写相干的模块。三、外围设计解剖对立的数据文件组织格局 要反对全量和增量解决一体化架构首先须要设计对立的表类型以及对应的数据组织格局,这里称为Transactional Table2.0,简称TT2,根本能够反对一般表的所有性能,同时反对增量解决链路的新场景,包含timetravel查问、upsert操作等。 TT2要失效只须要在创立一般表时额定设置主键primary key(PK),以及表属性transactional为true即可。PK列用于反对Upsert链路性能,PK值雷同的多行记录在查问或者Compaction会merge成一行数据,只保留最新状态。transactional属性则代表反对ACID事务机制,满足读写快照隔离,并且每行数据会绑定事务属性,比方事务timestamp,用来反对timetravel查问,过滤出正确数据版本的记录。此外TT2的tblproperties还能够设置其余的一些可选的表属性,比方write.bucket.num用来配置数据写入的并发度,acid.data.retain.hours用来配置历史数据的无效查问工夫范畴等。 TT2表数据文件存在多种组织格局用来反对丰盛的读写场景。其中base file数据文件不保留Update/Delete中间状态,用来撑持全量批处理的读写效率,delta file增量数据文件会保留每行数据的中间状态,用于满足近实时增量读写需要。 为了进一步优化读写效率,TT2反对依照BucketIndex对数据进行切分存储,BucketIndex数据列默认复用PK列,bucket数量可通过配置表属性write.bucket.num指定,数据写入的高并发可通过bucket数量程度扩大,并且查问时,如果过滤条件为PK列,也可无效的进行Bucket裁剪查问优化。数据文件也可依照PK列进行排序,可无效晋升MergeSort的效率,并有助于DataSkipping查问优化。数据文件会依照列式压缩存储,可无效缩小存储的数据量,节省成本,也可无效的晋升IO读写效率。 数据近实时流入后面介绍了对立的数据组织格局,接下来须要思考数据如何高效写入TT2。 数据流入次要分成近实时增量写入和批量写入两种场景。这里先形容如何设计高并发的近实时增量写入场景。用户的数据源丰盛多样,可能存在数据库,日志零碎或者其余音讯队列等零碎中,为了不便用户迁徙数据写入TT2, MaxCompute定制开发了Flink Connector、Dataworks数据集成以及其它开源工具,并且针对TT2表做了很多专门的设计开发优化。这些工具外部会集成MaxCompute 数据通道服务Tunnel提供的客户端SDK,反对分钟级高并发写入数据到Tunnel Server,由它高并发把数据写入到每个Bucket的数据文件中。 写入并发度可通过后面提及的表属性write.bucket.num来配置,因而写入速度可程度扩大。对同一张表或分区的数据,写入数据会按pk值对数据进行切分,雷同pk值会落在同一个bucket桶中。此外,数据分桶的益处还有利于数据优化治理操作例如小文件clustering,compaction等都能够桶的粒度来并发计算,进步执行效率。分桶对于查问优化也十分有益处,可反对bucket裁剪、shuffle move等查问优化操作。 Tunnel SDK提供的数据写入接口目前反对upsert和delete两种数据格式,upsert蕴含insert / update两种隐含语义,如数据行不存在就代表insert,如已存在就代表update。commit接口代表原子提交这段时间写入的数据如返回胜利就代表写入数据查问可见,满足读写快照隔离级别,如返回失败,数据须要从新写入。 SQL批量写入 批量导入次要通过SQL进行操作。为了不便用户操作,实现了操作TT2所有的DDL / DML语法。SQL引擎内核模块包含Compiler、Optimizer、Runtime等都做了大量革新开发以反对相干性能,包含特定语法的解析,特定算子的Planner优化,针对pk列的去重逻辑,以及runtime结构Upsert格局数据写入等。数据计算写入实现之后,会由Meta Service来原子性更新Meta信息,此外,也做了大量革新来反对残缺的事务机制保障读写隔离、事务冲突检测等等。 小数据文件合并 因为TT2自身反对分钟级近实时增量数据导入,高流量场景下可能会导致增量小文件数量收缩,从而引发存储拜访压力大、老本高,并且大量的小文件还会引发meta更新以及剖析执行慢,数据读写IO效率低下等问题,因而须要设计正当的小文件合并服务, 即Clustering服务来主动优化此类场景。 Clustering服务次要由MaxCompute 外部的Storage Service来负责执行,专门解决小文件合并的问题,须要留神的是,它并不会扭转任何数据的历史中间状态,即不会打消数据的Update/Delete中间状态。 联合上图可大略理解Clustering服务的整体操作流程。Clustering策略制订次要依据一些典型的读写业务场景而设计,会周期性的依据数据文件大小,数量等多个维度来综合评估,进行分档次的合并。Level0到Level1次要针对原始写入的Delta小文件(图中蓝色数据文件)合并为中等大小的Delta文件(图中黄色数据文件),当中等大小的Delta文件达到肯定规模后,会进一步触发Level1到Level2的合并,生成更大的Delta文件(图中橙色数据文件)。 对于一些超过肯定大小的数据文件会进行专门的隔离解决,不会触发进一步合并,防止不必要的读写放大问题,如图中Bucket3的T8数据文件。超过肯定时间跨度的文件也不会合并,因为时间跨度太大的数据合并在一起的话,当TimeTravel或者增量查问时,可能会读取大量不属于此次查问工夫范畴的历史数据,造成不必要的读放大问题。 因为数据是依照BucketIndex来切分存储的,因而Clustering服务会以bucket粒度来并发执行,大幅缩短整体运行工夫。 ...

June 27, 2023 · 1 min · jiezi

关于大数据:Hologres-弹性计算在-OLAP-分析上的实践和探索

简介: 1、本文介绍了OLAP剖析在大数据分析中的地位 2、剖析并介绍目前大数据OLAP遇到的剖析性能、资源隔离、高可用、弹性扩缩容等外围问题 3、解析阿里云Hologres是如何解决极致性能、弹性、业务永续、性价比等外围刚需的最佳实际 4、介绍阿里云Hologres弹性计算组在弹性计算、资源隔离上的摸索和翻新 一、 OLAP剖析在大数据分析中的地位目前业界将大数据分析次要分为四个阶段:描述性剖析、诊断性剖析、预测性剖析、规范性剖析。 目前OLAP剖析次要集中在描述性分析阶段,其中诊断性剖析、预测性剖析、规范性剖析属于高阶剖析畛域,后续OLAP剖析也会逐渐浸透于诊断性剖析和预测性剖析中。 二、Hologres如何解决OLAP剖析的外围问题OLAP剖析的外围问题剖析性能差,数据价值可望而不可及。以后大数据在接受度、技术、利用等各方面趋于成熟,大数据逐渐利用于各行各业,这些行业在大数据应用领域面临的第一个问题和挑战就是剖析性能差,进而妨碍了开掘大数据中的微小价值。如何让用户更快的进行OLAP数据分析是广泛面临的一个问题。多种业务场景之间相互影响,隔离老本较高。业务在线上常常会遇到不同业务场景之间的相互影响而带来的查问抖动的问题,比方写写之间、读写之间、大小查问间的相互影响,以及在线服务、多维分析、即席剖析等之间的相互影响。尤其是某些大数据引擎并不是存算拆散架构,个别会通过复制多正本去实现隔离,老本很高。无服务级高可用、 容灾和多活的计划。业务个别通过双/多链路来实现高可用、容灾和多活,这其中波及的人力、计算资源等老本较高。不反对弹性扩容。越来越多的业务对弹性能力有着强烈的诉求。当业务流量忽然增长能及时扩容扛住流量,否则对业务就意味着资损;在业务低峰时能及时缩容,降低成本。那么如何低成本的实现弹性扩缩容是大数据引擎面临的一个广泛问题,尤其是某些引擎不是存算拆散架构,个别是须要通过数据的复制来实现多正本,基本上很难实现及时的弹性扩容能力。 OLAP剖析的外围刚需:高性能、弹性、低成本随着业务的一直倒退,OLAP剖析也逐步进入大多数业务的外围在线场景。用户对其OLAP剖析有如下四大刚需: 业务永续:有高可用、容灾和多活的能力,晋升生产零碎的稳定性极致性能:数据的价值应该被最大水平的开掘,须要有更加极致的性能来满足业务需要弹性:弹性资源可能很好的反对业务的动态变化,满足业务的不同需要低成本:用更少的老本反对更多的业务,实现更高的性价比 Hologres如何解决OLAP剖析的外围问题Hologres是阿里云自研的一站式实时数仓引擎,反对数据的实时写入、实时更新,同时也反对OLAP剖析和在线服务查问,目前已广泛应用于阿里外部泛滥外围业务场景,包含菜鸟物流、淘宝搜寻举荐等,同时在云上也有着泛滥客户实际。那Hologres作为企业级的生产实时数仓,是如何解决OLAP剖析问题呢? HSAP架构使用。在解决OLAP剖析时使用 Hybrid Serving/Analytical Processing(HSAP)设计理念,通过对立的实时存储,数据无需复制就能一站式提供简略查问、OLAP 剖析、在线数据服务等多样化的数据查问和应用服务,满足数据利用方的拜访和接入需要。这种架构大大地升高了业务的复杂度,疾速应答新的业务需要。同时也提供的秒级甚至亚秒级实时性让决策更及时高效,从而让数据发明出更大的商业价值。 弹性能力晋升。Hologres引入弹性计算组模式(Warehouse),每个Warehouse可按时按需创立销毁,重新配置,且可动静热扩缩容。计算和存储高度可扩大,具备双重弹性的能力。云原生资源存储。基于云原生资源存储的弹性扩大,按需应用,能够做到低成本、高可用,高牢靠,同时还具备弹性能力。极致性能。基于现有的C++ Native执行引擎+优化器,领有全异步框架(Thread-per-core 架构)、向量化计算、多种 Index 的实现、精细化的 Cache、基于代价的优化器模型,反对各种 predicted pushdown、runtime filter 等;轻量级用户态线程调度,同时反对多种查问负载(高并发、简单统计)、偏心调度算法(CFS)、高并发充分利用计算资源等次要个性。实现流批对立存储。具备业内当先的行列共存个性,列存对查问剖析敌对,行存对点查疾速;具备高效数据分片、分段、压缩、索引;LSM-like 写敌对数据结构,高吞吐数据写入,反对更新,写入即可见。三、Hologres只读从实例(共享存储)解决隔离问题如上文所述,简直每个用户都会遇到不同业务场景之间的相互影响而带来的查问抖动的问题。不同的引擎因为架构不一样,对于隔离的实现也不一样,那Hologres又是如何解决隔离的问题呢,上面咱们以具体场景为例: 具体场景: 场景一:多种业务场景之间相互影响 。 简直每个用户都会遇到不同业务场景之间相互影响而带来抖动。比方:读写、读读 相互影响;剖析、服务、离线加工 相互影响 场景二:在线业务须要通过多链路能力实现计算多活 。 具体挑战: 挑战一:如何更好的解决系统资源隔离的问题 挑战二:如何让用户更简略低成本的实现计算多活,降本提效 具体措施:通过Hologres只读实例(共享存储)来解决 只读实例具备五大个性:基于物理WAL日志驱动、共享存储、物理文件的齐全复用、主实例 Failover 时从实例不受影响、只读实例 Failover 时可从最新地位开始复原。通过只读实例能够实现: 1. 资源隔离:用户能够实现残缺的读写/读读拆散性能,保障不同业务场景的服务稳定性; 2. 计算多活:用户只需简略配置能够疾速实现同城计算多活,以更少的资源(8~10:1)实现多链路,并节俭用户的人力、计算资源等老本。 四、Hologres新一代弹性计算组实例解决弹性问题越来越多的业务对弹性能力有着强烈的诉求,那么Hologres又是如何解决弹性的问题呢? 具体场景: 场景一:只读实例须要多个Endpoint,用户感知差 。业务须要配置新的Endpoint能力应用新的只读实例。 场景二:用户心愿业务高下峰弹性扩缩容 。用户冀望按需弹性扩缩容,节省成本。 场景三:用户心愿有更灵便更精细化的资源隔离计划 ,能够按业务等场景实现资源隔离。比方:写写隔离,业务隔离。 具体措施:建设新一代实时数仓Hologres弹性计算组实例 为了更好的解决弹性问题,满足业务不同场景下对资源的正当应用,Hologres率先反对弹性计算组实例。弹性计算组实例采纳 Multi-cluster, Shared Data 架构,将计算资源合成为不同的计算组(Warehouse),每个计算组可独立弹性扩大,计算组之间共享数据、元数据。 Hologres弹性计算组实例介绍弹性计算组实例次要分为以下几个组件: 计算组:计算组的弹性能力: 计算组在任意工夫进行按需地创立、销毁或者重新配置, 可动静热扩缩容独自的计算组,实现单个计算组的弹性伸缩能力。 同时Hologres 具备人造的计算存储拆散架构,联合计算组实例能够同时做到计算、存储高度可扩大,具备双重弹性。 计算组的资源隔离能力: 写写隔离:实时写入拆散、离线写入拆散,以及 实时写入 和 离线写入等写入之间的隔离。 ...

June 26, 2023 · 1 min · jiezi

关于大数据:大数据-SQL-数据倾斜与数据膨胀的优化与经验总结

背景目前市面上大数据查问剖析引擎层出不穷,如Spark,Hive,Presto等,因其敌对的SQL语法,被广泛应用于各畛域剖析,公司外部也有优良的ODPS SQL供用户应用。笔者所在团队的我的项目也借用ODPS SQL去检测业务中潜在的平安危险。在给业务方应用与答疑过程中,咱们发现大多含有性能瓶颈的SQL,次要集中在数据歪斜与数据收缩问题中。因而,本文次要基于团队理论开发教训与积攒,并联合业界对大数据SQL的应用与优化,尝试给出绝对系统性的解决方案。本文次要波及业务SQL执行层面的优化,暂不波及参数优化。若设置参数,首先确定执行层面哪个阶段(Map/Reduce/Join)工作执行工夫较长,从而设置对应参数。本文次要分为以下三个局部:第一局部,会引入数据歪斜与数据收缩问题。第二局部,介绍当数据歪斜与数据收缩产生时,如何排查与定位。第三局部,会从零碎层面给出常见优化思路。 问题篇数据歪斜数据歪斜是指在分布式计算时,大量雷同的key被散发到同一个reduce节点中。针对某个key值的数据量比拟多,会导致该节点的工作数据量远大于其余节点的均匀数据量,运行工夫远高于其余节点的均匀运行工夫,连累了整体SQL执行工夫。其次要起因是key值散布不均导致的Reduce解决数据不平均。本文将从Map端优化,Reduce端优化和Join端优化三方面给出相应解决方案。 数据收缩数据收缩是指工作的输入条数/数据量级比输入条数/数据量级大很多,如100M的数据作为工作输出,最初输入1T的数据。这种状况不仅运行效率会升高,局部工作节点在运行key值量级过大时,有可能产生资源有余或失败状况。 排查定位篇本节次要关注于业务SQL自身引起的长时间运行或者失败,对于集群资源状况,平台故障自身暂不思考在内。1.首先查看输出数据量级。与其余天相比有无显著量级变动,是否因为数据量级的问题人造引起工作运行工夫过长,如双11,双十二等大促节点。2.察看执行工作拆分后各个阶段运行工夫。与其余天相比有无显著量级变动;在整个执行工作中工夫耗时占比状况。3.最耗时阶段中,察看各个Task的运行状况。Task列表中,察看是否存在某几个Task实例耗时显著比均匀耗时更长,是否存在某几个Task实例解决输出/输入数据量级比均匀数据量级生产产出更多。4.依据步骤3中定位代码行数,定位问题业务解决逻辑。 优化篇数据歪斜1.Map端优化1.1 读取数据合并 在数据源读取查问时,动静分区数过多可能造成小文件数过多,每个小文件至多都会作为一个块启动一个Map工作来实现。对于文件数量而言,等于 map数量 * 分区数。对于一个Map工作而言,其初始化的工夫可能远远大于逻辑解决工夫,因而通过调整Map参数把小文件合并成大文件进行解决,防止造成很大的资源节约。 1.2 列裁剪 缩小应用select * from table语句,过多抉择无用列会减少数据在集群上传输的IO开销;对于数据抉择,须要加上分区过滤条件进行筛选数据。 1.3 谓词下推 在不影响后果的状况下,尽可能将过滤条件表达式凑近数据源地位,使之提前执行。通过在map端过滤缩小数据输入,升高集群IO传输,从而晋升工作的性能。 1.4 数据重散布 在Map阶段做聚合时,应用随机散布函数distribute by rand(),管制Map端输入后果的散发,即map端如何拆分数据给reduce端(默认hash算法),打乱数据分布,至多不会在Map端产生数据歪斜。 2.Reduce端优化2.1 关联key空值测验 局部实例产生长尾效应,很大水平上因为null值,空值导致,使得Reduce时含有脏值的数据被散发到同一台机器中。针对这种问题SQL,首先确认蕴含有效值的数据源表是否能够在Map阶段间接过滤掉这些异样数据;如果后续SQL逻辑依然须要这些数据,能够通过将空值转变成随机值,既不影响关联也能够防止汇集。 SELECT ta.idFROM taLEFT JOIN tbON coalesce(ta.id , rand()) = tb.id;2.2 排序优化 Order by为全局排序,当表数据量过大时,性能可能会呈现瓶颈;Sort by为部分排序,确保Reduce工作内后果有序,全局排序不保障;Distribute by依照指定字段进行Hash分片,把数据划分到不同的Reducer中;CLUSTER BY:依据指定的字段进行分桶,并在桶内进行排序,能够认为cluster by是distribute by+sort by。对于排序而言,尝试用distribute by+sort by确保reduce中后果有序,最初在全局有序。 -- 原始脚本select *from user_pay_tablewhere dt = '20221015'order by amtlimit 500;-- 改良脚本SELECT *FROM user_pay_tableWHERE dt = '20221015'DISTRIBUTE BY ( CASE WHEN amt < 100 THEN 0 WHEN amt >= 100 AND age <= 2000 THEN 1 ELSE 2 END ) SORT BY amtLIMIT 500;3.Join端优化3.1 大表join小表 ...

June 26, 2023 · 1 min · jiezi

关于大数据:实录分享-Alluxio-Operator一体化部署方案

明天给大家分享的内容是 Alluxio Operator的一体化部署计划。我会将内容分成 4 个局部来给大家解说。 首先,介绍 Kubernetes 容器化部署和以后所面临的挑战。而后,引入operator的概念,介绍以后业界对于Kubernetes 容器化部署问题的支流解决方案。接着,解说如何针对应用服务去实现对应的operator。最初用Alluxio作为理论案例展现operator是如何实现的。 一、Kubernetes 容器化部署所面临的挑战目前 Kubernetes 曾经是业界比拟支流的容器化部署计划,次要因为它对当初的容器化反对十分好,然而同时它也存在一些问题。咱们具体看一下Kubernetes容器化部署的过程,以Presto 为例,部署Presto、将Presto上云,须要做哪些事件? 第一步:梳理组件上云之后须要部署哪些 Kubernetes 资源。咱们把利用打包成容器镜像,传到云仓库外面。 第二步:设计部署组件所须要的 Kubernetes 资源。如上图就展现了Presto在 Kubernetes 上的部署架构。因为Presto 组件蕴含了 coordinator 和 worker 两个不同的角色,所以咱们针对这两个不同角色的配置须要有对应的ConfigMap资源,而且对coordinator和 worker 别离都须要有 Deployment 撑持部署。此外,为了买通 worker 与 coordinator的网络通讯,咱们还须要一个 Service 资源。有了这样一个部署架构图之后,咱们还要去思考到底要按什么样的程序提交资源。比方对Presto 来说,咱们须要提交Service、Deployment,还有 ConfigMap,这些资源都是通过 yaml 文件形容的,它们之间有先后顺序,有肯定的依赖关系。比方在这个例子里,咱们要先提交ConfigMap,再基于 ConfigMap创立Deployment,有了 Deployment 之后,咱们再去部署Service。至此,咱们发现须要有先后顺序做部署组件,这样就带来了一些问题: 首先它带来的第一个问题就是所波及到的Kubernetes 资源可能有多个,保护起来很不不便。尤其是对于很多大数据存储和计算畛域外面的中间件,可能波及到十分多的依赖,甚至包含一些上游上游的撑持组件。 在Kubernetes 上要跑起来,须要多个 yaml 文件。比方以 Presto 为例,它须要的yaml文件有 5 个,咱们如果要去实现Presto上云,就要保护多个yaml文件,这就导致了第二个问题,当咱们须要批改某一个配置的时候,其实咱们不仅要批改某一个 yaml 文件,可能还要批改所波及到的跟它相关联的yaml文件。假如咱们要批改容器的镜像版本,咱们应该只须要批改某一个文件的镜像版本即可,但事实上,因为整个架构外面波及到多个yaml文件、多个 Kubernetes 资源,所以这就导致了至多批改两个文件,批改起来非常复杂。又假如咱们要批改服务的端口,从8080改成8081,会导致保护的复杂度变高,要改多个文件。诸如此类的批改操作,就导致减少了运维复杂度。 第三个问题是一个组件其实是由多个资源独特撑持而实现,然而这些资源的状态又是互相独立的。咱们无奈从更形象更高维度的层级去监控所有资源的信息。比方刚刚提到的这些 Kubernetes 资源,独特组成了一个集群。但咱们无奈主动收集集群的应用状况,因为不同资源之间互相独立,而它们各自的日志只局限于本人自身。假如咱们想依据集群的状况进行主动扩缩容,这个时候须要手动依据集群的状况去做扩缩容。咱们只能晓得某一个资源在某个时刻产生了变更,但无奈晓得集群到底什么时候产生了变更,要获取到这些信息,须要在更形象的层级下能力实现。再比方,咱们无奈在集群的层面做主动备份容灾,如果忽然遇到了一个需要,要下线一批机器,须要对机器上的数据进行迁徙,那么这个时候只能手动做这些事件,通过手动调整Kubernetes的配置来实现。一方面须要很大的人力保护老本,另一方面即便可能通过手动实现,也很难跟踪到集群在何时做了哪些变更,只能看Kubernetes的内置日志,因而,咱们也无奈很好地做到弹性扩缩容。 诸如 Presto 这样的计算引擎,白天可能用的人较多,申请量很大,这时候须要的资源就比拟多,能够适当地给它裁减一些资源,然而到了早晨,或者是一个业务比拟闲置的状况下,其实大部分的资源就能够回收起来,去做一些别的事件。比方留给 spark 或者 Flink 做ETL ,节俭资源缩小耗费,也相当于是在省钱。 ...

June 25, 2023 · 2 min · jiezi

关于大数据:阿里巴巴中国站获得店铺的所有商品-API-返回值说明1688-店铺所有商品接口1688API

1688.item_search_shop - 取得店铺的所有商品 API 返回值阐明1.公共参数: 名称 类型 必须 形容key String 是 调用key(必须以GET形式拼接在URL中,复制Taobaoapi2014)secret String 是 调用密钥api_name String 是 API接口名称(包含在申请地址中)[item_search,item_get,item_search_shop等]cache String 否 [yes,no]默认yes,将调用缓存的数据,速度比拟快result_type String 否 [json,jsonu,xml,serialize,var_export]返回数据格式,默认为json,jsonu输入的内容中文能够间接浏览lang String 否 [cn,en,ru]翻译语言,默认cn简体中文version String 否 API版本2.申请形式:HTTP POST GET3.申请地址:http://o0b.cn/opandy4.申请示例: import java.io.BufferedReader;import java.io.IOException;import java.io.InputStream;import java.io.InputStreamReader;import java.io.Reader;import java.net.URL;import java.nio.charset.Charset;import org.json.JSONException;import org.json.JSONObject;import java.io.PrintWriter;import java.net.URLConnection;public class Example { private static String readAll(Reader rd) throws IOException { StringBuilder sb = new StringBuilder(); int cp; while ((cp = rd.read()) != -1) { sb.append((char) cp); } return sb.toString(); } public static JSONObject postRequestFromUrl(String url, String body) throws IOException, JSONException { URL realUrl = new URL(url); URLConnection conn = realUrl.openConnection(); conn.setDoOutput(true); conn.setDoInput(true); PrintWriter out = new PrintWriter(conn.getOutputStream()); out.print(body); out.flush(); InputStream instream = conn.getInputStream(); try { BufferedReader rd = new BufferedReader(new InputStreamReader(instream, Charset.forName("UTF-8"))); String jsonText = readAll(rd); JSONObject json = new JSONObject(jsonText); return json; } finally { instream.close(); } } public static JSONObject getRequestFromUrl(String url) throws IOException, JSONException { URL realUrl = new URL(url); URLConnection conn = realUrl.openConnection(); InputStream instream = conn.getInputStream(); try { BufferedReader rd = new BufferedReader(new InputStreamReader(instream, Charset.forName("UTF-8"))); String jsonText = readAll(rd); JSONObject json = new JSONObject(jsonText); return json; } finally { instream.close(); } } public static void main(String[] args) throws IOException, JSONException { // 申请示例 url 默认申请参数曾经URL编码解决 String url = "https://api-vxx.Taobaoapi2014.cn/taobao/item_get/?key=<您本人的apiKey>&secret=<您本人的apiSecret>&num_iid=652874751412&is_promotion=1"; JSONObject json = getRequestFromUrl(url); System.out.println(json.toString()); }} ...

June 21, 2023 · 1 min · jiezi

关于大数据:数据仓库12数据治理之数仓数据管理实践心得

这边文章聊聊本人对数据治理开发实际的一些思路,就是聊聊怎么开始去做数据治理这件事件。说起数据治理,有时候尽管看了很多文章,看了很多的介绍,理解数据治理的实践,然而实际上须要咱们去搞的时候,就会踩很多的坑。这里记一下本人做数据治理的一些思路,做做笔记,也分享给须要的同学。 当然,想要做数据治理,想要学习理解,一下数据治理的范畴,实践等,最好能够看看他人怎么做的,理解数据治理能够参考:数据仓库(11)什么是大数据治理,数据治理的范畴是哪些。 那接下来就持续说说数据治理的一些思路心得。 接到数据治理的工作?要怎么做? 梳理目前数据集群,以及业务的总体状况这个,其实没有什么好说,做事件之前,必定是要先理解,咱们要做的货色是怎么样的,评估可能会遇到的问题,这样能力进一步做进去好的数据品质计划。 对数据治理进行分类理解了咱们面对的数据集群之后,就要理解对咱们须要治理的方向,进行分类了,这个对咱们后续的方案设计和组件的选取、革新会有很大的影响,不一样的分类,咱们要解决问题的范畴,是不一样的。 那要怎么分类?首先是大的方向。 主数据管理元数据管理数据规范数据品质治理数据安全治理数据计算治理数据存储管理大的方向确定了,当其实还是太大了,还是须要进一步的进行切割。 像是数据品质治理,能够进一步切分为 1 唯一性校验:不存在无意义的反复数据2 完整性校验:数据残缺且间断3 一致性校验:数据在多数据源中意义统一4 有效性校验:这里次要指数据在剖析的工夫点是无效,而非过期或生效数据5 准确性校验:数据正当、精确,并合乎数据类型的规范 元数据管理,要划分为技术元数据和业务元数据等,具体的划分粒度,应该须要到具体的,可实现的,不容易混同,以及偏于当前数据的治理和应用。毕竟这个货色后续要给开发,给数据bi等人应用的。当然,咱们可能不能已下载就划分好一个最好的分类,咱们应该循环迭代,做出一个更加符合实际进去。 数据管理这个,如果说技术能力,开发人力无限,那其实往往更加简略的形式更好,也便于推广,应该说一个可用的计划好过于一个全面,但用起来不不便的计划。 针对某个类别的数据,进行具体设计,开发,并进一步成标准下面,咱们曾经大略梳理好了咱们数据治理的范畴和分类,进一步的,咱们就须要落地了。这个时候,咱们就要进一步的针对,咱们的划分的问题,提出,咱们的计划,并实现他。 如果,下面说的数据品质治理中的准确性校验,这个时候,咱们就面临了一个问题,怎么样的数据,合乎数据正当、精确,并合乎数据类型的规范这样的数据标准?咱们会怎么去验证这个货色呢?失常状况下,开发人员是怎么去验证这个货色的? 所以,这个时候,咱们就须要形象出这些具体的操作,拼通过适合的计划实现他。 如果,准确性校验,开发人员个别是通过写sql,通过肯定的数据规定判断的,比方数据的稳定,数据值的范畴等。那么咱们做这个的时候,是不是就能够做这样的一个零碎,能够配置sql,或者一些比拟通过的逻辑,定时比对数据,失去咱们的一个后果,实现这样的一个性能?当然这个必定不是最好的计划,然而一个可用的计划好过于一个全面,但用起来不不便的计划。而后不停的迭代优化,欠缺。 当然,这个时候也要放过来思考咱们下面的划分是不是,正当,比方数据品质治理,是不是能够应用同一个思路去做?争取事倍功半。 执行标准做好下面的事件,接下来,就是考验执行了的时候了,任何计划在,最终如果不能很好的执行,那就是事倍功半。 啰里啰唆,写了这一点点心得,逻辑可能不是很通顺,心愿能够给到各个在数据治理挣扎的同学,一点思路,这个也是我的集体笔记,后续有新的想法,再更新。 须要数据仓库材料能够点击这个支付数据仓库(13)大数据数仓经典最值得浏览书籍举荐 参考文章:数据仓库(12)数据治理之数仓数据管理实际心得

June 21, 2023 · 1 min · jiezi

关于大数据:Json-封装关键词搜索1688商品列表数据关键词搜索1688商品接口1688API接口

1688 是中国最大的批发市场之一,是阿里巴巴旗下的一个 B2B 电子商务平台。其商品品类繁多,包含服装、鞋帽、箱包、家居、餐饮、办公用品、手机数码、美妆、食品饮料等。以下是对几种次要商品的具体介绍:服装类、鞋帽类、箱包类、家居类、餐饮类、办公用品类、手机数码类、美妆类、食品饮料类,总之,1688 商品种类繁多,价格和品质不一,消费者可依据本人的需要和估算选购适宜本人的商品。通过 python 封装 API 接口获取整站的商品实时数据,能够用于数据分析,商城建设,店铺搬家,代购业务等业务场景。1688 商品列表 API 接口是 1688 开放平台提供的一项接口服务,容许第三方开发者通过 API 接口获取 1688 平台上商品的详细信息列表。1688 商品列表 API 接口文档蕴含了接口申请地址、申请参数、响应参数和示例等详细信息,开发者在应用该接口服务时须要先认真查阅接口文档,确保本人理解接口的应用办法和限度条件。1688.item_search - 按关键字搜寻商品数据 API 接口返回值阐明1.申请形式:HTTP POST GET2.申请链接:http://o0b.cn/opandy3.申请参数(复制Taobaoapi2014) 申请参数:q=女装&start_price=0&end_price=0&page=1&cat=0&discount_only=&sort=&page_size=40&seller_info=no&nick=&seller_info=&nick=&ppath=&imgid=&filter=参数阐明:q:搜寻关键字cat:分类IDstart_price:开始价格end_price:完结价格sort:排序[bid,_bid,_sale,_credit] (bid:总价,sale:销量,credit信用,加_前缀为从大到小排序)page:页数 page_size:每页宝贝数量,默认40filter:额定的过滤参数,如:filter=filtId:1,2,3,4;activityType:1,2,3,4;city:天津;quantityBegin:1000filtId 过滤:48小时发货,7+天包换,赠运费险,收费赊账;activityType 优惠类型:包邮,产地货源,伙拼,手机专享价city 地区:地区名quantityBegin 起订量:数字4.申请样例 # coding:utf-8"""Compatible for python2.x and python3.xrequirement: pip install requests"""from __future__ import print_functionimport requests# 申请示例 url 默认申请参数曾经做URL编码url = "https://api-vxx.Taobaoapi2014.cn/1688/item_search/?key=<您本人的apiKey>&secret=<您本人的apiSecret>&q=女装&start_price=0&end_price=0&page=1&cat=0&discount_only=&sort=&page_size=40&seller_info=no&nick=&seller_info=&nick=&ppath=&imgid=&filter="headers = { "Accept-Encoding": "gzip", "Connection": "close"}if __name__ == "__main__": r = requests.get(url, headers=headers) json_obj = r.json() print(json_obj)5.响应样例(展现局部) ...

June 20, 2023 · 1 min · jiezi

关于大数据:关键词搜索淘宝天猫商品列表接口实现价格排序销量排序天猫商品列表接口天猫API接口轻松实现商城数据调用和应用

作为目前国内最大的电商平台,淘宝市场提供了相当丰盛的 API 接口,通过 API 调用能够获取到淘宝网站上的海量商品数据、订单数据以及用户数据等信息,从而帮忙企业或集体更加不便地获取和治理商城数据及利用到很多行业例如数据分析代购业务商城业务 ERP 业务店铺监测等利用场景。本文将为您介绍如何轻松利用淘宝 API 接口实现以上利用场景。通过 Python 封装:taobao.item_search - 关键词搜寻商品列表数据接口 申请形式:HTTP POST  GET申请地址:http://o0b.cn/opandy 申请参数: 申请参数:q=女装&start_price=0&end_price=0&page=1&cat=0&discount_only=&sort=&page_size=&seller_info=&nick=&ppath=&imgid=&filter=援用参数阐明:q:搜寻关键字cat:分类IDstart_price:开始价格end_price:完结价格sort:排序[bid,_bid,bid2,_bid2,_sale,_credit] (bid:总价,bid2:商品价格,sale:销量,credit信用,加_前缀为从大到小排序)page:页数4.python申请代码示例 # coding:utf-8"""Compatible for python2.x and python3.xrequirement: pip install requests"""from __future__ import print_functionimport requests# 申请示例 url 默认申请参数曾经做URL编码url = "https://api-vx.Taobaoapi2014.cn/taobao/item_search/?key=<您本人的apiKey>&secret=<您本人的apiSecret>&q=女装&start_price=0&end_price=0&page=1&cat=0&discount_only=&sort=&page_size=&seller_info=&nick=&ppath=&imgid=&filter="headers = { "Accept-Encoding": "gzip", "Connection": "close"}if __name__ == "__main__": r = requests.get(url, headers=headers) json_obj = r.json() print(json_obj)

June 17, 2023 · 1 min · jiezi

关于大数据:数仓架构瘦身Hologres-5000CU时免费试用

Hologres基于翻新的HSAP架构,能够将您原先数仓架构中的OLAP零碎(Greenplum、Presto、Impala、ClickHouse)、KV数据库/Serving零碎(HBase、Redis)对立在一个大数据计算引擎中,并提供疾速的离线实时一体化剖析能力。 Hologres 5000CU时,20GB存储收费试用, 返回试用>>产品外围劣势:1、简化数仓架构,缩小数据搬运与多处保护老本 2、实时查问性能强,刷新TPC-H 30000GB世界纪录 3、交融湖仓查问,0 ETL导入离线MaxCompute数据 Hologres应用教程简介基于MaxCompute中TPC-H数据集数据和GitHub公开事件数据,在阿里云实时数仓Hologres上创立Hologres的数据库、内部表、外部表、导入数据至外部表中以及应用Hologres别离查问外部表和内部表中数据的指引。Hologres在查问数据方面具备极速响应的劣势。 筹备环境和资源开始教程前,请按以下步骤筹备环境和资源: 已创立专有网络(VPC)和专有网络交换机,详情请参见创立专有网络和交换机。拜访阿里云收费试用。单击页面右上方的登录/注册按钮,并依据页面提醒实现账号登录(已有阿里云账号)、账号注册(尚无阿里云账号)或实名认证(依据试用产品要求实现集体实名认证或企业实名认证)。胜利登录后,在产品类别下抉择大数据计算 > 数据计算与剖析,在实时数仓Hologres卡片上,单击立刻试用。在弹出的试用实时数仓Hologres产品的面板上实现参数信息配置。本试用教程以表格中的参数信息为例,未提及参数放弃默认值。参数示例值地区华东1(杭州)实例类型通用型计算资源8核32GB(计算节点数量:1)专有网络抉择步骤1中创立的VPC。专有网络交换机抉择步骤1中创立的交换机。实例名称hologres_test资源组默认资源组勾选服务协定后,单击立刻试用,并依据页面提醒实现试用申请。 单击返回控制台,开启试用体验。创立数据库通过Hologres疾速创立数据库,用于后续寄存示例数据进行查问应用。 登录Hologres治理控制台,单击左侧实例列表。在实例列表页面,单击对应实例名称。在实例详情页左侧导航栏,单击数据库治理。在DB受权页面,单击右上角新增数据库。在新增数据库对话框,配置如下参数。题目阐明实例名抉择在哪个Hologres实例上创立数据库。默认展现以后已登录实例的名称,您也能够在下拉框中抉择其余Hologres实例。数据库名称本示例数据库名称设置为holo_tutorial。简略权限策略您能够为创立的数据库抉择一种权限策略。更多对于权限策略的阐明,请参见:- SPM:简略权限模型,该权限模型受权是以DB为粒度,划分admin(管理员)、developer(开发者)、writer(读写者)以及viewer(分析师)四种角色,您能够通过大量的权限治理函数,即可对DB中的对象进行不便且平安的权限治理。- SLPM:基于Schema级别的简略权限模型,该权限模型以Schema为粒度,划分 <db>.admin(DB管理员)、<db>.<schema>.developer(开发者)、<db>.<schema>.writer(读写者)以及 <db>.<schema>.viewer(分析师),相比于简略权限模型更为细粒度。- 专家:Hologres兼容PostgreSQL,应用与Postgres完全一致的权限零碎。单击确认。创立表数据库创立胜利后,您需在数据库中创立对应的表。 登录数据库。在DB受权页面的顶部菜单栏,单击元数据管理。在元数据管理页面,双击左侧目录树中已创立胜利的数据库名称,单击确认。新建内部表。在SQL编辑器页面,单击左上角的图标。新增应用TPC-H数据集数据的内部表,TPC-H数据援用自TPC,更多信息请参见TPC。 在新增的长期Query查问页面,抉择已创立的实例名和数据库后,请您在SQL查问的编辑框输出示例代码,单击运行。 示例SQL语句用来创立一个映射到MaxCompute公共空间MAXCOMPUTE_PUBLIC_DATA中odps_customer_10g、odps_lineitem_10g等表的内部表,用于后续查问。DROP FOREIGN TABLE IF EXISTS odps_customer_10g;DROP FOREIGN TABLE IF EXISTS odps_lineitem_10g;DROP FOREIGN TABLE IF EXISTS odps_nation_10g;DROP FOREIGN TABLE IF EXISTS odps_orders_10g;DROP FOREIGN TABLE IF EXISTS odps_part_10g;DROP FOREIGN TABLE IF EXISTS odps_partsupp_10g;DROP FOREIGN TABLE IF EXISTS odps_region_10g;DROP FOREIGN TABLE IF EXISTS odps_supplier_10g;IMPORT FOREIGN SCHEMA "MAXCOMPUTE_PUBLIC_DATA#default" LIMIT to( odps_customer_10g, odps_lineitem_10g, odps_nation_10g, odps_orders_10g, odps_part_10g, odps_partsupp_10g, odps_region_10g, odps_supplier_10g) FROM SERVER odps_server INTO public OPTIONS(if_table_exist 'error',if_unsupported_type 'error');新增应用GitHub公开事件数据的内部表,数据援用自GitHub,更多信息请参见基于GitHub公开事件数据集的离线实时一体化实际。 单击左上角的图标,在新增的长期Query查问页面,抉择已创立的实例名和数据库后,请您在SQL查问的编辑框输出示例代码,单击运行。 示例SQL语句用来创立一个映射到MaxCompute公共空间MAXCOMPUTE_PUBLIC_DATA中github_eventsSchema下名为dwd_github_events_odps的内部表,用于后续查问。DROP FOREIGN TABLE IF EXISTS dwd_github_events_odps;IMPORT FOREIGN SCHEMA "MAXCOMPUTE_PUBLIC_DATA#github_events" LIMIT to( dwd_github_events_odps) FROM SERVER odps_server INTO public OPTIONS(if_table_exist 'error',if_unsupported_type 'error');新建外部表。在SQL编辑器页面,单击左上角的图标。新建应用TPC-H数据集数据的外部表。 在新增的长期Query查问页面,抉择已创立的实例名和数据库后,请您在SQL查问的编辑框输出如下语句,单击运行。 示例SQL语句用来创立名称别离为LINEITEM、ORDERS、PARTSUPP、PART、CUSTOMER、SUPPLIER、NATION和REGION的表,用于后续存储数据。DROP TABLE IF EXISTS LINEITEM;BEGIN;CREATE TABLE LINEITEM( L_ORDERKEY BIGINT NOT NULL, L_PARTKEY INT NOT NULL, L_SUPPKEY INT NOT NULL, L_LINENUMBER INT NOT NULL, L_QUANTITY DECIMAL(15,2) NOT NULL, L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL, L_DISCOUNT DECIMAL(15,2) NOT NULL, L_TAX DECIMAL(15,2) NOT NULL, L_RETURNFLAG TEXT NOT NULL, L_LINESTATUS TEXT NOT NULL, L_SHIPDATE TIMESTAMPTZ NOT NULL, L_COMMITDATE TIMESTAMPTZ NOT NULL, L_RECEIPTDATE TIMESTAMPTZ NOT NULL, L_SHIPINSTRUCT TEXT NOT NULL, L_SHIPMODE TEXT NOT NULL, L_COMMENT TEXT NOT NULL, PRIMARY KEY (L_ORDERKEY,L_LINENUMBER));CALL set_table_property('LINEITEM', 'clustering_key', 'L_SHIPDATE,L_ORDERKEY');CALL set_table_property('LINEITEM', 'segment_key', 'L_SHIPDATE');CALL set_table_property('LINEITEM', 'distribution_key', 'L_ORDERKEY');CALL set_table_property('LINEITEM', 'bitmap_columns', 'L_ORDERKEY,L_PARTKEY,L_SUPPKEY,L_LINENUMBER,L_RETURNFLAG,L_LINESTATUS,L_SHIPINSTRUCT,L_SHIPMODE,L_COMMENT');CALL set_table_property('LINEITEM', 'dictionary_encoding_columns', 'L_RETURNFLAG,L_LINESTATUS,L_SHIPINSTRUCT,L_SHIPMODE,L_COMMENT');CALL set_table_property('LINEITEM', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS ORDERS;BEGIN;CREATE TABLE ORDERS( O_ORDERKEY BIGINT NOT NULL PRIMARY KEY, O_CUSTKEY INT NOT NULL, O_ORDERSTATUS TEXT NOT NULL, O_TOTALPRICE DECIMAL(15,2) NOT NULL, O_ORDERDATE timestamptz NOT NULL, O_ORDERPRIORITY TEXT NOT NULL, O_CLERK TEXT NOT NULL, O_SHIPPRIORITY INT NOT NULL, O_COMMENT TEXT NOT NULL);CALL set_table_property('ORDERS', 'segment_key', 'O_ORDERDATE');CALL set_table_property('ORDERS', 'distribution_key', 'O_ORDERKEY');CALL set_table_property('ORDERS', 'bitmap_columns', 'O_ORDERKEY,O_CUSTKEY,O_ORDERSTATUS,O_ORDERPRIORITY,O_CLERK,O_SHIPPRIORITY,O_COMMENT');CALL set_table_property('ORDERS', 'dictionary_encoding_columns', 'O_ORDERSTATUS,O_ORDERPRIORITY,O_CLERK,O_COMMENT');CALL set_table_property('ORDERS', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS PARTSUPP;BEGIN;CREATE TABLE PARTSUPP( PS_PARTKEY INT NOT NULL, PS_SUPPKEY INT NOT NULL, PS_AVAILQTY INT NOT NULL, PS_SUPPLYCOST DECIMAL(15,2) NOT NULL, PS_COMMENT TEXT NOT NULL, PRIMARY KEY(PS_PARTKEY,PS_SUPPKEY));CALL set_table_property('PARTSUPP', 'distribution_key', 'PS_PARTKEY');CALL set_table_property('PARTSUPP', 'colocate_with', 'LINEITEM');CALL set_table_property('PARTSUPP', 'bitmap_columns', 'PS_PARTKEY,PS_SUPPKEY,PS_AVAILQTY,PS_COMMENT');CALL set_table_property('PARTSUPP', 'dictionary_encoding_columns', 'PS_COMMENT');CALL set_table_property('PARTSUPP', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS PART;BEGIN;CREATE TABLE PART( P_PARTKEY INT NOT NULL PRIMARY KEY, P_NAME TEXT NOT NULL, P_MFGR TEXT NOT NULL, P_BRAND TEXT NOT NULL, P_TYPE TEXT NOT NULL, P_SIZE INT NOT NULL, P_CONTAINER TEXT NOT NULL, P_RETAILPRICE DECIMAL(15,2) NOT NULL, P_COMMENT TEXT NOT NULL);CALL set_table_property('PART', 'distribution_key', 'P_PARTKEY');CALL set_table_property('PART', 'bitmap_columns', 'P_PARTKEY,P_SIZE,P_NAME,P_MFGR,P_BRAND,P_TYPE,P_CONTAINER,P_COMMENT');CALL set_table_property('PART', 'dictionary_encoding_columns', 'P_NAME,P_MFGR,P_BRAND,P_TYPE,P_CONTAINER,P_COMMENT');CALL set_table_property('PART', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS CUSTOMER;BEGIN;CREATE TABLE CUSTOMER( C_CUSTKEY INT NOT NULL PRIMARY KEY, C_NAME TEXT NOT NULL, C_ADDRESS TEXT NOT NULL, C_NATIONKEY INT NOT NULL, C_PHONE TEXT NOT NULL, C_ACCTBAL DECIMAL(15,2) NOT NULL, C_MKTSEGMENT TEXT NOT NULL, C_COMMENT TEXT NOT NULL);CALL set_table_property('CUSTOMER', 'distribution_key', 'C_CUSTKEY');CALL set_table_property('CUSTOMER', 'bitmap_columns', 'C_CUSTKEY,C_NATIONKEY,C_NAME,C_ADDRESS,C_PHONE,C_MKTSEGMENT,C_COMMENT');CALL set_table_property('CUSTOMER', 'dictionary_encoding_columns', 'C_NAME,C_ADDRESS,C_PHONE,C_MKTSEGMENT,C_COMMENT');CALL set_table_property('CUSTOMER', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS SUPPLIER;BEGIN;CREATE TABLE SUPPLIER( S_SUPPKEY INT NOT NULL PRIMARY KEY, S_NAME TEXT NOT NULL, S_ADDRESS TEXT NOT NULL, S_NATIONKEY INT NOT NULL, S_PHONE TEXT NOT NULL, S_ACCTBAL DECIMAL(15,2) NOT NULL, S_COMMENT TEXT NOT NULL);CALL set_table_property('SUPPLIER', 'distribution_key', 'S_SUPPKEY');CALL set_table_property('SUPPLIER', 'bitmap_columns', 'S_SUPPKEY,S_NAME,S_ADDRESS,S_NATIONKEY,S_PHONE,S_COMMENT');CALL set_table_property('SUPPLIER', 'dictionary_encoding_columns', 'S_NAME,S_ADDRESS,S_PHONE,S_COMMENT');CALL set_table_property('SUPPLIER', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS NATION;BEGIN;CREATE TABLE NATION( N_NATIONKEY INT NOT NULL PRIMARY KEY, N_NAME text NOT NULL, N_REGIONKEY INT NOT NULL, N_COMMENT text NOT NULL);CALL set_table_property('NATION', 'distribution_key', 'N_NATIONKEY');CALL set_table_property('NATION', 'bitmap_columns', 'N_NATIONKEY,N_NAME,N_REGIONKEY,N_COMMENT');CALL set_table_property('NATION', 'dictionary_encoding_columns', 'N_NAME,N_COMMENT');CALL set_table_property('NATION', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS REGION;BEGIN;CREATE TABLE REGION( R_REGIONKEY INT NOT NULL PRIMARY KEY, R_NAME TEXT NOT NULL, R_COMMENT TEXT);CALL set_table_property('REGION', 'distribution_key', 'R_REGIONKEY');CALL set_table_property('REGION', 'bitmap_columns', 'R_REGIONKEY,R_NAME,R_COMMENT');CALL set_table_property('REGION', 'dictionary_encoding_columns', 'R_NAME,R_COMMENT');CALL set_table_property('REGION', 'time_to_live_in_seconds', '31536000');COMMIT;新增应用GitHub公开事件数据的外部表。 单击左上角的图标,在新增的长期Query查问页面,抉择已创立的实例名和数据库后,请您在SQL查问的编辑框输出示例代码,单击运行。 示例SQL语句用来创立名称为gh_event_data的外部表,并设置distribution_key、event_time_column、clustering_key的表属性,用于后续数据导入和高性能查问。DROP TABLE IF EXISTS gh_event_data;BEGIN;CREATE TABLE gh_event_data ( id bigint, actor_id bigint, actor_login text, repo_id bigint, repo_name text, org_id bigint, org_login text, type text, created_at timestamp with time zone NOT NULL, action text, iss_or_pr_id bigint, number bigint, comment_id bigint, commit_id text, member_id bigint, rev_or_push_or_rel_id bigint, ref text, ref_type text, state text, author_association text, language text, merged boolean, merged_at timestamp with time zone, additions bigint, deletions bigint, changed_files bigint, push_size bigint, push_distinct_size bigint, hr text, month text, year text, ds text);CALL set_table_property('public.gh_event_data', 'distribution_key', 'id');CALL set_table_property('public.gh_event_data', 'event_time_column', 'created_at');CALL set_table_property('public.gh_event_data', 'clustering_key', 'created_at');COMMIT;导入示例数据外部表创立胜利后,能够通过以下步骤将数据导入Hologres外部表中。内部表在Hologres中不存储数据,只进行字段映射。通过内部表您能够应用Hologres间接调用存储于MaxCompute公共空间MAXCOMPUTE_PUBLIC_DATA的数据。 ...

June 15, 2023 · 5 min · jiezi

关于大数据:海纳千川得物多场景统一推荐平台

1 千川由来得物的举荐场景,除了首页瀑布流等几个比拟大的场景之外,还有很多长尾的小场景,包含:频道、会场、购中购后场景、品牌墙等。这类场景存在单个场景体量小(UV和GMV均偏小)、场景零散、类型多元的状况。如需对这类场景进行独自优化,波及的老本投入远高于产出。而随着业务倒退,这类长尾场景只会越来越多,对这类场景的优化亟待解决。因而,咱们须要这样一个通用举荐平台,来承接住这些小场景,并可能继续优化,带来收益。“化零为整”、“兼容并包”、“对立平台”,这就是千川。 2 千川须要解决的难题联合各类需要及定位,千川作为对立举荐零碎,面临不少难题,至多需具备五种能力。 3 工程和算法解决方案应答上述艰难,千川提出对立举荐框架。在千川ID体系根底上,实现多场景举荐的对立优化。 千川举荐框架总体分五层 APP服务层:对接各个长尾场景,目前接入了包含主题、频道、会场、购中购后独立流、出图等场景千川接入层:目前提供两种接入形式,一种是通过商品投放服务接入,一种是注册千川直连。千川根据接入场景的差别建设千川ID体系,会为每个接入的场景提供特定的千川ID(或者千川ID汇合)。千川DPP层:提供多种DPP举荐模块,满足多类型举荐需要,包含商品举荐DPP,多类型举荐DPP,楼层举荐DPP,品牌举荐DPP。每个DPP模块框架基本一致,会依据举荐类型设计差异化举荐策略。算法层:搭建残缺举荐链路,在召回、粗排、精排、策略等全流程上进行效率和体验优化。 召回阶段:设计包含I2I、U2I等在内5类召回,尽可能解决场景、行为、趣味偏差,召回用户爱好商品。粗排阶段:在满足高性能要求上,提供单指标及多指标粗排能力,为后续精排晋升空间。精排阶段:针对场景差别、用户趣味、多种指标、大促利用方面进行一系列模型迭代。策略阶段:联合业务需要提供策略干涉、场景差异化配置、流控调权、多样性重排、多类型散发等能力。基建层:依靠包含机器学习平台、索引平台、特色服务、流控平台等在内的弱小能力反对,方可打造出整套千川举荐框架。4 算法迭代过程4.1 召回粗排练进因千川多业务场景的特色,召回和粗排阶段面临一系列挑战,包含:场景行为偏好差别、多场景下用户趣味偏差、场景指标定位差别。 挑战1:场景行为偏好差别千川用户行为较为扩散,不同场景下行为稠密且差别较大。为解决这类偏差,千川会集全场景下用户的长短期行为,设计I2I、重定向、Trigger选取、向量化等一系列策略。 I2I、重定向捕捉行为偏好不同的Trigger选取策略兼顾长短期行为GraphEmb、RankI2I实现行为偏好的向量化挑战2:多场景下用户趣味偏差不同场景下用户的趣味不完全一致,具体表现如:男性用户A在主题落地页更多关注鞋、静止、3C等之类的商品,在送礼频道更关注化妆品相干商品;女性用户B在主题落地页更偏向于包袋、玩偶等,在送礼频道更关注篮球、休闲服之类的商品。用户在不同场景之间的趣味体现既有共性又存在差别,千川通过实现全场景的DSSM向量表征与联合场景特色的MIND向量表征多场景下用户的趣味偏差。 DSSM引入全场景数据表征用户对商品的根底趣味MIND联合场景特色扩大用户在多场景多趣味上的表征挑战3:场景指标定位差别因场景定位不同,对应的指标也不统一。整体可演绎为dpv导向场景和uv价值导向场景。dpv导向场景对应的是对点击的预估,uv价值导向场景须要同时预估点击和转化。千川针对两类场景指标,设计了粗排双塔和粗排ESMM模型实现分指标差异化预估,打消场景指标定位差别。 粗排双塔模型实现点击预估粗排ESMM实现点击与转化的多指标预估4.2 排序模型迭代挑战1: 用户趣味建模用户趣味建模始终是举荐零碎中重要的优化点之一,用户的历史行为则是用户潜在趣味最间接的表白。 之前的工作次要针对用户实时和中短期行为进行建模,仅应用近期行为无奈建模用户长期以来稳固的趣味和周期性的行为,同时也会将举荐零碎的数据反馈循环限度在部分的热门的内容中。 另一方面则是特色穿插的有余,模型从deepFM单指标范式迁徙到基于dmt范式下的多指标模型,去掉了fm侧构造,尽管能够充沛开掘用户行为序列特色,然而对稠密特色在模型上的穿插还较少,有肯定的优化空间。 挑战2: 场景差别建模因为不同的场景往往具备本身独特的定位,服务的用户、蕴含的商品都有较大的差别。而小场景自身的用户散布和行为偏好也随流动和经营策略等变动产生较大的稳定。 新人落地页、新人频道等场景,新用户占比拟高,点击率偏高而转化率显著偏低;补贴频道次要以性价比高商品为主,点击、转化的动向都不错,然而aov较整体有显著的降落;女性频道的受众根本是女性,这个场景的商品集较支流场景有着显著差别,女性用户在爱好上也有显著偏差,数据上看这个场景的女装、箱包占比有显著晋升;而会场等场景,日常和大促用户散布和商品池变化很大,用户行为也有相应的变动,在预热期珍藏志愿继续晋升,直到大促当天集中实现转化。而对于购后、领取后等场景,因为用户需要曾经局部满足,浏览深度就相应偏低。 迭代1: 用户趣味建模为了充沛建模用户的趣味的差别,咱们在构建场景下用户、商品各种显式穿插统计特色的根底上,进一步通过优化对用户行为序列的充沛建模和隐式的特色穿插形式,晋升咱们对用户偏好刻画的准确性。 首先咱们减少了transformer的构造来解决用户的长短期用户行为序列,并对行为序列做了合并和去重解决来增大信息容量。咱们减少了显式的对用户统计特色、稠密特色的穿插,晋升模型成果。减少千川id、商品、用户属性对用户行为的穿插特色,并利用co-action构造做隐式穿插。 a. 用户行为序列作为Feed Feature, 复用attention之前的sequence embedding b. cspu、qcid、gender、brand等作为Induction Feature,构建3层mlp c. 做3次阶乘,减少高阶的特色穿插 迭代2: 多场景差别建模为了充沛建模不同场景的差别,咱们在构建场景下商品、品牌、类目标穿插统计特色根底上,进一步通过模型构造的优化,充沛学习用户在不同场景的偏好差别。 通过构建特色刻画场景偏好以及场景效率的差别 通过构建特色刻画用户活跃度、用户生命周期标签等特色 a. 用户标签-生命周期 b. 用户-不同场景-活跃度 【exp|clk|buy|clickbuy && cspu|brand|cate】 c. 用户-全场景-活跃度【exp|clk|buy|clickbuy && cspu|brand|cate】 通过mmoe构造,使得模型进一步学习到场景的差别。 a. 只管丰盛了特色,然而不同场景的样本混合,只用一个模型会使得不同场景相互烦扰笼罩,难以达到最优的成果,所以进一步对模型构造做了调整,复用了mmoe的构造。 b. 为了凸显场景的差异性,须要对原始的MMoE的 Gate 网络的输出做调整,为此只抉择千川id的自身信息作为特色,利用场景id的信息对experts进行抉择,使得不同场景通过softmax输入不同的Gate 权重。 c. 针对不同的场景,模型可能感知场景的差别,不同场景可能抉择不同的experts子网络的组合,从而实现不同场景的差异化建模。 ...

June 14, 2023 · 1 min · jiezi

关于大数据:MaxCompute中如何处理异常字符

背景在解决数据时,当业务数据同步至MaxCompute后,会产生一些含异样字符的脏数据,比方字段中蕴含了一个不可见字符,在DataWorks中显示不进去,但在BI界面又会显示成其余字符,影响整体观感。这种状况,通常咱们的解法是,将异样的字符洗掉,上面来介绍几种常见的解决异样字符的办法。 问题形容定位如下图,能够看到“异样name”和“失常name”的 length值 不同,多了个不可见字符,然而咱们并不能看进去啥。前期做数据处理或数据展现可能成为一个难以定位的问题。 SELECT name as 异样name, LENGTH(name) as 异样name长度, '北京' as 失常name, LENGTH('北京') as 失常name长度from tbl1 where name RLIKE '北京';后果: 小技巧咱们能够通过在线Unicode编码转换工具,将数值粘贴过来,获取到对应的Unicode码。同理也能够获取其余异样字符的Unicode码,以便后续解决。输出异样 vs 失常的字符串,比照 Unicode 差别能够倒推不可见字符为“ \u200b” 。      解决方案定位到问题后,回顾数据荡涤的惯例计划,想方法把消掉这种不可见字符计划形容备注本case是否实用trim()函数惯例的首尾不可见字符解决实用首尾部的空格、tab、换行Yesreplace()函数定向剔除字符串实用于单个待替换的字符,多个须要层层嵌套Yes正则替换函数定向剔除一类字符串通过正则匹配符,替换一类字符串Yes计划1:trim() - 替换MaxCompute的trim()函数反对通过设置参数的形式调特色字符TRIM相干文档:https://help.aliyun.com/document_detail/455667.html成果如下: 利用 trim() 函数将数值中的异样不可见字符替换为失常空值字符(不可见字符可通过在线Unicode编码转换工具Unicode转中文复制一下)SELECT name as 异样name, LENGTH(name) as 异样name长度, trim(name,'') as 失常name, LENGTH(trim(name,'')) as 失常name长度from tbl1 where name RLIKE '北京';后果: 计划2:replace() - 替换长处:点对点思路解决问题,方便快捷毛病:实用待替换的字符只有一个状况,如果有多个,须要再套一层replace函数,不容易保护REPLACE相干文档:https://help.aliyun.com/document_detail/455611.html成果如下: 利用 replace() 函数将数值中的异样不可见字符替换为失常空值字符(不可见字符可通过在线Unicode编码转换工具Unicode转中文复制一下)SELECT name as 异样name, LENGTH(name) as 异样name长度, replace(name,'','') as 失常name, LENGTH(replace(name,'','')) as 失常name长度from tbl1 where name RLIKE '北京';后果: ...

June 14, 2023 · 1 min · jiezi

关于大数据:火山引擎-DataLeap一个易用高效的数据目录是如何搭建的

企业如何找到数据、理解数据以及应用数据? 这离不开数据目录的能力。数据目录有着相似于“字典”的作用,可能帮忙数据生产者和使用者疾速定位数据、解释数据、找到数据,并从中提取业务价值。 对以研发人员为代表的数据生产者来说,他们利用数据目录来组织、梳理各类元数据。例如,数据生产者会将元数据以目录等模式编排到一起,不便保护,并通过打业务标签、增加利用场景形容、字段解释等丰盛业务相干属性。 对以数据分析师、产品、经营等数据使用者来说,他们通过数据目录来查找和了解数据,例如通过关键字检索,或目录浏览,来查找业务场景数据,并浏览详情介绍、字段形容、产出关系等,进一步了解并利用数据决策。 在字节跳动,也有这么一套被外部宽泛应用的数据目录零碎。目前,该零碎已通过火山引擎DataLeap数据地图平台对外输入。内部用户也能够在DataLeap数据地图平台,收集、组织、拜访和补充元数据信息,为本身数据建设和治理提供反对。 火山引擎DataLeap数据地图平台-数据目录要构建一套扩展性强、易保护且易用的数据目录零碎并非易事。在大数据畛域,各类计算和存储系统百花齐放,概念和原理又千差万别,对于元数据的采集、组织、了解、信赖等,都带来了很大挑战。 在调研各个开源软件及技术体系根底上,火山引擎DataLeap抉择基于Apache Atlas革新,而这套数据目录零碎次要依赖五大关键技术: 第一,数据模型对立。一方面,DataLeap通过充沛复用各种元数据类型间的类似能力,取得数据模型定制灵活性;另一方面,DataLeap将数据源关联的能力进行收敛到一起,以升高后续的保护老本。 第二,数据接入标准化。当用户接入新的元数据时,只须要从新编写Source和Diff Operator,而其余组件可间接复用,以标准化的connector节俭接入和运维老本。 第三,搜寻优化。在数据目录中,搜寻是用户最宽泛应用的性能,也是用户找数次要的伎俩。搜寻优化可分为离线局部和在线局部。离线局部负责会集各类与搜寻相干的数据,实现数据荡涤或者模型训练,再依据不同的用处,写入不同的存储,供应在线搜寻模块应用。在线局部则分为搜寻了解、召回、精排三个次要阶段,步骤和概念与通用搜索引擎对齐。 第四,血统能力。齐备的血统能力,既能够帮忙数据生产者梳理、组织元数据,也能够帮忙数据消费者找数、了解数据上下文。火山引擎DataLeap在设计上充分考虑血统链路的多样性和复杂性,并在血统品质上,通过定义无效的血统准确率、覆盖率和时效性,确保血统信息精确、全面和实时性。 第五,存储层优化。当业务中有越来越多的元数据接入数据目录,图存储中的点和边将别离达到百万和千万量级,造成读写性能呈现问题。在读优化和写优化层面,火山引擎DataLeap别离通过开启MutilPreFetch 能力、去除Guid全局唯一性查看,最终实现小表性能小于100ms、中表性能2~5s、大表性能0.5~1min。 据介绍,火山引擎DataLeap能帮忙企业疾速实现数据集成、开发、运维、治理、资产、平安等全套数据中台建设,其中数据目录能力次要涵盖在数据地图平台,该平台通过提供数据检索、元数据详情查看、数据了解等性能,解决找数难、了解数据难的痛点,同时反对数据专题、血统图谱、数据发现、库表治理等特色性能。目前,火山引擎DataLeap的数据地图平台已接入全链路外围元数据,包含LAS、MySQL、ByteHouse CE、ByteHouse CDW、TOS、LasFS、EMR hive等,提供可视化的血缘关系展现能力,帮忙用户全面的探查理解数据,反对表、字段级别血统可视化查问,以及按层级、范畴筛选展现,可依据用户需要灵便适配。 立刻跳转火山引擎DataLeap理解详情

June 14, 2023 · 1 min · jiezi

关于大数据:火山引擎-DataLeap从短视频-APP-实践来看如何统一数据指标口径

短视频正在成为越来越多人发现世界的窗口,其背地的创作者生态建设是各大短视频 APP 不可漠视的重要组成部分。 为了激励更多优质内容生产,某短视频 APP 常常面向创作者主办投稿流动,而在复盘投稿数据过程中,该团队音乐经营人员在查找「音乐投稿率」指标时,同时搜寻到了「音乐投稿率(音乐元素投稿比例)」,两个指标名称类似,但细究之下含意却天壤之别。 不仅仅是「音乐投稿率」这一个指标,该短视频 APP 外部每天都会产生很多相似问题。 因为该短视频 APP 旗下业务线比拟多,包含工具、社交、极速版、特效、剪映、策略等,每个流动协同的业务方多、人员简单,而各业务指标都由本人独自定义,并独立交由不同研发人员开发,由此导致指标扩散、口径不统一。 即便曾经实现研发、经营、策略等各个团队对齐,也可能存在某团队因业务需要调整口径,又未周知其余团队,导致指标再次对不上,影响工作效率,甚至呈现数据误差。 为了解决数据指标中存在的种种难题,数据团队基于火山引擎 DataLeap,把建设对立的数据指标治理平台纳入团队重点工作。据理解,火山引擎 DataLeap 可能解决“灵便数据分析”场景下的找数据、找口径的问题,帮忙客户建设可共享、可视化、服务化的业务指标体系。 在机制层面,数据团队自上而下发动数据指标看板建设需要,从各业务指标诉求中形象出对立的标准,并建设投稿数据应用标准。当收到一个新指标开发需要时,先明确指标负责人,其余方向同学则对齐该指标。举个例子,主端投稿“投稿数”业务指标建设,影像、图文投稿则要对齐该“投稿数”指标的口径。 在工具层面,数据团队通过 DataLeap 建设了对立的指标治理平台,辅助以上机制落地。首先,数据团队建设了一个跨业务团队的公共层数据,各业务方的数据均依赖公共层数据表进行加工。其次,基于火山引擎 DataLeap 的“指标平台”能力,将投稿外围指标分类管理,保障指标口径进口一致性。DataLeap 指标可视化能力,间接屏蔽了底层物理表,帮忙经营等非研发人员,更清晰获取数据指标信息、操作指标变更、实现指标进一步剖析。 通过以上办法,该短视频 APP 外部对于数据指标口径的答疑会和讨论会大大减少,一方面进步团队工作效率、指标应用效率,另一方面,也很大水平躲避由指标口径不对立导致的上游数据问题。 随着越来越多公司数据规模的扩充,垂直业务单元会越来越多,而在跨垂直单元数据建设过程中,各种数据不对立、指标集中梳理难、指标对立定义难、指标追溯难等问题更加突出。火山引擎 DataLeap 将提供从指标定义、经营、发现、洞察、品质到生产与反馈的全流程,晋升指标应用效率、升高指标反复开发成本和数据答疑老本,为更多有数据指标建设的企业、行业提供服务。

June 8, 2023 · 1 min · jiezi

关于大数据:揭秘阿里云Flink智能诊断利器Fllink-Job-Advisor

引言阿里云实时计算Flink作为一款业余级别的高性能实时大数据处理系统,它在各种业务场景中都施展了要害的作用。丰盛而简单的上下游零碎让它可能撑持实时数仓、实时风控、实时机器学习等多样化的利用场景。然而,随着零碎的复杂性减少,用户在日常应用中往往须要面临诸如简单的数据开发报错剖析、工作运行报错解决、工作运行调优等疑难问题。 然而,因为谬误日志剖析透出和全链路异样诊断能力方面存在肯定的有余。这些问题通常较难通过自助机器人进行拦挡和排查。由此,用户不得不通过提交工单等形式寻求反对,这种状况又会导致人工服务单量大幅上涨,给运维团队带来了不小的压力。 为了解决这些问题,咱们设计了一款数智运维工具:Flink智能诊断(Advisor)。这个工具的指标是解决用户在应用Flink全托管产品全生命周期中可能遇到的各种难题。Flink智能诊断通过精准的错误诊断和优化倡议,可能晋升用户应用Flink的体验,升高了对人工服务的依赖。 问题合成通过对大量的Flink用户案例剖析,咱们将常见的Flink的问题分成谬误日志剖析、异样剖析(影响作业以后运行) 、危险剖析(不影响以后运行) 三个大类,并为其制订了明确的剖析我的项目。 谬误日志剖析剖析内容为以后作业抛出的日志栈,剖析蕴含两个阶段: 开发阶段: 开发状态的异样日志栈剖析,如常见的语法错误、表模式配置谬误等。运行阶段: 作业运行过程中产生的异样日志栈剖析,如上游binlog过期、Time字段存在Null脏数据等。异样剖析次要剖析内容为影响作业以后运行的问题,剖析蕴含三个阶段: 启动阶段: 启动文件剖析、依赖的云资源剖析、数据源权限探测、网络分析、Session集群剖析等。运行阶 段: Checkpoint查看、权限查看、状态查看等。进行阶段: 进行速度剖析。危险剖析次要剖析内容为不影响作业运行的问题,剖析蕴含两个阶段: 配置阶段:JobGraph查看、版本查看、HA查看等运行阶段:Checkpoint查看、作业运行环境查看等。核心技术工程架构 Flink智能诊断的技术架构分为数据层、服务层和业务层: 数据层向服务层提供诊断所需的实时数仓能力,它将根底集群(Kubernetes)、产品引擎(VVP&Flink)的根底数据,通过大数据&AI计算引擎进行ETL、聚类、剖析,最终将数据存储到数智平台的实时数仓中。这些数据蕴含用户Flink作业全生命周期的残缺可观测数据,为剖析用户全托管Flink产品提供底层数据反对。 服务层服务层提供了两种能力,别离为谬误日志剖析服务,用于剖析用户开发、运维过程产生的实时日志信息;以及作业诊断服务,提供更多纬度的数据分析能力,蕴含数据层提供的Flink全生命周期数据。两种能力通过接口层提供谬误日志诊断、作业衰弱分、作业深度诊断服务,为业务层提供多样的作业探查能力提供底层反对。 谬误日志剖析服务:借助数智平台提供的日志聚类&举荐算法,建设服务于Flink业务场景的谬误日志知识库,积淀了 用户报错信息输出 - 谬误日志库聚类日志 - 产研/SRE剖析 - 日志打标 - 回馈用户解决方案 这样一套欠缺的谬误日志分析方法。相比于传统工单形式,谬误日志诊断服务买通用户问题直接触达产研的渠道,真正帮忙用户解决面临的高优报错问题,进步了用户问题解决的效率。谬误日志诊断服务通过引入日志聚类能力,解决传统日志剖析场景通过正则匹配形式面临的信息拟合准确度问题以及海量信息去重的难题。其余对于日志聚类细节会在技术创新局部详解。作业诊断服务:调度引擎是智能诊断的大脑,通过读取数据层Flink残缺生命周期的数据,会定期轮训执行决策树,并产出诊断后果。决策树中积淀了Flink产研/SRE数载打磨Flink产品积淀下来的专家教训,蕴含作业报错、作业性能、作业配置、底层运行环境危险等。将这些作业面临的危险通过数条诊断项模式透出给接口层,帮忙用户实现全托管、免运维的产品体验。业务层通过调用接口层封装了不同模式的Flink诊断数据,实现了多入口的数据查问能力,包含VVP(阿里云实时计算Flink用户作业控制台)、钉钉答疑机器人和ABM诊断等。不同应用方通过以上入口获取到Flink作业的异样信息以及解决方案,最终帮忙终端解决作业异样,助力Flink实时计算产品稳固晦涩运行。Flink智能诊断中日志聚类&举荐局部算法侧整体链路如图所示,整体分为两个阶段: 常识积淀:面向大量日志,通过算法提取要害信息并积淀在知识库中。日志诊断:通过报错日志内容,从知识库中匹配相应的起因和解决方案。次要提供两大外围能力: 诊断能力:实时为谬误日志匹配相应的起因和解决方案,提供日志诊断能力。自动化剖析能力:定时对未命中谬误日志进行剖析,晋升专家教训集成效率。技术创新诊断能力日志实时诊断面临的最大问题是日志数量宏大且信息碎片化重大,无奈无效提取要害信息。为了解决这个问题,Advisor建设了面向Flink谬误日志的日志知识库,通过算法提取日志中的信息,并联合专家教训进行聚合,积淀要害信息。日志聚类算法次要流程如下: 冗余信息荡涤[日志预处理和编码]:去除非结构化信息,缩小信息烦扰。日志特色构建[分词&特征选择]:提取日志特色,将日志转化为结构化表征。档次聚类:基于日志特色间的类似度,对日志进行聚合。联合标注:联合专家教训对类别进行调整和细化,晋升后果准确性。当日志诊断算法服务被触发时,算法的匹配逻辑如下: 规定:优先依据Flink产研/SREs事后定义的规定匹配相应的起因及解决方案。算法:计算日志内容与知识库中类别的类似度对日志进行归类,给出对应的起因和解决方案。无关日志诊断相干的原理能够参考基于 Flink ML 搭建的智能运维算法服务及利用,如需更进一步体验日志聚类,能够参考SREWorks开源的日志聚类算法SREWorks v1.5 版本公布 | 基于实时作业平台的日志聚类开源。 自动化剖析能力为了可能升高专家教训集成和产品化的门槛,晋升产研共建的效率,Advisor构建了日志自动化剖析能力。 定时收集产品未命中的谬误日志信息联合知识库中积淀的后果以及专家教训对未命中的谬误日志进行聚类,将海量日志聚合成数量无限的日志类依据类别调用频率进行排序日志自动化剖析能力带来的外围劣势如下: 实时性:可能帮忙产研和SRE实时感知日志匹配状况。高效性:明确给出了产品以后无奈解决的日志类别,给产品功能完善提供了明确的方向。同时算法还能剖析已有规定的有余,实现查漏补缺。低门槛:算法对海量日志进行了去重并给出了关键词,升高了产研的标注老本和门槛。性能实战开发态谬误日志剖析在Flink全托管开发控制台作业开发页面,您能够应用开发态谬误日志剖析: 登录实时计算控制台。在 Flink全托管 页签,单击指标工作空间 操作 列下的 控制台 。在左侧导航栏上,抉择 利用 > 作业开发。编写SQL后,点击验证,可查看谬误日志的剖析。实时计算控制台: https://realtime-compute.console.aliyun.com/console/cell 查看衰弱分在Flink全托管开发控制台作业运维页面,您能够查看作业的衰弱分 登录实时计算控制台。在 Flink全托管 页签,单击指标工作空间 操作 列下的 控制台 。在左侧导航栏上,抉择 利用 > 作业运维 。您能够查看以下信息。实时计算控制台: https://realtime-compute.console.aliyun.com/console/cell 查看运行态日志剖析在Flink全托管开发控制台作业运维页面,您能够应用开发态谬误日志剖析 登录实时计算控制台。在 Flink全托管 页签,单击指标工作空间 操作 列下的 控制台 。在左侧导航栏上,抉择 利用 > 作业运维 。单击指标作业名称。在作业详情页面,单机 作业探查。在右边可切换运行日志、启动日志、异样信息可查看运行态日志剖析。实时计算控制台: https://realtime-compute.console.aliyun.com/console/cell 对作业进行诊断在Flink全托管开发控制台作业运维页面,您能够通过诊断性能,查看作业具体的危险起因及平台所给的倡议。 登录实时计算控制台。在 Flink全托管 页签,单击指标工作空间 操作 列下的 控制台 。在左侧导航栏上,抉择 利用 > 作业运维 。单击指标作业名称。在作业详情页面右上角,单击 诊断 。 在页面左侧,查看诊断后果和优化倡议。 总结Flink智能诊断的外围能力次要体现在:1、 产品体验:产品控制台开发引入了秒级实时报错诊断性能,笼罩了作业从开发态到运维态的全流程,不便用户自助解决问题,升高工单量。2、技术创新:采纳了日志聚类和举荐算法来代替传统的正则表达式,不仅解决了海量日志“去重”难题,同时也大幅升高了专家业务教训的集成门槛。3、根因倡议:笼罩异样场景,提供100%精确匹配异样起因诊断以及解决方案,麻利公布热更新即刻失效。4、产研共建:智能诊断是SRE、研发、服务团队、产品多团队联结共建的后果,属于全链路专家教训产品化的产物,已造成常态化运作及保护机制,保障继续迭代优化。Flink智能诊断上线至今,在用户PV、问题覆盖率等几个方面都获得了较好的阶段性后果: 每个Flink用户均匀每天应用诊断3.5次。作业运维类征询工单(报错日志&运行异样)降落了28%。

June 8, 2023 · 1 min · jiezi

关于大数据:一份配置轻松搞定表单渲染配置式表单渲染器在袋鼠云的实现思路与实践

前段时间,袋鼠云离线开发产品接到革新数据同步表单的需要。 一方面,数据同步模块的代码可读性和可维护性较差,导致在数据同步模块开发新性能和定位问题的效率很低。另一方面,整体规划上,心愿在对接新的数据源时,能够不再关怀表单渲染相干问题,从数据源核心新建数据源始终到数据源在数据同步模块的利用,全链路的表单都能够通过配置化的形式解决。 本文就将以此为例,抛砖引玉,为大家具体介绍配置式表单渲染器实现的实际之路。 数据同步表单背景数据同步模块整体上分为四个局部,数据起源表单、同步指标表单、字段映射组件和通道管制表单。 其中前三个局部对应的代码十分凌乱,代码量也很大,单个组件代码 5000+ 行,这里着重说一下数据起源表单和同步指标表单。 数据起源和同步指标表单的次要性能是收集数据源对应的配置信息,并且依据数据源类型的不同,对应须要渲染的表单项也不同。 目前袋鼠云离线开发产品 BatchWorks 数据同步性能的数据源多达50+种。在长时间的迭代过程中,与日俱增呈现了很多强行复用的代码,这些强行复用的代码外部又蕴含着大量的 if else 逻辑。另外,数据同步模块的表单外部有很多联动关系,比方: · 某个表单项的值变动时,须要发动接口申请,申请的返回值被用作另一个表单项下拉框的数据 · 某个表单项的值变动时,须要去清空/重置其余一些表单项的值 · 某个表单项的值变动时,须要显示/暗藏某个表单项 · 某个表单项的值变动时,某个表单项的 label 文案、表单项组件(比方从 select 变成 input ) 等随之发生变化 这些表单项的联动解决逻辑在代码中混淆穿插,另外还要加上表单回显的非凡逻辑解决,表单的值收集到 redux 的非凡逻辑解决等。 需要剖析基于上述需要背景,表单渲染器的外围性能是输出一份配置,输入表单 UI 组件。 基于上述数据同步表单背景,咱们心愿渲染器能够尽可能排汇掉表单外部的复杂度,也就是说在表单的配置中要可能形容上述的联动关系,那么能够大略得出表单的配置须要形容: · 表单项的根底信息,比方字段名、label、表单组件、校验信息等 · 表单项数据之间的联动 · 表单项 UI 的联动(管制显示/暗藏) · 表单项的值变动时须要触发的副作用(比方调用接口) 表单根底信息形容这里配置格局应用 JSON 格局,用一个数组形容所有的表单项信息,UI 上表单项的渲染程序即配置数组中表单项配置的程序,表单组件应用 Ant Design Form。 对于表单项根底信息的形容配置,大多能够间接搬用 Ant Design Form Item 的 props,比方 label、rules、Tooltip 等属性,这里不多赘述。 比拟非凡的是,须要在配置里形容表单项形容的 UI 组件,比方 Select、Input,那么这里应用 widget 字段去形容。另外,组件的形容除了组件名称,还须要形容组件的 props, 所以还须要一个 widgetProps 字段去形容组件的属性,比方 placeholder、disabled 等。 ...

June 7, 2023 · 5 min · jiezi

关于大数据:Maxcompute数据上云一致性比对

我写过很多如何去对数、如何批量对数的技术文档,最近我的项目遇到这个问题,我才发现在官网博客上还没有公布过这个课题的文章。这就像灯下黑,太长用到的知识点,反而没有意识到其重要性。 注:这里对数的场景就是指在阿里云平台应用 dataworks 等大数据开发工具集成业务零碎数据库( oracle 等)数据上云到 maxcompute 的场景,所以,示例的SQL也是针对 maxcompute 。 先说说个别业务上怎么对数的,咱们做了一个报表,出了一个数据“某个产品卖了30个”。这个不只是在大数据平台上有这个数据,在业务零碎也有这个数据,这些统计动作在业务零碎通过程序和人工也会有一份,个别做好报表后会先对这个数据。 所以,第一线反馈回来的数据就是这个汇总数据不统一的问题。然而这个后果是十分概括的,因为就像我感觉这个月工资少发了5毛一样,如果我不看我的工资条我其实不晓得本人是不是少发了。工资条不只是一个汇总数据,外面有我税前工资、奖金(浮动)、社保、扣税等一系列的明细数据,这些数据让我去判断我是不是少了5毛,而加工过的数据是简单的。 说到这里,我其实就像表白一个事件,对数是要对明细数据。这是所有计算后事实的根底,能够拿进去作证的。 所以,两边都查一下这个汇总值应用的表的对应的记录,比如说查问“明天这个产品ID的售卖记录”。后果就发现业务零碎有31笔,而大数据平台有30笔。 即使到了这里,其实咱们依然不晓得期间产生了什么,为什么会失落数据。另外咱们还不晓得其余商品ID的数据是不是也有失落的,还有其余的表的数据是不是也会产生相似的状况。 1. 明细数据比对既然最终都是对明细数据,那么我是不是能够间接比对明细数据呢?答复是:正确。 个别产生这种状况,首先要比对业务零碎和大数据平台两个表的数据。 1-再利用全量集成工具,从业务零碎的数据库全量抽取一遍数据到大数据平台。比对数据肯定要把数据放到一起,隔空比对是不存在的。因为大数据平台的容量是数百倍于业务零碎的,所以,个别都在大数据平台比对。(这里有一个悖论,如果集成工具自身就有缺点,导致抽取过程中就丢数据,岂不是永远没方法比对了。所以,如果对这个工具也不确定就得从数据库导出数据到文件,而后再加载到某个数据库下来比对。在这里,通过我对离线集成这个产品的长年应用教训,这个工具是十分牢靠的,还未遇到过这个问题。)   2-依据主键关联,比对2个表中的主键的差别。如果是下面提到的记录失落的问题,这一步做完就很容易比对进去了。这里还会发现一个问题,就是业务零碎的表是一直变动的,所以,这时与大数据平台的表比照会有差别。这个差别的外围起因是:大数据平台的表是业务零碎表在每日的日末(00:00:00)的一个时点数据,而业务零碎的数据是始终在变动的。所以,即使有差别超出预期也不要惊恐。如果是应用实时同步能够从归档日志中获取到这期间数据的每一条变动,能够追溯变动起因。如果没有实时同步,也能够通过表中与工夫相干字段去判断数据是否被更新掉。要是什么都没有(这种状况也是存在的),那就去骂骂设计表的业务零碎开发(没错,是他们的锅),也能够跟业务去具体理解一下,这行记录是不是明天做的,而不是昨天。   3-还有一种状况,就是主键统一,数据内容(主键之外的字段)不统一。这种状况,还是须要思考数据变动的状况,能够从日志、工夫字段、业务等几个角度去比对。如果发现数据的确不合乎预期,就须要查问同步工具的问题。 2 . 比对SQL剖析在下面的章节,我形容了比对明天新抽取的全量表和上日在maxcompute上应用前日全量和上日增量合并的上日全量的环节。比对两张表汇合是否统一的SQL办法其实比较简单,大家第一工夫就会想到汇合操作。在oracle外面有Minus、except,同样在maxcompute外面也有。然而为了便于剖析问题,我还是本人写了一个SQL。示例SQL(maxcompute sql)如下: --限定日期分区,比对上日 select count(t1.BATCH\_NUMBER) as cnt\_left ,count(t2.BATCH\_NUMBER) as cnt\_right ,count(concat(t1.BATCH\_NUMBER,t2.BATCH\_NUMBER)) as pk\_inner ,count(case when t1.BATCH\_NUMBER is not null and t2.BATCH\_NUMBER is null then 1 end) as pk\_left ,count(case when t2.BATCH\_NUMBER is not null and t1.BATCH\_NUMBER is null then 1 end) as pk\_right ,count(case when nvl(t1.rec\_id ,'') = nvl(t2.rec\_id ,'') then 1 end) as col\_diff\_rec\_id ,count(case when nvl(t2.rec\_creator ,'') = nvl(t1.rec\_creator ,'') then 1 end) as col\_diff\_rec\_creator ...

June 7, 2023 · 2 min · jiezi

关于大数据:任务全链路诊断助力云音乐大规模计算资源优化

计算资源vcore的优化不同于内存优化,vcore重大影响着工作的运行效率。如何在保障工作运行效率不变甚至进步的状况下,能进一步优化vcore的利用率?咱们须要对工作做出全面的剖析,给出不同的优化策略。这篇文章次要围绕工作运行阶段,介绍工作全链路诊断针对工作不同查看项异样给予的优化策略,以及带来的收益。 对于大数据离线工作来说,因为流转服务节点较多、技术栈要求较高、数据采集难度大、指标简单难懂等一系列起因,造成业务方对工作的掌控力十分差:不分明异样呈现在哪;不确定工作是否能够优化、如何优化。 目前大数据基础设施组开发了一款EasyEagle产品,并通过其中的工作全链路诊断模块,帮忙用户去解决上述的问题。 本篇文章大抵介绍工作全链路诊断模块,通过局部案例和数据,帮忙用户更好的理解该功能模块能带来什么样的收益,以及如何简略的应用。本篇文章仅波及计算资源vcore的优化,对于异样定位会有其余文章进行介绍。 01什么是工作全链路诊断?工作全链路,指的是工作从提交到产出完结,整个生命周期内流转的各个服务、节点的汇合。 诊断,指的是将上述整个链路,依照已有的运维教训和特色进行形象划分,细分成不同查看项进行诊断定位。 总结起来就是:将工作从提交到产出完结(包含各个流转节点以及流转服务),形象并划分成不同阶段,并对上述各个阶段细分不同的查看项进行诊断定位,提供相干专业化的优化以及解决倡议,进步业务方对工作运行过程的掌控,包含工作运行效率的晋升以及资源利用率的晋升。 02对业务能产生什么价值?次要的价值其实就一点:减少业务方对工作的掌控能力。这里的掌控能力次要分以下几个方面: 资源:指的是资源申请和理论应用是否正当,利用率是否失常 效率:工作运行效率是否能够晋升,是否能够放慢产出 异样定位:异样在哪,如何解决 配置:配置是否正当,不合理的配置如何批改 在目前的零碎中,业务方提交工作之后,直至完结,对工作的整个运行齐全属于一个摸黑状态。工作全链路诊断就能解决这种摸黑状态,并且晋升业务方上述几个方面的掌控能力,达到降本增效的目标。 说到这里,可能有的小伙伴会问,这是真的吗?那咱们就间接贴图以及数据来展现~ 目前外部咱们针对音乐进行了一次工作计算资源的优化,优化工夫范畴为0-7点(业务高峰期),优化工作数量为前200的工作,总体统计数据均只蕴含该时间段(0-7点)。 整体优化成果如图: 在针对0-7点的前200工作优化后,vcore的资源水位降落如上所示。 对于一个只有5.3w的vcore的集群而言,前200的工作占集群43%的资源,可能达到上述的优化成果,还是十分可观的,并且音乐业务方自身对于工作的优化状况就较好。 单个工作的优化成果如图: 单个工作的优化成果如上所示,显而易见。 看到这里,小伙伴对于工作全链路诊断这块对于业务方是否能带来收益,是否还有疑难? 03工作全链路诊断咱们是怎么做的?首先,咱们将工作生命周期大抵分为三个阶段,如下所示:工作筹备阶段,次要是指资源的初始化、本地化等一系列的后期筹备。波及到yarn的调度、资源、本地节点、hdfs等。  工作运行阶段,次要是指工作依照既定逻辑运行。  工作产出阶段,次要是指工作具体逻辑运行结束后,数据长久化或其余的一系列操作。波及到hdfs、metastore等。 针对每个阶段,咱们再依据外部运维相干教训以及特色,形象划分成不同的查看项对其进行诊断。如果诊断出异样,会附加相干的标签。标签会携带异样起因、异样表象、优化倡议等。 看到这里,大家可能会有个疑难:工作依据标签依照优化倡议优化后,就能放慢产出、进步资源的利用率吗? 答案是能够的。因为每个查看项的评判规范都是时长和资源,所有的优化最终的体现都能够通过时长和资源两个维度进行掂量。 上面咱们会具体阐明下各个阶段的查看项划分。 3.1 工作筹备阶段针对这一阶段,咱们对其进行了形象划分,分为如下各个查看项: 该阶段,咱们通过对不同类型container的状态机变动的距离时长,进行查看项划分。上述的各个查看项,也能够关联相干节点和服务。 在这之前,这个阶段基本上对于所有的业务方来说,甚至开发,都是属于齐全不理解、不掌控的阶段。理论监控后,发现很多工作在该阶段都存在问题。 目前在产品中,咱们将其查看项提取成4组标签,展现如下: 上述查看项的优化,次要带来的是工作产出时长的优化。这里咱们简略的举一个例子来阐明下咱们是如何做的。 AM调配耗时过长以AM调配耗时这个查看项为例,判断的根据如下: 获取工作该查看项的耗时; 与集群AM调配速率以及该工作此查看项的历史程度进行比照; 如发现不匹配集群的调配速率或超出历史统计模型设置的下限,则查看工作提交队列的资源水位; 如该队列资源水位已满,则告知业务方因为队列资源有余造成;如该队列资源水位失常,然而AM资源已满,则告知业务方因为AM资源有余造成,倡议批改AM资源配比 如该查看项异样,业务方能够依据给出的相干倡议进行解决,放慢工作的产出。 3.2 工作运行阶段针对这一阶段,咱们也将spark工作进行了一个大略的形象,如下所示:该阶段,咱们次要通过实时统计分析spark的event指标进行查看项的诊断。 以后此阶段查看项的划分还处于增长的状态,目前大抵已有20余项,局部查看项标签如下所示: 上述查看项的优化,为什么能带来资源利用率的晋升以及运行效率的晋升?咱们以几个简略的查看项来举例说明一下。 (1)Input Task数量查看该查看项次要是针对input阶段task数量过多,然而input数据量不大的状况(这里不大,是指的小于等于目前咱们诊断配置的阈值,个别默认为128Mb)。 在目前生产环境中,咱们发现很多input阶段的stage存在10W+的task在运行。这里很多人会认为,这些工作应该会很快产出,工作没啥问题。 然而咱们通过理论的数据分析后发现以下规定: input阶段的stage存在巨量的task,个别会随同GC查看项异样,GC耗时占整个stage运行时长超过10%以上 雷同工作雷同阶段的task解决数据量减少,并不会使task的运行时长出现等比例的增长。因为调度开销以及序列化会有局部耗费,另外input阶段网络以及磁盘IO对task运行时长的影响较大 这种含有巨量task的stage,不可能一轮就能运行结束 因而针对input阶段的stage,存在巨量的task运行并不是一个很好的主见。 针对该查看项,咱们个别会倡议用户将spark.sql.files.maxPartitionBytes配置进步,例如由默认的128Mb进步至512Mb。咱们能够简略的计算下,大抵对于该阶段的stage资源以及时长能节约多少: 原先每个task解决数据量:128Mb 原先input阶段stage的task数量:16w 该工作同时最大task运行数量:2w 原先一轮task运行耗时:t 现每个task解决数据量:512Mb 现input阶段stage的task数量:4w 该工作同时最大task运行数量:2w 数据量增长后,task耗时增长倍数:2.5(数据量晋升4倍后,大抵为2-3倍的耗时减少) 资源: 该阶段vcore资源降落比例:37.5% = (2w 16w/2w t - 2w 4w/2w 2.5t) / (2w 16w/2w t) ...

June 6, 2023 · 1 min · jiezi

关于大数据:开源大数据平台-EMapReduce-Serverless-StarRocks-产品介绍

摘要:本文将分享阿里云与 StarRocks 社区单干打造的云上 StarRocks 极速湖仓的云原生产品实际。次要包含四个局部,第一局部介绍 StarRocks 全托管状态,以及免运维服务的 OLAP 云产品;第二局部介绍 StarRocks Manager 的实例治理、诊断剖析、元数据管理、平安核心等性能;第三局部介绍在社交、在线教育、电商等场景的应用案例;最初是对产品的长短期布局:1.StarRocks 产品介绍2.StarRocks 性能介绍3.StarRocks 场景案例4.StarRocks 将来布局一、StarRocks 产品介绍阿里云与 StarRocks 社区从2022年初开始以半托管的状态单干。现有大略200客户曾经在用半托管的 StarRocks 产品。往年开始做全托管的产品状态,心愿帮忙大家更进一步升高治理、应用门槛,也配合社区将产品推向更多的 OLAP 用户。 EMR Serverless StarRocks 是 StarRocks 在阿里云上的一个全托管服务,联合 StarRocks 本身极速和对立的个性,重点围绕升高门槛和升高运维复杂度这两个指标,为客户提供了更多的能力。 易用性方面,在 Serverless 的状态下,提供了全托管、免运维的服务,大家不必再去放心 StarRocks 集群的稳定性,比方日常应用中宕机等问题。在数据管理方面,提供了易用的慢 SQL 剖析和集群衰弱诊断,便捷的导入工作治理,以及可视化的元数据管理。 联合阿里云上的一些产品,集成了云原生的能力。首先是集成了底层资源,联合K8S,实现了即开即用,仅需三四分钟,即可实现一个集群的疾速创立。并且提供了后续高效扩缩容、升降配的能力,实现了资源的疾速交付。另外,与 DLF 深度集成,实现了整个云上数据湖体系的买通。与 Flink VVP 深度集成,进一步升高开发成本。 上图展现了 EMR 产品体系。本次介绍重点在 OLAP 局部。StarRocks 是 EMR 推出的第一个全托管状态,接下来还会有 Serverless Doris,以及 Presto 等更多的全托管状态,帮忙用户低门槛地去应用大数据的技术栈。 利用 StarRocks 咱们能够构建极速对立的新一代数据架构,在剖析层能够通过 StarRocks 对立 OLAP 引擎,笼罩所有 OLAP 场景,这样能够技术栈对立,一份技术及运维,多种 OLAP 剖析场景都能够实用。 ...

June 5, 2023 · 1 min · jiezi

关于大数据:通过python采集快手商品详情页面数据快手商品详情API接口快手API接口

快手商品详情页面数据包含商品的题目、价格、详情介绍和图片等信息。 具体可参考以下快手商品详情页面截图: 商品题目:显示商品的名称,个别位于页面顶部。 商品价格:显示商品的价格,个别位于页面顶部或底部。 商品详情:显示商品的具体介绍、规格、材质、适用人群等信息,个别位于页面中部。 商品图片:显示商品的图片,个别位于页面中部或底部,能够通过左右滑动查看不同角度的图片。 要采集快手商品详情页面数据,能够应用 Python 中的 Web Scraping 库,例如 beautifulsoup4 和 requests。上面是一个示例代码: import requests from bs4 import BeautifulSoup url = "https://m.kuaishou.com/short-video/3x2nwarwy95m67r/5mqmxv2ktxqj7uc"res = requests.get(url) soup = BeautifulSoup(res.content, "html.parser")# 获取商品题目和价格title = soup.find("h1", {"class": "goods-title"}).text.strip() price = soup.find("div", {"class": "goods-price"}).text.strip()# 获取商品详情details = [] for detail in soup.find_all("div", {"class": "goods-detail-text"}):    details.append(detail.text.strip())# 获取商品图片images = [] for img in soup.find_all("img", {"class": "goods-images"}):    images.append(img.get("src"))# 打印后果print("商品题目:", title) print("商品价格:", price) print("商品详情:", details) print("商品图片:", images)在下面的代码中,咱们首先发送一个申请,获取快手商品详情页面的 HTML 代码,并用 beautifulsoup4 库解析该页面。而后,咱们应用 find () 和 find_all () 办法来获取须要的数据,包含商品题目、价格、详情和图片。 ...

June 3, 2023 · 1 min · jiezi