背部肌肉构成

背部宽度训练动作

宽度训练着重在背阔肌的训练，以下拉为主

引体向上

主要锻炼肌肉：背阔肌，大圆肌，小园肌，肱二头肌。
次要锻炼肌肉：三角肌后束，胸肌，腹肌，斜方肌等。

1. 双臂在前方伸直，抓紧杠杆，身体向后倾斜30度，尽量让身躯挺直，挺胸。
2. 向后下方拉动拉动肩膀和上臂，让身体向上，直至杠杆碰到上胸。在进行着部分运动时吐气。提示：在达到完全收紧状态时集中注意力收缩后背肌肉。
3. 在收紧状态1秒后，开始吸气，并缓慢地降下躯体还原至起始状态，让手臂完全伸直，背阔肌完全伸展。

握杠技巧：
适当增加握的宽度，也更能增加对背阔肌的刺激

高位下拉

背要直，可以稍微向后仰一点
吐气的同时将肩膀和上臂向后下方拉动，拉下把手直至碰到上胸。提示：完全收紧时集中注意力收缩后背肌肉。动作中上躯应保持固定，只有手臂运动。前臂只需抓握杠杆，没有其他动作，不要用前臂拉动把手。
呼吸：用力下拉时呼气，还原时吸气
小臂力竭的问题：拇指环握时，小臂肌群收缩状态会发力，所以，解决方法是半握法，即不使用大拇指

俯身杠铃划船

杠铃划船是发达背阔肌最有效的动作之一。而用杠铃练习划船有 四种握法：窄握、中握、宽握和并握。
不同的握距和握法锻炼的部位有所不同。

• 宽握和并握的重点是发达背阔肌上部肌群;
• 中握重点是发达背阔肌中上部肌群;
• 窄握重点是发达背阔肌中下部肌群。

动作要点：膝盖微屈，背部伸直，身体朝前倾，双手反握哑铃，双手夹紧身体两侧，集中背阔肌的力将杠铃沿着大腿拉向自己的小腹，稍微停顿，然后慢慢还原到起始位置。

背部厚度训练动作

厚度训练着重在斜方肌和菱形肌的训练，以划船为主

哑铃划船

1. 前后脚弓步，一条手臂放在哑铃架或者健身椅上支撑身体。另一只手拿哑铃，手臂自然下垂，掌心向内。背部挺直
2. 呼气的同时，用背部的力量将哑铃上拉到胸部侧面，上臂紧贴身体，上身保持不动。
3. 在顶端稍适停留，感受背部的肌肉收缩，然后缓缓将哑铃降回起始位置，同时吸气。
4. 重复以上动作至推荐次数，然后换另一边继续。

总是，要让手臂内收，上臂更接近脊柱，而不是手臂向后过度伸展

注意：

1. 做完全程才会有效刺激到背部
2. 可以上大重量，这个动作可以用大重量刺激，可以放在训练开始时进行
3. 万万不可弓背，背要直

坐姿划船

1. 两腿踩住前方的踏板，微屈膝，腿不可伸直，两手紧握三角形（或其他形状的）手柄，双臂前伸，腰腹固定，挺胸抬头。
2. 收缩背部肌肉，加紧肩胛骨，用这股力量，将手柄拉至腹部，尽可能地向后牵拉你的双肩和双肘，直到手柄接触到你的身体中部。可以保持顶峰收缩1-2秒，努力挤压你的肩胛骨，得到最大程度的刺激
3. 以背阔肌的力量控制还原，所谓的快拉慢回，控制速度，但是！不需要过慢。

斜方肌训练动作

背部另一个重要的位置是斜方肌：这位置个可以放在练肩的那一天进行训练

杠铃耸肩

1. 手握杠铃，心手面向身体，挺立身体，双臂与地面垂直
2. 尽可能提高的肩膀，注意只是肩膀部份移动，身体其他部份静止不动，顶峰收缩保持2-3秒钟
3. 颈部放松，你是靠斜方提起中午，不是脖子

反握杠（哑铃）划船

锻炼斜方肌的中下部

1. 双脚与肩同宽、膝盖微弯，身体前顷，背要直，要平，下背一定要打直。双手略比肩宽，反握杠铃，身体对齐杠铃中心点。
2. 将杠铃往肚脐方向拉起，收缩背部将杠铃碰到肚脐，接触到身体。回到起始动作时，感受背部有明显展开的感觉，手再送出去。

哑铃耸肩

耸肩建议在能够维持动作标准的情况下，尽量使用大重量，小重量刺激不够深，比较难看到效果。

硬拉

屈腿硬拉:

动作要点：

1. 将杠铃放于地面，双脚分开，与肩同宽。背部保持伸直，双腿弯下，身体前倾，双手正握抓住杠铃。
2. 下蹲，收臀，直到大腿与地面平行，且肩膀位于杠铃正上方。然后挺胸、抬头、收腹，深吸一口气。

无法开启远程访问

在设置中对资料库开启远程访问失败，原因是nas上使用了带科学上网的软路由作为网关，网关自动代理了plex.tv域名的请求，是的plex服务器获得的公网ip是梯子的ip，无法访问到真正的库。将plex.tv域名添加到软路由的直接访问列表中即可

认证库权限返回401

通过公网访问库时，无法获取库的权限，显示“未经授权 您无权访问此服务器。”
这个不知道是什么原因，外网上也有类似的问题，但没有答案，我最后清掉配置目录下所有文件，重新构建docker实例，重新配置服务器，问题解决了

ubuntu安装

1
2

sudo apt update
sudo apt install syncthing

如果要使得webui在127.0.0.1以外也能访问，需要在安装后修改/lib/systemd/system/syncthing@.service增加--gui-address=0.0.0.0:8384配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

[Unit]
Description=Syncthing - Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
StartLimitIntervalSec=60
StartLimitBurst=4

[Service]
User=%i
ExecStart=/usr/bin/syncthing serve --no-browser --gui-address=0.0.0.0:8384 --no-restart --logflags=0
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

# Hardening
ProtectSystem=full
PrivateTmp=true
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

username替换为你的用户名

1
2

sudo systemctl enable syncthing@username.service
sudo systemctl start syncthing@username.service

同步

互相添加远程设备

通过识别序列号，互相添加远程设备。可在高级设置中手动设置对方机器地址

发送方

增加需要同步的文件夹，并在共享中选择需要共享到的机器

接收方

接收方web端会弹框提醒是否接受该文件夹，并且可以指定接受位置

错误处理

folder marker missing

问题提示：
Error on folder “xxxx” (xxxx): folder marker missing (this indicates potential data loss, search docs/forum to get information about how to proceed)
解决办法
在文件夹内新建.stfolder文件夹即可。修复后，依然可能会提示此问题，点确认即可。

ZFS ACL权限permission denied

例如其中一个syncthing节点为truenas scale下的k3s应用，则需要给zfs pool开通apps(568)用户的读权限与执行权限

文件系统监视器错误

操作系统的文件监听数量限制，参见How do I increase the inotify limit to get my filesystem watcher to work?

参考文档：
ContentCachingRequestWrapper解决入参读取

使用方法

增加拦截器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import java.io.IOException;
import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;
import org.springframework.web.filter.OncePerRequestFilter;
import org.springframework.web.util.ContentCachingRequestWrapper;

/**
 * 将HttpServletRequest包装成ContentCachingRequestWrapper，使其body可以多次读取
 */
@Component
@Order(1)
public class RequestWrapFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, FilterChain filterChain) throws ServletException, IOException {
        ContentCachingRequestWrapper wrapper =
                new ContentCachingRequestWrapper(httpServletRequest);
        filterChain.doFilter(wrapper, httpServletResponse);
    }
}

注册拦截器

注册方法不赘述。例如上述代码中@Component @Order(1)会自动注册Filter

读取方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import javax.servlet.http.HttpServletRequest;

import com.google.common.io.ByteSource;

import org.springframework.web.util.ContentCachingRequestWrapper;

public class HttpBodyReader {
    private HttpBodyReader() {
    }

    /**
     * 获取POST请求HttpServletRequest中的body信息
     * HttpServletRequest本身是不可以重复读取body的，filter中对request进行了wrap，使其变成了ContentCachingRequestWrapper
     * ContentCachingRequestWrapper是可重复读取的body的实现
     * 必须在已经通过getInputStream()读取了数据后，改方法才能返回数据
     * @param request
     * @return
     * @throws IOException
     */
    public static String getRequestBody(HttpServletRequest request) throws IOException {
        String responseBody = "";
        if (request instanceof ContentCachingRequestWrapper) {
            ContentCachingRequestWrapper cachingWrapper = (ContentCachingRequestWrapper) request;
            byte[] buf = cachingWrapper.getContentAsByteArray();
            if (buf.length > 0) {
                responseBody = ByteSource.wrap(buf)
                        .asCharSource(StandardCharsets.UTF_8)
                        .read();
            }
        }
        return responseBody;
    }
}

原理

在spring框架读入输入流时会调用getInputStream()方法

wrapper重写getInputStream()方法，将流替换成ContentCachingInputStream内部类

1
2
3
4
5
6
7

@Override
public ServletInputStream getInputStream() throws IOException {
    if (this.inputStream == null) {
        this.inputStream = new ContentCachingInputStream(getRequest().getInputStream());
    }
    return this.inputStream;
}

ContentCachingInputStream重写了read方法，在流式读取的过程中把内容复写到外部类的cachedContent中

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Override
public int read() throws IOException {
    int ch = this.is.read();
    if (ch != -1 && !this.overflow) {
        if (contentCacheLimit != null && cachedContent.size() == contentCacheLimit) {
            this.overflow = true;
            handleContentOverflow(contentCacheLimit);
        }
        else {
            cachedContent.write(ch);
        }
    }
    return ch;
}

再通过getContentAsByteArray()方法即可反复读取cachedContent中内容

参考资料
《Dataphin产品白皮书》
Dataphin帮助文档
Dataphin和Dataworks的区别与各自定位？

Dataphin简介

Dataphin是阿里巴巴集团OneData数据治理方法论内部实践的云化输出，一站式提供数据采、建、管、用全生命周期的大数据能力，以助力企业显著提升数据治理水平，构建质量可靠、消费便捷、生产安全经济的企业级数据中台。遵循阿里巴巴集团多年实战沉淀的大数据建设OneData体系（OneModel、OneID、OneService），集产品、技术、方法论于一体，一站式地为您提供集数据引入、规范定义、数据建模研发、数据萃取、数据资产管理、数据服务等的全链路智能数据构建及管理服务。

Dataphin的主要功能模块包括：

• 平台管理：平台管理是Dataphin的基础功能，主要包含全局化功能设置和首页引导。
• 全局设计：基于业务全局，从顶层自下规划设计业务数据总线，包括：划分命名空间、定义主题域及相关名词、划分管理单元（即项目）、定义数据源及计算引擎源。
• 数据引入：数据引入基于全局设计定义的项目空间与物理数据源，将各业务系统、各类型的数据抽取加载至目标数据库。
• 规范定义：基于全局设计定义的业务总线、数据引入构建的基础数据中心，根据业务数据需求，结构化地定义数据元素（例如维度、统计指标），保障数据无二义性地标准化、规范化生产。
• 建模研发：基于规范定义的数据元素，设计与构建可视化的数据模型。
• 编码研发：基于通用的代码编辑页面，灵活地进行个性化的数据编码研发，完成任务发布。
• 资源及函数管理：支持管理各种资源包，支持查找与使用内置的系统函数，支持用户自定义函数。
• 数据萃取：基于Dataphin数据建模研发沉淀的数据，萃取提供以目标对象为中心的数据打通和深度挖掘，并生成代码与调度任务，完成实体对象识别、连接及标签生产，可快速应用于各类业务。
• 调度运维：对建模研发、编码研发生成的代码任务进行基于策略的调度与运维，确保所有任务正常有序地运行。
• 即席查询：支持用户通过自定义SQL等方式，查询数据资产中的数据。
• 数据服务：数据服务为您提供高效便捷的主题式查询功能及有效的全链路企业内API生命周期托管

阿里OneData思想下的数仓结构

阿里云OneData数据中台解决方案基于大数据存储和计算平台为载体，以OneModel统一数据构建及管理方法论为主干，OneID核心商业要素资产化为核心，实现全域链接、标签萃取、立体画像，以数据资产管理为皮，数据应用服务为枝叶的松耦性整体解决方案。其数据服务理念根植于心，强调业务模式，在推进数字化转型中实现价值。
数据中台到如今的建设成果主要体现在两方面：一个是数据的技术能力，另一个是数据的资产。
阿里的各个业务都在共享同一套数据技术和资产。阿里内部为这个统一化的数据体系命名为 “OneData”。OneData又主要抽象成三个部分，分别是：OneID、OneModel、OneService。

• OneModel 统一模型构建与管理。通过全域数据集成、数据分层架构、业务视角标准规范定义数据和处理数据，致力于统一数据口径、消除指标二义性；
• OneID 即建立业务实体要素资产化为核心，实现全域链接、标签萃取、立体画像，其数据服务理念根植于心，强调业务模式。核心商业要素资产化。以业务和自然对象为基础，以标签数据为核心，能够实现全域实体识别与连接，数据价值深度萃取，助力企业构建标签体系、完成核心商业要素资产化；
• OneService 即数据被整合和计算好之后，需要提供给产品和应用进行数据消费，为了更好的性能和体验，需要构建数据服务层，通过统一的接口服务化方式对外提供数据服务。统一的主题式服务。以业务便捷消费数据为目标，建立主题式的数据服务单元，面向应用快速构建 API 以提供服务，建立起统一的数据服务中心。

数仓构建流程

数仓分层

维度设计原则

• 尽可能生成丰富的维度属性。例如电商公司的商品维度可能有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础。
• 尽可能多的给出包含一些富有意义的文字性描述。属性不应该是编码，而应该是真正的文字。在阿里巴巴维度建模中，通常是编码和文字同时存在，例如商品维度中的商品ID和商品标题、类目ID和类目名称等。ID
  通常用于不同表之间的关联，而名称通常用于报表标签。
• 区分数值型属性和事实。数值型字段是作为事实还是维度属性，可以根据字段的常用用途区分。例如，若用于查询约束条件或分组统计，则是作为维度属性；若用于参与度量的计算，则是作为事实。
• 尽量沉淀出通用的维度属性。
  • 通过逻辑处理得到维度属性。
  • 通过多表关联得到维度属性。
  • 通过单表的不同字段混合处理得到维度属性。
  • 通过对单表的某个字段进行解析得到维度属性。

明细数据层

事实表（事实模型，又称事实逻辑表）作为数据仓库维度建模的核心，紧紧围绕着业务过程进行设计。业务过程是通过事实表的度量、引用的维度与业务过程有关属性的方式获取。
事实表设计原则：

• 尽可能包含所有与业务过程相关的事实。
• 只选择与业务过程相关的事实。
• 在选择维度和事实之前，必须先声明粒度。
• 在同一个事实表中，不能包含多种不同粒度的事实。
• 事实的单位要保持一致。

汇总数据层

汇总数据层以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求构建公共粒度的汇总表。汇总数据层的一个表通常会对应一个统计粒度（维度或维度组合）及该粒度下若干派生指标。

Dataphin模型结构

Dataphin核心概念的逻辑结构

Dataphin的架构包括以下几个层次：

• 业务模型层和计算引擎层：业务模型层从业务视角对数据进行重新定义组织，分类打标；计算引擎层承载数据的实际计算与存储。
• 业务模型层按照不同的业务形态，划分出业务板块，一种业务形态对应一个业务板块。
• 同一种业务形态（业务板块）内，根据实际业务情况，将业务实体（维度和业务过程）划分到不同的数据域。
• 基于维度和业务过程创建明细逻辑表（包括维度逻辑表和事实逻辑表），及定义指标（包括原子指标、业务限定、统计周期、统计粒度、统计时效、派生指标）。

说明

在Dataphin 3.3版本，维度更名为业务对象，业务过程更名为业务活动，数据域更名为主题域，业务板块更名为数据板块。

核心概念的详细内容

基本概念之间的关系

Dataphin案例介绍

以某公司的零售事业群为例

规划数仓

1. 规划业务板块。
   某公司实行的是事业部制，各事业部之间业务独立，关联极少，主要体现在以下几方面：
   • 事业部之间不共享资源，人员独立、办公场地独立等。即从Dataphin的实施角度来看，事业部之间不存在共同的业务对象（业务参与人或物）。
   • 事业部之间不存在业务流程的流转。零售事业群的某个作业流程（如采购、销售）与金融事业部完全无关。
     因此，基于以上因素及数据板块的划分原则，某公司可以建立三个独立的业务板块：
   • 零售板块
   • 金融板块
   • 地产板块
2. 规划项目。
   零售事业群可以作为一个项目，也可以分为多个项目归属到一个业务板块。为了管理维护方便（计算与存储资源分配）， 本案例中规划了三对项目（每对项目包括开发项目和生产项目）：
   • ODS层项目（dummy_retail_ods_dev和dummy_retail_ods），用于存放从各个业务系统每天同步过来的原始数据.
   • CDM层项目（dummy_retail_cdm_dev和dummy_retail_cdm）, 用于存放企业内通用，且经常被很多业务场景使用的数据。
   • ADS层项目（dummy_retail_ads_dev和dummy_retail_ads），面向业务场景。
3. 划分数据域。
   基于主题域的划分原则，零售事业群的数据域划分详情如下：
   • 会员（消费者）域
   • 商品域
   • 门店域
   • 交易域
   • 供应链域
   • 履约域
   • 营销域
   • 服务域
   • 流量域
   • 公共域
4. 确定维度与业务过程。

   1. 列举出业务活动，下表仅列举了部分业务活动。

      数据域	业务活动
      交易域	订单、支付
      供应链域	采购、运输、仓储（入库、上架、拣选、出库、盘点等）
      履约域	接单、配送

   2. 拆分上述步骤中每个业务活动的参与对象和业务活动中的关键节点，下表仅列举了部分参与对象和关键节点。

      数据域	业务活动	参与对象	关键节点
      交易域	订单	消费者、门店、商品	下单、支付、关单 重要 线下订单下单、支付、关单在POS支付那一刻就全部完成。
      交易域	支付	消费者	创建（支付单）、支付、关单
      供应链域	采购	供应商、商品、仓库	确认采购单、预付、发货、收货、付尾款、关单
      供应链域	运输、调拨	仓库、商品、承运商、门店	确认调拨单、发运、收货、关单
      履约域	配送	仓库、商品、消费者	发货、收货、关单

   3. 确定维度及其所在的数据域。
      根据上一步的拆分，将各个业务活动的参与对象集合起来，去除重复后得到的就是维度。另外，维度本身的一些属性也是重要的分析角度，也需要设置为维度。确定了维度后，按照以下原则确定维度的归属数据域：

      • 有公共性的对象（即参与了多个数据域业务活动的对象），通常都设置了独立的数据域，如消费者域。
      • 只参与某一个数据域的业务活动的对象归属在所在数据域。
      • 维度的属性延展出来的维度，与本维度在同一个数据域。

      基于以上原则，确定的维度及维度归属的数据域如下表所示，下表仅列举了部分维度及归属数据域。

      数据域	维度
      消费者域	消费者、性别、年龄层、职业等
      商品域	商品、类目
      门店域	门店
      供应链域	供应商、仓库、承运商

   4. 确定业务过程
      通常，业务分析只需要关注业务活动的关键节点，这些关键节点可以设置为业务过程（如果后面业务需要，可以将其他节点也设置为业务过程） 。

      数据域	业务过程
      交易域	下单、支付、关单；创建（支付单）、支付、支付关单
      供应链域	确认采购单、预付、发货、收货、付尾款、采购关单确认调拨单、发运、收货、调拨关单
      履约域	发货、收货、关单

   5. 配置维度逻辑表
      给一个维度添加属性字段并设置字段的来源（对应某个ODS层物理表的字段或字段计算逻辑），设置其关联维度后就可以得到维度逻辑表。下表为消费者维度逻辑表，仅列举了部分属性字段。

      属性字段	说明	来源字段	关联维度
      customer_id	客户ID	dummy_retail_ods.s_customer.id	无
      customer_name	消费者名称	dummy_retail_ods.s_customer.name	无
      reg_date	注册日期	dummy_retail_ods.s_customer.reg_date	无
      gender	性别	dummy_retail_ods.s_customer.gender	性别
      address_id	消费者注册地址	dummy_retail_ods.s_customer.address_id	地址

      地址是一个公共域维度，其维度逻辑表为下表所示，仅列举了部分属性字段。

      属性字段	说明	来源字段	关联维度
      address_id	内部ID	dummy_retail_ods.s_address.id	无
      region_id	区域ID	dummy_retail_ods.s_address.region_id	区域
      province_id	省份ID	dummy_retail_ods.s_address.prov_id	省
      city_id	城市ID	dummy_retail_ods.s_address.city_id	城市
      district_id	区县ID	dummy_retail_ods.s_address.district_id	区县
      street	街道	dummy_retail_ods.s_address.street	无
      address_detail	详细地址	dummy_retail_ods.s_address.addr	无

   6. 配置事实逻辑表
      给一个业务过程添加属性字段并设置字段的来源（对应某个ODS层物理表的字段或字段计算逻辑），设置其关联维度后就可以得到事实逻辑表。下表为下单的事实逻辑表，仅列举了部分属性字段。

      属性字段	说明	来源字段	关联维度
      order_id	订单ID	dummy_retail_ods.s_order.id	无
      order_time	下单时间	dummy_retail_ods.s_order.gmt_create	无
      customer_id	消费者（买家）ID	dummy_retail_ods.s_order.buyer_id	消费者
      order_site	订单来源平台	dummy_retail_ods.s_order.order_source	平台类型（枚举）
      store_id	门店ID	dummy_retail_ods.s_order.store_id	门店
      amount	订单金额	dummy_retail_ods.s_order.amount	无

      该事实逻辑表关联了消费者维度，消费者维度又关联了地址，地址关联了地域相关的多个维度。
      

定义指标

下文以消费者运营团队统计 最近30天内每个消费者线上下单金额 为例，为您介绍如何定义其中的指标。

按照传统SQL研发方式，您可以使用以下代码，统计 最近30天内每个消费者线上下单金额 。

1
2
3
4
5
6
7
8

--假设今天是 2021/10/01
select customer_id
      ,sum(amount) as order_amt_30d 
  from fct_crt_ord_di
 where ds >= '20210901'
   and ds <= '20210930' 
   and order_site = 1
 group by customer_id

根据上述代码为您介绍如何定义统计周期、统计粒度、统计时效、原子指标、业务限定和派生指标：

• 统计周期
  统计周期用于约束指标的来源数据的时间跨度，即该指标的统计周期为最近30天，也就是指定了该指标的来源数据是最近30天内创建的订单。
• 统计粒度
  统计粒度是分析维度，即Group By后需要聚合的维度，该指标的统计粒度就是消费者维度。
• 统计时效
  最近30天这个统计周期是以天为统计粒度的，因此该指标的统计时效是天。
• 原子指标
  下单金额是该指标的原子指标，其计算逻辑为sum(amount)。下单金额是最基础、且不可拆分的事件。从SQL角度来看，下单金额sum(amount)是一个简单的聚合表达式。
• 业务限定
  统计周期约束了来源数据的时间跨度，其他过滤条件则进一步筛选出进入统计的数据，这些过滤条件即业务限定。该指标统计的线上订单为业务限定，其计算逻辑为order_site=1。
• 派生指标
  最近30天每个消费者的线上下单金额，就是派生指标。

Dataworks与Dataphin区别

区别1：产品功能不同
1、Dataworks，在阿里集团内部为大家所熟知的部分是D2，在阿里云则是数加平台的主体-数据工厂。DataWorks（数据工场）具备全栈数据研发能力（数据集成与开发、 生产运维调度、离线与实时分析、数据质量治理与资产管理、安全防护、数据共享与服务、机器学习、数据应用搭建）的大数据平台；
2、Dataphin，通过输出阿里数据中台实战沉淀的大数据建设体系OneData+OneID +OneService(产品+技术+方法论)，一站式提供集数据引入、规范定义、数据建模、数据研发、数据萃取的全链路智能数据构建及管理服务。
一句话总结： DataWorks具备全栈数据研发能力和机器学习开发能力的大数据平台,这是dataworks的优势，劣势就是不具备数据中台(数据仓库)建设方法论的指导； Dataphin具备完善的“OneData+OneID +OneService(产品+技术+方法论)” 数据中台(数据仓库)建设方法论构建体系，这是dataphih的最大优势，劣势就是不具备很强的全栈数据研发能力，暂时也不具备机器学习开发能力。

区别2：产品定位不同
1、Dataworks 定位为大数据开发平台，ETL、数据仓库建设等对开发者不做任何限制。开发者可以利用dataworks做任意想做的工作，数据中台(数据仓库)构建的方法论也不做任何限制。开发者可以利用dataworks，既可以按照维度建模理论构建数据中台(数据仓库)、也可以按照范氏建模理论构建数据中台(数据仓库)、也可以按照E/R理论构建数据中台(数据仓库)，灵活性是dataworks的优势之一，当然也是劣势之一。因为缺乏数据中台(数据仓库)建设方法论的支持，dataworks对于缺乏数据中台建设方法论经验的开发者(或者企业)不够简单易用；
2、Dataphin 定位于输出阿里巴巴数据中台方法论，开发者严格按照基于阿里多年零售经验的维度建模理论构建数据中台(数据仓库)。“设计即开发”，这是dataphin坚持的核心理念，使用dataphin的时候，开发者需要严格定义业务板块、数据域、业务过程、维度、原子指标、派生指标，然后“傻瓜式”地构建数据中台（数据仓库）。开发者可能都不用写任何代码(甚至连sql都可能不用写)，只要按照上述维度建模方法论完成所有设计，即可构建数据中台(数据仓库)。—-

区别3：实时计算能力
不论是dataworks还是dataphin，均定位于离线批量开发能力。对于实时计算能力的支持，dataworks比dataphin稍微更强一些。利用dataworks集成的datahub+flink等工具能力，能够实现一些简单应用场景的实时计算能力； dataphin也在规划实时计算能力，预计再过几个月，dataphin最新版本也能实现一些简单场景的实时计算能力。

【总结】
1、如果开发者(或者企业)希望傻瓜式的构建数据中台(数据仓库)，而且是借鉴阿里基于零售业务积累的“OneData+OneID +OneService”方法论构建维度建模体系的数据中台，那么dataphin是不错的选择；
2、如果开发者(或者企业)希望购买一套全栈数据研发能力的大数据平台，涵盖完善的数据集成与开发、生产运维调度、离线与实时分析、数据质量治理与资产管理、安全防护、数据共享与服务、机器学习、数据微服务应用搭建等能力。而且数据中台(数据仓库)不限制于维度建体系，那么dataworks是不错的选择。