WEBVTT

00:00:00.000 --> 00:00:10.500
[음악].

00:00:10.500 --> 00:00:11.910
>> 안녕하세요 다시 오신 것을 환영합니다.

00:00:11.910 --> 00:00:14.970
제 이름은 JRJ이고, 저는 여기 있습니다.
중 하나에 대해 알려주십시오.

00:00:14.970 --> 00:00:18.915
가장 간절히 기대되는
SQL Server 2019의 기능,

00:00:18.915 --> 00:00:21.285
이것이 바로 데이터 가상화입니다.

00:00:21.285 --> 00:00:23.175
데이터 가상화란,

00:00:23.175 --> 00:00:25.440
왜 그렇게 간절히 기대되는가?

00:00:25.440 --> 00:00:27.510
글쎄, 간단히 말해서,

00:00:27.510 --> 00:00:29.510
데이터 가상화를 통해

00:00:29.510 --> 00:00:31.670
모든 데이터를 함께 가져올 수 있습니다.

00:00:31.670 --> 00:00:35.780
쿼리 시간을 할애할 필요 없이
복잡한 ETL 파이프라인을 구축하여

00:00:35.780 --> 00:00:40.535
통합할 수 있도록
단일 쿼리의 데이터입니다.

00:00:40.535 --> 00:00:44.150
그래서 내가 할 거야
가기보다는

00:00:44.150 --> 00:00:47.540
데이터의 세부 정보를 통해
개념적 수준에서 가상화,

00:00:47.540 --> 00:00:49.730
난 그냥 보여줄게
의 차이점

00:00:49.730 --> 00:00:52.430
로컬 쿼리와
가상화된 쿼리,

00:00:52.430 --> 00:00:55.085
모두 부분적으로 완전히 가상화.

00:00:55.085 --> 00:00:56.280
그렇게 하려면,

00:00:56.280 --> 00:00:58.010
우리가 할 일은
우리는 전환 할거야

00:00:58.010 --> 00:01:00.270
이제 Azure 데이터 스튜디오로,

00:01:00.270 --> 00:01:03.035
그리고 당신은 내가 여기에서 볼 수 있습니다
통합 문서를 열고,

00:01:03.035 --> 00:01:08.990
그리고 들어가서
평가를 시작합니다.

00:01:08.990 --> 00:01:13.625
그래서 여기 당신은 내가 볼 수 있습니다
매우 간단한 쿼리가 있습니다.

00:01:13.625 --> 00:01:17.030
나는 두 개의 로컬이
데이터베이스의 테이블,

00:01:17.030 --> 00:01:19.160
그리고 그 쿼리를 실행하면,

00:01:19.160 --> 00:01:23.405
당신은 결과를 상상할 수
좋은 빨리 돌아온다.

00:01:23.405 --> 00:01:25.190
나는 약 1 초가,

00:01:25.190 --> 00:01:28.045
내 데이터 집합을 가져옵니다.
노트북에 다시 들어오게 됩니다.

00:01:28.045 --> 00:01:31.630
그러나 이 모든 것이
데이터가 SQL 서버에 있지 않았습니까?

00:01:31.630 --> 00:01:36.200
해당 데이터가 실제로
원격 SQL 서버에서 사용할 수 있습니다.

00:01:36.200 --> 00:01:40.145
우리는 이 에 액세스하고 싶었습니다.
동시에 모두 데이터?

00:01:40.145 --> 00:01:43.700
글쎄, 당신은 데이터 가상화를 사용할 수 있습니다
그 문제를 해결하기 위해.

00:01:43.700 --> 00:01:45.050
그러나 그것을하기 위해,

00:01:45.050 --> 00:01:47.030
일부 메타데이터를 설정해야 합니다.

00:01:47.030 --> 00:01:50.510
그래서 우리가 해야 할 첫 번째 일
마스터 키를 만드는 것입니다.

00:01:50.510 --> 00:01:53.720
마스터 키는 내부키입니다.

00:01:53.720 --> 00:01:55.910
우리가 보호하는 데 사용하는 데이터베이스

00:01:55.910 --> 00:01:58.660
그 안에 있는 다른 모든 메타데이터.

00:01:58.660 --> 00:02:03.380
메타데이터에서 볼 수 있습니다.
우리가 사용하고있는 알고리즘은 여기,

00:02:03.380 --> 00:02:06.110
생성될 때, 그리고
그런 흥미로운 것들.

00:02:06.110 --> 00:02:10.745
이제 PolyBase를 활성화해야 합니다.
기능을 사용할 수 있도록

00:02:10.745 --> 00:02:16.310
원격 소스 에 액세스
및 원격 데이터베이스,

00:02:16.310 --> 00:02:19.220
데이터베이스 자격 증명을 생성하여

00:02:19.220 --> 00:02:23.495
인증할 수 있어야 합니다.
이러한 원격 소스에 대해

00:02:23.495 --> 00:02:28.835
그리고 당신은 내가 본 것을 여기에서 볼 수 있습니다
과거에 몇 가지 를 만들었습니다.

00:02:28.835 --> 00:02:30.200
오라클의 부부로서,

00:02:30.200 --> 00:02:32.225
그리고 SQL의 몇 가지
뿐만 아니라 거기에 있는 것들.

00:02:32.225 --> 00:02:36.680
하지만 오늘, 우리는 갈거야
SQL 데이터 원본에 대해

00:02:36.680 --> 00:02:39.650
그리고 당신은 여기에서 볼 수 있습니다
그렇게 하기 위해,

00:02:39.650 --> 00:02:41.730
나는 을 만들어야합니다.
외부 데이터 원본을 참조하십시오.

00:02:41.730 --> 00:02:45.390
여기, 나는 내
위치, 이 경우,

00:02:45.390 --> 00:02:49.160
SQL 서버 주소
Azure의 어딘가에,

00:02:49.160 --> 00:02:51.874
그리고 그 자격 증명을 전달합니다.

00:02:51.874 --> 00:02:54.425
해당 인증을 활성화하려면
자리를 차지할 수 있습니다.

00:02:54.425 --> 00:02:56.590
그래서 가서 그것을 만들 수 있습니다,

00:02:56.590 --> 00:03:00.880
그리고 당신은 다시 볼 수 있습니다, 거기에
데이터베이스 내부의 메타데이터입니다.

00:03:00.880 --> 00:03:03.040
이제, 원칙적으로,

00:03:03.040 --> 00:03:06.290
나는 외부를 유지하는 것을 좋아한다.
정의하는 테이블

00:03:06.290 --> 00:03:08.465
이러한 외부 데이터 원본 개체

00:03:08.465 --> 00:03:11.210
내 내부 테이블과 분리,

00:03:11.210 --> 00:03:12.890
스키마를 사용하여 작업을 수행합니다.

00:03:12.890 --> 00:03:16.500
그럼 가자
외부 스키마를 만들고,

00:03:17.660 --> 00:03:23.350
그리고 지금 우리는 여기에 와서 할 수 있습니다
첫 번째 외부 테이블을 만듭니다.

00:03:23.350 --> 00:03:25.730
첫 번째 외부 테이블
우리는 만들거야

00:03:25.730 --> 00:03:28.240
웹 클릭 스트림은
는 첫 번째 테이블입니다.

00:03:28.240 --> 00:03:31.315
그리고이 경우는
팩트 테이블처럼,

00:03:31.315 --> 00:03:34.755
그리고 우리는 그것을 저장하려고합니다.

00:03:34.755 --> 00:03:36.490
그래서 그 외부 데이터베이스에서,

00:03:36.490 --> 00:03:38.375
우리는 정확히 동일한 데이터베이스를 가지고있다.

00:03:38.375 --> 00:03:44.200
우리는 단지 그것을 다시 사용하고 있습니다.
이 시나리오를 보여 줍니다.

00:03:44.200 --> 00:03:50.515
이제 프로세스에 착수할 수 있습니다.
클릭스트림 가상화,

00:03:50.515 --> 00:03:52.900
웹 클릭 스트림 테이블입니다.

00:03:52.900 --> 00:03:56.500
여기 당신이 볼 수 있습니다 내가
동일한 테이블 웹 클릭스트림,

00:03:56.500 --> 00:03:58.660
하지만 지금은 EXT 스키마를 사용하고 있습니다.

00:03:58.660 --> 00:04:01.060
그래서 외부 테이블에 액세스하고 있습니다.

00:04:01.060 --> 00:04:02.440
그러나 모든 의도와 목적에 따라

00:04:02.440 --> 00:04:05.630
나머지 쿼리
정확히 동일합니다.

00:04:05.630 --> 00:04:08.225
지금 해당 쿼리를 실행하면

00:04:08.225 --> 00:04:10.120
의는 이 걸리는 가정 해 봅시다
때문에 조금 더 이상

00:04:10.120 --> 00:04:12.100
우리는 갈거야 그리고
데이터를 원격으로 가져옵니다.

00:04:12.100 --> 00:04:14.905
그리고 당신은 그것이 말할 수
약 3.5초.

00:04:14.905 --> 00:04:17.260
그러나 우리는 우리가 가지고있는 것을 볼 수 있습니다

00:04:17.260 --> 00:04:20.785
해당 데이터를 여기에 있으며
그것은 정확히 동일합니다.

00:04:20.785 --> 00:04:23.710
그래서 후드 아래 모든

00:04:23.710 --> 00:04:27.065
완전히 투명합니다.
사용자로 나에게.

00:04:27.065 --> 00:04:29.920
이제 실제로 진행하면 어떻게 해야 합니까?

00:04:29.920 --> 00:04:33.250
두 번째 가상화
이 쿼리의 외부 테이블?

00:04:33.250 --> 00:04:35.680
당신은 첫 번째 기억
하나는 웹 클립 스트림이었다,

00:04:35.680 --> 00:04:38.905
두 번째
은 항목 테이블입니다.

00:04:38.905 --> 00:04:41.090
그래서 가서 그렇게 하자,

00:04:41.090 --> 00:04:45.650
그리고 지금은 둘 다
테이블이 가상화되어 있습니다.

00:04:47.290 --> 00:04:52.290
그래서 지금, 때 무슨 일이 일어나는지
이 마지막 쿼리를 실행합니까?

00:04:52.290 --> 00:04:57.565
이 마지막 쿼리는
정확히 동일한 쿼리를 실행합니다.

00:04:57.565 --> 00:05:01.670
하지만 둘 다 외부
테이블은 가상화되고,

00:05:01.940 --> 00:05:05.275
그리고 당신은 실제로 볼 수 있습니다
쿼리는 거의

00:05:05.275 --> 00:05:09.375
첫 번째 속도처럼 빠릅니다.
버전, 로컬 쿼리입니다.

00:05:09.375 --> 00:05:12.530
그런데 왜 그럴까요? 왜 우리는 얻을 수 있습니까?
성능의 이 차이는 무엇입니까?

00:05:12.530 --> 00:05:14.780
글쎄, 그 이유는
당신이 보는 경우에

00:05:14.780 --> 00:05:17.000
SQL 서버
충분히 지능적인 사용

00:05:17.000 --> 00:05:20.600
비용 기반 최적화 프로그램
이해하려면

00:05:20.600 --> 00:05:24.725
두 테이블은 모두 외부 테이블이며
그들은 같은 근원에서 온,

00:05:24.725 --> 00:05:28.400
그리고 그것을 볼 수 있습니다
이 조인을 푸시할 수 있으며

00:05:28.400 --> 00:05:32.030
집계 아래로
해당 원격 소스에 대해

00:05:32.030 --> 00:05:34.190
그래서 우리는

00:05:34.190 --> 00:05:37.445
해당 원격 소스를 해결합니다.
실시간으로 이 쿼리를 볼 수 있습니다.

00:05:37.445 --> 00:05:41.030
그러나 그것은 당신에게 빠른 개요를 제공합니다
기능의

00:05:41.030 --> 00:05:44.750
데이터 사용 중단
가상화 기술

00:05:44.750 --> 00:05:48.470
실제로 할 수 있는 방법
데이터를 투명하게 표시

00:05:48.470 --> 00:05:50.390
최종 사용자에게 돌아갈 필요 없이

00:05:50.390 --> 00:05:52.520
해당 데이터의 물리적 복사본을 만들고,

00:05:52.520 --> 00:05:54.410
이동하거나 빌드할 필요 없이

00:05:54.410 --> 00:05:56.420
복잡한 ETL 파이프라인은

00:05:56.420 --> 00:05:58.910
수 있도록 하기 위해
실시간으로 데이터를 쿼리할 수 있습니다.

00:05:58.910 --> 00:06:00.510
참여해주셔서 대단히 감사합니다.

00:06:00.510 --> 00:06:02.960
그리고 나는 잡기 기대
곧 다시 당신과 함께.

00:06:02.960 --> 00:06:17.560
[음악]