信息架构

（马蜂窝技术原创内容，公众号ID：mfwtech） 一、马蜂窝数据仓库与数据中台 最近几年，数据中台概念的热度一直不减。2018 年起，马蜂窝也开始了自己的数据中台探索之路。 数据中台到底是什么？要不要建？和数据仓库有什么本质的区别？相信很多企业都在关注这些问题。 我认为数据中台的概念非常接近传统数据仓库+大数据平台的结合体。它是在企业的数据建设经历了数据中心、数据仓库等积累之后，借助平台化的思路，将数据更好地进行整合与统一，以组件化的方式实现灵活的数据加工与应用，以更清晰的数据职能组织应对业务的快速变化，以服务的方式更好地释放数据价值的一种方式。 所以，数据中台更多的是体现一种管理思路和架构组织上的变革。在这样的思想下，我们结合自身业务特点建设了马蜂窝的数据中台，核心架构如下： 在中台建设之前，马蜂窝已经建立了自己的大数据平台，并积累了一些通用、组件化的工具，这些可以支撑数据中台的快速搭建。作为中台的另一大核心部分，马蜂窝数据仓库主要承担数据统一化建设的工作，包括统一数据模型，统一指标体系等。下面介绍马蜂窝在数据仓库建设方面的具体实践。 二、数据仓库核心架构 马蜂窝数据仓库遵循标准的三层架构，对数据分层的定位主要采取维度模型设计，不会对数据进行抽象打散处理，更多注重业务过程数据整合。现有数仓主要以离线为主，整体架构如下： 如图所示，共分为 3 层： 业务数据层

多级缓存的分层架构 前言 在互联网高速发展的今天，缓存技术被广泛地应用。无论业内还是业外，只要是提到性能问题，大家都会脱口而出“用缓存解决”。 这种说法带有片面性，甚至是一知半解，但是作为专业人士的我们，需要对缓存有更深、更广的了解。 缓存技术存在于应用场景的方方面面。从浏览器请求，到反向代理服务器，从进程内缓存到分布式缓存。其中缓存策略，算法也是层出不穷，今天就带大家走进缓存。 正文 缓存对于每个开发者来说是相当熟悉了，为了提高程序的性能我们会去加缓存，但是在什么地方加缓存，如何加缓存呢？ 假设一个网站，需要提高性能，缓存可以放在浏览器，可以放在反向代理服务器，还可以放在应用程序进程内，同时可以放在分布式缓存系统中。 从用户请求数据到数据返回，数据经过了浏览器，CDN，代理服务器，应用服务器，以及数据库各个环节。每个环节都可以运用缓存技术。 从浏览器/客户端开始请求数据，通过 HTTP 配合 CDN 获取数据的变更情况，到达代理服务器（Nginx）可以通过反向代理获取静态资源。 再往下来到应用服务器可以通过进程内（堆内）缓存，分布式缓存等递进的方式获取数据。如果以上所有缓存都没有命中数据，才会回源到数据库。 缓存的请求顺序是：用户请求 → HTTP 缓存 → CDN 缓存 → 代理服务器缓存 → 进程内缓存 → 分布式缓存 → 数据库。 看来在技术的架构每个环节都可以加入缓存

一、关于高并发 高并发是指在同一个时间点，有很多用户同时访问URL地址，比如：淘宝的双11、双12，就会产生高并发。又如贴吧的爆吧，就是恶意的高并发请求，也就是DDOS攻击，再屌丝点的说法就像玩LOL被ADC暴击了一样，那伤害你懂的。 来源：SFLYQ的博客 原文：http://blog.thankbabe.com/2016/09/14/high-concurrency-scheme/ 1、 高并发会来带的后果 服务端： 导致站点服务器/DB服务器资源被占满崩溃，数据的存储和更新结果和理想的设计是不一样的，比如：出现重复的数据记录，多次添加了用户积分等。 用户角度： 尼玛，这么卡，老子来参加活动的，刷新了还是这样，垃圾网站，再也不来了！ 我的经历： 在做公司产品网站的过程中，经常会有这样的需求，比如搞个活动专题、抽奖、签到、积分竞拍等等，如果没有考虑到高并发下的数据处理，那就Game Over了，很容易导致抽奖被多抽走，签到发现一个用户有多条记录等等，各种超出正常逻辑的现象，这就是做产品网站必须考虑的问题，因为这些都是面向大量用户的，而不是像做ERP管理系统、OA系统那样，只是面向员工。 下面我进行实例分析，简单粗暴，动态分析，纯属本人经验分享，如有说错或者更好的建议，请留言，大家一起成长。 2、 并发下的数据处理 通过表设计，如：记录表添加唯一约束

【From】 https://blog.csdn.net/u013332124/article/details/88350345 Spark History Server 是spark内置的一个http服务，通过sbin/sbin/start-history-server.sh启动。History Server启动后，会监听一个端口，同时启动两个定时任务线程，分别用来解析eventLog日志文件和清理过期的eventLog日志文件。 Spark History Server启动后，我们可以直接在浏览器输入 http://ip:port 访问。一般默认端口是18080 一、eventLog日志文件以及相关参数 eventLog日志文件介绍 eventLog需要将配置spark.eventLog.enabled设置为true来开启，默认是关闭的。 开启这个配置后，当我们提交spark job到集群中运行时，之后spark job在运行过程中会不断的一些运行信息写到相关的日志文件中。具体的eventLog存放目录由配置spark.eventLog.dir决定的。 Spark job在运行中，会调用EventLoggingListener#logEvent()来输出eventLog内容。spark代码中定义了各种类型的事件，一旦某个事件触发，就会构造一个类型的Event

主要语义分割网络调研 介绍 图像的语义分割是将输入图像中的每个像素分配一个语义类别，以得到像素化的密集分类。虽然自 2007 年以来，语义分割/场景解析一直是计算机视觉社区的一部分，但与计算机视觉中的其他领域很相似，自 2014 年 Long等人 首次使用全卷积神经网络对自然图像进行端到端分割，语义分割才产生了大的突破。 网络架构 一般的语义分割架构可以被认为是一个 编码器-解码器 网络。 编码器 通常是一个预训练的分类网络，像 VGG、ResNet，然后是一个 解码器 网络。这些架构不同的地方主要在于 解码器 网络。 解码器 的任务是将 编码器 学习到的可判别特征（较低分辨率）从语义上投影到像素空间（较高分辨率），以获得密集分类。 不同于分类任务中网络的最终结果（对图像分类的概率）是唯一重要的事，语义分割不仅需要在像素级有判别能力，还需要有能将编码器在不同阶段学到的可判别特征投影到像素空间的机制。不同的架构采用不同的机制（跳跃连接、金字塔池化等）作为解码机制的一部分。 Fully Convolution Networks (FCNs) 全卷积网络 Fully Convolutional Networks for Semantic Segmentation(2015) 作者将当前分类网络（AlexNet, VGG net 和 GoogLeNet）修改为全卷积网络

一、微服务介绍 1. 什么是微服务 在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"， 微 狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。 2. 微服务由来 微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。 3. 为什么需要微服务？ 在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高

　　 5.1 网站可用性的度量与考核 　　　　 网站的可用性描述网站可有效访问的特性。 　　　　网站的页面能完整呈现在用户面前，需要经过很多环节，任何一个环节出问题，都会导致网站页面不可访问。 　　　　DNS会被劫持、CDN服务可能会挂掉、网站服务器可能会宕机、网站交换机可能会失效、硬盘会损坏、网卡会松掉、机房会停电、空调会失灵、程序会有Bug、黑客会攻击、促销引来大量的访问、第三方合作伙伴的服务不可用..... 　　5.2 高可用的网站架构 　　 　　 网站高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。 　　　　实现上述高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。 　　　　一个典型的网站设计通常遵循如下图所示的基本分层架构模型 　　典型的分层模型是三层，即应用层、服务层、数据层；各层之间具有相对独立性，应用层主要负责具体业务逻辑处理；服务层负责提供可复用的服务；数据层负责数据的存储与访问。 　　　 　 　不同的业务产品会部署在不同的服务器集群上，如某网站的文库、贴吧、百科等属于不同的产品，部署在各自独立的服务器集群上，互不相干。这些产品又会依赖一些共同的复用业务，如注册登录服务、Session 管理服务、账户管理服务等

flume 采集数据 MapReduce HBse (HDFS) Yarn 资源调度系统 展示平台 数据平台 1 ，提交任务 2 ，展示结果数据 spark 分析引擎 S3 可以进行各种的数据分析 ， 可可以和 hive 进行整合 ， spark 任务可以运行在 Yarn 提交任务到集群的入口类 SC 为什么用 spark ： 速度快，易用，通用，兼容性高 hadoop scala jdk spark 如果结果为定长的 toBuffer 编程变长的 启动流程 spark 集群启动流程 和任务提交 主节点 master 子节点 work 多台 start-all 。 sh 脚本 先启动 master 服务 启动 work master 提交注册信息 work 响应 work 会定时发送心跳信息 集群启动流程 1 、调用 start-all 脚本 ，开始启动 Master 2 、 master 启动以后， preStart 方法调用了一个定时器，定时的检查超时的 worker 3 、启动脚本会解析 slaves 配置文件，找到启动 work 的相应节点，开始启动 worker 4 、 worker 服务启动后开始调用 prestart 方法（生命周期方法）开始向所有的 master 注册 5 、 master 接收到 work 发送过来的注册信息， master

每个大型网站都是由小变大的，在变大的过程中，几乎都需要经历单机架构、集群架构到分布式架构的演变。而伴随着业务系统架构一同演变的，还有各种外围系统和存储系统，比如关系型数据库的分库分表改造、从本地缓存到分布式缓存的过渡等。 在业务架构逐渐复杂的同时，保证系统的高性能、高可用、易扩展、可伸缩，使框架能有效地满足业务需要，是一个长远而艰巨的任务。本文介绍了五种相关的技术：分布式服务化架构、大流量的限流和削峰、分布式配置管理服务、热点数据的读写优化和数据库的分库分表。 值得注意的是，技术并不是越复杂越好，技术是为了更好地服务业务，只要能达到业务的需求，就是好的技术。简单说就是，即使你有实现复杂技术的能力，没有用户量和利润为基础，也难以落地实施。所以虽然下文中提到了一些框架，但是并不是每一种框架都需要你去亲自实践。很多时候，只是给你提供一个新的思路，一种新的方法，而至于是不是值得被实践，还需要得到业务和用户的考验。 文章目录 分布式服务化架构 集群和分布式 服务化架构，微服务和RPC 服务化架构的组成 服务的横向拆分 服务治理方案 总结 大流量的限流和削峰 分布式系统为什么要进行流量管制 限流方案 削峰方案 基于时间分片的削峰方案 基于异步调用的削峰方案 分布式配置管理服务 热点数据的读写优化 缓存技术 热卖商品的高并发读 基于Redis集群的多写多读方案

郑昀 创建于2016/3/30 最后更新于2016/4/8 关键词：技术预研课题，平台设计，应用场景，故事，信息架构，业务流程，数据流程 本文档适用人员：全体研发 提纲： 如何从零开始搭建一个技术平台？ 应用场景其实就是我们的愿景 从应用场景推导出故事 从故事推导出信息架构和业务流程 一，如何从零开始？ 如果让你把下面这套技术体系串联起来，从零开始构建一个技术平台，你如何做需求分析呢，在没有产品经理帮助你梳理的情况下？ 下面这些系统涵盖了我们研发测试运维日常工作的方方面面： idCenter ：它定义用户、用户组、权限。研发测试都有了唯一的身份和权限集合，贯穿所有系统。 iDB ：数据库自动化运维系统能把数据库建帐号、授予权限、建表、改表结构、刷库这些日常操作都变成流程， DBA审核通过后就可以自动执行，以及自动回滚。 Touchstone ：容器私有云的管理控制台，管理镜像库、应用、容器、主机等。日常发布就在这里做。 JobCenter ：定时任务调度和管理。 Summoner ：大型计算任务的调度和管理。云纵佣金计算就是在这上面跑的。 Notify ：异步消息可靠推送。所有的异步消息都走这个中间件。 Discache ：管理 memcached和 redis。 OAP ：运维自动化系统。主要是资产管理、资源管理和发布。 Secret ：天机和鹰眼。数据库、 Java、 PHP